While I generally don't think MMF2 is at all well-suited to making 3d games, I though it would be interesting to experiment with some ultra low resolution 3D voxel models, just for a bit of fun.
First things first - I needed a model to work with, and so I made this little Sopwith biplane, just like in the classic game "Sopwith", but in glorious technicolor and 3d:
To start with, I just followed the ingenious article here: http://www.create-games.com/article.asp?id=1933
I was actually quite happy with the results I got, using just low quality rotation and no anti-aliasing:
Unfortunately, the problem with this method is that although the model looks 3d, it can only rotate about one axis - which is going to seriously limit the kind of aerobatic manoeuvres our little Sopwith is capable of.
So, the next thing to try was storing the position of every single pixel (or "voxel" rather, since we're talking 3d now!), and doing complicated rotations on them.
Normally, when people use voxels, they're actually using proper cubes - but that would be an awful lot of work, so instead I'm just using individual pixels. That could have presented problems, since a pixel is a fixed size, and things generally get smaller the further away they are, so to get around this I'm using a parallel projection (like with isometric graphics) where there is no perspective and foreshortening.
Visually speaking, the results were not great, but if you squint, you can just about tell it's meant to be a plane:
Unfortunately, even a tiny model like this contains a whopping three hundred voxels, and when you're doing complex 3d calculations on 300 points each frame, that doesn't make for good performance - by which I mean the framerate dropped to 10fps.
I'm sure there are ton of major optimizations I could make that would improve performance, but it's probably never going to be fast enough to use in a game. The one thing that might make a big difference would be to use a scripting extension such as Lua.
The last thing which I haven't tried yet, but feel might be worth a shot, would be to use the first method (the one in the article by 3kliksphilip), but combine that with hardware accelerated scaling / stretching of the individual slices, to give the impression of true 3d rotation. That way, my Sopwith model would be made from just 9 slices instead of 300 voxels, and the complex rotation maths could be handled by the graphics card.
Anyway, just thought I'd share what I've been up to...
Watching that movie is the same place i found out about fez. And I have come across a lot of people who found it the same way. Makes me wonder just how many people here have netflix accounts ...lol
This is pretty neat! I do figure it's very taxing to calculate positions for every pixel in 3 dimensions. Couldn't you do this with a shader instead and just skew the textures? It wouldn't really be volumetric, but it would achieve the same effect you've got there, at that scale. Or is it that it was intention to make a voxel/3dpixel based engine?
If so, it would be interesting to see if you can translate this to the surface object, or even the textblitter. I guess the textblitter would be faster since all the blitting happens in c, and you'd be able to use the callback functions to place characters bigger than 1x1 on the surface. Don't know exactly how the z-layering would work, though, since all characters are rendered from left to right and top to bottom.
Anyway, pretty interesting! I'd love to see where you go with this.
Edit: Actually, it would be 100x better to do that with a shader, if one exists that's basically a reproduction of the surface object in HLSL. At least one with which you can draw textures, or just shapes/vertices.
The surface object has a callback function and is actually pretty fast - the bottleneck at the moment is all the calculations. I can remove the drawing events altogether, and it only raises the framerate by around 2fps.
The aim is to create a true 3D voxel engine, so simply skewing one image wouldn't cut it. If someone wanted to make a Fez clone though, that would be easy and fast using shaders.
Shaders might still have potential, but I can think of a few problems. It would be nice if the whole plane could be made from one object, with each of the slices as a shader image parameter. Unfortunately, I don't think MMF2 supports multi-pass shaders, which would make this impossible (no way to handle depth sorting).
Even if it were possible, if there were multiple voxel objects in a frame, it wouldn't be possible to sort them correctly (imagine a voxel landscape, where the nearest part is in front of the plane, and other parts are behind it), and you'd still need some way to handle collision detection, etc.
Really, I think the main reason it's slow (apart from being badly coded) is that MMF2 lacks any suitable data storage object - that's why I'm confident a scripting extension would make a big difference, and is probably what I'll be trying next. In fact, I might just ditch MMF2 for a while, and see what kind of performance I get using Javascript and the canvas element, since I don't remember Lua any more...
I don't really have a proper editor yet - just a tiny and very ugly app that scans an image and writes the coordinates & color of every pixel. I'll definitely need to make a better one before I move onto larger models.
Anyway, as promised, I've made an all Javascript / Canvas version, and it runs a *lot* more smoothly than the MMF2 version:
You can try it for yourself here: http://sdrv.ms/1aTwaAp (click "download" at the top; best viewed in Opera 12 - it looks bad in Chrome, as I haven't been able to disable anti-aliasing when scaling the canvas)
You can render your GFX with this voxels engine, come up with a dozen or so different explosions and whatnot for the player and enemy planes (AND the enemy cow), then use the graphics in MMF2 to build your Sopwith clone.
I was thinking that too - it would be handy for animating barrels rolls and maybe the odd cutscene. I'd quite like to make an HTML5 game anyway though. And of course, if you want to just pre-render voxel graphics, there are already good editors out there.
Anyway, I've just started on a course (with a *lot* of homework), so my time is likely to be rather limited for the next little while, and I probably won't be doing much of anything.
I still think MMF2 will be able to handle it via a scripting extension - it's really just the lack of sortable multi-dimensional arrays that's causing problems.
Firefox is soooo slow. Opera 12 is the best of both worlds - the speed of Chrome and the scaling options of Firefox. It's such a shame they ruined it by switching to webkit.
Are you still dabbling in HTML5 games? I learned a lot from your articles on the subject.
I'm finding non-accelerated Canvas a bit slower than I would like, so I'm considering making the move to WebGL, but it looks crazy complicated, requiring lines and lines of code even for the very simplest of tasks, like drawing a square.
Well, I've tried the MMF2 & Lua combo...
I'm getting 300+ FPS with just the small Sopwith model, which is pretty good - but it's dropping to just 45 FPS with the larger Hellcat
What I'm now thinking, is that the original Sopwith game only ran at a very low framerate (something like 15 FPS iirc), so maybe I could create kind of a 3D clone (maybe even with CGA graphics).
Ah, well if you ever find a simple way to do stuff with WebGL, feel free to write another article...
Even the simplest example I could find (doing nothing more than drawing a triangle and a square) was pretty long - http://learningwebgl.com/blog/?p=28
I don't want to use a library, and I'm actually still only really interested in using it for 2d stuff.
Anyway, I've nearly finished a B24 Liberator, to go with the Hellcat:
Thanks
It's a shame this doesn't seem to have any practical applications - at least not in MMF2.
Unfortunately, I really don't have the time for it right now - I'm really just here procrastinating, because writing essays on government legislation and various policies & procedures relating to child protection in schools, is making me lose the will to live.