Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
Sprite/Tile YSort effect and Camera Movement
#1
Currently, I have successfully managed to implement collision detection by making using of a TMX library (I advise loading collision objects be a future feature of Tilengine) however I have been unable to pull off a convincing enough in-front-of/behind effect for the protagonist and walls, as it makes use of layer priority, which only works so well while the protagonist is behind the upper part of the wall found in the prioritized layer. I suppose I may scrap having such situations at all for the better of continuing work without much hassle, but I am curious about doing this even then.

Another thing is that I wish to implement a camera similar to that of games such as Earthbound. However, I am not skilled at this and therefore having it center around the character results in the position of the player being stored becoming inaccurate, which prevents collision detection from working correctly. I'm also curious about this. 

[Image: unknown.png]

[Image: unknown.png]

Example screenshot from Earthbound for the SNES.
[Image: earthbound-twoson-jogoveio.png]
I wish you could just mov the obstacle from the destination.
Reply
#2
Hi!
I've moved this question to "Game development topics" because its topic is more about gameplay implementation than tilengine specific.

What you're attempting is not the easiest of gameplay mechanics. Unlike pure 2D games (either sidescrolling or top-down), you're dealing with 3/4 perspective here, that's a form of pseudo-3D, or 2.5D. Here the Y axis combines both height and depth.

Usually you have to split your map in two layers:
  • A regular priority layer with elements that are behind player ("front" part of walls)
  • A high priority layer with elements that are in front of player ("back" part of walls).
You have to design your map in a way that the same tile can't be both in front and behind the player, all extruded elements must have a minimum height so spriteas can't overlap in both sides.

Perspective in Earthbound is even trickier, as the x axis is also affected with this front/back scheme depending on which side of an extruded object your player is (left is back, right is front).

In broad sense, Tilengine is a graphics engine, not a game engine, so it doesn't feature gameplay-domain abstractions such as actors, player/level collisions, and so. The same concept as 2D graphic chipsets, they didn't provide these features (they just provided graphic output), it was the game code that implemented them. However Tilengine provides necessary tools to build these features on top of it. Tile-based gameplay don't usually require external collision data, as the collision information is stored in the tile itself, either in its ID or in its "type" standard property. Tilengine can already load "object" layers from Tiled (introduced in release 2.5.0), albeit it only loads "Tile" objects because it's the type of entity that Tilengine uses to draw object layers. Consider if free-form collision objects are the right tool for you task.

As always, if you put code and assets, I can take a look at them Smile
Reply
#3
(05-07-2020, 02:25 AM)megamarc Wrote: In broad sense, Tilengine is a graphics engine, not a game engine, so it doesn't feature gameplay-domain abstractions such as actors, player/level collisions, and so. The same concept as 2D graphic chipsets, they didn't provide these features (they just provided graphic output), it was the game code that implemented them. However Tilengine provides necessary tools to build these features on top of it. Tile-based gameplay don't usually require external collision data, as the collision information is stored in the tile itself, either in its ID or in its "type" standard property. Tilengine can already load "object" layers from Tiled (introduced in release 2.5.0), albeit it only loads "Tile" objects because it's the type of entity that Tilengine uses to draw object layers. Consider if free-form collision objects are the right tool for you task.

As always, if you put code and assets, I can take a look at them Smile

I see! I think it's a bit easier for me to think of things by treating Tilengine more as a graphics API xD But yes, currently I would appreciate help with this type of tile scenario. I should also adjust the collision box better for when the protagonist is moving left or right. I am soon going to use the object layer for loading in bigger assets like in the Forest example and also as well NPCs. Beware you'll need to disable the TMX library both on source and makefile if you won't use it, or if you do, compile the library accordingly to what the Github project wants. It was a head pain for that...  Sick


Attached Files
.zip   rpg.zip (Size: 10.76 KB / Downloads: 1)
I wish you could just mov the obstacle from the destination.
Reply
#4
Hi!
Finally had time to check your post. Your "city.tmx" map doesn't contain any square object, is that right?
I've checked that Tilengine since release 2.5.0  can directly load "Rectangle" object type out of the box, for that purpose you can discard libtmx entirely:
This is possible because Tilengine already loads "Tile" objects, that have the same internal representation as "Rectangle" objects, but with the "gid" attribute set all to 0.

Assuming you have an object layer named "collisions", this is how to load its objects:

Code:
TLN_ObjectList list = TLN_LoadObjectList("city.tmx", "collisions");
TLN_ObjectInfo info = { 0 };
bool has_object = TLN_GetListObject(list, &info);
while (has_object)
{
    //do_whatever_with(info);
    printf("Object %d, x=%d y=%d w=%d h=%d\n", info.id, info.x, info.y, info.width, info.height);
    has_object = TLN_GetListObject(list, NULL);
}

The TLN_GetListObject() iterator is called in two different ways:
  • First time, to get "first" object, the TLN_ObjectInfo pointer must ve a valid one
  • Inside of the loop, to get "next" object, TLN_ObjectInfo must be NULL, meaining that it uses the previous one and that is a continuation.
In next release I'll expand the TLN_ObjectInfo struct to retrieve name and type standard properties, but it should work for you just as it's now. Let me know!
Reply
#5
Hi again!
You may be interested on update 2.8.2, that enhances tmx compatibility loading. Check post here:
http://www.tilengine.org/forum/showthrea...11#pid1411
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)