|
|
| Line 1: |
Line 1: |
| − | ==notes on extended vram and tile boundry sizes==
| + | I might be beating a dead horse, but thank you for psoting this! |
| − | 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;
| + | |
| − | | + | |
| − | @_@???
| + | |
| − | | + | |
| − | Need better names for these two. So an 8x8 pixel arrangement of pixels i'll call 'tile'. first 10 bits of attribute 3 i'll call 'objtile' or mebbe just 'object'.
| + | |
