Getting The Data

So, having decided on using Unity to create the data (levels, sprites, definitions. etc.).. how to get it in to the game?

A common way when using assembler is to dump out binary files and #incbin them in to the code base. This always had the advantage of being quick to assemble, as all the assembler needs to do is to copy the binary contents of a file to a particular location.

The downside is that it's not so easy to debug.

Now that my PC is probably 100000x quicker than anything I used in the 90s, assembler time isn't an issue at all. Assembling the entire project takes way less than a second!

So instead, I opted for the other common technique, which is to export files with asm code and data in them.

All data is now exported as labels, tables, and declarations in source. This has the wonderful advantage of being much easier to debug.

Here's an example of exported level data:


As all the assets are given labels inside the editor, the labels get recursed during export to come up with unique names for everything. This example shows two level character sets being exported, with pointers to their addresses.. and the _biscuits label shows the definition of a character set. (Number of cells followed by the cell data)

Here's an example of 'spawn data' - that is, positions and data for each different GameObject in a level. 


Notice that different types of object have different numbers of parameters. This is a very easy thing to do in assembler, but would require more messy setup in C, for instance.

Next is an example of Sprite definitions. (Sprites are organised in to SpriteGroups, with varying numbers of frames for each one. It's a handy way to organise the data)


This one is odd in that it has some filler bytes at the end. This is because the data is organised in such a way as to make the code which uses it much faster than it would otherwise be. And 6 bytes are added there at the end to make make the lookup quicker. This sort of thing I am sure to re-visit during production when more optimization is needed, either for speed or space!

I was very lazy when programming the export code in Unity. It was basically a wrapper for string concatenation, eg. "outputStr += sprite.label;"
This was fine, but after adding a few levels and character sets, export time was starting to increase in to numbers of seconds! 
Of course StringBuilder was the answer, but it was way more performant than I expected, turning out to be >100x faster than adding strings together. So now a full export from unity is 2-3 seconds (much of that is converting the data and crunching the cells), and a typical "Export and Run" during level editing is under a second, and maybe 2-3 seconds to assemble, and load up the emulator. This is way faster than normal building and running in Unity.. but that's to be expected, it's only a Megadrive game after all.

Comments

Post a Comment

Popular posts from this blog

Mega Palettes

Image
  Ah, the Sega Megadrive, halcyon days. I remember pre-ordering mine from Special Reserve and eagerly awaiting the launch date. They sent me a copy of Super Monaco GP and a second control pad, which I got to stare at for a week before the console itself finally arrived. It was worth the wait. I still own one today. If you're going to make graphics for a Megadrive game, then you're going to be spending a lot of time with palettes! Aside from the pixel art program Aseprite, the most useful graphics tool I have is a post-it note stuck to the monitor with the numbers 0, 52, 87, 116, 144, 172, 206, 255 written on it. I am almost exclusively using Aseprite to produce the graphics for Rocket Panda, and occasionally Cinema4D to render any 3d animated objects which then need to be processed through Aseprite. The end result is a series of sprite and tile sheets which are mapped to particular palettes. Creating these palettes is the crux of the operation and has to be nailed down fairly e...
Read more

Converting Gunslugs to Megadrive / Genesis

Image
Overview This is all about porting Gunslugs, a PC game written in Java (by OrangePixel  ) to SEGA Genesis / Megadrive, written in 68000 assembler. Original Game (PC) Genesis Conversion Code Objects / Entities There are quite a lot of active objects at once in the original game- something lke 100-200 plus bullets and effects. This would not be doable on the Genesis, so instead I generate a list of spawn points for level objects. These are sorted horizontally so that I only need to check one at a time as the screen scrolls. Once a spawnpoint is determined to be just off the right edge of the screen, it is promoted to being an active GameObject, and the spawer code continues looking for the next object in the spawner list. Early on I knew there would be a problem with this, due to objects disappearing off the left of the screen. In the original these continue to be active. But at the start I didn't know enough about the game to determine what to do about it. In other games I'd uns...
Read more
Image
Passing Breeze, An Arcade Adventure. Our entry for Retro Platform Jam #5 We normally try to make something technically impressive for these jams, but this time we just decided to do something different. We'd never made an Interactive Fiction before. Our platform of choice was again the SEGA Genesis. The Jam theme was Breezy, so as old arcade game lovers we thought of Passing Breeze, the music from SEGA's Outrun. This all fitted together nicely. We'd do an adventure game based in a 1980s(ish) arcade. PICTURES Even though it's simple, I wanted to do something a little technical, so decided to see what sort of images we could display. I started with a simple 16 color image, then tried to do 31 colors by combining the two background scroll layers, A and B. (31 because the top layer would need a transparent color to show the bottom layer through) This all comes down to the tooling. (another story, as I'm converting my game tools to WinForms at the moment).  So I wrote t...
Read more