Sunday, December 10, 2017
Reproduced without permission from here Mark Sibly is going great guns as he enters final lap of monkey2 development.
Posted on December 9th, 2017
Well, it’s being a kind of quiet month in terms of flashy new features, but lots of ongoing ‘under the hood’ work has been done so it’s all good.
The mojo3d entity animation system is now (mostly) usable. All the bits are in place, the actual API just needs a few tweaks. You can now copy animators and ‘slice’ animations which is kind of equivalent to thd old ‘ExtractAnimSeq’ from Blitz3d. Check out the turtle and ninja samples in mojo3d-loaders to get an idea of progress. And thanks to ‘psionic’ yet again for the models (a real blast from the past!) which I have been tinkering with on and off for the last 15 years or so by now surely!
I would actually like to do lot more with animation. I have a very cool ‘game programming’ book by one of the devs of the ‘drakes fortunes’ games (of which I am a big fan) and, true to the drake games, it has an awful lot in there about animation! There’s lots of great stuff about effective animation blending techniques that do things like blending the lower half of a ‘crouching’ pose with, say, the upper half of a ‘firing gun’ pose. But alas, I think to realistically do any work in this direction I’d need to collaborate with an actual animator. And it’s not like I haven’t got a ton of other stuff to be working on too! But I am starting to get a bit desparate for quality media in general though. I feel like mojo3d *could* be producing some great results already, but I’m still stuck with ‘freeware’ media, much of over 15 years ago from the blitz3d glory days! Nothing with bump/metalic/roughness maps which I think is when things should starting look looking sweet. Oh well, patience…
And some big news! Simon Armstrong (‘skidracer’ to those in the know…) has commissioned me to write a vr system for use with mojo3d! He has set me up with a vive vr kit and I’ve been going nuts with it, it’s great! I did have an oculus dk2 a few years back, but vive is really quite a step up in terms of responsiveness and image quality (as I assume are the latest oculus units). And as many people have discovered, one of the coolest things about it is simply the ability to ‘wave your hands’ in VR space which IMO really does improve the feeling of ‘being there’ significantly. I am using vive’s openvr SDK for a mojo3d-vr module and already have some stuff going in the form of a little demo that features a ‘sea of rubber ducks’ floating around your head (the urge to ‘swat them away’ is really strong!) complete with simple primitives to represent the base stations and controllers. I have found the openvr SDK to be very clean and easy to work with, and it *should* work with oculus rift out of the box, although I have no idea if that’s really true or not. Here’s hoping… I’ll have more of a rant about vr in a later blog, there’s a lot to go into really.
There also plans afoot to get monkey2 onto steam, something I have long though was generally a good idea, as long as it didn’t have to actually involve me as I suck at that sort of thing. Simon has offered to help out here so I’m basically just gonna let him go for it. I’m afraid I can’t be any less vague than that right now though – more news as we make it up!
Apologies to the patreon supporters but there will be no ‘prebuilt’ release this month, as there really isn’t all that much in the way of ‘new’ APIs or anything like that. Plus, there is a pretty major overhaul of the opengl subsystem in there that couold potentially cause problems (although it hasn’t so far) so I’d really like to give it a bit more of a workout before declaring it ‘release ready’. Hopefully, there should be a really cool new years release instead (I hope – although it’s already the 10th!). And you can of course still just build monkey2 from source as easily (if slowly) as ever.
As for the new opengl system, the old ‘gles20’ module has been deprecated in favor of a new ‘opengl’ module. This means that, whereas previously monkey2 was more or less emulating gles20 on targets that didn’t support it natively (macos, linux…), monkey2 now emulates opengl on targets that only support gles20. For most users, this should have NO practical effect as this is all behind the scenes stuff. But if you are using ‘raw’ gl in any way, please use the opengl module instead of gles20. The functions should be the same (there are just more of them) except for glClearDepthf which is now just glClearDepth.
I did initially try to use ‘glew’ for this. Glew is a library that provides support for a ton of opengl extensions, and it almost worked as is except it couldn’t handle extensions (or the basic v1.1 gl functions) for angle, webgl and basically any ‘weird’ gl setups. On the other hand, SDL2 does this really well via SDL_GL_GetProcAddress which seems to work on all targets and with all flavors of GL drivers. So I basically converted glew to a version that uses SDL_GL_GetProcAddress to fill in all the GL function pointers and it works well. I’m only using the bits of glew up to opengl2.1, but it supports up to opengl4.5 or something and I’ll eventually add these too. I’m also only adding extensions on a ‘new to use’ basis too though.
I also had a hack at the icky ‘app config’ system. Previously, if you wanted to do something like use set the depth buffer bit depth, you needs to pass a StringMap to the AppInstance ctor, typically in Main. This meant only the app really got a shot at passing config to AppInstance which sucked, so I replaced it with a very simple, env var-like SetConfig/GetConfig system.
So the code to set depth buffer depth is now:
Currently, config for GL type setting must generally be done before AppInstance is created, but this will likely eventually change to before first window is created (not a whole lot difference) or maybe even optionally leave GL context creation up to the user. But the important point here is really that not just the app but ANY module can now set app config vars. For example, the mojo3d module can set default renderer, depth buffer config etc, so if you import mojo3d you automatically get sane defaults but can still override them if necessary.
Have a look at docs for std.filesystem.SetConfig for a list of current config settings.
Finally, you now create a ‘real’ opengl context on windows. To date, all opengl on Windows has gone through the ‘angle’ library ( which actually translates opengl->d3d9/11) but you can now do this to create a ‘real’ opengl context:
This should, in theory, ‘just work’ for all existing mojo/mojo3d apps on windows without messing anything up. It will likely be a little ‘less compatible’ so I’ve left “es” (ie: angle on Windows) as the default on Windows for mojo 2d apps. Also, you still currently need to ship the angle dlls without your app even if your app doesn’t actually use angle. This will be fixed ASAP. I’m hoping upgrading SDL2 to the latest version will magically fix several issues here, if not I’ll have to hack SDL2.
The main motivation for adding real opengl support was initially to support openvr (I didn’t think angle would work, and it didn’t) but it also turns out to be faster at some things. Not quite the ‘3 times’ speed up I proclaimed on twitter a while back, but it’s definitely about 3 times faster at instancing. Raw pixel rendering of course is the same as it’s the same GPU after all regardless of driver (ie: bunnymark’s about the same), but I suspect driver overhead is considerably less with real opengl vs angle.
Also of course, real opengl is way more powerful than gles20, although I will probably be limiting myself to gles20 features for now for the sake of as much cross-target compatibility as possible.
Also still a bit WIP but I just pushed to github yesterday is 64 bit support for windows. You’ll need to use visual c++ community edition 2017 for this (vs expresses doesn’t have 64 bit support?) and it’s currently implemented as a ‘global’ setting (see env_windows.txt) much the way MX2_USE_MSVC works so it’s kind of all or nothing right now, but it seems to work OK so far! I had to add 64 bit builds of openal.dll to the repos but apart from that there wasn’t too much drama involved. Still, you might want to give it a few days to ‘settle’ – I did push a version yesterday which wrote the ‘.o’ files to the root monkey2 dir! Should be fixed now, but I’m taking the day off dammit and if there’s anything else screwy in there it wont be fixed until tomorrow!