Extra VDP Tiles ? more than 1310

[NightShadow]

Hi

I would like to know how to initialize more space for Tiles in vdp ram. I'm sure I already read someone who said he was doing it but didn't explain how to, also it's hard to search in the forum for this kind of info, using target terms are just too much vague..

I already plan my project with a vdp memory map for my needs that worked at first but if I really want to achieve correctly, space for 200 more tiles would really be a need. If more are possible it would be a great welcome.

I don't necessary need the fonts in the final release (only for debugging ;-P) , so I think I could us those tiles too ?.

On the net all I found is something like "between 1300-1800 tiles depending on system configuration" ... ?!

[Sik]

Are you dealing with SGDK, by any chance?

[Stef]

In case you're dealing with SGDK you have to know the default VRAM map :

system tiles = 0x0000 (16 plain tiles used which can be used for fast fill operation)
user tiles = 0x0200
font tiles = 96 tiles = window map address - 0x0C00
window map = 0xB000
H scroll table = 0xB800
Sprite table = 0xBC00
B Plan map= 0xC000
A Plan map = 0xE000

You can see the reserved window area is not big enough to display a bottom window in H40 mode, i made that choice as window is rarely used and it's better to use more space for tile. SGDK is always using the window map address to define how many VRAM is allocated for user tile so it's important that user tiles are located in bottom space of VRAM and that window map is the first map in high VRAM area (then order of H scroll / sprite table and plans doesn't matter).
So by default you have (0xB000 - 0x0C00) - 0x0200 = A200 bytes for user tiles which is 1296 tiles exactly.
Actually you can change the VRAM mapping by using methods as VDP_setWindowAddress(..) / VDP_setAPlanAddress(..) so you can free more space for user tiles. For instance you can arrange tile map that way :
window map = 0xD800
B Plan map= 0xD800
A Plan map = 0xE800
H scroll table = 0xF800
Sprite table = 0xFC00
That means you can't use window anymore (not a big deal), and that you are restricted to use 64x32 sized background plans.
But then now you have : (0xD800 - 0x0C00) - 0x0200 = CA00 bytes for user tiles which is 1616 tiles exactly.
And in the worst case you can even overwrite the font tiles located at the end of user tile space to get 96 extra tiles if you don't need to use text at all in your program but i recommend you to keep it as it's always useful (for debug purpose at least).

Note that even if i was speaking about default VRAM memory mapping in SGDK initially the informations i provided here (about modifying the VRAM memory map) work whatever are your programming tools.

[Sik]

100% sure that the scroll plane addresses must be a multiple of 0x2000...

For what matters, this is my usual mapping (note that this leaves the whole first 3/4 of VRAM for tiles):

• Scroll A: 0xC000
• Scroll B: 0xE000
• Window: 0xD000
• Sprites: 0xF000
• Hscroll: 0xF800

There are some gaps in-between for when you're really strained on tiles... anyway, between that and just ignoring SGDK's own tiles (just repurpose them for your own) that should give you enough (1536 tiles not counting the gaps).

What are you trying to do, anyway?

EDIT: also I normally use 64×32 tilemaps (meaning the scroll planes only eat 4KB and not 8KB), otherwise you may need to readjust some addresses to account for it.

[Stef]

Ah yeah, i forgot plans are aligned to 0x2000, so no way to do better than 0xC000 as map start address :-/
I could probably let the font tiles in the high end part of VRAM so the whole 0x0000-0xC000 space could be used for user tiles.

[BigEvilCorporation]

I've only recently started experimenting with gaps, just hijacking the Window Plane space for now:

Code: Select all

VDP screen width: 320
VDP screen height: 224
VDP scroll width: 64 tiles
VDP scroll height: 32 tiles
VDP plane A addr: 0xc000
VDP plane B addr: 0xe000
VDP sprite tbl addr: 0xf000
VDP hscroll addr: 0xfc00
-----------------------------------

-----------------------------------
VDP tile count (bank 0): 1524 / 1536
VDP tile count (bank 1): 102 / 128
-----------------------------------

My game uses a font, but it's cut down to the bare minimum - just A-Z (uppercase only), 0-9, comma, fullstop, forward slash, colon - that pretty much covers all menus and dialogue in the game, saves a bit of space compared to a full character set.

What helps far more than finding space is finding a pixel artist who knows how to make efficient use of the minimal space available - excellent use of forward planning, repetition, flipping, dithering.

A good streaming implementation goes a long way, too. I'm looking into a reference counted system which treats each tile as a resource, and calculates all tiles needed for the current frame. It'll probably be dog slow, we'll see.

[Sik]

Sonic 3D does stream the tiles (although it doesn't look for repetition, it just allocates enough for a screenful of tiles), it needs so since levels may use up to 4096 unique tiles (for context, that'd need twice as much VRAM, ignoring space for everything else). The biggest problem is that then it's required to keep them uncompressed in ROM.

[NightShadow]

Hi guys

thanks a lot for answers

Yes I'm programming with SGDK.

I'll do a jump n run Contra style game for 1-2 players.. I have unlimited ideas to integrate in the game, about gameplay, physics, Ai and special effects graphics.. I almost done main character's graphics and gameplay, I still have to add 3-4 moves and it's very long because I use a special engine that will deal with the many sprites the main characters does have so I need to convert alot of data and create animation sequences and positionning of the sprites + streamming tiles update from rom in a cycle of 1-2 frames. Anyway, not much clear on technical infos but I need to stream alot of tiles for everything and the vdp memory tilemap is already all planned and I need to optimize everything to achieve all what I want. There's also a secret special effect I will do, I already know how, just a lot and a lot of work...Could almost look an C64 or Amiga gfx Demo in the end ;-P Actually the main character gameplay is near perfect to my though and doesn't move or look any other game on the system. I retouched a lot of things and I continue to do it. When I'll be finish with the main character moves, I'll start coding the map engine.

I really think 1616 tiles will be enough for now, If I need more later I'll try to deal with the fonts ...

I started the project vaguely about 2 years ago.. working more or less on it ... doing graphics .. trying sgdk to test the sprites/tiles function to draw my gfx, finally coding gameplay, and now I got the motivation back again to do some more needed gfx and code the last moves. I already have some backgrounds and enemy gfx too, and a lot of ideas for the rest. I'm hurry to get to the map stuff and other things because I spent too much time in converting data at hand and that's only for the main characters, I prefer getting it finished as it's the more boring part, and everything else will go much better and faster after that.

Thanks for the infos !

[MintyTheCat]

Have you thought about compression? Most MD games utilised compression and you might want to do the same.

[Sik]

You can't use compression in video memory though o_O