#27399 - noaktree - Tue Oct 12, 2004 6:34 am
I guess I'm the idiot that posted gbadev.NET kicks ass..and not to take away from that site (if it exists) but I did intend it for gbadev.ORG. Sorry!!
So just to make up for my mistake.
gbadev.org kicks ass!
gbadev.org kicks ass!
gbadev.org kicks ass!
gbadev.org kicks ass!
gbadev.org kicks ass!
That should do it.
Hope everyone likes my game. But let me know if you think it sucks too.
http://www.gbadev.org/index.php?ID=441
Neil
_________________
_Neil
#27406 - Lord Graga - Tue Oct 12, 2004 1:07 pm
YOU MUST BURN IN HELL FOR YOUR MISTAKE! (not)
Mortal Pong is a good first game, but it's inredibly large in it's filesize, and it's not very original in it's gameplay, no? :)
Let us see you do something original and shiny ;)
#27422 - noaktree - Tue Oct 12, 2004 7:35 pm
Yes mortal kombat is a rip off and it is my first game for the GBA.
The file size is so very large because all the graphics are in 256 color.
Mostly I made this game to test out a little memory manager that I wrote. It's the shiny part for me and I'm very proud of it. The manager uses a first fit - compress algorithm to insert sprite data throughout the VRam.
Anyway if you're interested in shinny things you could check out a few games I made for the PC and Pocket PC at www.oakentertainment.com
_________________
_Neil
#27425 - Lord Graga - Tue Oct 12, 2004 8:25 pm
Heh, because all pics are 256 it doesn't mean that the ROM has to be huge :)
Use GBACrusher to compress your images, then use the BIOS decompression function to decompress :D
#27427 - noaktree - Tue Oct 12, 2004 9:55 pm
Thanks for the tip Lord Graga!
I'm planning to port my Meditation strategy game to the GBA. It would be nice to have have a smaller ROM size.
_________________
_Neil
#27435 - Lord Graga - Tue Oct 12, 2004 11:07 pm
Heh, go on then :)
#27447 - noaktree - Wed Oct 13, 2004 3:27 am
Do you know of any code examples that deal with BIOS decompression?
Also is there a way to just compress the whole ROM and not individual sprites?
EDIT
I just found this site for helping me with the compression:
http://members.iinet.net.au/~freeaxs/gbacomp/
But I'm still wondering about the ROM compression.
_________________
_Neil
#27450 - sajiimori - Wed Oct 13, 2004 4:18 am
Your startup code will obviously have to be uncompressed in the ROM, but besides that you can compress whatever you want. Just keep in mind that you'll need RAM space for everything you decompress.
Also, dynamically decompressing code is not trivial (symbol relocation) and it's probably not worth the effort on systems like GBA where you can run code straight off the ROM and graphics/sound usually outweigh code by quite a lot.
#27458 - noaktree - Wed Oct 13, 2004 7:34 am
Thanks sajiimori - good stuff.
I have a related question directed to anyone:
In my game...
I used pcx2gba for all background gfx.
I used pcx2sprite for all sprite gfx.
My first step in adding compression will be to build an image converter that converts 8bit bitmaps to a binary file (which will then be compressed by GBACrusher).
What I don't understand...
When I take the exact same 8bit bitmap and convert using both pcx2gba and pcx2sprite I get two different header files. On closer inspection I see that the palettes for both of these headers are identical, yet the image data is either ordered differently or is perhaps different all together?
Why are there two types of 8bit images for GBA? What are their differences?
_________________
_Neil
#27469 - Lord Graga - Wed Oct 13, 2004 5:49 pm
pcx2gba = linear data (mode 4 backgrounds)
pcx2sprite = block data (8x8 tiles/sprites)
#27473 - noaktree - Wed Oct 13, 2004 7:22 pm
| Quote: |
pcx2gba = linear data (mode 4 backgrounds)
pcx2sprite = block data (8x8 tiles/sprites) |
Please elaborate.
_________________
_Neil
#27476 - sajiimori - Wed Oct 13, 2004 8:01 pm
I don't know anything about those 2 programs, but Lord Graga seemed to be saying that one of them outputs linear pixel data (i.e. full rows of pixels, top to bottom), and the other one outputs "charified" data (i.e. split up into 8x8 chars).
#27569 - tepples - Fri Oct 15, 2004 9:22 pm
| noaktree wrote: |
| Also is there a way to just compress the whole ROM and not individual sprites? |
Something to do with compiling as multiboot, compressing the binary, and adding an unpacker to decompress it at runtime. See UPX or Pucrunch to learn how this works in practice on another platform. Has anybody made a multiboot unpacker for GBA yet?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27696 - noaktree - Tue Oct 19, 2004 10:31 am
Thanks tepples.
Well in order to please Lord Graga I developed an image conversion / compression tool called iMage+. It uses GBACrusher's LZ77 algorithm to compress. It exports to binary with or without palette - or palette separately- backgrounds and sprites.
I don't think I'm going to waste my time remaking Mortal Konsole though. Compressing all 100 + separate images doesn't sound like fun for a game that nobody seems to care about. But it should come in handy for future projects.
See iMage+ here: http://www.oakentertainment.com/gcdev/iMage+.html
I'm not going to post it to gbadev.org until I've got all of the bugs worked out.
Just wondering... has anyone unlocked the pinball machine in mortal konsole yet?
Oh and thanks again to tepples... I used your 0-255 / 11 + 8 formula when converting to 15bit. Works great!
_________________
_Neil
#27700 - keldon - Tue Oct 19, 2004 4:49 pm
People do care about this game, just that I think they have little they can say that will contribute in anyway. I think battling arcades it pretty cool =D reminds me somehow of the days of watching Transformers.
Gameplay adjustment
Whilst the joypad is not being moved a power meter (visible or not, preferably visible) grows, and increases power of shot, speed slowly decreases over its travel to the standard speed. This rewards the player for figuring out where it will bounce first time and adds a visual variation.
p.s. why did not choose not to allow a the position of contact to slightly vary the angle of the bounce? Would have added, since there is a simple method and strategy for defeating the CPU player (or human player in the case of AI).
EDIT: although there could have be some player input to the angle that wasn't so obvious
#27719 - tepples - Wed Oct 20, 2004 12:31 am
| noaktree wrote: |
| I don't think I'm going to waste my time remaking Mortal Konsole though. Compressing all 100 + separate images doesn't sound like fun for a game that nobody seems to care about. But it should come in handy for future projects. |
Or you can have your makefile compress them for you by calling a command line tool.
| Quote: |
| Oh and thanks again to tepples... I used your 0-255 / 11 + 8 formula when converting to 15bit. Works great! |
You're welcome.
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#27726 - noaktree - Wed Oct 20, 2004 2:18 am
| Quote: |
| Or you can have your makefile compress them for you by calling a command line tool. |
The thing is I already have the pics compiled into seperate libs. To compress them I'd have to have them in a binary format and not compiled headers. It was a crappy way to do things but lesson learned.
| Quote: |
| why did not choose not to allow a the position of contact to slightly vary the angle of the bounce? Would have added, since there is a simple method and strategy for defeating the CPU player |
I just added some random angles for now. New version available here:
http://www.oakentertainment.com/gcdev/projects/MortalKonsole.zip
_________________
_Neil