-
Notifications
You must be signed in to change notification settings - Fork 4
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
Comments
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. |
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. |
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 |
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.The text was updated successfully, but these errors were encountered: