You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The current tools either create or modify a cart file in place (build) or create a second cart file as output with the same type as an input cart file and a munged name (luamin, others). They support loading and saving .p8 files and .p8.png files, but only operate on the same type of file.
We can clarify the command line syntax with explicit input and output files, similar to, say, ImageMagick. This would also give us an opportunity to implement format conversion, where the input is one type and the output is another type. This was always the intent, but we never got around to it.
Important: We'll need to review carefully whether there are bugs in the internal representation of a cart that need to be fixed before we can implement this. For example, I believe that the .p8 reader needs to swap letter casing such that regular PICO-8 text is represented by P8SCII uppercase letters, and the .p8 writer has to swap it back again. If we don't do this, loading a .p8 then saving a .p8.png will have code with inverted letter casing. We haven't noticed this yet because no case conversion is happening on input or output and the tools only write the same format out as was read in.
I have some thoughts on rearchitecting game.py to be extensible with format readers/writers, and more formally using P8SCII as the internal representation of Lua code. This would allow not only .p8 and .p8.png conversions, but conversions between the .js and .rom formats as well.
The text was updated successfully, but these errors were encountered:
The current tools either create or modify a cart file in place (build) or create a second cart file as output with the same type as an input cart file and a munged name (luamin, others). They support loading and saving .p8 files and .p8.png files, but only operate on the same type of file.
We can clarify the command line syntax with explicit input and output files, similar to, say, ImageMagick. This would also give us an opportunity to implement format conversion, where the input is one type and the output is another type. This was always the intent, but we never got around to it.
Important: We'll need to review carefully whether there are bugs in the internal representation of a cart that need to be fixed before we can implement this. For example, I believe that the .p8 reader needs to swap letter casing such that regular PICO-8 text is represented by P8SCII uppercase letters, and the .p8 writer has to swap it back again. If we don't do this, loading a .p8 then saving a .p8.png will have code with inverted letter casing. We haven't noticed this yet because no case conversion is happening on input or output and the tools only write the same format out as was read in.
I have some thoughts on rearchitecting game.py to be extensible with format readers/writers, and more formally using P8SCII as the internal representation of Lua code. This would allow not only .p8 and .p8.png conversions, but conversions between the .js and .rom formats as well.
The text was updated successfully, but these errors were encountered: