Pandora Pandora Panic


PokeParadox said:
Ok well I looked at a few images and was trying to find higher detailed one but in any case here is the cake background from the Birthday Cake minigame
http://img194.imageshack.us/img194/1363/caket.png

We have about 10MB of music and 10MB of images so maybe it's not so bad...
Yupp, 20MB for so many included games is OK. :) I forgot that the Pandora 800x480 res is used for most of the Images. If you really want to hardcore-optimized, the Games could be done in 400x240 and then simply blowed up in hardware, still should look good and you have more "pixelated" Retro-graphics and maybe it even runs faster (?)
Anyway, the cake graphic was simple, no problem in 256 Colours so I tried it with only 64. :D Photoshop gave me around 43KB Filesize with 8BPP and 64 Colours (difuse dither), the IrfanView Plugin compressed this file to around 27kb
I think it could be done in 32 or even 16 Colours if the background wouldn't have a slightly gradient ^^


EDIT: With a different dither, the green BG looks better, still 64 colours (I think 48 Colours are no problem to realize)
 
Last edited by a moderator:
fusion_power said:
PokeParadox said:
Ok well I looked at a few images and was trying to find higher detailed one but in any case here is the cake background from the Birthday Cake minigame
http://img194.imageshack.us/img194/1363/caket.png

We have about 10MB of music and 10MB of images so maybe it's not so bad...
Yupp, 20MB for so many included games is OK. :) I forgot that the Pandora 800x480 res is used for most of the Images. If you really want to hardcore-optimized, the Games could be done in 400x240 and then simply blowed up in hardware, still should look good and you have more "pixelated" Retro-graphics and maybe it even runs faster (?)
Anyway, the cake graphic was simple, no problem in 256 Colours so I tried it with only 64. :D Photoshop gave me around 43KB Filesize with 8BPP and 64 Colours (difuse dither), the IrfanView Plugin compressed this file to around 27kb
I think it could be done in 32 or even 16 Colours if the background wouldn't have a slightly gradient ^^


EDIT: With a different dither, the green BG looks better, still 64 colours (I think 48 Colours are no problem to realize)

Okay, a few things, firstly some graphics will compress well, others not so well, hence why I suggested a script that checks the amount of colours present in the original image first, for instance Pang has a cloud background that has a smooth gradient between a lot of different shades, so I imagine it would look very banded if compressed to 256. The birthday cake example strikes me as something that should work well with reduced colours as it visually doesn't look like it has much in the way of gradients/shades.

Next, I wouldn't call hardcore-optimization renderering everything to a 400x240 surface, and then scaling that up, that's like a quick and dirty hack for saving on fill rate and if we resize all the sprites, memory+storage. The end result will look low res (and either pixelated or blurred depending on filter). Some games might look nice enough like that, but once again, Pang as an example, I'm pretty sure it'd look worse in every way!

Thank you for looking in to the birthday cake example though, at least that confirms my hunch that some graphics are suitable for compression. If I get a chance I'll write something to scan all images for ones that are 100% suitable for auto conversion. If we were lucky we might be able to half the image size foot print without any loss!

Steve
 
Last edited by a moderator:
Rockthesmurf said:
Okay, a few things, firstly some graphics will compress well, others not so well, hence why I suggested a script that checks the amount of colours present in the original image first, for instance Pang has a cloud background that has a smooth gradient between a lot of different shades, so I imagine it would look very banded if compressed to 256. The birthday cake example strikes me as something that should work well with reduced colours as it visually doesn't look like it has much in the way of gradients/shades.
Yes, the result can be very different depending onto the Graphics. I don't know how the PANG BG looks but if the game has the right graphic style, rastered or banded effects could be part of the style like ages ago nobody complained about banded bg's (I remember many AMIGA games used "striped" Sky's ^_^ )

Rockthesmurf said:
Next, I wouldn't call hardcore-optimization renderering everything to a 400x240 surface, and then scaling that up, that's like a quick and dirty hack for saving on fill rate and if we resize all the sprites, memory+storage. The end result will look low res (and either pixelated or blurred depending on filter). Some games might look nice enough like that, but once again, Pang as an example, I'm pretty sure it'd look worse in every way!
It will be hardcore if you don't simply redsize existing graphics but redo the graphics entirely to the new size. Because if a existing graphic has only a 1Pixel line somewhere this can't get be propper reduced. ;) So Sprites, BG, everything has to be painted correctly for the new size. I'm sure it is not worth this because I can't imagine, the current games eating alot of processor power.

Rockthesmurf said:
Thank you for looking in to the birthday cake example though, at least that confirms my hunch that some graphics are suitable for compression. If I get a chance I'll write something to scan all images for ones that are 100% suitable for auto conversion. If we were lucky we might be able to half the image size foot print without any loss!

Steve
No Problem.
I was able to reduce a 106KB file to somewhat around 29KB, even in worst cases I think you can reduce the images easily to around 50% of the original file Size only by changing the color depth. :)
 
Last edited by a moderator:
Maybe grafx2? Long, long time ago I had to use it for demoscene purposes on PC (MS-DOS) after few years on Amiga Deluxe Paint. Right now grafx2 is Google project :) If you know how to draw 8-bit old school graphic this software realy rocks.
 
forums are funny, i make a remark about the size of the preview folder and suddenly the conversation is about auto-conversion scripts and scaling everything :D
 
Ok, most of the work on the pxml is done. but one line of the example confuses me:

Code:
<clockspeed frequency="600"/><!--Frequency in Hz-->

is it in Hz or should it say MHz? because it should be way higher otherwise.

And i don't have a clue how to validate an xml file, will look into it, but any tips in the meanwhile?

I included the latest version of the icon in the repo, the icon line of the pxml needed to point somewhere. It is in the built/images folder, filename: ppicon.png. I will update it if there is another version ofcourse.

That's about it for now, Cheers!

Edit: Im having errors on pausetoggle in all games since i updated
 
MarkoeZ said:
Ok, most of the work on the pxml is done. but one line of the example confuses me:
Code:
<clockspeed frequency="600"/><!--Frequency in Hz-->
is it in Hz or should it say MHz? because it should be way higher otherwise.
Edit: Im having errors on pausetoggle in all games since i updated
I'm pretty sure it's in MHz. Thanks for you work on this.

Make sure you update to the very latest Penjin! If you are still having problems clean the build and then try again. I changed a lot of files in my last commit!
 
Last edited by a moderator:
PokeParadox said:
MarkoeZ said:
Ok, most of the work on the pxml is done. but one line of the example confuses me:
Code:
<clockspeed frequency="600"/><!--Frequency in Hz-->
is it in Hz or should it say MHz? because it should be way higher otherwise.
Edit: Im having errors on pausetoggle in all games since i updated
I'm pretty sure it's in MHz. Thanks for you work on this.

Make sure you update to the very latest Penjin! If you are still having problems clean the build and then try again. I changed a lot of files in my last commit!
Wait... why are you even specifying <clockspeed>? Do you need to overclock the Pandora to run Panic?

Oh and sorry for that typo, yes, it's of course MHz.
 
Last edited by a moderator:
Hey, I hoped to heavily underclock my Pandora for these kind of games. ^_^
Pandora Panic look like it can run at 200MHz or less at least I'm sure when we can play Q3 or PSX or maybe N64 Full Speed, these small games for PP are a good way to save battery time. :)
 
dflemstr said:
PokeParadox said:
MarkoeZ said:
Ok, most of the work on the pxml is done. but one line of the example confuses me:
Code:
<clockspeed frequency="600"/><!--Frequency in Hz-->
is it in Hz or should it say MHz? because it should be way higher otherwise.
Edit: Im having errors on pausetoggle in all games since i updated
I'm pretty sure it's in MHz. Thanks for you work on this.

Make sure you update to the very latest Penjin! If you are still having problems clean the build and then try again. I changed a lot of files in my last commit!
Wait... why are you even specifying <clockspeed>? Do you need to overclock the Pandora to run Panic?

Oh and sorry for that typo, yes, it's of course MHz.
I doubt we need to overclock... I think since it was part of the spec, he thought it was necessary to provide the <clockspeed> element...

fusion_power said:
Hey, I hoped to heavily underclock my Pandora for these kind of games. ^_^
Pandora Panic look like it can run at 200MHz or less at least I'm sure when we can play Q3 or PSX or maybe N64 Full Speed, these small games for PP are a good way to save battery time. :)
Quite a few games will be fine underclocked... I can't say for certain that the game as a whole will play nicely if you underclock it. Some of the games use rotations (slow in SDL) and blending(also slow in SDL)... so these may be problamatic at lower clock speeds!

It is my every intention to update Penjin with GLES support... this would help greatly with the above issues... but even my regular OpenGL render target isn't ready yet... for now though at least we can get some nice results with the SDL renderer(if a little slow in places)!

You are certainly welcome to try underclocking of course! :)
 
Last edited by a moderator:
Ok it's compiling nicely again.

I removed the clockspeed line in the pxml for now.

Maze now has an extra level. it's just as easy/difficult so they appear random, but it adds to the panic. And some more will probably be made before release. Small bug in jumper fixed where one could fall through a tile. also minor background changes for joust/maze, bit darker.
 
hiya ppl, not much activity last few days. Are we allready done or is everybody just hard at work? ;) Poke, anything i can help you with? I'm no master coder as you know, but maybe some boring stuff that needs to be done? Otherwise i might have to make another minigame :p

Cheers!!!
 
Sometimes things go quiet! The only thing remaining is to try and balance the difficulties as much as possible.
I want to make a release build at the end of this week.
I've been looking over some bugs in Penjin too.
 
PokeParadox said:
Sometimes things go quiet! The only thing remaining is to try and balance the difficulties as much as possible.
I want to make a release build at the end of this week.
I've been looking over some bugs in Penjin too.

How about a release candidate binary (for 32bit x86 linux too please)
 
Last edited by a moderator:
MarkoeZ said:
hiya ppl, not much activity last few days. Are we allready done or is everybody just hard at work? ;) Poke, anything i can help you with? I'm no master coder as you know, but maybe some boring stuff that needs to be done? Otherwise i might have to make another minigame :p

Cheers!!!
Are all the PNG graphics reduced in bit-depth (as far as possible) yet or was this just a theoretical discussion? ^_^
 
Last edited by a moderator:
fusion_power said:
MarkoeZ said:
hiya ppl, not much activity last few days. Are we allready done or is everybody just hard at work? ;) Poke, anything i can help you with? I'm no master coder as you know, but maybe some boring stuff that needs to be done? Otherwise i might have to make another minigame :p

Cheers!!!
Are all the PNG graphics reduced in bit-depth (as far as possible) yet or was this just a theoretical discussion? ^_^
It was discussed... and Rockthesmurf said maybe he'd write a script... I think.
Apart from that yeah the images still need some "optimising".

The end of the week will be the RC build. I'll send Pandora builds to those that can run it and if there are no problems the RC will be the release. And yes I'll try to cover the main build targets!
 
Last edited by a moderator:
PokeParadox said:
The end of the week will be the RC build. I'll send Pandora builds to those that can run it and if there are no problems the RC will be the release. And yes I'll try to cover the main build targets!

Great! I'll see if I can squeeze some time off my schedule to test and report back :)
 
Last edited by a moderator:
PokeParadox said:
fusion_power said:
Are all the PNG graphics reduced in bit-depth (as far as possible) yet or was this just a theoretical discussion? ^_^
It was discussed... and Rockthesmurf said maybe he'd write a script... I think.
Apart from that yeah the images still need some "optimising".
If this really is an issue, why not use the "optipng" tool to do the PNG compression and palette alteration? (tl;dr you find a "script" at the bottom to optimize all images)

caket.png, before:
http://img194.imageshack.us/img194/1363/caket.png

After having used "optipng -o7 <file>":
http://img20.imageshack.us/img20/1363/caket.png
...which is a 24.18% file size decrease (26104 bytes less)

Note that this method:
1. Does not alter the image in any shape or form. It looks *exactly* the same, pixel for pixel, as it did before compression. Aka, the compression is lossless (duh)
2. Only does compression and palette swaps, nothing more, nothing less

Using this method, you don't have to choose the number of colors your images should have; optipng automatically chooses the right format for your images, and no quality is lost, ever. And you can use this program like it is; no need to create a script. ("find -name "*.png" -exec optipng -o7 '{}' ;" optimizes all images recursively in the current folder)
Even if you do decide that reducing the palettes statically for all images is what you desire, then please run "optipng" after you're done anyways, to further reduce the size of the file.

You'll find optipng as a package for your favorite Linux distribution, or just visit the home page

tl;dr your script:
Code:
#!/bin/sh
find -name "*.png" -exec optipng -o7 '{}' ;
exit 0
 
Last edited by a moderator:
Thanks! it worked wonders shaved about 2-3MB off the images... unfortunately it also makes it difficult to get Pixel values... so I get some transparency issues.
I realise something in my code needs fixing since the pngs should work the same before and afterwords but right now, it doesn't make sense to spend time looking into this when we have a game to finish! :)

But thanks again! I'll keep that script handy.
 
Back
Top