Post by Tommy on Mar 1, 2005 12:59:59 GMT
Hi,
first I apologize for my bad english, it's not my native language. I hope you'll still understand the following brain dump
I am currently porting my 2D WIP game to Blitz3D and SpriteCandy.
It is a game with a scrolling tile based map bigger than the screen.
I already asked Mike a few questions regarding scrolling tile based maps with SpriteCandy and he asked me to use the forum, so here we go...
To keep my questions understandable I'll explain everything with fixed values.
First, the following describes my existing 2D implementation:
Assume screen resolution is 640 x 480, tilesize is 32 x 32 pixels.
The map itself is stored in a 3 dimensional array Map(x, y, layers) where I have 5 layers (Ground, Walls, Objects, Top, Collision) and x and y have a maximum of 256.
The Collision layer is never drawn but only used for collision detection with Walls and Objects layer.
For each layer I use a AnimImage which contains the graphics tiles for the layer.
Each map cell contains the index/frame number of the AnimImage for that layer.
My 2D code works like this:
1. read the graphics tiles with LoadAnimImage() and store them in globals. I have one AnimImage for each layer.
2. in some loop draw all the required tiles by calculating top left tile coordinate into map array, layer by layer from the ground up.
Important to mention here is: all graphics are loaded only once, drawing is done with DrawBlock for the Ground layer to avoid Cls and with DrawImage for the other layers.
And now for SpriteCandy:
I can use SpriteCandy layers for my map layers. Simple.
Sprite Candy images are somewhat smarter. They know about their x/y position on screen so I cannot take an image and draw it several times at different screen positions like I could do with AnimImages and DrawImage.
This means that I have to create a bunch of SpriteCandy images, one for each visible tile. I will also need to consider that it's possible to have more than one image at the same screen position on top of each other (ground layer and object layer)
In general I would need to create a minimum of 640/32 * 480/32 = 20 * 15 images = 300 images to draw a full screen. To allow pixel scrolling I need to create at least one more row and one more column of tiles so I have 21 * 16 = 336 images because the topmost, bottommost, rightmost and leftmost tiles will only be partially visible.
I can use HUD_MoveLayer() to scroll the visible layers pixelwise.
As soon as I scrolled to a TILESIZE (32 pixel) boundary I need to drop a column or row of images and create a new column or row of images at the opposite side of the screen, taking the image information out of my map array.
Questions:
1. Is this fast enough?
2. If I move a layer do I also need to move the images? Or is that done automatically?
3. What is an efficient way to keep track of the created images and the images to be deleted due to scrolling?
4. Am I completely wrong and is there a much easier solution?
5. Has anyone already created similar code and could provide some source code example?
I will start implementing a prototype on my assumptions tonight and see how far I'll get.
Any input highly appreciated.
Regards,
Tommy
first I apologize for my bad english, it's not my native language. I hope you'll still understand the following brain dump
I am currently porting my 2D WIP game to Blitz3D and SpriteCandy.
It is a game with a scrolling tile based map bigger than the screen.
I already asked Mike a few questions regarding scrolling tile based maps with SpriteCandy and he asked me to use the forum, so here we go...
To keep my questions understandable I'll explain everything with fixed values.
First, the following describes my existing 2D implementation:
Assume screen resolution is 640 x 480, tilesize is 32 x 32 pixels.
The map itself is stored in a 3 dimensional array Map(x, y, layers) where I have 5 layers (Ground, Walls, Objects, Top, Collision) and x and y have a maximum of 256.
The Collision layer is never drawn but only used for collision detection with Walls and Objects layer.
For each layer I use a AnimImage which contains the graphics tiles for the layer.
Each map cell contains the index/frame number of the AnimImage for that layer.
My 2D code works like this:
1. read the graphics tiles with LoadAnimImage() and store them in globals. I have one AnimImage for each layer.
2. in some loop draw all the required tiles by calculating top left tile coordinate into map array, layer by layer from the ground up.
Important to mention here is: all graphics are loaded only once, drawing is done with DrawBlock for the Ground layer to avoid Cls and with DrawImage for the other layers.
And now for SpriteCandy:
I can use SpriteCandy layers for my map layers. Simple.
Sprite Candy images are somewhat smarter. They know about their x/y position on screen so I cannot take an image and draw it several times at different screen positions like I could do with AnimImages and DrawImage.
This means that I have to create a bunch of SpriteCandy images, one for each visible tile. I will also need to consider that it's possible to have more than one image at the same screen position on top of each other (ground layer and object layer)
In general I would need to create a minimum of 640/32 * 480/32 = 20 * 15 images = 300 images to draw a full screen. To allow pixel scrolling I need to create at least one more row and one more column of tiles so I have 21 * 16 = 336 images because the topmost, bottommost, rightmost and leftmost tiles will only be partially visible.
I can use HUD_MoveLayer() to scroll the visible layers pixelwise.
As soon as I scrolled to a TILESIZE (32 pixel) boundary I need to drop a column or row of images and create a new column or row of images at the opposite side of the screen, taking the image information out of my map array.
Questions:
1. Is this fast enough?
2. If I move a layer do I also need to move the images? Or is that done automatically?
3. What is an efficient way to keep track of the created images and the images to be deleted due to scrolling?
4. Am I completely wrong and is there a much easier solution?
5. Has anyone already created similar code and could provide some source code example?
I will start implementing a prototype on my assumptions tonight and see how far I'll get.
Any input highly appreciated.
Regards,
Tommy
