struggling with loading bitmap

SGDK only sub forum

Moderator: Stef

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Mon Feb 24, 2014 10:11 am

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?

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Feb 24, 2014 1:21 pm

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.
Image

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Mon Feb 24, 2014 1:37 pm

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!

Stef
Very interested
Posts: 3009
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Feb 24, 2014 1:39 pm

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.
Last edited by Stef on Mon Feb 24, 2014 3:16 pm, edited 2 times in total.

r57shell
Very interested
Posts: 478
Joined: Sun Dec 23, 2012 1:30 pm
Location: Russia
Contact:

Post by r57shell » Mon Feb 24, 2014 3:08 pm

matteus wrote:I will check out your mod!
In my mod, this window is pretty same.

Stef, fix my quote :D.
Image

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Tue Feb 25, 2014 12:53 am

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...

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Wed Feb 26, 2014 10:04 am

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?

Stef
Very interested
Posts: 3009
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Wed Feb 26, 2014 10:24 am

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 !

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Wed Feb 26, 2014 7:20 pm

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;

        }

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Wed Feb 26, 2014 9:37 pm

Another progress video :)

http://youtu.be/MX786RgBP2w

haroldoop
Very interested
Posts: 118
Joined: Sun Apr 29, 2007 10:04 pm
Location: Belo Horizonte, MG, Brazil

Post by haroldoop » Wed Feb 26, 2014 10:13 pm

Looking pretty cool, so far.

Stef
Very interested
Posts: 3009
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Thu Feb 27, 2014 9:37 am

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).

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Thu Feb 27, 2014 10:45 am

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? :)

matteus
Very interested
Posts: 336
Joined: Mon Feb 04, 2008 1:41 pm

Post by matteus » Mon Mar 03, 2014 11:06 am

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?

Stef
Very interested
Posts: 3009
Joined: Thu Nov 30, 2006 9:46 pm
Location: France - Sevres
Contact:

Post by Stef » Mon Mar 03, 2014 11:30 am

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 =)

Post Reply