Hi !
Featured games (90)
games approved by the League of Dukes
Games in Showcase (777)
Games in Android Showcase (231)
games submitted by our members
Games in WIP (856)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
    Home     Help   Search   Login   Register   
Pages: [1]
  ignore  |  Print  
  How to improve my Iso Engine?  (Read 5279 times)
0 Members and 1 Guest are viewing this topic.
Offline FaVorith

Junior Newbie

« Posted 2008-03-15 14:22:53 »


After I have gained experience in writing a 2D Role Playing Game in Visual Basic, I now want to realize the project in Java.
Since I don't want it to be just a remake, I decided to improve some features.
One of these improvements is the Iso Engine I use.
Up to now it is a very simple "engine" which is able to display a huge (scrollable) picture of the landscape which can furthermore animate objects (e.g. a mill wheel etc.). Because I use the graphics from which do not have a unified size, the engine is not tile-based and information like unwalkable areas has to be set manually by placing "invisible walls".
What annoys me is the fact that this engine lacks an important feature:
The hero is painted above all the other objects. That is, he cannot walk "behind" a house for he would conceal the building. Until now, in order to whitewash this weak point, I place the "invisible wall" mentioned above all over the building so the hero simply can't move to the place where he would be "behind" the building. However, this solution doesn't look very nice.
I now want to write an engine which supports an improved "ZOrder" so that the hero can walk in front of and behind the building (by the way- how is this feature called correctly?).
Unfortunately I have no idea how to realize such a feature... . I think I will have to discard the practice of simply loading a huge image file as the map and just placing some animated objects here and there. Instead I will have to place every object "in real time" in order to decide if it has to be drawn before or after the hero image. But how can I decide this? When does the draw order has to be changed? And do I have to alter the "invisible wall" concept as well in order to realize the "ZOrder"?

Sincere regards,
Offline moogie

JGO Ninja

Medals: 16
Projects: 6
Exp: 10 years

Java games rock!

« Reply #1 - Posted 2008-03-17 02:13:55 »

You could demux the big image up into multiple big images which will be layers. (say three) Such that the first layer consists of objects in the fore ground, the second layer consists of object on the same plane as the player and the third layer of object that exist in the back ground.

and so in the render loop.

draw background layer
draw player plane layer
draw player and enemies, etc
draw foreground layer.

Java4k RIP 2014
Offline Riven

« JGO Overlord »

Medals: 1357
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #2 - Posted 2008-03-17 06:48:12 »

If you'd simply render everything back-to-front (up-to-down) you'd have infinite layers.

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline cylab

JGO Kernel

Medals: 188

« Reply #3 - Posted 2008-03-17 10:21:33 »

Like Riven said, rendering the level from it's parts at run-time would be the most flexible solution. If for some reason you don't want to do that, you can create your own z-buffer while composing your level-image. Companioning your level, you would have to create a map of z-positions of every pixel in the map, so you can compare the z-position of your player-sprite with that of a possible occluder (e.g foreground buildung) or obstacle (buillding or invisible wall on the same z-level).

Mathias - I Know What [you] Did Last Summer!
Offline FaVorith

Junior Newbie

« Reply #4 - Posted 2008-03-21 19:13:31 »


First of all: Thank you for your answers!

I already came up against the idea using several layers but there is something I don't understand:

Let's say I put all my buildings in one layer and the player is in another one.

So what happens if we want to walk "behind" a building- but being "in front of" another building at the same time?
If the player layer is higher than the buildings layer and as a result is drawn later, we will get something like this:
As you can see, the hero is drawn over both buildings- not what we wanted.

If the player layer is lower than the buildings layer and as a result is drawn earlier, we will get something like this:
As you can see, the hero is drawn under both buildings- not what we wanted either.

So, to get the correct result:
we will have to sort "in real time"- am I right?

Ok, let's say we draw "up to down", as Riven said, and we care about the player's position, we could get something like this:
// pseudo code
objects_to_draw.sort(); // beginning with the object which has the lowest (y+height) coordinate (second criterion in case of equality: lowest (x+width) coordinate).
for (current_object : objects_to_draw) {
   current_object.draw(); // one of the objects_to_draw is the hero himself

By the way, you might ask why I'm sorting by (y+height) and not just by y?
The answer is that if we just sort by the lowest y coordinate, our hero won't be able to disappear behind a building "completely", because as soon as his head disappears behind the building (that is when he walks down), his y value is higher than the y value of the building he stands behind and as a result the hero will be drawn over the building (because we are rendering top to down).

This algorithm might work, however sorting the objects_to_draw every frame is not high-performance at all ;-)
Furthermore I'm not sure if I'm not overlooking a possible building-to-building or building-to-hero arrangement which doesn't work with this code... .

So what to do?
I apologize for any disabusing notation- it's not what I wanted- I've just written down my thoughts :-)
I hope you can help me to solve this problem :-)
Offline Riven

« JGO Overlord »

Medals: 1357
Projects: 4
Exp: 16 years

Hand over your head.

« Reply #5 - Posted 2008-03-21 20:11:32 »

Sorting every frame might be somewhat slow. You can only re-order the units that have moved.

1. Take all moved units from collection (preferable NOT one backed by an array, such as ArrayList)
2. Put them into a separate collection
3. Sort the collection with units that moved
4. Insert the moved units one-by-one in the world-list, at the appropriate places.


global = ..;
insertIndex = 0;
   Unit unit =;
   int y = unit.y + unit.h;

   while(insertIndex < global.size())
      Unit gUnit = global.get(insertIndex);
      int gY = gUnit.y + gUnit.h;
      if(y < gY) { global.insertAt(insertIndex, unit); break; }

// add remaining moved units.


That should be as fast as it could ever be, when relatively few units move around.

A custom implementation of a LinkedList (that remembers what the last get(i) was, and caches it for a quick insertAt) would work best.

And now it's only a matter of time before somebody hands another solution

Hi, appreciate more people! Σ ♥ = ¾
Learn how to award medals... and work your way up the social rankings!
Offline JAW

Senior Devvie

Medals: 2

« Reply #6 - Posted 2008-05-09 09:31:14 »

An Isometrich Engine handles Z Order by the drawing order.

You draw the tiles in lines, beginning with the top row. First draw the ground, then the top wall and the right wall (if any). Then draw objects on the tile like player, monsters, trees and stuff. Then draw left wall and bottom wall, if they exist, and the tile is done. Draw from left to right and top to bottom.

This way the player is always drawn over walls top of him and is overlayed by walls from tiles below him. The layering is not applied to the whole screen, but actually to every tile. Every tile is drawn back to front in means of the viewing perspective. Elements far away from the camera are drawn first, then elements that are nearer. That way, everything closer to the camera will overlay things further away.

Offline fletchergames

Senior Devvie

« Reply #7 - Posted 2008-05-09 15:08:06 »

Put the player in the same layer as the buildings.

In a pseudo-isometric RPG I made, I had several layers: ground, events (which were invisible), walls/furniture/characters, and roofs.  I believe that it is what JAW described, though I'm not sure he described enough detail.

Instead of storing characters in an array by themselves, I included them in a 2d array with the walls, furniture, etc.  I put each object in only one array position (rather than storing it in every position the object covered), so moving it was easy.  I believe the (x,y) position in the array was the position of their bottom-left tile.

I drew from top-to-bottom then left-to-right, and it all worked out fine.

There may be a slight problem if the characters can be drawn inside the buildings, since you have whole buildings, where I just had walls that happened to form buildings.

Of course, you've probably already resolved this, since the topic is almost 2 months old.
Pages: [1]
  ignore  |  Print  

hadezbladez (290 views)
2018-11-16 13:46:03

hadezbladez (159 views)
2018-11-16 13:41:33

hadezbladez (291 views)
2018-11-16 13:35:35

hadezbladez (72 views)
2018-11-16 13:32:03

EgonOlsen (2151 views)
2018-06-10 19:43:48

EgonOlsen (2177 views)
2018-06-10 19:43:44

EgonOlsen (1366 views)
2018-06-10 19:43:20

DesertCoockie (1984 views)
2018-05-13 18:23:11

nelsongames (1626 views)
2018-04-24 18:15:36

nelsongames (2273 views)
2018-04-24 18:14:32
Deployment and Packaging
by mudlee
2018-08-22 18:09:50

Java Gaming Resources
by gouessej
2018-08-22 08:19:41

Deployment and Packaging
by gouessej
2018-08-22 08:04:08

Deployment and Packaging
by gouessej
2018-08-22 08:03:45

Deployment and Packaging
by philfrei
2018-08-20 02:33:38

Deployment and Packaging
by philfrei
2018-08-20 02:29:55

Deployment and Packaging
by philfrei
2018-08-19 23:56:20

Deployment and Packaging
by philfrei
2018-08-19 23:54:46 is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!