Page 7 of 10
Posted: Mon Feb 24, 2014 10:11 am
by matteus
Stef wrote:Exactly ! you were just running out of VRAM.
A nasty fix is just to roll over VRAM, when you rise the memory limit just restart to TILE_USERINDEX (more or less what you did).
Things suddenly make a lot of sense! I know your SGDK removes duplicate tiles reducing the overall amount of VRAM required.
The ind variable indicates the tile index (total number of tiles currently in use?). If I wanted things to work properly I'd allocated 540 tiles per frame but I'd be wasting VRAM, which your SGDK is written not to do
Ok so if I have an image that has 540 tiles all the same, I guess your engine reduces this to use 1 tile? If I have a second image that takes 540 tiles, I have 541 tiles in memory.
When I come to load the next image, I have 540 again, I want to place this at the front of the VRAM tile index but I can't because I only allocated 1 tile of VRAM to the first frame and would be overwriting half the second frame if I loaded it there. How do I overcome this? do i simply default the ind to 540 everytime? A big waste of VRAM but I guess it might work? Or do I need to write an algorithm to rearrange the positioning in VRAM? Is that even possible?
I guess your tile-engine may resolve this issue and must track the positions of each image and its tiles in VRAM and rearrange and reallocate them automatically as images are pushed on and off the memory stack?
Posted: Mon Feb 24, 2014 1:21 pm
by r57shell
matteus, check VRAM yourself first!!!!!!
It's realy difficult to understand anything without looking in VRAM yourself.
You can use GensKMod or my mod for that purpose.
It shows VRAM memory with tiles, also all palettes.
Check it first, and I think, if you see it, you didn't' even Ask those questions.
Stef wrote:Exactly ! you were just running out of VRAM.
A nasty fix is just to roll over VRAM, when you rise the memory limit just restart to TILE_USERINDEX (more or less what you did).
It means to set index where tiles will be loaded to TILE_USERINDEX.
As far as I know, in SGDK no info about allocated/not allocated tiles.
There is only index that is incremented when you load tiles in VRAM.
And you can set it yourself if you want to load at different place.
Good luck.
Posted: Mon Feb 24, 2014 1:37 pm
by matteus
r57shell wrote:matteus, check VRAM yourself first!!!!!!
It's realy difficult to understand anything without looking in VRAM yourself.
You can use GensKMod or my mod for that purpose.
It shows VRAM memory with tiles, also all palettes.
Check it first, and I think, if you see it, you didn't' even Ask those questions.
Stef wrote:Exactly ! you were just running out of VRAM.
A nasty fix is just to roll over VRAM, when you rise the memory limit just restart to TILE_USERINDEX (more or less what you did).
It means to set index where tiles will be loaded to TILE_USERINDEX.
As far as I know, in SGDK no info about allocated/not allocated tiles.
There is only index that is incremented when you load tiles in VRAM.
And you can set it yourself if you want to load at different place.
Good luck.
Hi r57shell,
Before I posted I checked the VRAM with GensKMod but I couldn't tell if it was full though, I'm still learning.
I will check out your mod!
Posted: Mon Feb 24, 2014 1:39 pm
by Stef
It means to set index where tiles will be loaded to TILE_USERINDEX.
As far as I know, in SGDK no info about allocated/not allocated tiles.
There is only index that is incremented when you load tiles in VRAM.
And you can set it yourself if you want to load at different place.
In the last SGDK you have a "tile cache" unit which provide some tools for easier VRAM tile allocation.
SGDK uses it internally for the new sprite engine stuff.
Posted: Mon Feb 24, 2014 3:08 pm
by r57shell
matteus wrote:I will check out your mod!
In my mod, this window is pretty same.
Stef, fix my quote
.
Posted: Tue Feb 25, 2014 12:53 am
by matteus
Latest update video
http://youtu.be/9yO2rTTnJSE
Updated code, increased frames making up current animation and continuing to hunt for a program that will automate the setting of index 0 for RGB(36,36,36).
In the process of drawing more frames of animation post logo...
Posted: Wed Feb 26, 2014 10:04 am
by matteus
Stef wrote:I reply here about your PM as well as it can be interesting for anyone in general.
To start with you don't need to clear the screen when loading a new image, the new image should erase the previous one. Then we come to your second question... there is no way to load a full screen image at 24 fps and it is even worse if you want to refresh plan A and plan B. The VRam bandwidth is quite limited, if you consume the whole vblank period you only have about 7 KB to 8 KB per frame... it is far from the needed 14KB needed to maitains 24 fps and only for a single plan. If you plan to use compression you also have to take the unpacking time in account... If your image contains many identicals tiles then loading can be faster but for complexes images you will never achieve 24 FPS.
I believe 12 FPS is the maximum when you refresh a complete plan on a NTSC system and probably 17 FPS on a PAL system.
I've hit what I believe to be a frame rate issues! My screen size is 216 x 160 pixels (27 x 20 tiles) and I'm using the VDP_drawImageEx and VerticalScroll method. The frame rate seems to have dropped drastically, should I be expecting 12 FPS at this screen size?
Posted: Wed Feb 26, 2014 10:24 am
by Stef
It's really depends from the complexity of your image but you should be able to have more than 12 FPS.
Problem is that decompression can consume a lot of time, try to disable it or force to RLE to see if that make any difference !
Posted: Wed Feb 26, 2014 7:20 pm
by matteus
Stef wrote:It's really depends from the complexity of your image but you should be able to have more than 12 FPS.
Problem is that decompression can consume a lot of time, try to disable it or force to RLE to see if that make any difference !
Maybe its my loop?
Code: Select all
for(i = 0; i < 173; i++)
{
u16 nextypos = ypos ^ 0x20;
VDP_setVerticalScroll(BPLAN, vpos);
VDP_drawImageEx(BPLAN, images[i], TILE_ATTR_FULL(pal, FALSE, FALSE, FALSE, ind), 6, vpos + 4, TRUE, TRUE);
if (ind > 1080) {
ind = TILE_USERINDEX;
}
ind += 540;
pal ^= 1;
ypos = nextypos;
}
Posted: Wed Feb 26, 2014 9:37 pm
by matteus
Posted: Wed Feb 26, 2014 10:13 pm
by haroldoop
Looking pretty cool, so far.
Posted: Thu Feb 27, 2014 9:37 am
by Stef
Your loop is really simple and efficient
The problem comes from the VDP_drawImageEx(..) method. It's a very high level method which unpack the image data, the map and send it to the VDP. If your image is not packed you should observe a performance improvement (but the rom size will increase).
Posted: Thu Feb 27, 2014 10:45 am
by matteus
Stef wrote:Your loop is really simple and efficient
The problem comes from the VDP_drawImageEx(..) method. It's a very high level method which unpack the image data, the map and send it to the VDP. If your image is not packed you should observe a performance improvement (but the rom size will increase).
I've been searching the SDGK for references to the compression method, I can find the struct that defines the compression but am not entirely clear what you're suggesting I need to do with this?
Do I need to rewrite my code so it makes use of lower level methods in the SGDK? Or can I somehow set the type of compression for VDP_drawImageEx? Is there a flag?
Posted: Mon Mar 03, 2014 11:06 am
by matteus
matteus wrote:Stef wrote:Your loop is really simple and efficient
The problem comes from the VDP_drawImageEx(..) method. It's a very high level method which unpack the image data, the map and send it to the VDP. If your image is not packed you should observe a performance improvement (but the rom size will increase).
I've been searching the SDGK for references to the compression method, I can find the struct that defines the compression but am not entirely clear what you're suggesting I need to do with this?
Do I need to rewrite my code so it makes use of lower level methods in the SGDK? Or can I somehow set the type of compression for VDP_drawImageEx? Is there a flag?
Sorry be a pest Stef, Any suggestions?
Posted: Mon Mar 03, 2014 11:30 am
by Stef
It's me, again a missed message.. i don't understand ^^
Well the compression information is given in the .res file, just look in the SPRITE definition of the rescomp.txt file, you will see that is pretty easy =)