Getting frustrated in thinking about how to handle things like bullets without loading the same graphics 30x over, I figured that there must be some way to have the engine know if the tiles for the bullets are already in vram so that they wouldn't have to be uploaded extra times. At first, I figured bullets would have to look through the object table for other bullets, and then see if they're on the same frame, but I figured, why not just look through the giant vram table for them while looking for empty slots? I mean, this is how it would work: there'd be table with 128 entries, with each entry stating the 16x16 tile identity, and how many objects are using that 16x16 tile. If no objects are using a tile, it can get overwritten. (Every time and object is done using certain tiles, it find them in the vram table, and subtracts one. That way, you don't delete it if other objects are using it. I don't know how I'm going to go about implementing this too.) When requesting new tiles, you look through the list for a tile identification number that matches yours (4 for 32 x 32 sprites) and if it's correct, you set a flag or something in the object tile request table that says not to upload the tile. If an empty spot is found after going through the list more than once, it has the flag set to upload. Now, one problem of many about this is that 32 x 32 sprites need 4 checks instead of one if you were using bits to just say if a tile is occupied or not. However, the very slightly good news about this is that the process of converting the result of where an identical tile or empty space doesn't need to be quite as difficult. Also, this could make one object using another objects double buffered sprites way easier, like if I had 2 64 x 64 explosions 2 frames off from each other, I would only need 2.5 64 x 64 sprite tiles vs.. 3 64 x 64 tiles, and this would also cut the bandwidth down by half.
SA-1, here I come... Oh boy... Again though, if it weren't for stupid PPU related stuff like this, the CPU's workload would be way less. I think I'm actually going to end up doing more processing for things like this than the actual game.
You know though, I also find it kind of weird that something that seemed pretty obvious to me like looking through vram for open slots for each sprite had never really been done before. I've come to learn that with these kinds of games, there are two types: One that goes for the Super Mario World approach where everything is pretty much static in that vram and cgram pretty much stay the same throughout the whole game and don't change depending on the situation, and there's the Donkey Kong Country approach, where everything is dependent on what's on screen, in that new tiles and palettes are being loaded in and out all the time for the different situations, and it's not hardcoded. It's fairly obvious which one leads better results, even if it takes a good bit more processing power. (Strangely enough, many Neo Geo class arcade board games take the DKC approach when it comes to palettes, even though I'm pretty sure you could store all the palettes for all the objects in Metal Slug without changing anything, and would only need to change the "BG" palettes between levels, if even. Palettes are always something this systems had a ton of relative to home systems, even though no other difference between them is nearly as drastic. I guess palette ram space doesn't become as much of an issue when it's outside the video chip, then it's just like vram.)
Maybe I should look at the Irem M92 again. I'll probably just get annoyed due to lack of good documentation though like I did last time...
SA-1, here I come... Oh boy... Again though, if it weren't for stupid PPU related stuff like this, the CPU's workload would be way less. I think I'm actually going to end up doing more processing for things like this than the actual game.
You know though, I also find it kind of weird that something that seemed pretty obvious to me like looking through vram for open slots for each sprite had never really been done before. I've come to learn that with these kinds of games, there are two types: One that goes for the Super Mario World approach where everything is pretty much static in that vram and cgram pretty much stay the same throughout the whole game and don't change depending on the situation, and there's the Donkey Kong Country approach, where everything is dependent on what's on screen, in that new tiles and palettes are being loaded in and out all the time for the different situations, and it's not hardcoded. It's fairly obvious which one leads better results, even if it takes a good bit more processing power. (Strangely enough, many Neo Geo class arcade board games take the DKC approach when it comes to palettes, even though I'm pretty sure you could store all the palettes for all the objects in Metal Slug without changing anything, and would only need to change the "BG" palettes between levels, if even. Palettes are always something this systems had a ton of relative to home systems, even though no other difference between them is nearly as drastic. I guess palette ram space doesn't become as much of an issue when it's outside the video chip, then it's just like vram.)
Maybe I should look at the Irem M92 again. I'll probably just get annoyed due to lack of good documentation though like I did last time...