icurafu
The Hallucinogenic Elf
ah ha, Dr Ian. This games looks very fun. I can't wait for a demo.
Official Contest
- Thread starter J201605
- Start date
xenon_soft
Member
I don't know why there have been only 15 games, but congratulations to all. I am now waiting fot them 
And yes, the video of Dr. Ian looks good. Also, I am a fan of Crocodingus, and it's good to see that now it's on GP2X ^_^
And yes, the video of Dr. Ian looks good. Also, I am a fan of Crocodingus, and it's good to see that now it's on GP2X ^_^bluey
Still Fresh
Arecibo has a Commander Keen feel, which I spent hours playing on my first PC (IBM PS2 286), it seems to be fun! Nice work!
thos_thom
Still Fresh
I wonder what happened to my entry. Perhaps they did not want more than one puzzle game in the winning few.
I wonder if they will ask me to "open the source codes". Which I don't really want to do. Mainly because my code is not really of a benefit to anyone. I might be willing to relese it for free though.
</grumble>
I wonder if they will ask me to "open the source codes". Which I don't really want to do. Mainly because my code is not really of a benefit to anyone. I might be willing to relese it for free though.
</grumble>
icurafu
The Hallucinogenic Elf
Think it's commerical. And smooth scrolling is not really a secret.
Last edited by a moderator:
Thanks for all the positive comments. The game is taking a while because things like drawing all the tiles and getting the enemies working well are very time consuming. I hope to get it out some time next year.
I don't know whether it would be commercial or free. Both have advantages. As the game compiles directly for windows, linux or gp2x (or in fact any SDL compatible system) it would be a shame to restrict it to just one system, although it would be good if it persuaded some people to get a gp2x. However if it were free then I could touch up the code base and release the source code, which is always nice.
The only libs used are c standard libraries, SDL and SDL_Mixer.
I can understand how there can be problems with scrolling, as you mentioned, as SDL does some strange things in certain circumstances which can really trip you up and it doesn't tell you, only the framerate suffers.
Basically you must set the screen to be 320 by 240 and 16BPP as well as whatever flags you want (SDL_HWSURFACE | SDL_DOUBLEBUF). This is the screen format that the GP2X has, so if you don't set this, SDL will create a surface in memory with whatever settings you asked, and then downsample the image to the GP2X's screen format every frame. This doubles the rending time at least. You can also get around this by passing SDL_ANYFORMAT as a flag on other systems.
The next thing is to make sure to call SDL_DisplayFormat(SDL_Surface*) on every single surface you want to blit to the screen. This will adjust the surface to be the same format as the screen's surface. If you don't do this, it will down- or up-sample each surface on EVERY blit. You must also set the colour key before doing this, if you want to use one. For example:
If you don't do this the rendering time will be probably doubled again.
The last thing to know is about the bottlenecks in calling SDL_BlitSurface. Of course the speed is directly proportional to the area you are copying, but there is also a slightly large overhead in calling this function. When my rendering code draws in the panorama sky in the far background, instead of copying the sky only where it is needed, I just copy the whole sky over the screen before the rest is drawn on top. I do this because when there is a lot of sky visible (nowhere in the video I posted) the extra calls to SDL_BlitSurface mean it ends up a lot slower than just copying all of it in one call.
As for loading things off the SD card, I just made all the images the last BPP I could make them, and made sure to keep everything in memory once it is loaded, in the form of a linked list. As all the sprites are very small it doesn't use much memory, but even then a linked list like this can be optimized by counting accesses to each entry and sorting it quickly at each level change (or similar) then dropping the least used. The sounds are also loaded up during level change when each object spawns so that they don't interupt the music streaming off the card during gameplay.
I hope that explains enough. :wub:
I don't know whether it would be commercial or free. Both have advantages. As the game compiles directly for windows, linux or gp2x (or in fact any SDL compatible system) it would be a shame to restrict it to just one system, although it would be good if it persuaded some people to get a gp2x. However if it were free then I could touch up the code base and release the source code, which is always nice.
The only libs used are c standard libraries, SDL and SDL_Mixer.
I can understand how there can be problems with scrolling, as you mentioned, as SDL does some strange things in certain circumstances which can really trip you up and it doesn't tell you, only the framerate suffers.
Basically you must set the screen to be 320 by 240 and 16BPP as well as whatever flags you want (SDL_HWSURFACE | SDL_DOUBLEBUF). This is the screen format that the GP2X has, so if you don't set this, SDL will create a surface in memory with whatever settings you asked, and then downsample the image to the GP2X's screen format every frame. This doubles the rending time at least. You can also get around this by passing SDL_ANYFORMAT as a flag on other systems.
The next thing is to make sure to call SDL_DisplayFormat(SDL_Surface*) on every single surface you want to blit to the screen. This will adjust the surface to be the same format as the screen's surface. If you don't do this, it will down- or up-sample each surface on EVERY blit. You must also set the colour key before doing this, if you want to use one. For example:
Code:
SDL_Surface *temp = SDL_LoadBMP("hello.bmp");
SDL_SetColorKey(temp, SDL_SRCCOLORKEY, SDL_MapRGB(temp->format, 0xff, 0, 0xff));
hellosurf = SDL_DisplayFormat(temp);
SDL_FreeSurface(temp);If you don't do this the rendering time will be probably doubled again.
The last thing to know is about the bottlenecks in calling SDL_BlitSurface. Of course the speed is directly proportional to the area you are copying, but there is also a slightly large overhead in calling this function. When my rendering code draws in the panorama sky in the far background, instead of copying the sky only where it is needed, I just copy the whole sky over the screen before the rest is drawn on top. I do this because when there is a lot of sky visible (nowhere in the video I posted) the extra calls to SDL_BlitSurface mean it ends up a lot slower than just copying all of it in one call.
As for loading things off the SD card, I just made all the images the last BPP I could make them, and made sure to keep everything in memory once it is loaded, in the form of a linked list. As all the sprites are very small it doesn't use much memory, but even then a linked list like this can be optimized by counting accesses to each entry and sorting it quickly at each level change (or similar) then dropping the least used. The sounds are also loaded up during level change when each object spawns so that they don't interupt the music streaming off the card during gameplay.
I hope that explains enough. :wub:
Last edited by a moderator:
Blah
Wanna Be Programmer
Any word on when GPH is going to get around to release the damn things? I want to play Crocodingus again.
Blah posted on Dec 13 2006 at 06:52 PM said:
My game was a really incomplete alpha version and I don't think GPH will release the version I sent (I hope not anyway.) They did say that when my game was complete I could contact them about perhaps publishing it, should I want to. I guess if I don't want to, I'll just release it when it's done. I guess the same applies to all the other entrants.
Last edited by a moderator:
Draken
Well-Known Member
A bit late to respond, but your game looks really cool Dr Ian, reminds me of Cave Story, one of my favorite games.
Similar threads
