Projects history - Part II: Gameboy, Symbian and J2ME(iPhone) times

 In the first part I went thropugh old Atari and DOS projects. It the second part I will describe history of SBC projects for Gameboy, early Symbian phones and also history of one iPhone game that originally was not iPhone at all will be mentioned.

Gameboy

 In 1999 I left PC and started amateur coding for Gameboy. The reason was simple. While stuck in DOS times changed and if I wanted people to play my games I had to switch over to big world of Windows or to find another platform. Gameboy was still platform where single person could make all the job by himself and the code was mostly written in assembler.

 First finished game was Little Fantasy (needs Gameboy emulator). The game was created for GBDev 2000 compo and according to rules it had to be under 32 kb. Into this limited space I pressed small RPG game in Final Fantasy style with 64 screens and big evil boss Skullhead in the end. The game won in game category of the compo:

 In the same year in the end I took part in another compo sponsored by Bung. Bung was producer of specialised  HW used by amateur developers. For this compo I created game Jumpik. The game was really hard to play. Lot of dying for every small mistake:

 The last GB game was Tom Atom. This was first game where appeared Tom Atom and it was also first game we created with Jupiter together. Jupiter is professional grafician. His graphics raised the quality of game by hundreds percents. We formed small team with name SBC (Small Blue Cube). The game itself was about wandering through land, speaking with characters and fighting with monsters. You could find several weapons and had to defeat five bosses. The main one - Dr.Zloun - escaped in the very end after final battle and so the end stayed open:

Symbian

 One of the first real smartphones was Nokia 7650 running Symbian operating system. Now we could make games that more people will play! Our first one was Deadly Abyss. You controlled submarine and launched torpedoes to destroy enemy ships. You had to avoid hitting civil ships and you also had to dodge deadly mines dropped from enemy ships:

 Next Symbian game called Guns'n'Girls. In the wild west you shoot evil guys who appeared in windows of buildings. Your task was to kill only the bad ones. Some of them looked like good ones until gun appeared in their hand:

J2ME (iPhone)

 After long time and after lot of unfinished projects. We started to work on next adventure of Tom Atom. The game called Horror Labs. It was our biggest game so far and there was plenty of other people working on it. Beside Jupiter there were other graficians (Cobold - most of the tiles graphics, Likandro - big part of characters, Tomboid - characters) and it was also our first game that had really great music by Honza Dušek. We also had publisher that provided testers. The game was completely written under J2ME but in the very end it was decided by publisher to release it on iPhone:

 Conclusion

 This second part is closing history review of SBC and pre-SBC projects. All newer projects have their separate articles here on this blog as these are still alive.

Projects history - Part I: Atari and DOS times

 This is first part describing our SBC projects and also my pre-SBC projects. Today I will briefly go through my very old Atari and DOS works.

Atari

 In 1989 we (me and my brother) got our first computer - the great Atari 800 XL. It was not so common to have computer at home in those times. But fortunately my schoolmate Ladislav Salát had also one. We both had the same interests. Not only we played that good old games but we were also curious how things work. Yes, we were young, wild and in short time we were drunken with power of 6502 machine code! Together we created Music Master 5 (can be run in emulator). It was kind of jukebox where under each letter of alphabet was one computer song ripped from some famous Atari game:

 Some time after that I created simple game with name Kosmonauti (can be played in emulator). The game was really very hard to play... Umm, well ... it was unplayable. Graphics was just pile of rips from other games. But it was completely written directly in machine code. Here are some screenshots:

DOS

 In 1993 we got our first PC. It was 386SX machine with 42MB hard drive and 256 color VGA graphics card. For this comp I first created simple logical game Cases (will run ok in DosBox). You controlled small tank like character and your task was to pick up objects in room. The room was all crammed with cases which you could move:

  My next game was named Bloody Revenge (will run ok in DosBox) and it was frenzy action platformer similar to Atari Kosmonauti. With main character you are wandering from left to right through screens and shooting the enemies:

 There was lot of unfinished experiments and my only last finished game was Požár. It was simple game where you controlled with mouse the platform in the bottom of the screen and your task was to catch survivors jumping out of windows in tree village. The characters were taken mostly from old NES games:

 This was first part of my portfolio history describing pre-SBC times. Next part will show you old Gameboy and Symbian projects and Jupiter, the second member of our small team, will appear on the stage! So, stay tuned...

Sprite Atlas Tool - Part II: Data Exports

 This is second part of article describing our tool for creating sprite atlases (SBC PicOpt). In Part I I described features of the tool as well as the way how to add custom properties like collision boxes to your sprites. It was also described how to create animations from the frames. If you followed it the tool created directory "export" during exporting and there are three files:

• MyProj_N.png
• MyProj_N.dat
• MyProj_N.anm

Exported data

 First let us look at MyProj_N.dat. The header is very simple:

 short width  
 short height  
 short count  

width and height are dimensions of exported texture atlas and count in number of individual sprites in it. Next, blocks follow - each for every single sprite. Blocks have the same size but its total length can change depending custom on properties you created. Basic structure is like this:

 short x  
 short y  
 short width  
 short height  
 short offsetX  
 short offsetY  

x and y are position of top left corner of sprite within sprite atlas. Width and height are dimensions of the sprite - note that empty space around sprite is trimmed in export. OffsetX and offsetY is relative position against the central point (the red one). First time you import sprites the offset is decided by tool based on sprite position within imported grid (if you do not understand what I call grid read Part I). This allows you to create animations like this:

 and only one ball will be exported into final atlas while in data all three frames will be preserved. The only difference between them will be the offset part of data block.

Custom properties export

 If you created any custom properties your data block will be longer. Let's say you created the properties like this:

 then your export will look like this:

 // basic data  
 short x  
 short y  
 short width  
 short height  
 short offsetX  
 short offsetY  
 // ColBox  
 byte x1  
 byte y1  
 byte x2  
 byte y2  
 // MarkerPoint  
 short x  
 short y  

where all custom properties coordinates are relative to central point (the red one).

Animation data export

  If you do not have any animations the MyProj_anm will be 2 bytes long and it will contain zeros. It is because first short is the total number of animations exported. After that every animation is exported with very simple structure. First short says how many frames it contains and then so many times pairs of shorts follow for frame and delay. From the this table it will be very clear:

 // total number of all animations included in export  
 short number_of_animations
  
 // animation 0  
 short number_of_frames_for_animation_0  
 // frame 0  
 short sprite_index_within_atlas_data_export  
 short delay  
 // frame 1  
 short sprite_index_within_atlas_data_export  
 short delay  
  :  
  :  

 // animation 1  
 short number_of_frames_for_animation_1  
 // frame 0  
 short sprite_index_within_atlas_data_export  
 short delay  
 // frame 1  
 short sprite_index_within_atlas_data_export  
 short delay  
  :  
  :  

Conclusion

 As you can see the exports are very simple but flexible in adding your custom properties. Loading them is then very straightforward.

Download: SBC PicOpt tool v 1.00

Sprite Atlas Tool - Part I: Creating the atlas

Sprite Atlas - why bother?

  When creating even small game you usually have to deal with lot of single sprites. Putting them into separate files may help you to organize them somehow but loading plenty of textures and switching between them will not make openGL happy as well as it will probably eat more of your memory.

 It is where sprite atlas comes into play. Sprite atlas is just a one big image created from all the individual sprite images. Of course, as the number of sprites increases its maintenance and changes require more and more overhead. More, creating it by hand is pretty boring and be sure that decent computer algorithm can do the job better than you. "Better" means it will be faster and sprites will be placed in atlas in such a way that the memory consumption is minimized.

 Unfortunately, most of the sprite atlas tools I came across on web are not optimizing anything. It just glues several images into one big by putting one after each other.

 All these problems can be solved when using our tool SBC PicOpt. It will help you to keep single files with your sprite assets and create optimized sprite atlases from them. Even more! You can create animations in it or add custom properties to sprites. The result you get may look like this:

GUI sprite sheet form our Mahjong Tris game

SBC PicOpt Tool

 The SBC PicOpt tool is Java desktop application. After you run it with "java -jar SBC_PicOpt.jar" or simply with clicking on provided .bat file you will get this screen:

SBC PicOpt main screen

  Next you will need to create your sprites. The tool can process .png files created like this:

example of sprite animation frames enclosed in grid

 Note the 1 pixel thin grid. The grid can have any color but this color should not be used elsewhere as it may confuse the tool when looking for particular sprites. Of course you can have may of such  images because with the tool you will add them to project. The grid can be also vertical or combination but each line in the grid must preserve its starting height. So, here are examples of good and bad grid:

good and bad grid for sprite frames

 OK, back to the tool. Select File->New Project and name your project. Next select Bitmap->Add bitmap and open your first picture with grid. Add another bitmap and you should have something similar to this:

SBC PicOpt main view after importing some gird based sprites

 In upper left combo box there are all imported images with grid. Selecting one changes content of combo box below it where particular sprites are already extracted from the grid. Your project is thus pile of grids that may contain one or more sprites enclosed in grid (even single sprite must be enclosed).
 The red dot in the editor is center which the sprite is relative to. You may drag the sprite on the screen end see how its Offset property is changing (more on properties later). How is the offset initialized? Yes, it is another feature of the grid. Actual start of the sprite is measured against top left pixel within the grid. Next time when loading your project it will be taken from saved property data.

Handling properties

  So far on the left side is only one property - Offset. Beside this there are also properties that are currently hidden and that will be present in data export after optimization. These are position of sprite within final atlas and also its size. But you are not limited only to these. What about creating rectangular collision box and some kind of point marker? Select Sprite->Sprite Properties and change it like this:

property dialog

 After clicking on OK you will be returned to main screen where all the new properties are placed over single red central point. So drag them with mouse to desired positions:

main view with custom properties

Animations

 You can also create animations with imported sprites. On the top right side of main screen you can add animations and below it you can manage animation frames. Try changing the screen so it look similar to this:

adding animations

Optimization and export

 Finally we got to creating the atlas. Choose Optimize->Best Place and the optimization starts. "Best Place" is the name for optimization method used. There was also alternative genetic algorithm but it was terribly slow so it is now removed. Ok, my result looks like this:

example of final atlas

 It merged two grid base sprite images in my project into one optimized sprite atlas. The result can be found in directory "export' that was created along with additional files with .dat and .anm extensions. These files contains all the data with properties and animations. Their format will be explained next time in Part II.

 You probably noticed some controls on the top of the main screen:

controls used to modify export

  these can affect the export you are generating:

Little endian - tells the exporter how the data should be saved - which byte order to use,

POT Texture - whether the final atlas should have its dimensions as power of 2. It is helpful when working with openGL ES textures,

Padding - says how much pixels is minimal space between sprites stored in final atlas. If you ever encountered ugly artifacts around your sprite when working with atlases and openGL you will appreciate it (it is related to way how pixels are interpolated when drawn)

Sprite Border - in connection with Padding says how many times the first and last row and column will be repeated instead of padding with empty space. Again, very useful - prevents artifacts and also fading out of the image in the rim.

Closing words

 This was my first blog post. I hope the tool will be useful for you and in Part II I will describe the output format. The tool is still far from perfect, so you may encounter situations where it throws some exception or so. But four games were already made using it.

Download: SBC PicOpt tool v 1.00