New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

New chunk based format for infinite maps #1696

Merged
merged 4 commits into from Aug 28, 2017

Conversation

Projects
None yet
3 participants
@ketanhwr
Contributor

ketanhwr commented Aug 22, 2017

I've removed startx and starty attributes from Tile Layer. Now, for infinite maps, each 16x16 chunk will be stored along with its startx and starty coordinates.

@Ablu

I added some code style comments. Generally I wonder whether it would maybe also make sense to store non-infinite maps in the chunk based format... In some cases this could help to speed up the processing of the file (and file size if no compression is used...). But I am not sure on this and would like to hear @bjorn's feedback first. Otherwise I think that in some places the code is reaching a deep nesting of ifs, loops, etc... which makes it hard to follow at times. Maybe some helper functions could be introduced to prevent too deep nesting and keep the individual parts easier to understand?

Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapwriter.cpp Outdated
@ketanhwr

This comment has been minimized.

Show comment
Hide comment
@ketanhwr

ketanhwr Aug 22, 2017

Contributor

Generally I wonder whether it would maybe also make sense to store non-infinite maps in the chunk based format... In some cases this could help to speed up the processing of the file (and file size if no compression is used...).

Although this would be quite helpful, but this would break all the current maps 😕

Contributor

ketanhwr commented Aug 22, 2017

Generally I wonder whether it would maybe also make sense to store non-infinite maps in the chunk based format... In some cases this could help to speed up the processing of the file (and file size if no compression is used...).

Although this would be quite helpful, but this would break all the current maps 😕

@Ablu

This comment has been minimized.

Show comment
Hide comment
@Ablu

Ablu Aug 22, 2017

Contributor

Although this would be quite helpful, but this would break all the current maps

Sure... It would have to be configurable somehow... But I am not sure how such a configuration could look like...

Contributor

Ablu commented Aug 22, 2017

Although this would be quite helpful, but this would break all the current maps

Sure... It would have to be configurable somehow... But I am not sure how such a configuration could look like...

@bjorn

Added many comments regarding the same theme: reducing code duplication.

Regarding the usage of chunk-based storage for finite maps, while I agree that this could be useful it's not a high priority to support this right now. Please do make sure that reading of chunks also works for finite maps, which should be pretty much automatically supported.

Show outdated Hide outdated src/libtiled/gidmapper.cpp Outdated
Show outdated Hide outdated src/libtiled/gidmapper.cpp Outdated
Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapwriter.cpp Outdated
@bjorn

Some more comments.

Show outdated Hide outdated src/libtiled/gidmapper.cpp Outdated
Show outdated Hide outdated src/libtiled/gidmapper.cpp Outdated
Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapwriter.cpp Outdated
Show outdated Hide outdated src/libtiled/mapreader.cpp Outdated
Show outdated Hide outdated src/libtiled/mapwriter.cpp Outdated
@@ -825,26 +823,52 @@ void MapReaderPrivate::readTileLayerData(TileLayer &tileLayer,
mMap->setLayerDataFormat(layerDataFormat);
int x = 0;
int y = 0;
if (mMap->infinite()) {

This comment has been minimized.

@bjorn

bjorn Aug 26, 2017

Owner

It's a pity the reading code relies on checking whether the map it's reading is infinite or not. I believe this really shouldn't be necessary, and not doing so would help with forward-compatibility when eventually we may support chunked storage for finite maps. Can you think of a way to handle the chunks without this check?

@bjorn

bjorn Aug 26, 2017

Owner

It's a pity the reading code relies on checking whether the map it's reading is infinite or not. I believe this really shouldn't be necessary, and not doing so would help with forward-compatibility when eventually we may support chunked storage for finite maps. Can you think of a way to handle the chunks without this check?

This comment has been minimized.

@ketanhwr

ketanhwr Aug 27, 2017

Contributor

I'm not able to think up of a solution. I don't see how we could remove this check, atleast as of now.

@ketanhwr

ketanhwr Aug 27, 2017

Contributor

I'm not able to think up of a solution. I don't see how we could remove this check, atleast as of now.

@bjorn bjorn merged commit 3f907f0 into bjorn:master Aug 28, 2017

2 checks passed

continuous-integration/appveyor/pr AppVeyor build succeeded
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@bjorn

This comment has been minimized.

Show comment
Hide comment
@bjorn

bjorn Aug 28, 2017

Owner

Alright, I'll have a look later at trying to remove the infinite check on reading, but otherwise it looks good, thanks!

Owner

bjorn commented Aug 28, 2017

Alright, I'll have a look later at trying to remove the infinite check on reading, but otherwise it looks good, thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment