Forum Replies Created
-
Posts
-
Aha!
Try adding “freetype” to the “depends” array in modules/mojo/module.json.
I’ve used it a few times in c++, usually to prevent code from having to constantly check for null pointers in frequently called methods, eg: when incrementing/decrementing reference counts etc, eg:
1234567void retain(){if( this ) ++_refs;}void release(){if( this && !--_refs ) delete this; //doubly naughty!}This saves you the hassle of having to wrap ALL retain() calls in ‘if( blah ) blah->retain();’, eg: you can just use blah->retain(); (or blah->release() etc ) even if blah is null.
So I guess it’s useful for frequently used methods of classes that may have many null instances.
I can live without this if it’s causing people hassles, although it’s never caused me any problems in the past – the first field access will raise an exception anyway if the method tries to do anything with the instance.
Nope, can you post full output, or is it only trying to rebuild mojo?
Bad keycodes – just pushed a fix.
Is the file actually there?
Haven’t you had this problem before?!?
Tried rebooting?
Generic types are only infered from parameters. If a type can’t be infered from parameters, you need to explicitly specify it, which isn’t supported for operators so you’d need to use something like…
1Local car:=foo.Get<Car>( "Car" )…instead.
This is by design – Self can be Null for non-virtual methods.
> The immutable part threw me a little bit because obviously vectors are going to change if you use them to store coordinates for game objects and whatnot,
Terms like immutable, const etc aren’t very clearly defined in general, and the definitions of lots of stuff changes from language to language, so yes, that statement was probably a bit confusing!
By immutable, I mean the ‘value’ of something doesn’t change once it’s constructed – and in the case of structs, by ‘value’ I mean the value of any of it’s fields. So a ‘New Vec2(10,20)’ will always have x=10 and y=20. Therefore, any methods will not modify ‘self’ – if necessary, they will return a ‘New Vec2’ instead.
But a variable is not a value – it contains a value – so you can do something like ‘p=p+v’ where the types involved are all immutable. In fact, ints, floats, strings etc are all effectively immutable…
You don’t have to make structs immutable in mx2 of course, but IMO if something ‘looks’ like it could be implemented as immutable, it’s a possible candidate for structification.
Probably just confused things even more!
I was looking at my particle engine and wondering where I can use structs,
Depending on how your particles work, there’s actually a really good use case for structs, and that’s to use a circular queue.
This only works if your particles have a ‘fixed’ timeout, in which case you’ll always be adding N particles to the front of the queue and removing N particles from the end.
In this case a ‘particle buffer’ can be implemented using a simple array of structs, with ‘put’ and ‘get’ pointers (ie: indicies).
You can use canvas.DrawPrimtives to draw the particles in one ‘hit’ too. You’ll have to do this twice, as the buffer will be ‘wrapped around’.
Did this myself in c++ a while back on the Ouya and got 30,000 odd particles flying around at 60FPS – not bad for the Ouya!
Why is MX2 so much faster? Is it just that c++ compilers have come a long way and BMX compiler hasn’t updated to take advantage of any additional CPU trickery?
More or less. C++ has been under development for much longer than bmx, and has had many extremely clever people working on it! It would have been faster than bmx even back when bmx first came out…
After looking through a bunch of ASM the other day, I’d guess the biggest factor is function inlining. C++ does this amazing well, to the point where trying to read ‘-O3’ generated code is almost impossible! Even stuff like internal string and array constructors are inlined – that silly cstring->bbstring conversion was inlined too (shouldn’t be really – that’s going a bit too far), which initially made the ASM code look like complete garbage.
And mx2 can help out even more here. Currently, all generated code ends up in the cpp file which means it can’t be inlined so only ‘system’ code is currently inlined. But eventually, I’ll be moving some of the generated code to the .h file so it can be inlined too.
> This article can be interesting in those CPU consumption thoughts… though tests are made in C# so it’s maybe not comparable to C++
That article looks incredibly dodgy to me. Without seeing the actual code they’re testing, there’s no way of telling it’s not just the authors doing some stupid. Some of the results sound highly suspect to me, but then again, I don’t know much about the inner workings of C#. Not much of it would apply to c++ though.
It would be really nice if we can compile some guidelines when structs are preferred over classes and when not. I’m struggling with that kind of stuff.
Google for more advice, but I generally only use them for simple, often ‘mathsy’ types that are more or less immutable (ie: once they’re created, their fields don’t change). Things like vectors, matrices, complex numbers etc. are all pretty good candidates for structification.
Structs also have some limitations that will help you decide…
- They can’t be extended.
- They can’t have virtual methods.
- They are copied ‘by value’ so can be expensive to pass to functions or to assign to (although inling will ultimately help here).
- They can’t (easily) be referred to indirectly.
The last can be solved in a number of ways – you can create a ‘pointer’ class that contains a struct and pass that around, effectively passing a ‘reference’ to a struct around. But I think if you end up having to do this, you’re probably misusing struct and should just use a class instead.
You can also create an array of structs and use an int index as the ‘reference’, giving you a form of indirection.
You can also use Varptr – nasty/dangerous!
The builtin types like int, float, string are effectively structs, so you have much the same choices for indirection as you do for the builtin types.
Alrighty!
BMX sort of flicks up to 10 every other second, I wonder if that’s the garbage collector cleaning things up?
Quite likely. Mx2 uses an incremental collector so it collects garbage as it goes, whereas bmx collects everything in one hit when it reaches some threshhold, and you get a ‘bump’ ala Java/C#. The incremental system actually ends up taking a bit more time in total, but I think it’s worth it for the smoother performance.
Next think I would suggest looking into is perhaps using a struct for vector2d instead of a class. This would reduce GC overhead even more, as structs are created ‘on the stack’. Structs take a bit of getting using to – the semantics are fairly different from classes – but in some situations they are very efficient.
Oops, try again. mx2cc was making console apps by default – now changed to gui apps for compatbility with ted1. Trying to access assets from a console app on macos will not currently work.
Also moved the v010 tag.
V010 now pushed!
Some things have been moved around (eg: build scripts are now in /scripts) as I’m in the process of getting it all ready for a release, hopefully by the end of the month.
Found it I think!
I haven’t tried the bmx version, but the mx2 version has gone from 570,000/sec on my machine to 3,700,000/sec!
The problem was my implementation of DebugAssert. It was evaluating the string param even if the condition param was true – even in release mode – and one operation that uses DebugAssert is the array indexing operator in bbArray (to check the array index isn’t out of range).
This meant that *every* use of array[blah] in an app has been doing a cstring->bbstring conversion of “Array index out of range” behind the scenes, which involves strlen, malloc, strcpy etc. I’m actually pretty impressed by how well stuff was running with this going on.
This may also explain the slow DrawLine, as each vertex added involves 7 array index ops so 40000 lines=560000 completely unnecessary cstring->bbstring ops.
Looking forward to fixing this properly tomorrow!
I had a quick look at this and there does seem to be some kind of weird overhead (on my windows machine anyway) with the line drawing (and nothing to do with GL either…) – will investigate. Ethernaut’s mac performance suggests this may even be a compiler thing.
I also had a go at comparing the mx2/bmx code quadtree code, but they seem to use slightly different algorithms – the bmx one looks like it uses a ‘leafy’ tree, whereas the mx2 one has objects stored in nodes too. It may or may not make much difference, but it makes it harder to compare the 2.
Without the rendering code, the 2 have similar performance although the bmx one is a bit faster – but it’s using a different algorithm and the mx2 one does a bit more, so it’s hard to tell what’s up.
Just to clarify, we’re talking about what happens when a constructor (and only a constructor) calls an overridden (ie: virtual) method.
The mx2 behaviour might yet change before V1.0, but in general it’s not a good idea for a constrcutor to call an overridden method. I think this sums it up best:
https://msdn.microsoft.com/en-us/library/ms182331.aspx
