User Tools

Site Tools


PokéParadox's Development Blog

It's Not Rocket Science!... Oh Wait...


Now that the majority of the engine for PandoraPanic! is finished, it's leaving me with a bit of time to actually start some of my own minigames for the project. What you see above is the result of 2 days work. The rocket itself was done in paint by yours truly and now I'm trying to get the particles to come out of the bottom of the ship properly and for them to react to objects upon collisions! I still have to figure what the actual goal of the rocket game is, but I'm thinking escape from a silo filled with obstacles that will get in your way in a short time limit! ;-) The rocket can turn and flies in the correct direction and everything, I just need to check my code for positioning the Emitters at the thrusters.

PandoraPanic! Itself

It's coming along nicely. The joy mappings for Pandora have been added to SimpleJoy, we are still waiting to get hold of some SDL libs for Pandora to be able to compile a Pandora executable. The buglist has got shorter and shorter and basically we are just housekeeping and finalising game credits. There were a few muddled mis-credited entries which I doubled checked and fix. I really don't want to miss people out or mistakenly credit someone else! Gruso gave us a nice little write up on the community Pandora blog recently. It opened a few eyes to our efforts and I'm quite confident some people will end up playing our game!

Other Stuff

MarkoeZ (The Minigame MACHINE) has joined us at Pirate Games (website will probably not be ready still!) This is great as it's good to have another person scrutinise your code and point out bugs and also point out limitations of the engine that can be resolved. I hope 2009 really is the year of the Pandora, and a good year for Pirate Games to bring you some great homebrew!

2009/01/24 09:05 · 0 Comments

CodebaseConfusion or... FrameworkF-ups!

Fixing Alpha-blend Speed


PandoraPanic is based on Penjin which, in this case uses SDL. Unfortunately SDL is really bad when it comes to alphablending… Very S L O W! At first I have just put up with the cpu time wasted on alpha blends since the bg requires them I thought there wasn't much I could do about it. But I realised I could pre-render the background with the colour and store the surface. Basically this pre-render is updated when the background colour is changed and the pre rendered background is used to clear the screen at the beginning of each frame. Results are good. I hope they will benefit the actual Pandora build too.

But Then!

No sooner than I had the background buffering working… I had found I had broken it again… I was getting a plain black background instead of the random coloured, gradient background. Whoops! Looking at the code there didn't appear to be anything wrong… I was hitting my head against the keyboard for a few hours trying to figure it out.

Go To Bed!

I finally gave up and went to sleep. As soon as I woke up the thought entered my head. “It's the transparent colour setting or hardware blits!” Basically I was running my other projects through the Penjin codebase to fix incompatibilities. Unfortunately fixing them meant that I had introduced incompatibilities in PandoraPanic! It did in fact turn out that HW blits were breaking the background buffering (They are enabled for Background objects by default.) I added code to disable HW blits for the background image:


And that's it! Don't you just hate it when it's something simple that you miss!?

SimpleJoy Update

SimpleJoy is a little more complete. It's an all in one class to support the control pad of GP2X, Pandora and Wiimote. It now supports a dual stick USB controller to test analogue control. I need to add some sort of button mapping in order for USB control to be useful outside of a testing capacity. I've also been thinking of incorporating Mouse/Touchscreen control from inside the class. This would mean everything is in one place and less… um… scattered.

New Game Idea


I like the idea of a self evolving game. This is what inspired me to write CromoZome. Unfortunately CromoZome didn't quite achieve the level of evolving that I want to see. It was a great proof of concept, however. My current idea is an extension of CromoZome.


Basically you have an array of Genes a Gene is a class which holds info about what the Gene does and a Gene type. All needed information will be represented in this way. This will allow us to display the Creature and allow it to interact with other creatures.

Display Issues

My main problem with this sort of game, even when discussing it with Cameleon, has always how to display a self evolving creature… But finally, I realised that my creatures don't have to be humanoid or such. Basically I can represent creatures as polygons and colours and maybe patterns on the polys. This means the creatures can be procedurally generated. Furthermore, the cretures can mate and swap genes to make a differing complexity poly, or create a symbiotic organism with other polys that may eventually become a 3D creature!


I am very excited by this idea but I refuse to start it until PandoraPanic! is finished because I know it will take my focus completely. I do intend to release it for Pandora, I also hope I can get it to other platforms too!

Cross Platform Joypad Handling

Today I managed to put together the SimpleJoy class. This is a simple generic joypad handler which should let you use mainly the same code on GP2X, Pandora and the PC for testing. Common buttons are kept common and platform specific keys are kept separate.

Current Status

The class has integrated and deprecated the existing GP2XJoy class and replicates all the functionality there. It has a stub key-mapping for Pandora and shares many of the button names. It does not currently give access to the Pandora's analogue nubs.


The priority at this time is to finalise the Pandora aspects of the class for PandoraPanic. This requires finishing the stub for the Pandora key-map and more immediately, adding routines to handle both Nubs, since at least one mini-game from uses the nubs.

PandoraPanic! Status Update

Well I've managed to squeeze PandoraPanic! into my schedule quite a lot in the last couple of days. I've been spotting bugs and fixing them quite rapidly. Here's some things I've managed to get done.

Bugs Fixed

  • Particles actually fade in alpha/colour… it's still not fading exactly with the Particle lifetime, but it's better than no fading!
  • Managed to figure out why Kagato's transparent star image was not displaying properly - The Emitter class was auto-setting the sprite to use HW accelerated blits… they are not compatible with alphablends.

Stuff Added

  • It's now possible to manipulate the settings for transparent colour. You can set a specific colour, or a pixel on the surface to use as the transparent colour or disable the transparent colour.
  • It's possible to set Sprites to use hardware acceleration or not in the Emitter and Menu classes.
  • Mouse/TouchScreen added to StateTitle… will be used in sensible places elsewhere in the game too!

Stuff Changed

  • Fixed point is now an option and the Particle engine can run in Fixed or Float form, depending on if PENJIN_FIXED is defined.

Stuff Changing

  • More compile targets are going to be added to Penjin. This is not going to happen till after PandoraPanic! has a first release.
  • More compile targets means more render methods. In addition to the GL and SDL renderers, GX(Wii/GameCube) GLES2.0 and Trenki's SoftGPU will be added.

In Closing...

I must say thanks to all PandoraPanic! contributors. The warm reception and positive criticism to my engine has been a great boost for me. This is exactly what I need to keep improving it and I hope that you will consider using Penjin for future homebrew projects.

2008/12/06 00:50 · 0 Comments

PandoraPanic! Rotations 2

My previous thoughts on what was wrong with rotations were somewhat false. This is because my reasoning was based on my observations on the current code. Unfortunately the code was functional but broken. Alex posted a sample function which worked, centring the surface and rotating on the screen and from there my problems became more apparent.

  • The code was offsetting the clip rect instead of the surface itself.
  • It was offsetting the clip box negatively and resizing the box to accommodate the resized surface, which almost works for surfaces with equal length and height.

Fixing Positioning

This fix for this was changing:

   src.x -= (src.w - tempImage->w)/2;
   src.y -= (src.h - tempImage->h)/2;

To this:

   dst.x += (images[i]->w - tempImage->w)/2;
   dst.y += (images[i]->h - tempImage->h)/2;

And use no cropping Rect on the blit, since rotozoom provides a resized surface automatically.


It required a little more thought in rotating animated sprites correctly, because they can be loaded as a sprite/tilesheet. Passing in the full surface to rotozoom rotates ALL the frames and is not the effect we're going for! The answer to this problem is we need to isolate the current frame of animation for rotation. I put together a quick crop function which takes an SDL_Surface* as an input and spits out a cropped surface. I tried many many things, but I would only get a black square as a surface… I asked for some help, Alex suggested it may be the colour masks… which for some reason made me realise that the problem was that the crop function was losing the transparent colour! This was after many many tests to do with positioning…

Finished Working Code Snippet

Rotation Code

else if(useRotation && (angle || scaleX!= 1 || scaleY!= 1))
            SDL_Surface* tempImage = NULL;
            SDL_Surface* subSprite = NULL; // Need to use this for animated sprites to get the subsprite isolated.
                subSprite = cropSurface(images[i],&src);
                tempImage = rotozoomSurfaceXY(subSprite, angle, scaleX, scaleY, SMOOTHING_OFF);
                dst.x += (subSprite->w - tempImage->w)/2;
                dst.y += (subSprite->h - tempImage->h)/2;
                tempImage = rotozoomSurfaceXY(images[i], angle, scaleX, scaleY, SMOOTHING_OFF);
                dst.x += (images[i]->w - tempImage->w)/2;
                dst.y += (images[i]->h - tempImage->h)/2;
            SDL_BlitSurface(tempImage,NULL, dstimg, &dst);

Cropping Code

    SDL_Surface* Image::cropSurface(SDL_Surface* in, SDL_Rect* c)
        SDL_Surface *cropped = NULL;
        //  Cropped surface
        cropped = SDL_CreateRGBSurface(in->flags,c->w, c->h,in->format->BitsPerPixel, 0, 0, 0, 0);
        Image tImage;
        Colour col = tImage.getPixel(cropped,0,0);
        SDL_SetColorKey(cropped, SDL_SRCCOLORKEY | SDL_RLEACCEL, SDL_MapRGB(cropped->format,,,;
        return cropped;

GP32X Post

PandoraPanic! Rotations

I've been looking at the sprite rotation code in Penjin. It seems like it wasn't quite as fixed as we thought it was. There are two problems that I can see:

  • The rotated sprite still gets visible parts of the image cropped.
  • Rotations currently only work if you have equal length width and height…

The problem with cropping can be resolved by getting the diagonal length of the surface, and in following the other problem can be solved by getting the longest diagonal. There is now another problem, however; We then have to translate the surface so that the visible image remains centred where it is and is not offset… In my current build this is not the case.

Basically this is what I'm trying to fix right now, it'll be a little longer but then a framework update will come! =)

2008/11/26 03:15 · 0 Comments

First Test Entry

So basically this is to see if the wiki blogging thing actually works… Hopefully it does.

If you are reading it… it probably works…8-o

2008/11/21 00:15 · 0 Comments
You could leave a comment if you were logged in.
devblogs/pokeparadox.txt · Last modified: 2008/11/21 00:14 by pokeparadox