which would be faster...
which would be faster...
let's say i'm making a vertical shooter. Do you think drawing the map with tiles would be faster, or clipping from one large map image in memory. My current scrolling engine clips from a large map image stored in a buffer to the screen and I'm getting about 50-60 FPS (vsync off) using Allegro, 16-bit color, 640x480 res. There's some obvious pros/cons to both, drawing one large map eliminates that grid look, but takes a lot of memory and loading time. The tile method, vice versa. So, should I consider switching over to a tile-based engine? I would if you all think it would give me a decent speed increase in the main loop. Also, is BYTE the smallest variable type in FB? Is there a boolean type like in C? Thanks for any advice.
I wouldn't do that. The Nintendo had a 1mhz processor and could scroll tiled graphics. My 1990 286 Tandy had full screen scrolling games. you don't need to waste megabytes and megabytes of memory for something that will limit the graphical capabilities of your game, and won't even be noticably faster.
A byte (8 bits) is the smallest addressable amount of memory on a PC. The "boolean" type is just a convention. Use integers where you can, using individual bits just requires extra cycles for shifting and masking larger numbers.
A byte (8 bits) is the smallest addressable amount of memory on a PC. The "boolean" type is just a convention. Use integers where you can, using individual bits just requires extra cycles for shifting and masking larger numbers.
i was wondering why it lags the speed if I clipped from a large map instead of tiles. I mean, essencially, I'm doing the same thing with tiles anyways. So you're saying it takes more time to blit a 640x480 region directly out of memory than to blit several tile-sized regions covering the same surface? Wouldn't it take the same time?
Well it could be many different reasons, a tile is more likely to be repeated, its also much smaller then one big image, and so can be cached more easily. So if you have numerous repetitions of a cached piece of memory, its going to be faster then numerous repetitions of a giant piece of memory being accessed, and clipped, also, with a tile engine you can simple shift the tiles down, and draw the new ones on top, instead of redrawing the whole thing.
-
- Posts: 5494
- Joined: Sep 12, 2005 20:06
- Location: California
About art not seeming as high quality, it's a good idea to plan out your sceneries very well. Re-use tiles as often as possible if it makes no visual difference.
You should notice your huge 1 image map files that some areas should look somewhat repetitive. If you can find out which tiles belong in which area, you can have the same beauty of 1 whole image made out of many different tiles.
You should notice your huge 1 image map files that some areas should look somewhat repetitive. If you can find out which tiles belong in which area, you can have the same beauty of 1 whole image made out of many different tiles.
I am fairly surprised by that. Maybe it's just the sheer scale of the large image, and the corresponding complication of cutting the right rectangle from it.Ophelius wrote:i was wondering why it lags the speed if I clipped from a large map instead of tiles. I mean, essencially, I'm doing the same thing with tiles anyways. So you're saying it takes more time to blit a 640x480 region directly out of memory than to blit several tile-sized regions covering the same surface? Wouldn't it take the same time?
Certainly in optimising a tile engine I would draw a bit more than a screenfull to an off-screen buffer and then cut the whole screen in one.
One word "cachability." The ability to store several 32x32 tiles in the CPU and blit them repeatedly will give a huge preformance boost over a single 640x480 image which can not be stored on the CPU.Ophelius wrote:oh ya, big difference. My engine with tiles increased to 150 fps as opposed to about 50-60. I'm still curious as to why that is.
You're dealing with a problem which takes the CPU cache (a small amount of high-speed memory on the CPU) into account. The less you try to work with (smaller graphics), the faster it will become as it can store a larger chunk of the destination buffer in that cache too.
so, ideally, in a hypothetical situation, it is fastest if you would use 1x1 tiles. Or would it? Since you have to go through every one of those 1x1 tiles, it would take, on a 640x480 display, 307200 loops to display the whole page. So in this sense, I'm getting the feeling that there's a bell curve involved (tile size over speed) where there's an optimal tile area that gives you the most speed. I guess the best way to find out is to loop through every possible tile sizes, 1x1 up to ScreenW x ScreenH, then take each average frame rate, and plot a graph. My guess that there's an optimal tile size in between full screen tile and 1x1 tiles, but closer to 1x1. Something like 16x16, or 32x32. But I could be totally wrong. I'll try this experiment tonight after work, unless someone beats me to it, or already knows the answer.
A common mistake people make with tiles is that they think that all the tiles for say grass must be the same, why not draw out your scene, break it up into a grid, and the similar areas can use the same tile. This would save on memory and still keep away from a grid look.anonymous1337 wrote:About art not seeming as high quality, it's a good idea to plan out your sceneries very well. Re-use tiles as often as possible if it makes no visual difference.
You should notice your huge 1 image map files that some areas should look somewhat repetitive. If you can find out which tiles belong in which area, you can have the same beauty of 1 whole image made out of many different tiles.
axipher said:
jofers said:
Yes, that is a good idea. I can even draw the whole map by hand, scan it, touch it up in photoshop, then find ways to reuse some tiles for certain portions of the map.A common mistake people make with tiles is that they think that all the tiles for say grass must be the same, why not draw out your scene, break it up into a grid, and the similar areas can use the same tile. This would save on memory and still keep away from a grid look.
jofers said:
I was thinking hypothetically that by reducing the tile size to it's limit of 1x1, you would gain maximum speed. But i now know that's not the case.If you had 1x1 tiles, wouldn't that be, ... a bitmap? ;)