#1507 - D3z - Sun Jan 19, 2003 6:09 pm
what's the best way to update VRAM without cpu slowdown?
i've got RLE compressed sprites in game rom...
#1509 - Kay - Sun Jan 19, 2003 6:14 pm
First of all RLE is a time consumming technic to store sprites to be updated dynamicaly to VRAM.
Best way to leave them uncompressed to ROM and doin' transfer with DMA3.
-- Kay
#1510 - D3z - Sun Jan 19, 2003 6:21 pm
| Kay wrote: |
First of all RLE is a time consumming technic to store sprites to be updated dynamicaly to VRAM.
Best way to leave them uncompressed to ROM and doin' transfer with DMA3.
-- Kay |
that's a good performance solution.
but what about ROM used? i think that sprites remains uncompressed after BIN or GBA file is created..
i saw games like Street Fighter Alpha 3, King of Fighters and Tekken 3 that uses a lot of 16 colors sprites in the game.. using a 64-128Mbit ROM
how can it be done?
#1511 - Kay - Sun Jan 19, 2003 6:31 pm
Combat game sprites are stored fractionnaly into ROM.
Even if you see a 64x64 16 colors sprite on screen, it's certainly possible that characters are composed with a bunch of 16x16 attached sprites.
This method reduce considerably the amount of memory used by sprites in ROM.
-- Kay
#1512 - D3z - Sun Jan 19, 2003 6:39 pm
| Kay wrote: |
Combat game sprites are stored fractionnaly into ROM.
Even if you see a 64x64 16 colors sprite on screen, it's certainly possible that characters are composed with a bunch of 16x16 attached sprites.
This method reduce considerably the amount of memory used by sprites in ROM.
-- Kay |
so it's possible that sprites are composed of 8x8 4bit blocks, each one tranferred into vram with one call of dma3...
#1513 - Kay - Sun Jan 19, 2003 6:54 pm
Transfering only 32/64 bytes with DMA is not the optimal way, since loading DMA registers take a minumum of 6 ARM instructions (equivalent to 12 transfered bytes).
Better way is to transfer @ mini 128/256 bytes a time.
This is depending what language you use to code.
To perfectly master CPU time, you may code in assembly, otherwise use C/C++.
But, if they're only 2 characters onscreen ... no need to optimise !!! :)
-- Kay
#1515 - Splam - Sun Jan 19, 2003 7:08 pm
RLE is slow unless you use deltas which will make your sprite even smaller and faster to transfer BUT means you're limited to playing the animation sequentialy and not randomly.
Kay is correct about larger sprites being built from smaller tiles to save space. My grabber and gba side code does this. You just give it a rectangle around each sprite, it skips all 8x8 blank areas then allows you to use two methods to display it, either all 8x8 sprites OR will intelligently build the larger sprite out of smaller ones, so for example a 64x64 may be made up of a 32x32 a 16x16 and a couple of 8x8s with some of the 64x64 area "missing". That way the dma can always be 1 transfer for the whole sprite BUT you don't waste any space.
#1525 - ampz - Sun Jan 19, 2003 8:58 pm
That's a bad method.
The way to do it is to coordinate with the person who makes the sprite animation. That way you can store separate bodyparts in separate tiles (the lines between the bodyparts doesn't have to be straight), this makes for some major space savings when doing complex animated sprites like fighters.
If the fighter takes a blow on the head, just run the head_hit animation on the head-sprite, the rest of the body remains the way it is.
You get some great flexibility, your code becomes nice and clean, and you save lots of space.
Besides... why do you worry so much about ROM space??? You can fit 2000 uncompressed 64*64 sprites into a 64Mbit ROM.
#1529 - Splam - Sun Jan 19, 2003 9:17 pm
hmm theres no reason why the way I do it couldn't also use the "overlayed" sprite method so its not a BAD way to do it, it's smaller, faster than any other way if you don't have the ability to use overlays, not all sprites can be done using that method so if you rely on it then you're screwed. Figther taking a blow on the head, head moves, great, saves space, looks bad, I would want the whole sprite to move, if I were to punch you in the head your body would move not just your head.
Still people are entitled to use their own methods but please don't call someone elses BAD until you're sure it is. eg I'm hiring you to convert a game from one platform to gba, the sprites are already drawn as solid frames, you don't have an artist to alter them to do them your way, now what??
As for worrying about ROM space, your games must be fantastic if they're just 2000 64x64 sprites , hmm, no music, no backgrounds, no complex code, ahhh, no game ;)
#1531 - tepples - Sun Jan 19, 2003 9:26 pm
| ampz wrote: |
| If the fighter takes a blow on the head, just run the head_hit animation on the head-sprite, the rest of the body remains the way it is. |
Not so simple. A fighter who takes a blow to the head moves more than just the "neck" joint. The entire upper torso moves back a bit, and the shock propagates downward until the feet correct the stance, then the correction propagates back to the legs, torso, arms, and head. However, I do see your point as to how jointed character models could improve flexibility in a sprite system.
| Quote: |
| why do you worry so much about ROM space??? |
Because single-pak multiplayer requires the entire code to fit into the 256 KB EWRAM on the slave machines.
| Quote: |
| You can fit 2000 uncompressed 64*64 sprites into a 64Mbit ROM. |
Aren't 64 Mbit ROMs more expensive than 32 Mbit ROMs? And aren't there also backgrounds, maps, and audio samples to worry about?
_________________
-- Where is he?
-- Who?
-- You know, the human.
-- I think he moved to Tilwick.
#1534 - ampz - Sun Jan 19, 2003 10:02 pm
Sorry, I didn't really meant it that way.
What I meant is that relying on programs to convert your graphics into something you can use on the GBA is not the optimal solution. In order to get good results the graphics should be made with the GBA hardware in mind.
I know of one guy who painted this good looking background for a platform game in photoshop. Then he relied on a automatic tile-conversion program to generate tiles and a tilemap from it.
Of course, this consumed almost the entire VRAM for some segments of game.
The way it should have been done is of course the oposite. Draw some tiles, and then make a map out of them using a map editor.
Just dumping a folder of animated sprites into a automatic converter does produce useable output, but by keeping the GBA hardware in mind, already when you paint the sprite, you can often get a much better result.
It's sorta like when you are coding. You can either rely on the compiler to do a good enough job, or you can write the code so that it is optimized for the intended hardware.
#1535 - Splam - Sun Jan 19, 2003 10:22 pm
Admittedly having the artist work to the gba specs is better especially as you say with backgrounds. The last place I worked the artist had to do a rot/scale background, I think he used dpaint for it, anyway he made it look nice, converted it, something like 100 tiles too many. Sometimes though (as I mentioned) it's just not possible to have the artist work to constraints you set, either the gfx are already done or they're too stupid to understand (trust me, there are some around who want to create ART not GAMES :( ) and even if you can get them to do overlaid sprites they would only be usefull in a handfull of cases. We've already talked about the fighting game (not much use there if you want it to look good) so..
A shoot-em-up set in space.
Big end of level sprite, it only animates gun turrets etc on its surface. Whats the point of having EXTRA sprites overlaid over graphics that are already there when you could replace the 8x8 16x16 etc whatever size that is already there and bounds the animating turret ?
My grabber produces more than "useable" output it WORKS and it creates packed tile based graphics (with repeated tiles removed too) either for sprites or backgrounds which are then very easy to handle, fast to draw and small in size, certainly enough for any use I could imagine. Nearly every game I've worked on uses the same technique and it's time tested and proven to be the best way unless memort is REALLY low in which case I would add an RLE pass to the data.
In the end it all depends on the human resources available and the graphic assets you're provided with and what tools are available to you, my grabber has been in development for many years and can be used for any purpose, maybe someone starting to write one with no prior knowledge wouldn't produce something as useable.
#1542 - ampz - Sun Jan 19, 2003 11:36 pm
Yeah, I know, there are artists that don't understand that graphics, code, audio, and hardware should be made to work well together.
#1546 - Kay - Mon Jan 20, 2003 12:13 am
When coding games on handheld console system, don't miss something important: memory size is important, especially if size of ROM is fixed at 32Mbits by commercial agreements.
-- Kay