Skip to content
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

Secondary compilation using a vanilla set as paired primary is confusing #47

Open
grunt-lucas opened this issue May 10, 2024 · 3 comments
Assignees
Labels
enhancement New feature or request

Comments

@grunt-lucas
Copy link
Owner

grunt-lucas commented May 10, 2024

See #46 . This is obviously not a good user experience. Porytiles should provide a way for users to supply a compiled tileset as the paired primary. This should not be too difficult, since Porytiles already has an easy way to import Porymap-format tilesets into a CompiledTileset object, this is used by the decompiler. We can leverage that here. Porytiles can do some basic file-existence checking to determine if the input is a Porytiles or Porymap-format tileset.

@grunt-lucas
Copy link
Owner Author

After an initial trial implementation on this branch, I am suspecting this is not a great idea. The reason being: since the pre-compiled paired primary was not compiled via Porytiles, it's not guaranteed to contain properly normalized tiles.

For example, if a user creates a secondary tileset and then pairs it with the pre-compiled primary general, they'll end up with a lot of tile duplication, since Porytiles is not able to detect that some of the compiled tiles are flips.

There is also the problem of transparency. Vanilla tilesets don't use a consistent transparency color. This is technically OK, as long as the user utilizes the Porytiles transparency color in their secondary set, it will still be able to match up the tiles with the primary (assuming that it happens to already be in normal form in the compiled primary). But it's highly unintuitive.

Finally, the compiled tileset import code (created for the decompiler) which I am borrowing for this feature does not fill in some of the CompiledTileset fields that are needed to do tile assignment.

@grunt-lucas
Copy link
Owner Author

One way to address user confusion: we should have a very explicit error message when Porytiles detects that a user tried to supply a Porymap-format tileset for use as the paired primary. If we can't properly implement pre-compiled paired primaries, this is a decent compromise.

@grunt-lucas grunt-lucas removed this from the Official 1.0.0 Release milestone Sep 11, 2024
@grunt-lucas
Copy link
Owner Author

Another idea: implement a system that can "normalize" compiled tiles, so that the emit step can find instances where a secondary tile is already present in the pre-compiled paired primary. This would be a significant amount of work. I am removing this feature from the 1.0.0 milestone.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

1 participant