Skip to main content

Browse GamesGame JamsUpload GameWinter Sale 2024Developer LogsCommunity
On Sale: GamesAssetsToolsTabletopComics
Indie game storeFree gamesFun gamesHorror games
Game developmentAssetsComics
SalesBundles
Jobs
TagsGame Engines
vonhoff2 years ago

Hi Marc,

I hope you're doing well. I took another look at the issue this afternoon and found a potential fix!

The issue seemed to occur randomly, and when something seems random it could have something to do with memory allocations. I managed to fix the issue by moving line 167 in LoadTileset.c to line 100. It should execute after the tilecount assignment.

After performing this fix, I no longer got randomly missing tiles, which is great. I'm not sure whether there would be a better fix, perhaps you might have an idea. I could make a pull request with the changes if you would like.

Reply
megamarc2 years ago

Hi vonhoff!

I revised your possible fix. I can't see the logic behind it, I'll share my thoughts here:

  • block around line 100 is called for every xml attribute found inside the main "tileset" tag. Here the loader is just gathering all the attributes
  • block around line 167 is called after the last "tileset" attribute has been issued, but before starting to process the next xml tag. Here the loader has all the xml attributes, so it proceeds to allocate memory for the required structures
  • "property" and "tile" xml tags are always found after main "tileset", so the required structures are always found to be already created.

Moving the creation of structures inside the parsing of a single attribute before the whole set of attributes has been gathered would be premature, and potentially dangerous. So I won't do a pull request with a fix until we don't understand why it works.

That said, you're right wit the assumption that nondeterministic (random) behaviour happens with memory management issues, as well as with threading. These two components change their state outside the control of the application, so they can present a different state each time if not properly managed.

I'll do some tests, as the "cliffs" tileset is very prone to exhibit this behaviour.

Thanks a lot for your support!

Reply
vonhoff2 years ago

You're right, on second thought I don't see it as a solution either. The bug still persists with the incorrect solution I thought I had found. I'm just not that experienced with software development yet, I'm still learning.

I hope you can find something that could resolve the issue. Keep me up to date :-)

Reply
megamarc2 years ago

Hi!

I've found the cause, now I can proceed to write a fix. Quick fix for now: just open "layer_background.tsx" with Tiled version 0.13 or newer (released on August 2015) and save it without editing anything.

Tilengine relies on a tsx property called "tilecount" to determine how much memory the custom properties array will need. This property was introduced on Tiled 0.13. It seems that I created come of these tilesets long ago with an older version, so this property is missing. The loader doesn't check this value, so it allocates a 0 bytes array that gets filled with random garbage padding (legit arrays are properly zero-filled). This garbage causes that some tiles get priority property randomly set, making them appear in front of the front layer.

Regards,

Reply
AboutFAQBlogContact us
Copyright © 2024 itch corp · Directory · Terms · Privacy · Cookies