RAM on page 0 for megarom

صفحة 2/2
1 |

بواسطة retrocanada76

Hero (538)

صورة retrocanada76

28-10-2011, 16:14

I am already doing this Metalion, but the problem are the coins, ? boxes and everything else which is dynamic in the game.

Look, the map is omni-directional. It's different from manbow where you scroll right, then after a precise place start diagonally or up. Manbow is a shooter on the rails, you can't control where are you going on the map. In this case of game you can set a list of events and when the map goes left or right you just adjust the pointer.

But mario isn't it. I have a list of events for a huge 2D map. The map has around 19k. Every time I read the map from rom and I find a coin I need to check the event list if it was already consumed or not. If it was, then draw a blank space on it, if not draw the coin.

So basically when I find a coin, I look in the event list (a loop from beginning). The next coin in the same row will be the next on to the last found.
But for the next row, I will need to loop from last position to skip the rest of the line. Did you get it ? I'm looping like a mad to get the correct event. I tried indexing the event list by row, but it adds complexity and cost to the loop.

And when mario jumps and hit his head I need to loop again through the event list to find the correct event and set/consume it appropriately. I'm caching the first event found in the map reading, but i still have to loop it. Also, using a event list means I'm limiting the number of coins, boxes, etc. The enemies spawnpoints are in the same list.

I could divide the map in rooms, but this also adds complexity to the code. I could have to check between four rooms when drawing a map if I am in the crossing borders of the rooms.

So copying the map from rom to ram i could flag set/consume the coin right on the map, avoiding looping like map. Understood ? No map are bigger than 20k. So that's my need for 32K of RAM.

بواسطة retrocanada76

Hero (538)

صورة retrocanada76

28-10-2011, 16:21

I can use quad-trees but hey it's an 8-bit processor. That's not cheap iterating trough, even a quad-tree will end up having a list at the last quad. Doing this is assembly is hard too.

بواسطة Metalion

Paragon (1558)

صورة Metalion

28-10-2011, 18:54

I don't understand all your limitations ...

But you would gain by splitting your map in rooms and indexing a limited number of events per room.
You would only need that list in RAM.

بواسطة retrocanada76

Hero (538)

صورة retrocanada76

28-10-2011, 19:25

but even though when I copy the map from rom to ram (then after i copy to vram in the vsync) for each tile i get from rom i need to compare to check if it's an event or not. If it's an event, i need to find it's room and then look for each event in that particular room.

Another problem: how to find the room.

The world11 map is 352x54 tiles (this is the original NES size). It takes 18.56Kb. If I round up to next power of two, that would be 512x54 = 27Kb. So I will be wasting around 10k just to make me easy to find the room. Unless I perform a division by 352 (which is expensive, 1 per 4 tiles in worst case when you get a room full of coins) or I work with 2 maps = 256 + 128. but this will make everything more complex, finding the correct map, subtracting the offsets, etc and I still need to find the event in the list.

So for me would be much more easier to have it in RAM. It's there why it looks wrong if I take it ?

بواسطة sd_snatcher

Prophet (3551)

صورة sd_snatcher

28-10-2011, 22:47

So for me would be much more easier to have it in RAM. It's there why it looks wrong if I take it ?

Hey, it's your hobby! There are no rights or wrongs. I was just curious, as it's an interesting project. Smile

بواسطة Sonic_aka_T

Enlighted (4130)

صورة Sonic_aka_T

29-10-2011, 12:11

Keeping the map in RAM makes perfect sense to me (if you can afford it memory wise). I once tried building a generic RPG engine and had all map data in RAM, layered even, which made updating events/states etc that much easier. If you have enough 'space', I'd say go for it. The easiest (laziest) way is usually the best (and fastest) on these systems...

بواسطة hit9918

Prophet (2925)

صورة hit9918

30-10-2011, 21:33

2D event map: you could have another table next to the nametable. Then you can keep the nametable in ROM. The event map can go in 16x16 pixel granularity, 25% size of the nametable in RAM.

But how would one place tanks on a 8x8 position? Maybe with using 4 different event IDs for tanks.

But how to place 2 tanks in a 16x16 grid? High nibble of the byte could be ID, low nibble "additional info", 4 bits to set 4 tanks in a 16x16 grid.

I never found one clear answer, another one is:
The event map can point to a list where every entry can have multiple bytes to describe things. These bytes even could describe a pixel granularity position of the thing. So the map no more contains obj ID but obj number. A new limit, max 255 things in a level.

صفحة 2/2
1 |