VVhat's new ?
✅ Changed code so it will load any image, 3-bytes per pixel or 4-bytes per pixel such as images that include transparent layers. Thanks to @jo560hs for catching this error.
✅ Set the code to exit if you choose WEBSITE. No need for it to keep running.
Not only do you get a nice Christmas greeting in 256-colors, (you might need to squint a bit to remove the flicker), you can create your own 256-color pictures to add to your own Pico-8 games with the EXE tool I've included as well as some sample pictures to try on your own.
You can also import any PNGs or JPGs of any proportion or image size from your own collection or from the internet, my program will accept them all the same.
Once the filebox appears and you decide you want JPG, Press TAB and the down arrow key to change to view JPG images.
To record your results you can save to the clipboard replacing the single line that contains your picture or save an entirely new Pico-8 program that features just the image you've put in it. No need to paste.
If you choose clipboard, once the code is run, go back to your Pico-8 code and press the following keys:
CTRL+P CTRL+V CTRL+P
Make certain you press CTRL+P twice. Once before and after CTRL+V. Then the image will be pasted properly.
Also this affects none of your sprites, mapper, SFX, or music. They are all untouched once the picture has been seen. This demo shows a box appear in the center at the end which is from the sprite worksheet to show nothing is affected.
The playback routine is also pretty small too at 186-tokens, and outside of the picture, no other code is needed.
If you get flicker, and you are using Firefox, shut it down completely and bring it back up. Apparently the timer is getting garbled somehow. I have received no flicker at all running it in the P8 system, however.
@zep ! Please add ability to play carts at 120fps =or= allow someone to plot 2-pixels in the same space merging the colors with the original. Doing so should remove the last of the flicker in this particular code.
If this cart becomes popular I'll consider adding to the converter the ability to edit the image in true-256 color fashion where you can fill in regions to match other colors so the direct conversion looks better as well as fine-tune editing - useful for real photographs which will almost always give trouble converting to 256-colors.
And there you have it !
As always if you have any questions, comments, or kerosene, please direct them below.
Merry Christmas !
Thanks, @jo560hs ... and,
Oh, transparency. Something I had not anticipated. I just tried it with one of my own PNGs with transparency and it works fine.
Can you post the PNG HERE or give me the URL to it please ? With that image I should be able to hunt down the problem.
Failing transparency on some images it should work for all other files. My program is especially looking for 128x128 PNG images with 24-bit color although it will reduce larger images and keep the proportion correct.
Thanks, @ScrubSandwich. Yep, it's pretty well a parlor trick and while I'm certain you could play music behind it no problem and the illusion would be maintained, I doubt a real game could be developed and played in it.
Certainly it could be done you could post a cart that has 2-pieces. The first is opening music and 256-blended logo. Hit a key, it runs the main game via the load # command.
Yet this goes back once again to some suggestions and directions I'd like to see future Pico-8 take - hopefully @zep is reading.
We already have 128x128 pixels at 16-colors, that's 8192-bytes, that's fine.
We HAVE the potential to have many more resolutions though which I think would be well-appreciated. Here are 3 at the top.
- My favorite, 256x256 pixels with B&W dots only, or choose your two-colors. 8192-bytes.
- 64x128 pixels with 1-byte per pixel, 256-colors. Each pixel would appear 2-across by 1 down. Pretty well would look like just what I developed here but would not flicker. 8192-bytes.
- 64x64 pixels with 2-bytes per pixel, 65536 colors or mix and match the full spectrum of 32-shades of red, 64-shades of green, and 32-shades of blue. Each pixel would appear 2-across by 2-down. Also 8192-bytes.
The other idea might be simpler and that is to have a screen mode, a mode only, where you can blend up to 2-colors per pixel on the screen visually. Visual only. Memory does not change.
For instance if you plotted let's say color 4 and color 0 on this new screen mode. You would have a darker brown but if you read the pixel back it would still be zero, the last color you plotted.
So in fact the screen itself is still 128x128 at 16-color pixels but the MODE it runs in would let you BLEND up to 2-colors per pixel visually.
Thus it would require your code to plot 2-black pixels per pixel to erase it completely and CLS() might even have to be run twice to clear the screen completely.
I think these are good ideas and can be done ! Something to consider ...
oops i forgot to send it
(google drive because lexaloffle doesnt support transparent images)
Thanks, @jo560hs. I have the image in hand. Hmm ... There is a slight set of green pixels outlining in the image provided.
Here is the command code:
And here are the image results:
.. wait, I am forgetting you said it did not load properly in my converter. Let me get that working first and I'll return.
. . .
Found the problem. Apparently loading a transparent PNG uses 4-channels instead of the standard 3. The easiest solution would be to treat it all images as custom PNG and force-load it using the resizer and method. There really was no reason for my code to skip over it if the image was already 128x128.
At a pixel level nothing will change, however all images will now be loaded internally instead of assuming 128x128 perfection at 3-bytes per. In this I should be able to give you your WHITE background.
Working on this ...
Solved. No pixel differences in other imports. Let me save it back. Be aware that any resized image which does not appear 1x1 proportions will have a white background behind it now, transparent source or not.
There are 2 changes now. See top for information.
Not now but later, JO560HS, I can see it would be helpful to have a pixel editor in the EXE converter for instance to remove or replace with a new color the stray green pixels. It is considered.
Glad you like it ! And no I haven't seen the GBA do this. This idea is actually based on an article I wrote for Call A.P.P.L.E. back when I was a tween. That and I think someone in Pico-8 showed a merge of colors use a cross-hatch pattern.
Is there an example cart for GBA ?
I don't know if that is possible. I did this years ago on the Apple ][ computer to give you "virtually" 560-pixels across and even wrote an article for Call A.P.P.L.E. about it. Yet to maintain the effect it had to run in a tight 6502-assembly loop.
As I remember it I made a loop where it would show HIRES 1 and look for a key. If there was a key it would exit. If no key it then showed HIRES 2 and look for a key. If there was a key it would exit. If no key was found it would return back to showing HIRES 1.
I used NOP between statements to fine-tune out the flicker.
For the full article, go HERE:
Until we can blend pixels I'm afraid this is as good as it gets. It must run in a tight loop to give the effect as well as it can.
Now if @zep can add the ability where a function can run automatically in the background of your main code giving it maximum priority over _draw() and _update(), say,
function _pulse() running at 30/ 60/ or even 120fps, then it might be possible.
[Please log in to post a comment]