Hi @zep:

I was giving this some thought and think it would be good and interesting to have the ability to import a picture to sprite-sheet (or memory) directly through the import command thus:

import("?.png",0xe000,0x2000)

So in this case a file-box would appear and you can select importing a 128x128 16-color PNG directly to memory contents 0xe000. It could be a picture or an 8192-byte data file saved as a PNG.

And the opposite could also be true:

export("?.png",0x6000,0x2000)

Which would also open a filebox and this time give you a chance to save off the current screen as a single 128x128 16-color PNG file.

Defaults are memory location 0x6000 and length of 0x2000, so if you chose, export("?.png") it would save memory location 0x6000 (screen) length of 0x2000 (8192-bytes) to external file of user choosing.

' save 0xe000-0xffff to png
function savedata()
  print("save your world data")
  export("?.png",0xe000)
end

What do you fellow Piconians think ? is this something you could also find useful ?

For me, dealing with file dialog boxes doesn't fit with the whole idea of PICO-8 being an 8-bit fantasy console. It would feel more like Windows 95 at that point. It may just be that I lack imagination, but I also can't think of a console gameplay scenario where I as a player would want to select a file, which I would have to be aware fits into PICO-8's color palette ahead of time, to replace the sprites the game already provides, and as a developer I can already import spritesheets from immediate mode.

This isn't to discount use cases others may have for this idea, but I would never make use of it myself.

Quick check: are you describing functionality that the existing .png importer doesn't offer? I'm a little confused by the request because I remembered seeing that in there already.

(That said, I had no idea that the importer let you fill in the label, not just the spritesheet - that sounds incredibly useful.)

Hi @2bitchuck:

Now let me see if I am hearing this correctly. You don't want this function because it "breaks" the theme of 8-bit fantasy console ?

Let me ask you a few other questions if I may.

Would you prefer that TLINE was never created ? The usefulness of it. The function.

Would you like it so that HELP is no longer a command in it as it was not chosen in the original Pico-8 design ?

Would you like P8SCII to have never been made or designed ?

What I'm getting at here is very simple, @2bitchuck. Pico-8 is a wonderful and marvelous invention written by the multi-talented @zep.

Without US, you and me, Pico-8 would never have gotten as far as it has without our deep debugging, suggestions, corrections, and additions. NO incredibly complex and versatile program such as this ever has.

And suggestions are part of that flow. I have made some suggestions to Pico-8, and they were enacted. You may have yourself. They may have been carried out.

So, no, I do not agree that limiting Pico-8 is a good option. I do not see that as positive. In fact I see it quite negatively.

And to put the icing on the cake it appears that ZEP has already allowed external data to be saved similar to as I mentioned above, though it is not documented to this effect.

Try this code:

cls()
repeat
  circ(rnd(128),rnd(128),rnd(6)+6,rnd(15)+1)
  if btnp(🅾️) then
    extcmd("screen")
  end
  flip()
until forever

Run that ^^ online. Press 🅾️ to see something incredible.

In this you can save that image as a separate data file or screenshot .PNG with a filebox that appears. No, there is no way to inject a PNG into Pico-8 memory I know of - yet. But I hope to see it in time.

. . .

Hi @packbat:

Yep, this is different from regular import() and export() In that it could be coded so if you choose "?" as a filename, it then goes to the standard filebox for that OS, Windows or Macintosh, and lets you choose a filename to fill in for that text. And then runs the command associated with that file. That is all.

Here is a good example. We have 8192-bytes of data stored into our array game[]. We are now ready to save it to an external file.

function transferdata()
  for i=0,8191 do
    poke(0xe000+i,game[i])
  end
  export("?.png",0xe000,0x2000,"choose filename to save data")
end

export( "?.png",(memory start),(memory length),(optional text to appear with filebox) )

Since you can choose 0x8000 as memory, you could save really 32768-bytes of data via:

export("?.png",0x8000,0x8000)

Which would produce a PNG of 128-pixels across and 512-pixels down, or add an argument to save it as a PNG 256x256, your choice, created from the data stored from 0x8000-0xffff

. . .

And to ALL, once again this is just a suggestion. If it is created by @zep you in no way are required or forced to use it. But it is there and available if you so choose. It breaks nothing and affects no-one's current or previous code.

@dw817 HELP is surely a different thing though, it's API documentation and not something you would put into a game. HELP to me is something akin to the IMPORT we already have, something a developer would use in immediate mode while developing. And TLINE is just another drawing API using data already in the cart.

> And to ALL, once again this is just a suggestion. If it is created by @zep you in no way are required or forced to use it.

Understood, but your question was "is this something you could find useful?", which is what I was answering rather than "could anyone find this useful?" Similarly, in regards to your extcmd() example, I would also never use that but I don't care that it's there.

Thank you very much for taking the time to clarify.

To answer your initial question, no, I don't think I'd find it very useful as you've described it. For data i/o, you can already use printh() to save data to files and drop files onto the window to load data from them; for image sharing, 128 px square is so core to PICO-8 that honestly? If I want to use a cart to generate something larger, I just take multiple screenshots and composite them together afterwards.

Hi @2bitchuck:

HELP is a command you can type in Pico-8 followed by the ENTER key now to get help on commands, or to put the cursor on a command in the editor and press CTRL+U to get direct help on that command. That was what I was referring to.

@packbat:

That's fine. I agree reading and writing to the string clipboard is convenient, yet reading and writing from direct memory such as 0x0000 up to 0xFFFF and saving it as a PNG is a different and unique way of saving and recalling binary data that can be shared by other members online.

It would not just be used for screenshots, yet allow you to import custom images online, useful for paint programs, for instance.

Sure there is 6-bit strings with printh() yet the PNG would give you true 8-bit data, 25% more storage and recall per character.

I can understand you being completely against it though.

@dw817 Yes, I know what the HELP command is, my point is that it's not the same as TLINE or your proposed import function - it's a developer tools/documentation feature rather than a part of the game building API. Players never encounter it.

From a developer point of view, I don't care too much about the 8-bit console feel - I use an external text editor and other external tools to develop. From a player POV though, I am in favor of games preserving the illusion & feel of an old school 8-bit console, and I think a file open dialog box where the player has to know enough about the guts of PICO-8 (file format, image size & acceptable colors) to choose the correct file breaks that illusion. It's possible I'm the only dev who cares about that, and that's OK.

You asked whether we could find this function useful, and I personally would not. I feel like you may have somehow translated that into me being opposed to its addition (and somehow that I may have been opposed to TLINE or HELP?), but I'm just saying I would never use it, I don't care if it ends up in PICO-8 or not.

Not at all, @2bitchuck. You stated your opinion, honestly, perfectly, and sincerely. And that's fine. No more, no less. And I thank you for your time.

In any case I just figured a simple way around this and in time may post my findings. In time ...

And no, you are not alone in not wanting to see certain changes to Pico-8 because it "breaks" it.

There have been a great many suggestions for Pico-8 from others that will likely never come to pass because others believe it "breaks" Pico-8.

Some of the greatest things happen in the world because someone simply doesn't want to believe it is impossible or will never happen.

Interesting findings these ! :)

@dw817 Thanks, and thank you for your contributions to the community!