Running out of VRAM FAST!

undisbeliever · Post by **undisbeliever** » Sat Aug 21, 2004 3:10 am

I have personally started to create a Zelda Clone engiene. but I'm having some problems.

The first and up most important is the VRAM issues. I am faced with a limit of 512 tiles and my sprites take up six of these per frame. Now if I use a minimum of 4 frames per direction to get a decent animation I would very easily run out of VRAM with 5 different monsters on the screen (considering they all are in the same format) before I even get a chance to add weapons animation.

I have thought a bit about this and had considered that if I could copy the current direction of the sprite directly from the ROM onto the VRAM during each VBlank (only if its direction changes) then I could effectively reduce my VRAM usage by a lot. The only objection I can come up with is that this constant transferring of Data would seriously cut into my VBlank time. I think it might work but I'm not sure, If you can help, please let me know.

PHoNyMiKe · Post by **PHoNyMiKe** » Sat Aug 21, 2004 4:21 am

16 bit games usually use a few OAM entries for the characters, and when the tiles need changing, the new tiles are copied over durring vblank. Zelda 3 does this exact thing. Maybe make a savestate and check it out with vSNES to see how it manages the VRAM.

Nightcrawler · Post by **Nightcrawler** » Sat Aug 21, 2004 4:57 pm

Agreed. Look into Sprite usage on the SNES(Sprite/OAM registers). Check several sources of documentation because you may find slightly inaccruate infromation and/or another source will help explain the register better if you don't understand.

neviksti · Post by **neviksti** » Sun Aug 22, 2004 12:54 pm

It sounds like you already have a good hold on what the issues and tradeoffs are. [Well, except that you seem to have forgotten about sprite flipping.

Let's say you want to have the characters/monsters walk in 4 directions ... due to sprite flipping you only need to draw pictures for 2.

In your case:
6 tiles/frame * 4 frames/direction * 2 directions = 48 tiles

This allows you to have up to 10 different animated objects in the format you suggested.]

Good dynamic loaders are annoying to code because you need to make sure to anticipate what pictures you will need since only so much can be loaded per vblank (although from the wording of your concern, I have a feeling you're underestimating how much can be transferred ... it is annoying though). I don't remember off hand how much can be transferred per vblank ... and due to the "refresh periods" where the system is stalled, which isn't currently emulated ... your best bet is to do a quick test on the system to answer this. If you still don't have something to allow running code on the SNES, I have a 32Mbit NTSC copier I can lend you (you sound dedicated enough that you really should have one). For PAL you need to remove a chip from a game and place it in the copier. Or I can run code for you (I don't have much time to write tests myself though).

Anyway, back to dynamic sprite loading ... If you need to load almost as much (or more) data per character than you have spare vblank time, then it becomes very hard to write a set of routines that isn't intricately intwined into how your game is setup (ie you are forced to make decisions on how the object and graphics engine handles everything carefully ... and then stick to that. This is frustrating because since this is your first game for this system, invariably you'll want to change somethings as you are learning.)

Therefore, I strongly suggest two things:

1) decide roughly how you want the game screen to look while you are playing (remember that the outer 10 pixels all around the screen isn't garaunteed to be seen on all TVs due to overscanning, so don't place important things like stats there). Choose sprite sizes that fits well with what you want the screen to look like ... draw a few and see what it looks like. Once you are happy with the scaling of things, draw all the sprites. (Don't go overboard with tiles and frames. Often enemies don't need as many ... or the upperbody/head can be reused between different frames.)

Also notice how much stuff looks comfortable on the game screen. Ten things of 6 tiles each sounds really crowded.

2) NOW decide how to handle that size of data. Here's some obvious suggestions (sorry I can't be more helpful, you probably already know this stuff).

- Usually you can get away with separate "scenes/areas". ie somethings are only seen in a forest, some in caves, some in castles ... if you can separate it nicely like this, AND there is a cut-scene transition (ie you walk into a hole you see in the forest, suddenly the screen cuts to you in a cave) you should be able to get away with static loading before each "scene".

- "Simple" dynamic loading ... for lack of a better term. Sometimes the problem is that you want the main character amazingly versatile. The result is he's/she's really hogging the VRAM. If you are lucky, changing _just_ the main character to dynamic loading gets rid of the huge hog and everything else can be static. So everytime the main character frame changes, load new data. This is nice because it should easily fit in one vblank and you don't need to predict what you'll need. Also, you can easily tell what the largest data chunk you need during vblank is. So you can easily test the engine to see if there are vblank time out problems.

- "Simple predictive" dynamic loading. Okay, if cut scene transitions don't narrow the animated object list enough, then you may be able to get away with "constrained beasts/objects". If you design the map so that there are "sections" (but still smooth transitions) like walking through a field then into a forest, then up into the mountain. Then design the beasts/objects so that they stay in their "habitat". Then you should be able to tell from your position on the map alone, what picture sets you'll need. The picture sets will be defined ahead of time, and looking at the map you should be able to see what is the most "memory stressful" transition. So again, you can easily test the engine here (even though it is more complicated to write and you need to be aware of limitations when designing the map which can be annoying).

- Full dynamic loading. There are many ways to do this. I would proceed along the following:
Know exactly how much vblank free time you have. In software have a buffer zone larger than the screen ... when animated objects enter this, check if their picture is needed, put it in the queue to be loaded if not ... when animated objects leave the buffer area, check if there are no more of those objects in the buffer area; if so, mark that vram as unused.

What if there isn't enough room (which is what brought us here in the first place)? I don't know. Have the animated object enterring the buffer (which still isn't viewable) disappear if that is reasonable ... or have other "beasts" run away.

That question is important (if it wasn't you should be using an easier method in the first place). It is also this issue which makes the code become intertwined with the engine in ways it doesn't seem it should have to. One consequence of this: it is very hard to test because each situation is unique. You're no longer testing the engine, you're testing "compatibility" of each situation. Plus, as mentioned, the intertwining prevents reuse of much of the code... or even just modifying the game without large difficulties.

Well, I wish you luck on your project. It sounds like fun!
-neviksti

EDIT: You wrote: "I have personally started to create a Zelda Clone engine."
Sorry, when I wrote my response I assumed you are going to make a Zelda Clone, or at least a game with similar mechanics. I hope that's what you meant (I'd love to play it

).

If you are just making the engine for others to use ... hmmm... I don't know. I guess just choose one of the methods that seems reasonable. This is hard to do without knowing what the end product is. If you really feel ambitious you could choose your favorite and then add the others as options to your engine as you see fit.

FistOfFury · Post by **FistOfFury** » Wed Sep 01, 2004 5:41 am

Would moving the most often used stuff to the direct page area and then using more direct page addressing code help here, or are you guys talking about something different? *confused*

neviksti · Post by **neviksti** » Thu Sep 02, 2004 6:22 am

He's talking about VRAM, which the CPU cannot access directly. So the CPU memory addressing modes don't really come into play here.

What he's discussing is kind of summed up by: "Graphics take up a lot of memory. VRAM can't hold it all. What can I do?"

undisbeliever · Post by **undisbeliever** » Thu Sep 02, 2004 7:14 am

Thanks, but neviskiti I think you made a mistake somewhere.

Let's say you want to have the characters/monsters walk in 4 directions ... due to sprite flipping you only need to draw pictures for 2.

even if I used sprite flipping then I would need 3 sprites because if you flipped the moving up sprite then it would be upside down.

FistOfFury · Post by **FistOfFury** » Thu Sep 02, 2004 8:23 am

neviksti wrote:He's talking about VRAM, which the CPU cannot access directly. So the CPU memory addressing modes don't really come into play here.

What he's discussing is kind of summed up by: "Graphics take up a lot of memory. VRAM can't hold it all. What can I do?"

Oh Ok, thanks for the explanation. I still haven't really learned about the VRAM stuff yet, just trying to help out

neviksti · Post by **neviksti** » Thu Sep 02, 2004 8:56 am

marcthemer wrote:Thanks, but neviskiti I think you made a mistake somewhere.

Yep, you're right. I was thinking of a completely overhead view for some reason.

Also, buried in my babbling above, I wrote:
If you still don't have something to allow running code on the SNES, I have a 32Mbit NTSC copier I can lend you (you sound dedicated enough that you really should have one). For PAL you need to remove a chip from a game and place it in the copier. Or I can run code for you...

Are you interested in the copier? If not, let me know since FistOfFury expressed some interest in it.

undisbeliever · Post by **undisbeliever** » Sat Sep 04, 2004 6:07 am

Sure, I'll accept.

It's a weird thing that I don't have a copier yet. I'll hope it works

I'll send you my deatils through hotmail.

neviksti · Post by **neviksti** » Sun Sep 05, 2004 3:14 am

I think you may have forgotten to send the email (or maybe it bounced), because I didn't receive anything.

undisbeliever · Post by **undisbeliever** » Sun Sep 05, 2004 5:50 am

Oh, Ill send them again OK.

Overload · Post by **Overload** » Sat Sep 18, 2004 12:54 am

Copier for sale. If your interested I'd email the dude asap and make him an offer before they pull it from the listings.

http://cgi.ebay.com.au/ws/eBayISAPI.dll ... Track=true

adventure_of_link · Post by **adventure_of_link** » Sat Sep 18, 2004 2:01 am

If it's supposed to be a copier, how come it's got two pics of a "how to win at video games" guidebook, plus a pic of the copier itself?

PS: How can some SNES games fit on a 3.5" Floppy disk, when they can be over 2Meg?

Post by **badinsults** » Sat Sep 18, 2004 6:21 am

adventure_of_link wrote: PS: How can some SNES games fit on a 3.5" Floppy disk, when they can be over 2Meg?

You can split files up. Why do you think Snestool was created? Besides, the demos he is making are small enough to fit on a floppy.

adventure_of_link · Post by **adventure_of_link** » Sat Sep 18, 2004 6:49 pm

Oh ok, thanks Evan