struggling with loading bitmap

SGDK only sub forum

Moderator: Stef

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

Post by matteus » Wed Feb 19, 2014 12:47 am

Chilly Willy wrote:EDIT: Sorry, need to look closer at the code...

Okay, you're setting the tile index for planes A and B to the same value. The whole point of adding numTiles to ind after drawing the image is to find the next free place in the tiles so that you don't overlap. You reset ind to TILE_USERINDEX before the next draw, which means it draws right over top of tiles already in use.
Thanks! I hadn't noticed >_< always useful to have a second pair of eyes look over something! It works fantastic now.

Going to look to draw a 10 frame animation over the next few days to see if it looks alright. If it does then I'm going to have a lot of work to do :D

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Feb 19, 2014 3:46 am

matteus wrote:Thanks! I hadn't noticed >_< always useful to have a second pair of eyes look over something! It works fantastic now.
I run into that myself a lot - you read the code the way you MEANT to write it, not how you ACTUALLY wrote it. :)

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

Post by matteus » Wed Feb 19, 2014 10:47 am

Chilly Willy wrote:
matteus wrote:Thanks! I hadn't noticed >_< always useful to have a second pair of eyes look over something! It works fantastic now.
I run into that myself a lot - you read the code the way you MEANT to write it, not how you ACTUALLY wrote it. :)
I guess that's why pair programming is so highly rated!

I've only been doing mega drive development for 2 weeks and I've learnt that my ideal solution for animation isn't so ideal!

I was under the impression 80's and early 90's cartoons would favor the Mega Drives VDP due to the their low colour count and detail. I thought I could get away with having a constant static background on one scrolling pane with animation frames on another but the need to buffer things just makes that fall flat on its face.

I'll just have to see what I can come up with 15 colours

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Wed Feb 19, 2014 8:31 pm

matteus wrote:I've only been doing mega drive development for 2 weeks and I've learnt that my ideal solution for animation isn't so ideal!

I was under the impression 80's and early 90's cartoons would favor the Mega Drives VDP due to the their low colour count and detail. I thought I could get away with having a constant static background on one scrolling pane with animation frames on another but the need to buffer things just makes that fall flat on its face.

I'll just have to see what I can come up with 15 colours
Well, that actually IS a good way to handle that kind of animation. The problem is that it takes talented artists to separate the two by hand. That was how the Amiga version of Dragon's Lair was done - the background was separated from the animated parts and displayed in one layer, while the much smaller animated parts were drawn in real-time over it. It made the Amiga version very nearly the quality of the laser disc while fitting on a few floppy disks. However, it was extremely labor intensive on the artists.

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

Post by matteus » Thu Feb 20, 2014 10:49 am

Chilly Willy wrote:
matteus wrote:I've only been doing mega drive development for 2 weeks and I've learnt that my ideal solution for animation isn't so ideal!

I was under the impression 80's and early 90's cartoons would favor the Mega Drives VDP due to the their low colour count and detail. I thought I could get away with having a constant static background on one scrolling pane with animation frames on another but the need to buffer things just makes that fall flat on its face.

I'll just have to see what I can come up with 15 colours
Well, that actually IS a good way to handle that kind of animation. The problem is that it takes talented artists to separate the two by hand. That was how the Amiga version of Dragon's Lair was done - the background was separated from the animated parts and displayed in one layer, while the much smaller animated parts were drawn in real-time over it. It made the Amiga version very nearly the quality of the laser disc while fitting on a few floppy disks. However, it was extremely labor intensive on the artists.
I've just been looking at the Amiga version of Dragon's Lair that's an impressive feat. Chilly from what I've read I take it that the SGDK/Mega Drive hardware is not capable of letting me have a static background, while loading a animated parts on top?

Anyhow I'll work on getting the animation finished then come back to how best to load it.

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

Post by Stef » Thu Feb 20, 2014 11:08 am

matteus wrote:
Stef wrote:You need to deal with a sort of double buffer.
Display image A while you are loading image B.
When image B is loaded switch display to image B then load next image (image A) and so on... For that you can use the vertical scrolling to switch between the 2 images for instance.
Ohhhh! so you can't use both panes at once! Gutted I'll look at vertical scrolling then.
Of course you can, when i said image A and image B, i didn't meant plan A and plan B, sorry for the confusion. I was just explaining the double buffer idea ;) You have to double buffer your plan update else you will have some garbled tiles when the update is happening (exactly as what happened when you tried actually).

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

Post by matteus » Thu Feb 20, 2014 11:31 am

Stef wrote:
matteus wrote:
Stef wrote:You need to deal with a sort of double buffer.
Display image A while you are loading image B.
When image B is loaded switch display to image B then load next image (image A) and so on... For that you can use the vertical scrolling to switch between the 2 images for instance.
Ohhhh! so you can't use both panes at once! Gutted I'll look at vertical scrolling then.
Of course you can, when i said image A and image B, i didn't meant plan A and plan B, sorry for the confusion. I was just explaining the double buffer idea ;) You have to double buffer your plan update else you will have some garbled tiles when the update is happening (exactly as what happened when you tried actually).
oh good :D my idea should work then! How do I prebuffer things into memory?

Do I need an additional method before VDP_drawImageEx to store the image data temporarily somewhere in memory? if so what would that be?

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

Post by Stef » Thu Feb 20, 2014 12:37 pm

You have to double buffer them in VRAM.
For instance you draw your first image at position 0,0 (tile position)
then you draw your second image at position 40,0 and change H scroll position to 320 ( 40 * 8 ) when the second image draw process is finish and then you draw your next image back to position 0,0 and so on...
You have to take care about the available tiles in VRAM so it can fit 2 images at same time.
Last edited by Stef on Thu Feb 20, 2014 2:23 pm, edited 1 time in total.

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

Post by matteus » Thu Feb 20, 2014 1:02 pm

Stef wrote:You have to double buffer them in VRAM.
For instance you draw your first image at position 0,0 (tile position)
then you draw your second image at position 40,0 and change H scroll position to 320 ( 40*8 ) when the second image draw process is finish and then you draw your next image back to position 0,0 and so on...
You have to take care about the available tiles in VRAM so it can fit 2 images at same time.
OOOOOO its the classic load things out of view scenario, I'd have never thought like that regarding the Mega Drive.

One Tile: 32bytes
SGDK VRAM: 1310 tiles
Screen 320 x 224 (40 x 28) = 1120 tiles

So if I'm sloppy with my animation and make it use a whole screen per frame will that mean I need to half the resolution to 160 x 112 in order to create enough space in VRAM?

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

Post by Stef » Thu Feb 20, 2014 2:32 pm

Depending of your image you may have some duplicate tiles so you even don't need to reserve 40 * 28 tiles for a single image (that is the worst scenario).
SGDK will optimize your image and remove duplicate tiles if you use the .res file to declare it. Then you can try to play with the new "tile cache" engine to get easier VRAM tile allocation.
Of course by reducing the image/view size you will lower the VRAM usage as well as the VRAM bandwidth required to update your image ;) If you want smooth animation you will anyway won't be able to refresh the whole 320x224 screen.

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

Post by matteus » Thu Feb 20, 2014 3:07 pm

Stef wrote:Depending of your image you may have some duplicate tiles so you even don't need to reserve 40 * 28 tiles for a single image (that is the worst scenario).
SGDK will optimize your image and remove duplicate tiles if you use the .res file to declare it. Then you can try to play with the new "tile cache" engine to get easier VRAM tile allocation.
Of course by reducing the image/view size you will lower the VRAM usage as well as the VRAM bandwidth required to update your image ;) If you want smooth animation you will anyway won't be able to refresh the whole 320x224 screen.
I'd thought about 248 x 168 but I thought that seems a weird resolution! How about 240 x 160 would that be possible?

I'd need around 1100 tiles to do two screens?

Screen 240 x 160 (30 x 20) = 600 tiles

600 tiles x 2 screens = 1100

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

Post by matteus » Thu Feb 20, 2014 4:26 pm

I'm taking a 4:3 TV resolution so it would probably make more sense for me to do a 200 x 200 (25 x 25)

Chilly Willy
Very interested
Posts: 2984
Joined: Fri Aug 17, 2007 9:33 pm

Post by Chilly Willy » Thu Feb 20, 2014 6:46 pm

Don't forget about priority. The default is S > W > A > B > G, but you can change that. Read the hardware doc for details. In a nutshell, normally plane A ALWAYS shows over top of plane B. So you'd only see plane B where there are 0's in plane A (the transparent color).

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

Post by matteus » Thu Feb 20, 2014 9:45 pm

I'm getting an new error when processing the pngs:

"1 bpp PNG not supported"

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

Post by matteus » Fri Feb 21, 2014 9:27 am

matteus wrote:I'm getting an new error when processing the pngs:

"1 bpp PNG not supported"
So by optimising my PNGS to be less than 16 colours have I shot myself in the foot?
Last edited by matteus on Fri Feb 21, 2014 10:03 am, edited 2 times in total.

Post Reply