Quote:
Originally Posted by Tsak
Nice work 
However would you like to elaborate further in regards to which part from that video is debunked? You say doing the player sprites with the blitter/cpu things become complicated. What do you mean? No enough blitter time left? Issues with ordering? Something else? |
Let's say they have the whole front playfield spare and use it purely for the player sprites as I recall they said they would do in their video. For the first player they can get away with a combination of straight blits and CPU moves to render the first player. For the second player, things are more complicated because that player has to be cookie cut into the playfield. So this means they have to hold a copy of the mask as well as the bitmap data.
Let's also assume they can hold all player frames unpacked in ram (which they can't) as they are rectangles up to 128x128 in size, the blitter can't render that size rectangle as a straight copy and then the same size again in a cookie cut .... and THEN clear them again in one frame.
So holding all the frames unpacked in ram... they run out of chip ram.
Packing the frames in ram? Well then they have to unpack the frames into the correct position using the CPU...doubtful at 50FPS. They might be able to hold the first frame of each move in ram and unpack the rest but again I'm dubious about this with the ram requirements.
Don't forget that each opposite frame needs to be mirrored and shifted on the fly too. (taking into account the trick Dan mentioned about holding the upper and lower sprite parts in different directions - most of the times the players will face each other which negates the need to do this, but I accept it is an efficiency)
Let's say they do what I did and create 16x16 tiles of each sprite and rebuild them each frame, this is doable until it comes to the second player because the mask then needs to be included when mirroring the frame along with being shifted.
Knowing what I know now they could look to hold mirrored copies of the tiles in chip ram and use the blitter purely for rendering with the barrel shifter, but then even this approach would need calculating and cookie cutting would be intensive.
Quote:
Originally Posted by Tsak
Other than that I should note that Dan might have a point with the projectiles and effects ordering. How would you approach this issue?
|
Effects can be blit into either the playfield or a hardware sprite - makes no difference, colours in both the hardware sprite playfield and front playfield would have to be reserved though.
Quote:
Originally Posted by Tsak
Another question is in regards to frames, character tiles and ram. Can you still have the characters saved and stored split into 16px wide tiles/parts and reconstruct them as 64 wide sprites or to use sprites you need to save each frame/part only as a 64 wide one? I was under the impression that when you choose to use f.e. 64 wide sprites you can only have the parts saved as 64 wide as well, so f.e. even if a character frame is much less (say 32px wide) you are still forced to save it as 64 wide non the less.
*edit: by 'saved' I mostly mean the chip ram it needs to occupy (which is the main issues here), not the disk/storage space.
|
Yes, 64 wide sprites does not mean tiles need to be 64 wide. You allocate
chip ram filling up the size you need and then fill it with what ever bitmap you want, no need to shift it, and the data in there is not affected by other things going on in the playfield so you can keep the data there for multiple frames at zero cost.
Apologies if I waffled on.