Comments (22)
To be honest this sounds like a bug. The map should be rendered as it appears in Tiled by default. It is possible that you are using newer, unsupported features - the map loader only supports Tiled up to 0.9 iirc, whereas Tiled is up to 0.18 now
from sfml-tmxloader.
Where in the library could I go about adding that code to support the features?
from sfml-tmxloader.
It would seem what I'm talking about was added in 0.4 Tiled.
https://github.com/bjorn/tiled/blob/0.9/NEWS
0.4.0 (30 January 2010)
- Added support for isometric maps
- Added automatic reloading of tileset images when they change
Added Offset Map action that can shift a set of layers by a certain amount - Added a fill tool
- Added ability to duplicate map objects
- Added support for choosing the tile layer data format used when saving
- Added mouse wheel zooming support to the tileset view
- Added an object display color attribute to object groups
- Added ability to edit tile properties through a context menu
- Made writing out a DTD reference optional and disabled it by default
- Made translations functional
- Updated Dutch, Portuguese, Spanish and German translations
It's almost as if the layers are all locked into place. They all render, and in proper order. They just dont take into account the offset.
Or are you saying that the .tmx that the latest version of Tiled saves as might be different and incompatible with tmxloader?
from sfml-tmxloader.
Looks like I never added support for it. You'll probably want to start by parsing the node property here, then add it to a new property in the Layer class and use it to draw the offset
from sfml-tmxloader.
Thanks so much man! Awesome thing you made here. Been reading your blog too.
There a way to contact you by email or just here?
from sfml-tmxloader.
Just trying to figure out where to put the property now for the drawing. Is that in MapLayer I need to change the draw method? I already parsed the node properties.
edit*
Such as this?
void LayerSet::draw(sf::RenderTarget& rt, sf::RenderStates states) const
{
//std::vectorsf::Int32 dirtyPatches; //TODO prevent patches being duplicated
for(const auto& q : m_dirtyQuads)
{
for(const auto& p : q->m_indices)
{
m_patches[q->m_patchIndex][p].position += q->m_movement; //<<<<<< add offsets here?
m_patches[q->m_patchIndex][p].color = q->m_colour;
}
from sfml-tmxloader.
To be honest I can't remember exactly what that bit does :) If you have the offset available in the draw function you can try modifying the states transform here by adding:
states.transform.translate(offset.x, offset.y);
from sfml-tmxloader.
Thanks again, I guess I don't have it available in the draw function yet. I will work on that, haven't figured it out. I haven't used translate and transforms yet in SFML. I'm guessing I need to somehow make the offsety and offsetx that were parsed, into the offset.x and offset.y. I am the suckiest noob after all. No formal education in this stuff. :P
Wish me luck!
from sfml-tmxloader.
I guess I was wrong. Custom Layer offsets weren't added til .14 of Tiled.
You said development of tmxloader is ended indefinitely? Was going to ask how much it costs to get you to add a feature, through that patreon.
Still working on adding it myself however :P
Could you possibly tell me the difference between the MapLoaderPublic vs MapLoaderPrivate .cpps? And why there is a MapLoader.h and a MapLoader.hpp? If you have the time.
from sfml-tmxloader.
Is there a way to share with you what I've changed? I am new to this github stuff.
Maybe get your input on it? It compiles and everything but for some reason the layers still don't move, I must be missing something minor.
edit** I just saw your TMXlite will do isometric orientation. I thought I read it only did orthogonal :P. Going to try again to make that work.
from sfml-tmxloader.
Hi
Yes, I'm afraid I'm unlikely to do any more work on this project, it's actually very badly made and pretty much beyond redemption, hence its deprecation in favour of tmxlite.
If you want to share your changes, however, I'll happily review them. The general github workflow is to first make a fork of the repository, which creates a copy under your own username. You may then clone it, makes changes, then push those changes back to your fork. When this is done you can do side by side comparisons of changes with the original, and submit 'pull requests' whereby I can choose to accept a change and 'pull' those into the original repository.
tmxlite will indeed parse all the information you're looking for, but I should point out that the example renderer does only support orthogonal maps. It's shouldn't be too much of a stretch to adapt it, however. The idea behind tmxlite is to separate the parsing of map files from the rendering. You'll end up with a map object which is effectively a C++ representation of the xml file. You can then use this data to draw the maps as best suits the framework you are using. This is why there are two examples included, one for sfml, and one for SDL2. If you're having difficulty building tmxlite there are binaries for visual studio for download under the 'releases' tab.
from sfml-tmxloader.
Ah okay. Thanks for the lesson on github workings. I actually found those releases last night looking through your blog. I have tmxlite working now.
The map loads, but I can't get the layers to draw yet. I will get it to work though.
from sfml-tmxloader.
Good to hear!
Personally I've never tried drawing non-orthogonal maps so I can't say for sure, but I'd assume it's a matter of correctly setting up the points of the vertex array to match the tiles, in which case you probably want to start here. The other thing worth bearing in mind is to add the vertices in the correct order (top down?) so that the tiles overlap properly if they need to. Once you get isometric maps working I'd love to see it so I can add it to the examples! ;)
from sfml-tmxloader.
Hey, back finally. Alright will do once I get it working.
Maybe you could help me out. It seems the example renderer has quite a bit to it. The map is split into "chunks"? I imagine so that there can be large or perhaps endless maps?
I'm having trouble pinpointing exactly where I need to place things because it's not as straight forward as I'm, used to.
For Isometric without layers I need to fit code that looks like this.
`
void Map::draw(sf::RenderWindow& window, float dt)
{
for (int y = 0; y < this->height; ++y)
{
for (int x = 0; x < this->width; ++x)
{
//Set the position of the tile in the 2d world
sf::Vector2f pos;
pos.x = (x - y) * this->tileSize + this->width * this->tileSize;
pos.y = (x + y) * this->tileSize * 0.5;
this->tiles[y*this->width + x].sprite.setPosition(pos);
// Draw the tile
this->tiles[y*this->width + x].draw(window, dt);
}
}
return;
}
`
That would be the code I have made for isometric without layers for a custom map format in binary.
Now I came across this, someone had been kind enough to show me how they get Z layers inside their game. And it would be akin to this.
`
for (int y = 0; y < viewModelMap.GetLength(1); y++)
for (int x = viewModelMap.GetLength(0) - 1; x >= 0; x--)
for (int z = viewModelMap.GetLength(2) - 1; z >= 0; z--)
if (viewModelMap[x, y, z] != -1)
{
int xPos = -(x * (Tileset.TileSize / 2));
int yPos = -(y * (Tileset.TileSize / 2));
int zPos = -(z * (Tileset.TileSize / 2));
int xPosition = -(xPos - zPos);
int yPosition = (xPos / 2) + (zPos / 2) + yPos;
spriteBatch.Draw(Tileset.GetTileSprite(viewModelMap[x, y, z]), new Vector2(xPosition, yPosition) + Position);
}
`
So this second snippet will do layers.
But seeing as the render example you have is split up between chunks and such. I am not quite sure where to place this code/where to get started.
You say start with the vertex array?
from sfml-tmxloader.
Not quite sure why those snippets didn't post properly...?
from sfml-tmxloader.
The chunks are there for performance reasons - it basically splits the layer into smaller parts so that there are only 1-4 chunks per layer drawn at any time, depending on what's visible for the current view. Of course if there are two layers visible the count jumps to 2-8 and so on. You should be fine to leave that as it is, and concentrate on where the tile quads are added. Like I say I've not done isometric rendering myself, but I should imagine it's only a case of making the vertices rectangular per tile, rather than square, or perhaps even diamond shaped to match the tile. Adding the vertices to the vertex array and drawing the arrays/chunk should stay the same (unless there's some special case I'm not aware of).
To post code snippets in markdown each line must begin with at least 4 spaces. I've found this page is worth bookmarking ;)
from sfml-tmxloader.
Alright so I think I've figured it out. The vertexes I don't think I need to change because it just takes in the parsed values for tileSize x and y. So it's just the tileOffset I need to change.
edit* erased what I wrote before. Realized it was something I had done when generation the tmx file. Still working on that offset though.
from sfml-tmxloader.
Hey again.
So I've almost got it working changing around that orthogonal example. The map loads, not sure if the offsets are working exactly but I am thinking that isn't the problem. The tile sizes also correctly parse and load.
I put some couts in there to tell me what was going on. The offsets are definitely wonky but I think it has more to do with the "chunk" system you have in there (which I want to keep to see how it works).
You said you didn't write Isometric before? (I am still using tmxlite)
Did someone else add this to your tmxloader?
https://github.com/fallahn/sfml-tmxloader/blob/master/src/MapLoaderPrivate.cpp#L706
https://github.com/fallahn/sfml-tmxloader/blob/master/src/MapLoaderPrivate.cpp#L170
https://github.com/fallahn/sfml-tmxloader/blob/master/src/MapLoaderPublic.cpp#L178-L184
^^^ When I had tmxloader working before (albeit without the Layer Offsets) it rendered isometric great. Just didnt have those offsets. I like your Tmxlite too it is definitely more flexible, so I'm going to stick with it.
So for that chunk system. In your example renderer.
https://github.com/fallahn/tmxlite/blob/master/SFMLExample/src/SFMLOrthogonalLayer.hpp#L63-L83
(I'm trying to get this to work before attempting to write my own loader with your tmxlite parser, though I'd say it works great when I tested it for orthogonal)
So in that code for splitting it up into chunks. The cout on the last line there does print to the console telling me it's an invalid map.
Will I have to apply the same math to how the "chunks" are created as I did to the layer/tiles and their offsets? Like is that "chunk" system set up for Orthogonal at the moment and I'll have to change it too to render the tiles?
from sfml-tmxloader.
This is what I've changed so far. If you want to see. It's the header file I just renamed it from IsometricLayer.h to what you see there to get it into a txt file.
The changes I tried to make to the tileOffset and such is down by where the Vertexes are created like you pointed out before, starting at around Line 111 if you turn that into a header file or throw it in Sublime text or something. I actually tried a fiew different ways of making the tile offset including the one u had in tmxloader, which I think is the one uncommented now. I had some others that arent commented in but it looks like I deleted them.
from sfml-tmxloader.
Also here.
https://github.com/fallahn/tmxlite/blob/master/SFMLExample/src/SFMLOrthogonalLayer.hpp#L279-L301
Will I need to change some stuff around in there to get it to render properly?
from sfml-tmxloader.
Did someone else add this to your tmxloader?
Yeah the tile flipping was contributed by someone else - you'll have to check the file history to find out who :)
The chunk system works something like this: It starts with a fixed size - in this case 1024x1024. It then looks at the tile size, divides the current size by that, then rounds it to the nearest whole tile (there's actually an open issue with this right now). Once it has calculated the chunk size the renderer calculates as many vertex arrays needed to create all the chunks it needs to draw the entire map. A chunk also has a global bounds of chunkSize
which the renderer can then use to check whether or not it intersects the current view.
I think the problem you'll have with isometric maps is that tiles aren't square - which the chunk calculation assumes. You'll need to update it to calculate both the width and the height of the chunk accordingly - as opposed to assuming the height is the same as the width, which it does currently.
from sfml-tmxloader.
Thanks!
I'm reeeally close now, even have the tileoffsets working properly. Still can't see them though. The last sentence you wrote is exactly what I need to do.
Could you by any chance highlight the section of code that calculates the chunks like the entire "scope", like the part I need to change? I am having difficulty pinpointing it (Noobishness)
from sfml-tmxloader.
Related Issues (20)
- Thanks Matt! HOT 3
- No compatibility with AnimatedSprite class? HOT 2
- MapObject setVisible ? HOT 3
- Terrain Tiled tmx load HOT 3
- Strange culling HOT 4
- Collision issues HOT 7
- Animated Tile with Tiled Editor HOT 4
- layer->tiles doesn't give tiles from layers HOT 3
- GetLayers() doesn't work as spected HOT 4
- Simple test fails: call for help
- Unresolved external symbol HOT 12
- Can't draw map properly if it wasn't the the first one the maploader loaded. HOT 4
- Colission with player sprite HOT 6
- Collisions detected incorrectly due to AABB having incorrect height (2x what it should be) HOT 1
- Isometric causing weird issues HOT 5
- unresolved symbol sf::Sprite::Draw in MapLoaderPublic.obj? HOT 1
- Missing vtable HOT 3
- Can not build tmxsfml project as I've set link options correctly HOT 1
- Doesn't build woth MinGW Makefiles HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from sfml-tmxloader.