Forum Replies Created
-
Posts
-
Use classes, not structs, for reference types!
Structs are not designed to be used ‘by reference’. Yes, you can Varptr them, but as you’ve found, as soon as they are assigned to something, passed to a function or returned from a function (which is what they’re designed for) the old Ptr becomes invalid. The intended use for Varptr with structs is really for interfacing with c/c++.
Varptr Self is esp. dangerous, as the code has no way of knowing if ‘Self’ is temporary or not. Self could refer to a local, a temporary copy, etc that is just about to go out of scope, or it could refer to ‘safe’ heap memory, such as a class field, global or array element.
This is one of the primary difference between c++ and mx2. In c++, structs/classes are the same thing and can be used as either references types or value types depending on how variables are declared. But in mx2 (and c# and d), a struct is always a value type while a class is always a reference type. Not as flexible as c++, but IMO well worth the huge amount of simplification it provides.
It’s the max length from the image handle to the bounds vertices.
If the image handle is 0,0, then Radius will indeed be the diagonal length. But using a handle of .5,.5 will halve the radius etc.
The idea with Radius is to provide a quick ‘worse case’ radius value for culling/colliding rotating images.
Ditto ‘Bounds’ can be used to cull non-rotating stuff. Both also take the ‘static’ image scale into account.
There’s no ‘clean’ way to do this as yet.
Be careful with Ptr/Varptr, as they can potentially blow up you program if you’re not careful!
Are there other “gotchas” you’d have to think about?
Don’t think so…
The garbage collector gets involved whenever you call ‘new class’ or ‘new blah[]’. Also, if you ‘Slice’ an array or somehow create a new array, eg: with String.Split().
Strings aren’t GC’d but still need to be malloced/freed.
Would be cool if someone explain the need about structs.When do you need them and are the a lot faster then a class ?
They’re really just another tool and it’s up to you when to use them!
I like to use them for small-ish data structures that are frequently duplicated, eg: things like ‘Vec3f’ that might be used in complex-ish mathematical expressions such as v=v*scale+offset.
If Vec3f were a class, such expressions would involve considerable memory management overhead. Not so with structs where new values just go on the stack and are pretty much free to create. The downside is the struct contents need to be copied, but this is likely to be true no matter how you write Vec3f as each ‘operation’ usually needs to modify all members.
re: the docs – is this any better?
A struct is a ‘value type’, whereas a class is a ‘reference type’. This means that when you assign a struct to a variable, pass a struct to a function or return a struct from a function, an entirely new copy of the struct is created. This can be expensive if the struct is large as it involves copying every field from the source struct to the copy. The up-side is that allocating a copy does not involve garbage collection as all copies are created on the stack.
> shape.image = tlShape.LoadFrames(url, frames, width, height, flags)
You’re missing the ‘padding’ param. Should implicit enum->bool be disallowed?
If that’s not it, can you post the lib code?
‘asset::fonts/’
Except it’s not – it’s just ‘fonts::’ eg:
Local font:=Font.Open( “fonts::myfont.ttf”,16 )
Meh, not really bothered mainly just wondered whether other people found it weird too – the physical dir is called ‘assets’ but you access it with ‘asset’.
although it was wdw.game2d then
I prefer that.
I’d call it ‘wdw-game2d’ and put everything in it in a wdw.game2d namespace – ie: just put ‘Namespace wdw.game2d’ at the top of each module file.
If you add more modules in future, you can call them wdw-core, wdw-this, wdw-that etc.
Users only have #import the wdw-blah’s they need, and can use everything in wdw with a single ‘Using wdw..’
They goal here is to have a TON of modules available in one place – not just a bunch of modules distributed randomly around the ‘net ala bmx, mx1 – so I’d like them to be reasonably distinctive namewise to avoid potential collisions.
> Putting all my names under one top level name turned out to be a chore though
In what way?
…published for now anyway!
I think the name ‘game2d’ is a bit generic for a module.
Modules names should have some kind of ‘proper noun’ identifier in them, like ‘mojo’ or ‘diddy’ or ‘lua’ etc – perhaps’ weibow2d’? The namespace can stay the same, although keep in mind that the top level namespace introduces a global-ish symbol, so you don’t want it too ‘generic’, like ‘x’ or something! But for name, it’s the module name I’m mostly worried about.
Does that make sense or am I being too paranoid here? It’s just that the goal is to have LOTS of modules so we want to avoid name clashes as much as possible.
Or should it all be strictly first come first served?
Yes, will clean up json output soon…
Yeah, the fiber stuff is pretty cool – especially now with the low-level fiber switch asm code from boost.coroutine.
It works kind of the opposite of C# which provides generators which can be contorted into coroutines, while mx2 provides coroutines that can be contorted into generators!
Should I add the Generator<T> class to std.fiber? Is it useful enough? I’ve certainly been thrashing the Future<T> class in ted2/mojox so that’s staying, but I haven’t needed a generator so far – or maybe I just don’t know when they’d be useful.
I do plan on taking on ‘real’ threading one day, but it’s a BIG job and there’s still a ton of smaller jobs to be finished. And in the meantime, fibers help reduce the need for threads to a degree. I have some thoughts on how real threads could work too, might share some of them later and try to get some brian-storming going.
You shouldn’t need it so I don’t know what’s up there – will have a look.
NOT GOOD MARK!
Chill out guy – it’s a dev repos and there WILL be issues.
Returning const char * to monkey2
This side of things is still a bit nasty, but for now I’d suggest make the function return a pointer to one of the char types in libc, eg: libc.char_t Ptr, libc.unsigned_char_t Ptr or libc.signed_char Ptr (I will probably also add const_char_t, const_signed_char_t etc).
Then use String.FromCString() or String.FromUtf8String() to convert the pointer to an mx2 string.
Add a -Ddefine to compiler flags when building a module’s .c and .cpp
You can’t yet, although you can hack the env_blah.txt file to force the define everywhere. I want to come up with a better way to achieve this rather than abusing #import ala bmx, but until then…
I am hacking #define into appropriate header so they build properly.
…is probably your best bet and what I actually what I’ve done for several modules.
What is state of audio modules?
Pretty good IMO!
Does openal mean sdl2 mixer should be deprecated.
I wont be using it myself for mojo.audio, but I don’t see why it can’t be left in there for others to use. Note also that AppInstance no longer inits SDL_AUDIO, but I probably don’t have to do this.
Does emscriptem have audio and how?
It has openal ‘built-in’. No fibers though, so no WaitQueued(). NumQueued can probably happen so you should eventually be able to poll.
Can monkey2 call webgl / webaudio/ webmidi directly for web?
Don’t see why not. #Import js might be useful here? Not in right now though.
> Especially the Cast operator that let you use p as an array. Is that some kind of pointer arithmetics?
Since pixels can be stored in a number of different formats, PixelPtr just returns a general purpose ‘UByte Ptr’ and leaves it up to you to cast it to the correct type (if you need to).
Our pixels are UInts, so the cast converts this to a ‘UInt Ptr’. It’s still just a pointer though, and it will have have the same value. It’s just that when you do math with it (eg: index it with the [] operator, or add/subtract to/from it) the fact the pointer is a ‘UInt Ptr’ will be taken into account. For example, p+=1 where p is a ‘UInt Ptr’ will actually add 4 to p, because UInts are 4 bytes long.
