Jump to content
  • Advertisement
Sign in to follow this  
Pussycat_669

Working with layers

This topic is 2772 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hi again :)

Here's the deal: I'm trying to handle objects/graphics with different print priorities (e.g. 'print floor before object') for a top down perspective. The way the algorithm is dealing with this now is to create a layer of arrays for every noted print priority and then print all the objects/graphics layer for layer. The position of the things to print are remembered by their position within the array since graphics (not objects) themselves can't store any coordinates. The neat thing about this is that it makes limiting the scope of the printed window fairly easy since you can basically cut a frame out of the array. This is still rather inefficient in the long run however since the algorithm often has to work through a lot of empty spaces (especially when there is only one object/graphic for a layer) and since this is my first shot at this, I'm really curious how the pros would handle the situation. Please note though that the language used doesn't allow any object creation during runtime although I don't know if that would be a problem.

Share this post


Link to post
Share on other sites
Advertisement
That seems like an oddly limiting language, not allowing dynamic object creation.
Can't you store the position in the objects and simply add the objects in the layer's list? Then every frame, you sort the list for rendering order(if you need to) and draw them based on the object's position. You would get rid of the "loop through a bunch of empty spaces" part of rendering.

Share this post


Link to post
Share on other sites
It's a language meant for interactive fiction and as ill-suited for the task as you might expect. Storing object coordinates isn't a big deal, however it's the independent graphics which is the problem here since all 'instances' printed are just references to one real instance, so every relevant data for a reference has to be stored within the object which is responsible for printing instead. My take at this would be to first print the floor tiles (the graphic stored within a tile with the lowest print priority) where I can use the original cut out frame approach (I just claim that every tile at least has a floor graphic) and then work with a combination of an graphic array and coordinates array, or just one number array with reference calls for graphics, per layer.

Another problem I forgot to mention is that the algorithm allows to expand graphics by either a variable assigned to individual objects or with a special print function for independent graphics. The print object only stores the modified height and width and not the extra fields the expanded graphic would occupy. This makes determining printing such graphics harder since when it's origin coordinate lies outside of the printing range and above or left of the focus point, some parts of it should possibly still be visible.

How would you efficiently decide what has to be printed and what not anyways? I presumed that you have a focus point and a range from that point which marks the legal printing range. What would be an efficient method to determine which graphics had to be printed, assuming they are not expanded?

Share this post


Link to post
Share on other sites
Printing from the ground and up can work as long as your objects will not overlap. For example, you will not be able to draw the ground in front of a character.

As for what needs to be printed, a simple AABB check will do it for you. Have your graphic objects store their screen coordinates, then compare with the camera and draw only those which are overlapping.

Share this post


Link to post
Share on other sites
Do you usually try to determine the distance between focus point and every single tile though? Seems like a waste of resources when you're handling a large map.

Share this post


Link to post
Share on other sites
You can use spatial partitioning for these cases. You got a few choices here like a quadtree or spatial hash. They will allow you to reject big parts of the map with a single check.

Share this post


Link to post
Share on other sites
When you say top down perspective, do you mean something like this?

screen_03a.jpg


If so, I can share with you the algorithm I wrote for my own project if you like (its open source). We have 3 layers of tiles and 3.5 layers of objects (the 0.5 layer allows for objects to pass over/under things like bridges). The algorithm is pretty efficient. You don't need to worry too much about algorithmic efficiency for an isometric game though (unless you're developing for systems with very basic requirements).

Share this post


Link to post
Share on other sites
I was more thinking of an Alien Breed kinda perspective but nothing is set in stone yet. So yeah, I sure would be interested!

I think I've made some progress though. Now I just store the graphical data (coordinates and print priority most specifically) within the map, so to speak. That way I just need to run through the sectors the print object is looking at to create a list, sort that list and print it on screen. This approach is quiet slow since it has to rebuild the whole screen in every reprint phase so I tried to speed things up by making the program able to differentiate between static (e. g. wall tiles etc.) and non-static (objects or anything with referable data) graphics. The print object will now collect the static graphics only once from the map but will ignore the non-static ones at first. Then, during the reprint phase, it circles through all printable objects within a location and add them to the list of graphics that are going to be printed (since the list is already sorted, I can use a d&c method to insert the object in a sorted manner). It is still slower than I had hoped for but I'm not sure if there is much else I can do otherwise.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!