MHGames

After a long break I’ve started working on the platformer engine again. I’ve added a material system, where every level shape (i.e. polygon) has a material assigned to them, which defines the texture and physical properties (friction, restitution and density) for the shape. Later on this could be used to trigger different sounds or other effects based on where the player walks, for example.

I improved the lighting system to support rotating lights and finally enabled them to be placed to the level in Inkscape (the lights were previously completely randomly generated). To test these new features, I abandoned the ugly mess of a test map I had been using from the start, and built my first “real” level. It’s not too detailed yet (and yes, ugly in some points too!) but at least it’s better than some random polygons. I do plan to expand it to test new features as they get implemented. Check out these screenshots to see the brand new level in action. Disclaimer: All the textures etc. and even the whole style are temporary and not representative of the final game (if I manage to complete it some day), purely because I have not decided on the final style yet! I may opt for more stylished visuals, as in not using “realistic” (photograph based) textures, contrary to what you see in these images. But as I said, I’m not sure yet.

Speaking of new features, I added support for “floor shapes” – shapes that act as a floor but not as a ceiling. That means you can stand on them but jump through them only from below. You can also drop down when needed. These things are so common in platformers, so I had to have them in. Unfortunately I had to restrict them to be straight horizontal lines – “floor lines” like I call them in the code – due to technical difficulties with the Box2D physics. At first I tried doing this with Box2D sensors/contact listener but it seemed like a bad hack and would probably have not worked correctly in some cases, so I deemed it too much trouble and went for a simpler approach. My biggest gripe with Box2D is actually the contact listener, it’s somewhat hard to use it nicely..

One of the things I’ll start coding next is sprites, which will be used in several places: as normal level decoration, level decals, in the background and so forth. Currently everything you see is crafted from polygons, which is wasteful on the resources. In the current test level, at least the mailbox, arrow sign and mushrooms should be sprites.

That is all this time (got to run to the school soon.. :/), stay tuned for more!

Before getting carried away with the platformer rambling, again, here’s something about PolyAnim. Yesterday I added automatic polygon triangulation for concave polygons into PolyAnims LWJGL-renderer. This is mainly for convenience, since the triangulation is quite expensive – it remains to be seen if this is fast enough for more general use. At least with simpler scenes it might work alright. Convex polygons should still be preferred for speed reasons, but I admit it: they’re major pain in the ass when animating. It’s cumbersome to build and animate non-convex shapes from several convex pieces.. Hopefully somebody will contribute faster triangulation code at some point!

What else.. I’ve been working a lot on the platformer engine. JBox2D got an update, so I ditched the old polygonal approach (which had a lot of problems, as Box2D is very picky about the shape of the collision polygons) and implemented the collision geometry using the new feature: edge chains. They work nicely and are just perfect for this kind of usage. I use triangulation with convex decomposition now only for the renderer, which luckily doesn’t mind very thin triangles. I’ve added more eye candy as well, generation of level outlines and support for background/foreground polygons (which are not collidable, of course). I still need to implement other decoration elements, such as a stripe of grass blades running along top edge of things, for example. Parallax scrolling is something I want to have in too, I mean, if you’re making a side scroller, why shouldn’t there be parallax scrolling!?

And finally I did bite the bullet and implemented those damn PBuffers (enjoy the picture there, that’s them buffers giving me hard time!). They work okay when FBO is not available, but they’re yucky to code. Luckily LWJGL makes it a bit less painful than it truly is. Looking back, in Funguloids things were almost too easy, as I had Ogre at my disposal! Along with PBuffers the thing now supports plain old frame buffer copying as well, though I couldn’t be bothered to make bloom work with it (lighting does, though, which is more important anyway).

While fighting with PBuffers, I noticed I could make the bloom much faster and more importantly allow for more shader effects if I used RTT (render-to-texture) same size as the screen dimensions. I could then render the scene only once to the RTT (currently I have to render twice!), have bloom shaders use that and actually do the final additive composition in the fragment shader too. Having a screen sized RTT would allow some neat shader effects like screen distortions and shock waves. There’s one problem, many cards don’t support rectangular (non power-of-two) RTTs.. The solution: separate rendering paths. I would implement several render paths with varying amount of shader and RTT usage, then determine what the host system supports and have things running nice and solid. Sounds like bit of work to me, but I guess the end results would be worth the trouble. We shall see.

Oh, and I’ve finished my bachelor’s thesis, like a month ago. Forgot to mention that earlier. Now I’d need to decide if I continue to write master’s thesis on the same subject, or choose something completely different. If only I could think of a subject having to do with game programming, that would certainly help with the motivation..

In the last post I talked about lighting, this time it’s shaders and more specifically bloom. I must say I like the effect when it’s used subtly as a mood enhancement and dislike it in it’s quite common burn-your-eyes-out -form..

For the platformer game I’m planning to use the effect for a nice and quiet dreamlike feel, although I’m still not sure what kind of game it will be (except that it’s a 4-way scrolling platformer!).. And as I often do, I find myself getting carried away doing all sorts of graphical effects (lighting, shaders) when I don’t even have the basic game mechanics in place! Can’t help it though, I must have some eye candy going on to keep myself motivated in a project. *shrugs*

So I coded a quick & dirty shader support to the engine, and today I’ve been trying to get the bloom working. And now it does. I’m still not done with it, needs some tweaking – and that’s somewhat impossible right now since I have no final assets for the game yet! Everything you see in those screens is temporary and/or random. For anyone interested, here’s some technical details on the subject.

I based the implementation on the GLSL bloom shaders from Funguloids, which in turn are modified from Ogre sample shaders. I’m still a beginner with the shader programming as I may have mentioned, so having anything to work from was invaluable. I tweaked the shaders to get the subtle look I was aiming for.

I’m using two small render textures (which are FBOs, no support for Pbuffers yet – and I think I’ll have to do those at some point, as my laptop doesn’t support FBOs), 128×128 in dimension and one bigger 512×512 RT. I render the scene normally to the bigger RT. The blurring is then done in two passes: first the scene RT gets rendered to 128×128 RT #1 using a horizontal blur shader (it also does some luminance stuff to have the bright parts more bright and dim parts more dim). Then RT #1 gets rendered to RT #2, this time with a vertical blur shader. Finally the RT #2 contents are blended additively over a normal 1:1 render of the scene. It needs quite a lot of tweaking, but I think it looks quite nice now.

In another news, my thesis is now almost complete! ^^

Wouldn’t you know, after I complained about lack of coding motivation in my last post, I started hacking at my Java platformer engine the very same evening! I finished the Inkscape SVG importer, now I can create the levels in Inkscape using polygons, rectangles and circles.

Last couple of days I’ve been implementing a lighting system to the engine (and preliminary scripting support before that). The lighting system is based on very simple ideas and was quite easy to implement. No troubles whatsoever, I was actually surprised. First I was contemplating on doing it using pixel shaders, but that would’ve required much more work (still learning the shader stuff) and I’m not sure if I could have pulled it off anyway. I still need to incorporate some shader support to the engine if I want to have a bloom effect later on.. Pixel shader lighting would have allowed to have normal maps for the textures though, now that would have looked very nice if done properly! Oh well.

Instead I went for texture based approach using a single FBO (Frame-Buffer-Object) where the lights get rendered to (additive blending naturally). Then with help of some stencil buffer magic, the light map is rendered over the scene using multiply blending. Stencil buffer is needed because it makes no sense to render the lights/shadows over the background (i.e. sky in my platformer). That would be very unrealistic (you can’t really cast shadows on the sky, now can you?) not to mention ugly. For top-down games no stencil buffer would be needed, unless the area that gets lit must be restricted somehow.

This technique allows completely dynamic lights of any shape (like flashlight cones) using one render-to-texture (FBO in my case). The light map doesn’t even need to be large, since (at least with soft lights) it’s hard to see the difference between 256×256 or 512×512. I’m using 256×256 currently, but even 128×128 looks fine. The system works nicely and I’ve yet to optimize anything about it: for starters I’m currently rendering each light, no matter if they’re actually visible or not!

Overall it suits my purposes perfectly – carefully arranged lighting can make a tremendous difference in the feeling and apprearance of the game.

Here’s a few sample screenshots. Please ignore all the graphics etc., as the level is just random polygons and lights are literally randomly generated. And the background is lifted off Jewels.

You know what, after starting to write a simple editor to be used before the proper animation editor gets finished (not anytime soon..), I started to think – what am I doing? Why to make a crappy editor, while I could use something else to do the job, and way better (yet I hope and believe that the custom made editor will be the most comfortable way of creating the animations).

Once again, Inkscape proved its worth. SVG was relatively easy to parse (except the damn transformation matrix – I wasted hours searching for clues how to decompose the original scaling and rotation from the matrix, finally got it working though..), and the Inkscape layers turned nicely into animation key frames. It requires quite a lot of patience, and my conversion tool is dodgy to say the least, but it will enable the creation of animations for PolyAnim!

So I wasted more hours, and created the very first proper PolyAnim animation, in Inkscape. After seeing the animated dude moving on the screen, I felt very pleased about how it all turned out. Rare moments, those. Hell, I even made a video to celebrate the event! In case anyone would want to try the Inkscape route, I also wrote a tutorial about it.

Check out this screen shot from the demo, and compare it to the earlier shot a post or two back.. The biggest dude is the original, the others are rendered using the various render modifiers.