ah, well, yes you are going to have to make layers then. If you ever played any of the emulated SNES games (not that any of us have...), some of the emulators have options to turn off seperate graphics layers. Evidently the Super Nintendo built graphics into layers. If you take a game like Chrono Trigger or Final Fantasy 3/6j, you can turn off the different layers and see how the game was built. So you'd have the background layer, the ground tile layer, the sprite layer, the tops of the buildings (which lets you peek inside and see hidden passages, teehee!), and special effects like fog, mist, sunshine or underwater looking things on top, all blended of course.

So, as was my original original suggestion, organize your UpdateObjects into layers. for my system, i have a sprite layer, 4 background layers and 4 foreground layers. That gives me lots of room to create special effects. Then i blit each layer in order from bottom to top. My objects are not tied to a map, as such, so...

The other thing is that you don't necessarily need to stick to the tile-based mode of thinking for everything. You can mix tiles and free-floating objects if you organize it right. Your free-floaters can be pointless eye candy too. But don't get stuck in the "Everything is a tile" mode of thought or you will unnecessarily limit yourself. However, if you still want to do that, that link i posted previously has links to articles that discuss that very problem of "walking under" tiles.

You can also see what i'm talking about mixing tiles and free-floaters here in this thread of mine

[edited by - leiavoia on May 28, 2004 11:12:51 PM]

you are not drawing a "scene full of tiles with an array". Your just drawing a bunch of objects. My system doesn't care if it's a tile, gunshot, character, exposion, etc. Let's disect:



A: Is an explosion consisting of 1) an explosion animation, 2) a light flare (textured quad), and a shower of particles. It all happens real fast. The animation, flare, and particles are free-floating. They have no tile coords and are not tiles. They simply exist in world space at about 500x,500y. None of these entities are collision objects. They just look pretty.

B: Happy face! He blows up if he hits too many walls. He exists in world space and he's also a collision object. All collision objects get sorted into a quadtree which files objects into a specific region of space you only check objects against other objects in the local space, instead of everybody against everybody.

C: Fading Explosion. The light flare has gone (it fizzles out in 95ms) and was removed as an UpdateObject from the list. The animation is still going, as are the particles.

D: World block. No it's not a tile array, it's a quad with a repeating texture. The same is true for the side bars. In total there are 5 world blocks in this scene. They are also collision objects and get sorted into the quadtree as well.

E: Particles. They are not collisionable and exist in world space by themselves. The update engine cycles over each particle and updates and draws each one every frame.

F: The background! It's just a textured quad with an offset repeating texture. The offset produces a scrolling effect and parallax too (pretty schnazy).

There are no tiles on this scene. There is no array. All objects are independent. That doesn't mean that i couldn't ALSO use a tile array. Which i have also played with: (Screenshot shows offset tiles, except all tiles are still independent quadtree-sorted objects)



[edited by - leiavoia on May 29, 2004 1:58:43 PM]

quote:if you dont use tiles to draw your background/world block, how do you track it all? i mean, if its not a tile, how do you judge how big to make the quad?

Everything gets stuffed into the UpdateObject list. Quadtrees keep track of collision object space partitioning.

quote:your map editor must be really sophisticated to say "make a quad here x by x units"...

Actually it''s pretty simple... i don''t have a map editor, as such. (yet). I plan to keep my world data in XML though.

quote:also, you must keep track of all these thing''s positions then, huh? so even the background tiles have a recorded x,y position for collision detection and such im assuming?

True. each object has a collision rectangle.

quote:also, how do you go about doing collision detection? is it just standard bounding box, or something different?

Something different. It''s a rather compicated system now. It checks for abject type and object geometries. All objects have a collision hitbox, but some objects have other more sophisticated geometries like a sphere or polygon or point. If it passes the basic hitbiox test, i can stop or move on to a more accurate test. There is a lot more to it than that, but if you ware looking for a headswim, check this other thread of mine

quote:lastly, is this system better then using tiles? i mean obviously you can get more diverse objects on your scene, but what about speed and such? i know that thread you mentioned it wasnt as fast....

No, not necessarily. This model works for free-floating objects very nicely. For tiles, i think i''d design something different and custom tailored for that. Not much can beat a raw array lookup for speed. My system is designed to handle objects of different types (world, player, enemy, weapon...) and different geometries (sphere, poly, point, box...) quickly. It wasn''t meant for a tile engine, but that doesn''t mean i couldn''t add a new kind of object to the list that acts like a tile array.

I don''t know anything. Man, i work in a photolab!

I''ve been C++''ing for about ~2 years. I picked up perl and PHP (mostly forgotten now) a year or two before that. Perl still comes in handy. I started learning C++ by creating a TBS game which i worked on constantly for a year. and dropped it around March to work on more action/graphics oriented games (i wanted to program explosions!).

Most of what i know i pick up from other people or learn from trying different things. I''m sure i''m a terrible programmer, but i sound smart :-)