Sorry your browser is not supported!

I'm trying to come up with my own culling system for a tile-based game that I'm writing. It's a 200x100 grid, and I use the scroll/zoom functions in AppGameKit to change the view.

Here's the problem that I'm facing - for some odd reason, whenever I use the zoom functions, it screws up my culling system! I don't know if it's a bug or flawed logic, but here is some pseudo-code of what I'm doing.



If I use Zoom, too many tiles activate when it's zoomed in and too many disappear when zoomed out (to the point where no tiles appear on screen). EDIT: This was due to some other bug in my code, but this is how it works now basically.

I'm pretty sure the latest Beta has a command which tells you the edge of the visible world area.

Just a thought, but why have 200x100 tiles, when you just need to cover the screen?, 20,000 sprites will have a detremental effect on, well it'll slow everything down, consider when you will scan through every tile, 20,000 iterations, consider also what will be required when your game gets further along in development.

Let's say that your game screen is 1024x768, and tiles are 32x32, to cover that screen you'd need 32x24 tiles, or 768 tiles. A lot less than 20,000. I'm guessing you are using a tile set, like maybe 16x16 images on a grid, each one 32x32 - then setting the sprites as animated sprites, and setting the relevant frame for each one. Well each loop, I would just use a range of sprites, say allowing for 1 sprite border - so 34x26 tiles, or 884. When scrolling the screen I would find the X and Y offset to start drawing the map from, basically the first tile that is visible at the top left of the screen, then step through 34x,26y - setting the sprite frame and position each time. This only needs to be done if the screen scrolls more than the tile size. This would allow you more control, you could have individually animated tiles for example, and for less than 1000 sprites, and no real need to step through 20,000 iterations.

I posted a tiled map example that uses this technique, it has scrolling and viewport zooming, worth a look I think - I'll add a link after I post this. AppGameKit will do it's best to avoid drawing sprites that it doesn't have to, but stepping through the iterations alone will cause a real slowdown, even if your not doing a lot inside the for...next loops. For the sake of AppGameKit, and what it might be doing behind the scenes with all those sprites, well I'd say you have to ban yourself from doing it .

One other option, for the next official release of AppGameKit maybe, is to use a 3D object for the map - so sticking with a single tile set image, you could have the 2D map as a polygonal model, each quad UV mapped as if it was a 2D tile map. That would be the ideal method as it removes the burden of handling several sprites and iterations - if you have any experience with DB, well it would be like using a matrix for a 2D tile map, something that seems ludicrous but functionally it avoids a lot of coding problems. I have been thinking of making a 2D map editor that can export to AppGameKit model files using this idea. I mean, it might take a while before 3D in AppGameKit is more useful, until it has bone animation and settled in a bit - but there's no reason why we can't rely on it for things like this.

My tiled map example:
http://forum.thegamecreators.com/?m=forum_view&t=198399&b=41

I'll look at your code VanB - I have my project programmed so it thankfully doesn't check the sprites each frame - it only checks as soon as the player is done panning and zooming. The tiles that are visible on-screen after movement are kept and everything else is discarded.

As my app is a turn-by-turn game, it really doesn't require constant iterations.

That being said, I did originally program the game with enough tiles to cover *just* the screen. I forgot why I decided that wasn't a workable solution (iirc it was an issue with zoom).