Triangular PixelsJournal entries about game development.
Don’t you hate it when you’re writing some new image loading or texture drawing code but don’t have any suitable test images? I always waste lots of time looking for a “nice” image to test with, and often end up drawing something with distict pixel values so I can pinpoint where any given image loading bug is. With that in mind I’ve spent a few evenings working on a proper “test card”.
Sometimes you get an idea that’s a little bit oddball but for some reason you can’t get out of your head and just have to run with it. This has been bouncing around my head for the last couple of days and has just been translated into code:
I plan to extend this somewhat to make it more useful, like having multiple (cross linked) pages of stats, a logging page containing trace messages, and possibly a resource/texture/rendertarget viewer as well. Any suggestions as to what else to (ab)use http for are welcome. 🙂
After I upgraded to a 720p display format (rather than just 800×600) the framerate took a little bit of a dip on my slower machine. Understandable really as it’s drawing quite a few more pixels – 921k rather than 480k in the worst case, ignoring overdraw. I’ve spent the last few days optimising the renderer to see how much of the performance I could get back.
Firstly, you’ve got to have some numbers to see what’s working and what isn’t, so I added a debug overlay which displays all kind of renderer stats:
The top four boxes show stats for the four separate sprite groups – main sprites are visible ones like the helicopters and landscape, lightmap sprites contains lights and shadows, sonar sprites are used for sonar drawing, and hud sprites are those that make up the gui and other hud elements like the health and fuel bars. The final box at the bottom shows per-frame stats such as the total number of sprites drawn and the framerate.
Most suprising is the “average batch size” for the whole frame – at only 4.1 that means that I’m only drawing about four sprites per draw call, which is quite bad. (Although I call them sprites there’s actually a whole range of “drawables” in the scene, water ripples for example are made of RingGeometry which is a ring made up of many individual triangles, but it’s easier to call them all sprites).
Individual sprite images (such as a building or a person) are packed into sprite sheets at compile time. In theory that means that you can draw lots of different sprites in the same batch because they’re all from the same texture. If however you’re drawing a building but then need to draw a person and the person is on a different sheet, then the batch is “broken” and it’s got to start a new one.
To test this out I increased the sprite sheet size from 512×512 to 1024×1024 and then 2048×2048. For the main sprites (which is the one I’m focusing on) this pushed the average batch count up from 5.3 to 5.6 and then 16.2. Obviously the texture switching was hurting my batch count – 16 would be a much more respectable figure. Unfortunately not everyone’s graphics card can load textures that big, which is why I’d been sticking to a nice safe 512×512.
However further investigation found that the sprite sheets weren’t being packed terribly efficiently – in fact packing would give up when one sprite wouldn’t fit and a new sheet would be started. This would mean that most sheets were only about half full – fixing the bug means that almost all of the sheet is now used. Below you can see one of the fixed sheets, with almost all the space used up.
Along with this I split my sheets into three groups – one for the landscape sprites (the grass and coast line), one for world sprites (helicopters and people) and one for gui sprites. Since these are drawn in distinct layers it makes sense to keep them all together on the same sheets rather than randomly intermingling them.
One last tweak was to shave off a few dead pixels on some of the larger sprites – since they were 260×260 it meant that only one could fit onto a sheet and would leave lots of wasted space. Trimming them down to 250×250 fits four in a single sheet and is much more efficient.
Overall these upped the batch count for main sprites up to a much more healthy 9.2, reducing the number of batches from ~280 to ~130.
Good, but there’s still optimisations left to be done…
I decided that the searching aspects of the gameplay are largely ruined by showing a larger area of the map at larger resolutions, so I’ve ruled that out as a possible way of dealing with multiple resolutions. Instead I’ve decided to pinch a trick from console games – the game world will internally always be rendered to a “720p” texture, and then that’ll be streched over the full screen to upscale or downscale to the native resolution as appropriate.
I say “720p” because (similar to how tvs do things) there isn’t a single fixed resolution, instead it’ll always be 720 lines vertically, and the number of horizontal pixels will vary depending on the aspect ratio. So someone with a 16:9 screen will have a virtual resolution of 1280×720, whereas those on 4:3 displays will have 960×720. In windowed mode the virtual resolution always matches the physical window size, so you still get nice 1:1 graphics when viewed like this. For fullscreen the streching may mean you’ll get some loss of sharpness but doing it manually in-game gives much better quality than letting the user’s TFT do the scaling.
The menus are also drawn over the top with a 720p virtual resolution, but without the render-to-texture step (they’re just scaled using the projection matrices). The HUD is the exception to the rule in that it’s always rendered over the top at the native resolution instead of the virtual resolution. This is possible since the components are all relatively positioned according to the screen edges.
Different aspect ratios are also handled tv-style in that anything less that 16:9 has bits of the edges chopped off. That’s not a problem as it’ll just make those with 4:3 displays a little more blinkered. And to avoid having to have scalable menus or multiple menu layouts I just need to keep the important stuff inside the center 4:3 area, which is easy enough now I’ve got red guidelines to mark off the areas for different aspect ratios.
I think it all works out quite nicely – the code stays (largely) simple because it’s all dealing with a single virtual resolution, the whole game looks better because it’s natively at somethingx720 instead of 800×600, windowed mode still looks nice and crisp with 1:1 sprites and everyone gets the game in the correct aspect ratio – even in fullscreen.
So I was screwing around with some random bits of polish in the game and realised that I havn’t tried fullscreen since I got my shiny new widescreen monitor a few months back. Unfortunately since the game is always rendered at 800×600 (and therefore a 4:3 aspect ratio) it looks a bit rubish when streched over a 16:10 display.
An hour of hacky tinering and it’s running at the native res and aspect ratio, and the results are rather pretty I think:
I was surprised to find that only a few things were resolution-dependant. The HUD was the most obvious, since it used hard-coded positional values, so it now uses relative offsets from the screen edges. The menus are all borked too, since they’re hardcoded to 800×600 so end up huddled in the bottom corner, I’ll worry about them later.
The problem is that I think it breaks the gameplay – searching and exploring the map is a large part of the fun and challenge, and you don’t get that when you can see half or a third of it on screen at a time. In fact it makes some maps laughably easy. But visually it looks so good I’m not sure I want to let it go.
Decisions decisions…
After getting back from holiday (and recovering from), progress on Rescue Squad 2 has been nice and steady, with lots of little tweeks and additions making it into a more rounded game. Most obviously I’ve drawn a handful of new sprites required for the new features, and to make the levels look more varied.
There’s a few different types of boat, including the large cargo ship which you’ll have to pick up cargo from in some missions. Currently they don’t move but I plan to give them some basic wandering AI in the future, and you’ll have to keep an eye on them to see if they get into trouble and need rescuing.
Buildings now have “needs”, and will only accept cargo of certain types. Most buildings will accept food and medical cargo, but the new hospital is where you’ll have to take the injured people you rescue (rather than unhelpfully ditching them on the nearest oil rig and heading home). Buildings display what they’re willing to accept in the little speach bubbles so you know where to take things.
I still haven’t figured out a good way to do animated waves and ripples along the coast line though, which has been bugging me for ages.
Just released into the wild is Analog version 0.5, now with a proper home on the internet with downloads, a feature list and screenshots. It’s a freeform map editor for 2d games that’s based on vectors rather than being tile-based.
I started work on Analog over a year ago when I wanted a flexible map editor for Rescue Squad 2, I looked around at various free tile-based editors but they really didn’t match what I was looking for. For Rescue Squad I wanted free placement of buildings, items and so on rather than being locked to a grid. Since then I’ve added support for rectangles, polys and poly lines, and also used it for NiGHTS4k.
It saves into xml format, and you can plug in your own export scripts (written in Java/Beanshell) so you can easily export to another format that’s crafted specifically for your game. This came in very handy for NiGHTS4k as I could write the levels into a highly compressed binary format to keep the size as small as possible.
Anyway, have a look and maybe a play with it and let me know what you think. If you’re wanting to use it for a game but it’s missing an important feature you’d like then don’t hesitate to drop me an email or a comment here and I’ll see what I can do.
Here’s a video I knocked up a little while back but never got around to posting here, it’s of the work-in-progress Rescue Squad 2.
It’s the first proper level I’ve done now I’ve got my map editor sorted and can properly lay out maps with a landscape to put the buildings and other objects on top of. I’ve also embedded Jython for scripting, so each stage loads a single jython file to control the objectives and tell the player what to do.
Since it’s the new year (yes, I’m a little slow catching up with things) I’ve been giving the site a bit of an overhaul. I was never really happy with the old theme, due to it being very dark narrow, making it a bit awkward to read on certain monitors and. It was also pretty restrictive in terms of what I could put on the individual pages due to the side navigation bar always being required.
So I’ve spent the last week working on this new theme and it’s pretty much done now. It’s much lighter and less bunched up which makes it much easier to read (particularly for large chunks of text) and because the primary navigation is the strip of tabs across the top I can have pages which ditch the side navigation if I want to have a really wide page.
There’s new content up too, a game called NiGHTS 4k, so check that out when you’ve got a moment. Applets are much more solid these days so I may try a few more applet games as tests, particularly as the new theme means I can embed decent sized applets without breaking the layout.
One minor note about the new theme – it’s been tested on the latest versions of Opera, Firefox and Chrome, as well as IE7. Safari hasn’t been tested (because I don’t have that handy) but since Chrome is based on the same renderer it should be identical. IE6 manages to make a complete pig’s ear of it, despite claiming to render it in “standards” mode. Frankly I don’t fancy spending a week fighting with IE6’s bugs because I shouldn’t have to.
Those twelve people reading this site who are still on IE6 will just have to bite the bullet and get a proper browser – or upgrade to IE7 :-).
So the theme voting for LD48 is up, and as usual there’s a whole bunch of interesting ones but nothing that really jumps out and grabs me. And a whole bunch of others which could be quite horrible to do (like “Film Noir”, which is a nice idea but would be very content heavy and hard to do well in the short time allowed). I try not to think too hard about the themes at this point because I can never guess which theme will actually be chosen, and it’s more fun to leave it until the contest starts anyway.
Goals
Like most LD48h competitions in the past, I’m going to set myself a few personal goals for this time around:
Things I won’t be caring about:
Things I’ll be trying to avoid:
I’ll be keeping a journal over at the official site along with the other contestants, and probably posting a potted summary here after the competition is over.