_25_11_2024_15_40_33.jpg)
_25_11_2024_15_40_55.jpg)
_25_11_2024_15_43_24.jpg)
|
Socoder -> Blitz Max -> tile or x and y based |
|
| Tue, 12 Jan 2010, 12:25 | |
|
deleted user |
I've never made a platform game before, a bit different from click based edu-games for children. But I've been working on a tile based level editor in blitzmax, and am wondering what would be quicker for big but not overly large levels, a tilebased system with the tiles stored in an array, or if I store all the objects in a list or similar and check whether their x and y co-ordinates are in the screens range to be drawn. I'm thinking that as my game will have lots of square or rectangular buildings to jump on, a tile-based one would be the obvious answer, but I'm just checking other peoples views for blitzmax. -=-=- delete my account 
|
| Tue, 12 Jan 2010, 13:05 | |
Jayenkai
|
It depends on the size vs the displayed area! If the level isn't too busy, running through 100 objects in a list will be quicker than a 100x100 array. But if you've a huge number of objects, then quickly flicking through the array between (visible top left) to (visible bottom right) would be a heck of a lot quicker than checking Everything!!! Plus, that amplifies when you add other colliding moving ai objects. They'd all have to check against (things near me) or (everything). Imo, Array if lots, List if few. -=-=- ''Load, Next List!''
|
| Tue, 12 Jan 2010, 14:04 | |
JL235
|
For a tiles level I would recommend a normal array of tiles because I'm imagining the screen will be fully (or at least mostly) filled with tiles. For the objects I would use something similar to a collision grid. The screen is split into a large 2D array where each element in the array represents a whole block of pixels (typically I found somewhere around 80x80 pixels to be a good size). You then just work out which block of the array your objects are in and store them in the list in that array element. Checking to draw is just a case of seeing which array elements are on screen and aren't on screen. You iterate over the lists of the on-screen elements drawing all objects. The only issue is with objects on the border of an array element. With a collision grid you would just store the object in two (or more) elements of the array. However in this example that would lead to the object being painted 2 (or more) times. I don't see this as a performance concern, but if the objects is transparent or glowing then it will look funny. But IMHO just make a list for the objects, add them all to it and then draw them all regardless of if they are onscreen or not. With hardware accelerated graphics there would have to be alot for it to get slow. |
| Tue, 12 Jan 2010, 16:20 | |
|
deleted user |
thanks, I understand and agree with your ideas. I guess I need to think about it more, as I only have some basic sketches of my game. and will need to think how I make things like the buildings and their roofs to run across, whether they are going to be built up from tiles or single drawings. -=-=- delete my account
|
| Tue, 12 Jan 2010, 16:29 | |
|
Jayenkai
|
Something I've been thinking about, recently... In the Megadrive/Genesis Sonic games, they used 8x8 tiles to build up 128x128 blocks, then draw those blocks at a much faster rate than they could draw the same number of tiles. Not sure if that helps at all!!! -=-=- ''Load, Next List!''
|
| Tue, 12 Jan 2010, 17:31 | |
|
deleted user |
you and JL235 have brought up an interesting thought and to be honest I hadn't thought of anything like that, about splitting the screen up into blocks, within blocks. I guess the best way to find out is with some basic demos, -=-=- delete my account
|
| Sat, 16 Jan 2010, 01:16 | |
therevillsgames
|
With my Sonic remake, I did the same thing as Jayenkai said - it made doing the levels so much faster! Heres a quick bit of code for a tile-based game:
|
|
|
| |||
|
| ||||