|
|
(6 intermediate revisions by 6 users not shown) |
Line 1: |
Line 1: |
− | ==notes on extended vram and tile boundry sizes==
| + | Great post with lots of ipmrtoant stuff. |
− | Some notes on this for later...
| + | |
− | * tiles are always 8x8 pixels. 64 bytes per tile for 256 color. 32 bytes for 16 color
| + | |
− | * videoSetMode/Sub can set either 32(default?), 64, 128, 256 byte tile boundries
| + | |
− | * oam objects (sprites) can select tiles 0-1023..
| + | |
− | | + | |
− | if using 128K of extended vram for object data, if the tile boundry was 32, you would only be able to access 32*1024= 32,768 bytes of vram. setting 64 would allow you access to 64K, etc. in this way all of vram could potentially be used.
| + | |
− | | + | |
− | This will affect animation schemes tho. in 128 byte boundry mode, a 8x8-16color animated sprite will need to align each frame on 128 byte borders essentially wasting the other 96bytes inbetween frames.. Not that big of a deal.
| + | |
− | | + | |
− | so something like:
| + | |
− | bytesperframe=(width*(height/frames)/cmode); //this would be a frame
| + | |
− | (macro this mebbe) tiles=rounduptoboundrytile(bytesperframe,boundrysize); to this:
| + | |
− | tiles=(bytesperframe%boundrysize)?(bytesperframe/boundrysize)+1:(bytesperframe/boundrysize);
| + | |
− | totalframes=tiles*frames;
| + | |
− | | + | |
− | @_@???
| + | |
Great post with lots of ipmrtoant stuff.