Confused about VRAM nametables (tiletables) sizes
Moderators: BigEvilCorporation, Mask of Destiny
-
- Interested
- Posts: 27
- Joined: Wed Sep 21, 2011 9:00 pm
- Location: Sevilla, Spain
- Contact:
Confused about VRAM nametables (tiletables) sizes
Hi guys!
I was having a look at Fonzie's "The VDP in 16 Pics" when I noticed about a "supposed" free-to-use 128 tile area I didn't know about:
That discovery made my day... for a while.
I made a quick test ... writing over that area brought no problem at all. Good, good.
And then I did another one ...
I tested the same, writing tiles at "1920 tile position" (VRAM 0xF000) but ...
My background became awfully glitched.
After a while I discovered that that thing was happening when my BPLAN tilemap heigh was exceding of 32 rows. And that made that "supposed to be a free-to-use area" to be filled whith some data belonging to BPLAN nametable.
This is a simplified test using sgdk:
OK with empirical then.
Anyhow, and looking back at Fonzie's VRAM table, I wonder how can it be like that (each plane consuming that amount of data) knowing that H-Scroll and sprite tables would be overwritten if APLAN (at Fonzie's table positioning case) has, for instance, 64 rows drawn.
Yup, I remain a bit confused
I was having a look at Fonzie's "The VDP in 16 Pics" when I noticed about a "supposed" free-to-use 128 tile area I didn't know about:
That discovery made my day... for a while.
I made a quick test ... writing over that area brought no problem at all. Good, good.
And then I did another one ...
I tested the same, writing tiles at "1920 tile position" (VRAM 0xF000) but ...
My background became awfully glitched.
After a while I discovered that that thing was happening when my BPLAN tilemap heigh was exceding of 32 rows. And that made that "supposed to be a free-to-use area" to be filled whith some data belonging to BPLAN nametable.
This is a simplified test using sgdk:
OK with empirical then.
Anyhow, and looking back at Fonzie's VRAM table, I wonder how can it be like that (each plane consuming that amount of data) knowing that H-Scroll and sprite tables would be overwritten if APLAN (at Fonzie's table positioning case) has, for instance, 64 rows drawn.
Yup, I remain a bit confused
-
- Interested
- Posts: 27
- Joined: Wed Sep 21, 2011 9:00 pm
- Location: Sevilla, Spain
- Contact:
That "VRAM dump" is taken from a demo, it's not an actual game.
My doubts are related with nametables sizes. Looking at that sample ... what happens if plane A is 64x64, will hscroll and sprite tables be overwritten?
I've coded a few demos where I fill both 64x64 planes and there's no problem nor with scroll neither with sprites. Then ... I guess I'm missing some info :-\
My doubts are related with nametables sizes. Looking at that sample ... what happens if plane A is 64x64, will hscroll and sprite tables be overwritten?
I've coded a few demos where I fill both 64x64 planes and there's no problem nor with scroll neither with sprites. Then ... I guess I'm missing some info :-\
-
- Very interested
- Posts: 616
- Joined: Thu Nov 30, 2006 6:30 am
-
- Interested
- Posts: 27
- Joined: Wed Sep 21, 2011 9:00 pm
- Location: Sevilla, Spain
- Contact:
OK. I'll take that
Thanks guys anyhow.
I know about the posibility of placing VRAM data tables into different memory areas, I just was not sure about how large nametables could be so I though that the most common size I have been finding was "its propper size".
When I started to fill planes with more than 32 rows of tiles my troubles started to show up. Anyhow I know how to bypass my old problems. OK now.
Regarding relocation of nametables (and others) I recommend to have a look at Eternal Champions VRAM state. All tables are placed in the beginning of VRAM so that a continuous and huge chunk of memory are avaible for tiledata.
It's very interesting to look at how many games take advantage of VRAM empty gaps when programmer know exactly where and how big their nametables (and others) are.
Reiterating: thanks guys
Thanks guys anyhow.
I know about the posibility of placing VRAM data tables into different memory areas, I just was not sure about how large nametables could be so I though that the most common size I have been finding was "its propper size".
When I started to fill planes with more than 32 rows of tiles my troubles started to show up. Anyhow I know how to bypass my old problems. OK now.
Regarding relocation of nametables (and others) I recommend to have a look at Eternal Champions VRAM state. All tables are placed in the beginning of VRAM so that a continuous and huge chunk of memory are avaible for tiledata.
It's very interesting to look at how many games take advantage of VRAM empty gaps when programmer know exactly where and how big their nametables (and others) are.
Reiterating: thanks guys