Views: 838,943,903
31 users online: Aeon, Aligus,  Anorakun, Atomicatoms, avestus, buggy789, carlmeow, Copyright,  Deeke, eric99333, Fermín Acosta Jr.,  FPzero, Green Jerry, Hooded Edge, KiloMinimo, LOLRyan2006 the Goombud, Mario is the best, mario90, MassPunishment, mikairanutshack, Minish Yoshi, morisot, Pat, Romano338, SimFan96, Sixcorby, SuperHack64,  Teyla, tjb0607, TomatoPhalanges, Umdlye - Guests: 65 - Bots: 73 Users: 45,931 (3,307 active)
Latest: NutBomber
Summer C3 2020 Content Spotlight
Not logged in.
A rather dumb question I couldn't find an answer to
Forum Index - SMW Hacking - SMW Hacking Discussion - A rather dumb question I couldn't find an answer to
Pages: « 1 »
Apologies for such a dumb question, but I looked around and couldn't find an answer. While I know that a graphics file must be 4 kb, why must it be this way? I understand that there's borders to deal with and stuff like that, but why can't this just be expanded? I don't have a problem with ExGFX, but there are limited slots for ExGFX, and my room for custom graphics in a single level is limited.
i dont have your answer, but i guess it involves a hardware/vram limitation.
from what i read, snes vram cant be expanded through the cartridge, so you cannot expand that.. Tho ive heard in the past someone made a patch that allowed inserting more gfx to the levels. Ive never seen it, maybe someone else could say something about that
It's not a dumb question at all.

Ultimately, it all comes down to the amount of VRAM the SNES has, and the way it is laid out. VRAM is a total of 64 kb, but remember that it has to be shared by BG1/2/3 GFX, sprite GFX, and BG1/2/3 tilemaps (which specify which block is where onscreen). (the sprite equivalent of tilemaps, OAM, is not stored in VRAM but in a separate location.)

Now, you have 4 sprite GFX slots, each of which is 4kb, which already eats 16kb.
The 4 layer 3 GFX files that are always loaded each take 2kb (since layer 3 uses half as many colors as layer 1/2), for a total of 8kb.
You also have the layer 1/2 tilemaps, 4kb each, and the layer 3 tilemap, 8kb, for a total of 16kb.

If you add this up, you have already used 40kb of the 64kb available. The remaining 24 kb is enough for exactly 6 normal GFX files. So from a purely hardware perspective, you can't load more than 6 GFX files at once, which is exactly how many LM allows.

(there are ways to reclaim some of that VRAM for FG graphics, such as shrinking the tilemaps, but AFAIK nobody has made patches to use those, since they either require significant changes to the SMW engine or have some other tricky limitations.)

Reading your question one more time, I see that you asked why the file size is 4kb. That's just an arbitrary amount that SMW devs chose since it was large enough to not get annoying to manage but small enough to allow the tileset mixing that SMW has. I'm pretty sure 2kb GFX files would work just as well. But the point is, you just can't load more than 24kb of FG/BG GFX at once.

fakeedit: damn ninjas
Another issue is that the graphics are decompressed and need to be decompressed first ‒ in RAM. The original game uses 3KiB of RAM starting from $7EAD00. Lunar Magic has expanded the decompression buffer to 6.75KiB which... is a bit more than half a page. The buffer needs to be relocated somewhere because the buffer ends at $7EC800 and the level data starts there. The only notable free area is $7F9C7B which is 11141 bytes large but much data is used there and is the general freeRAM area. There are possibilities to leave Mario's GFX and animation data uncompressed in the ROM and reload the overworld tilemap but both have got their own advantages in the way SMW handles.

Okay, my layout looks ugly.
So just a maybe dumber question

Some snes games seem to hold a shitload of more tiles/information on screen than smw, specially fighting games (with wider than screen bgs and huge sprites).
How that works? they just upload stuff to vram dinamically like every frame? or they are just more efficient than smw to fit everything in the 64 kb of vram?
^I feel like this is an interesting area; (Not an SNES hardware/software guy)

Games like the DKC Trilogy, if not exceeding 64kb VRAM, are great at simulating that it does. If you didn't know better you could think it was 32-bit or something. Also F-Zero sort've.

100 posts...and then four years went by.
One thing to remember for all SNES games is that the PPU limit is always persistent, there is no way to bypass the VRAM limit i.e. no more than 64KiB is possible (that would require to modify the SNES itself and implement a bigger VRAM chip). Even moreso, sprites can "reserve" (technically, the SNES can't reserve aynthing in VRAM) only up to 16KiB of VRAM, enough for 0x200 different 8x8 tiles. That's because the tile number for OAM tiles i.e sprite tiles is nine bits (maximum value: 0x1FF) and like the amount of VRAM the SNES can use, changing the properties of OAM tiles isn't customisable either (for comparison: All backgrounds use 10 bits which equals to 0x400 different tiles).
The workaround in the 64KiB VRAM and 0x200 tile limit is simply to use dynamic sprites. This is hardly unique for DKC and Street Fighter, though, because most games use dynamic graphics at least for the players (but they use more dynamic graphics than SMW does, that is true).

Okay, my layout looks ugly.
Pages: « 1 »
Forum Index - SMW Hacking - SMW Hacking Discussion - A rather dumb question I couldn't find an answer to

The purpose of this site is not to distribute copyrighted material, but to honor one of our favourite games.

Copyright © 2005 - 2020 - SMW Central
Legal Information - Privacy Policy - Link To Us


Follow Us On

  • YouTube
  • Twitch
  • Twitter


  • Super Mario Bros. X Community
  • Mario Fan Games Galaxy