256-colors, really REALLY ??
No, not really. Not in PICO-8 anyways.
Well, if you squint your eyes it sorta works. But that's really not good enough.
Now when I did something like this on the Apple ][+ years ago I had very favorable results.
- [1] it extended the resolution from 280-pixels across to 560.
- [2] There was very little flicker. Almost perfect. I wrote a 6502 machine-language routine to do it.
- [3] I even sat down and wrote a silly little Applesoft word-processor in it to demonstrate.
- [4] Apple was interested in how I did it so I wrote an article explaining my coding.
And as this cart is "presumably" running at 60fps, I'm not sure why it isn't just a comfortable blur the eyes can't see the flicker.
Maybe ... maybe if this truly is 60fps it needs 120fps to blend perfectly so the human eye cannot detect it ? Any chance of a [b]FLIP(60) and [b]FLIP(120) ZEP ?
Thanks to Felice who jogged my memory about this method in trying have the viewer see more colors in a tweetcart than were possible.
The update rate is 60Hz, however the A/B flicker cycle is 30Hz. Thus you can see it.
We've done some tests in the past and there are only about 24 colors (I forget the exact number) total that you could use with this method, including the original 16. All other combos are just too disparate.
I don't think zep's going to give us a 120Hz update, since it's not exactly in keeping with the retro theme, not to mention that most people still only have 60Hz monitors. I had a tough enough job convincing him & the crowd that a 60Hz version of _update() was a good idea.
Not to mention that your cpu bandwidth for each frame of a 120Hz update would be quite limited. The pseudo-cpu in PICO-8 only runs at 4MiHz. There are a few things, like table accesses, which are only a cycle each where they'd be hundreds on a real CPU, but that's a reasonable concession to make since the language is Lua and what Lua is capable of puts a faster-to-interpret language like BASIC to shame.
Well, as you said, the flicker is 30hz so increasing the framerate wouldn't do it I guess.
Well, darnit, worked so great on the Apple. All I needed were 2-machine language instructions. NOP and NOP and then flip pages.
Oddly enough the timing for that was perfect and while you could only see a bit of flicker at the bottom where the trace-line for the screen was - there wasn't much of it.
The Apple had a strange way of doing color. You had 7-pixels across per byte and the 8th bit would SHIFT the 7-pixels a half-step left and right.
So I thought, why not draw on both HIRES pages and the 2nd page would have everything shifted a half over and the primary not. The results ?
Beautiful, you could move in half-steps of a pixel and create some very legible and skinny text. :)
That was a long time ago though. Today ? I'm not sure what it would take to get that flicker removed completely.
Of course ZEP could add a new resolution mode, 64x64 with 64-colors. (I think that's the same space as 128x128x16) ? Already some people have favored the 64x64 and use it in their carts.
The Apple had a LORES screen that worked just fine at 40x40 pixels, longer pixels across than down, at true 16-colors instead of just 4 colors as HIRES 280x192 would give you.
I took advantage of the LORES in my games and did quite well with the wide range of colors, even going so far as to make a game that created random islands and dungeons for the player to explore using absolute colors as definitions of items instead of relying on recording their X&Y locations as games do today.
Good try with that. Too bad it didn't work. Pretty neat idea though.
Thanks, HWD. Yep, would've been awesome if it worked. Running a perfect blur Online though would be something.
Pico always staggers a bit when run as a .JS online.
It worked with picture tube monitors/TVs because they would kind of "bleed" between frames, it wasn't instant flickery like digital does. Now, if you can do this and flip(30) it in update60() such a way that there's two layers with alpha channels, it might be doable.
But then at that point, you could also just make P8 a 256-color thing, anyhow. shrugs
At least you tried.
PS: The preference for 64x64 mode is really more about fitting a substantial amount of stuff in the sprite/map space; but even that's hard to do with the limited code space. P8 is very close to being at a very cool creative sweet spot; but I do think the limits are just a tiny bit too tight to get anything other than raw jumpathons and basic shmups and puzzle games. Fitting substantial content in a cart is significantly difficult to do. Even with compression trickery.
I agree, Tony. PICO =IS= at the sweet spot - for most of us.
I mean I plan to make some real serious content in the future. Yes, I'm abandoning Blitz and RFA, at least for now.
PICO is just so darned fast, friendly, any cart posted online can easily be loaded with "#" in front.
I still think the 64x64x64 color method would work. I talk about that and have a color table HERE:
https://www.lexaloffle.com/bbs/?tid=31741
It truly would take no more space than the current 128x128x16.
Now what I'd REALLY like is multiple page commands.
APAGE(n) ... set active drawing page (0-255) (0-15 if you think 255 is too much)
PCOPY(n1,n2,c) ... copy one page to another, optional transparent color to "stack" pages on single page.
XFER(h1,v1,x1,y1,h2,v2, type, c)... copy portion of one page to another, makes use of MERGE, INVERT, XOR, AND, OR, and of course transparent color.
VPAGE(n1,n2 ... etc) ... set active viewing page, multiple pages are possible. I.E.: "VPAGE(0,1,2)" will show all three pages at once as a single view. Page 2 at the bottom, 1 in the middle, and 0 on top.
Making use of these VPAGE commands, you could try this test again. Draw one set of colors on one page, the other on the other, then simply:
REPEAT VPAGE(0) FLIP() VPAGE(1) FLIP() UNTIL BTNP(O) |
Now I tested and wrote some libraries that did these very things, but PICO proved to be too slow to keep up.
I might suggest, ZEP, that you release the speed of your virtual CPU completely.
That is, PICO will run as fast as humanly possible, where at least 10% of the entire CPU is available to burn if needed.
Only do your timeouts when you hit FLIP() or _DRAW() and stuff, and even then REALLY synchronize it to a clean VSYNC so there is no image tearing, and anything moving across the screen will glide as perfectly as can be.
You could also release memory so while you are still limited to 64k for coding (cosy spaces as you say), memory itself is released, that is, PICO can use a whole 1% to 2% of the entire computer's memory. That should be enough for everyone - and me. :)
You do those two things, and I'll have everything I need at that point. I'll go to write the graphic libraries for page copying I mentioned above as well as any other routines you would find helpful for other PICO programmers.
ZEP, If I can get a neat 1000fps or higher screen adjust with a simple For/Next loop in the 128x128x16 color space in modifying all 16384 pixels, I could write some immensely powerful graphic libraries for everyone.
You're kind of missing the point of PICO-8. Yes, it's fun to push the envelope, but PICO-8 is designed specifically to have restrictions that force people to make small games that they can actually finish. It's a very, very useful exercise in scoping, and it also reinforces the feeling that a person can finish something, allowing them to take on larger projects elsewhere with more confidence.
I'm pretty sure you saw zep's talk on cozy design spaces. That's what this is about. If you give people too much freedom, they end up with with the paradox of choice and tend to stall.
If you want unthrottled cpu, more colors, etc., use Löve2D or something. Yes, I know it doesn't have an IDE or a graphical editor, but that's part and parcel of having more freedom: the freedom to make your own tools.
(As an aside, ain't nobody actually running their draw at 1000fps, at least not without horrific tearing. The refresh rate of typical monitors is 60Hz, and tends to top out at 120Hz or 144Hz. You can't change any pixel more than once per refresh.)
Hi Felice:
By "1000fps" I am referring to the speed of running loops and calculations, no visual involved. It's sort of like an engine's RPM I guess but I'm not sure how to envision it. Let's just say billions of calculations per second. Get that CPU up to 10% if that's what it takes.
And no, I know 60fps is "visually" the top-end. That's why the CPU could be released WHILE no updating of the main screen is taking place.
I doubt very seriously it would harm a single programmer to bump up the calculation and derivation speed of PICO when it's only doing code and no graphics.
Truly, would any of you absolutely have a hissy-fit over a faster OS overall ? Would it break your code if _draw() and _update() ran at the exact same speed it does now and your code ran exactly the same way except there were no delays in your calculating loops or screen-preparation code at all ? Really really ?
And no, as many of you charming, sweet, lovable, kind, caring, would-take-the-shirt-off-your-back-to-help-a-homeless-man, and deliciously strawberry fruit-filled people have suggested in multiple, tactful, and utterly creative ways for me to "get stuffed" and "GO AWAY" - anytime I make a single suggestion about their iron-clad OS ...
I won't.
So there.
Deal with it.
:)
Some of my suggestions to advance PICO-8 have come to light and were and are now incorporated into PICO if you check your updates from years ago when I had a whole bunch of suggestions then.
Clearly not everyone's suggestions were enabled, but a few, a sparse few, were. ZEP is and always has been if nothing else a gracious host. And I was happy to see that and be a part and party of it.
Adding dither pattern improves the illusion
p=0 cls() function _update60() p=1-p fillp(23130) if(p>0)fillp(-23131) for i=0,15 do for j=0,15 do rectfill(i*8,j*8,i*8+7,j*8+7,i+j*16) end end end |
Hm ! It actually does. Nicely done !
As long as you concentrate on one area of it, it looks pretty good. Move your eyes and the illusion is broken.
Still, you've got an interesting angle on this.
It should be possible to import a 256-color picture now.
Could be personal preference but I like how fill pattern "0b0101010101010101 and 0b1010101010101010" look better than the "0b0101101001011010 and 0b1010010110100101" that p01 suggested. I actually wrote a small version that you can simply plug in more fill modes for testing.
fpt={}
c=1
p=0
function b2n(bool)
if(bool) return 1
return 0
end
function add_fp(_fp,_fp2)
add(fpt,_fp)
add(fpt,_fp2)
end
function fp_select()
print(c,0,0,7)
c-=b2n(btnp(0))*2
c+=b2n(btnp(1))*2
if(c<1) c=#fpt-1
if(c>#fpt-1) c=1
end
add_fp(0b0101101001011010,
0b1010010110100101)
add_fp(0b0101010101010101,
0b1010101010101010)
add_fp(0b1010101010101010,
0b0000111100001111)
cls()
function _update60()
p=1-p
fillp(fpt[c])
if(p>0)fillp(fpt[c+1])
for i=0,15 do
for j=0,15 do
rectfill(i*8,j*8,i*8+7,j*8+7,i+j*16)
end
end
fp_select()
end
|
If anyone is interested in messing about and finding better results or interesting ones. I supply 3 in the demo, you can use left and right to cycle through them. I like how the third one looks sort of patchworkish like a yoshi game sort of coloring filter. You can add as many as you like with the add_fp(pattern_1, pattern_2) function. Also, ignore the b2n function that's a personal preference thing. (I really believe bools should be numbers anyway.)
@dw817: That should look quite alright ;)
@Cabledragon: My eyes might be playing tricks, but with the patterns alternating vertical stripes, I clearly see 1px wide vertical lines flickering more than the rest x_X
Same thing happens if I switch for a pattern alternating horizontal stripes: I see 1px tall horizontal lines flickering more than the rest.
At least that's what I see in pico8 0.1.11g on Windows at 11pm :p
Strange on mine i don't see any flicker at all, to me it just looks like a literal static image. I don't know if my system is just running it faster or something to do with the vsync/monitor refresh rate?
Because eyes never hold still, you'll always see the flicker in stripe patterns more in the special cases, at least if the two colors both contrast with the background color. This is true not just for vertical lines with vertical stripes, but it's actually happening at left and right borders of rectangles.
It's the same problem they used to have with color-wheel DLP projection televisions. Moving your eyes leaves you with peristence-of-vision afterimages of the alternating colors, separated from each other instead of overlapping.
Checkerboard is really best overall, because even if the afterimages are separated, they are at least each dithered 50/50 between the two colors. You might see the pattern, but you won't see color fringing and the overall color will be correct, if rough.
I think I'm literally just seeing something different than ya'll. There's no flicker or anything for me. It's just a static image completely, nothing is moving at all.
Edit: Here are some pictures of what I mean. This is what it looks like to me, exactly like this, no shake, flitter, flicker, stutter, nothing. Just this exactly.
Checkerboard Pattern:
Vertical Stripe Pattern:
Also, I understand that it IS moving extremely fast and generally I can see these sort of things flicker and stuff no problem, I'm really keen about seeing small fast changes in things! But this is literally just static to me. I have no idea what's up with that.
Edit 2.0: I figured it out, I'm using a TV for a monitor and it has post processing that's preventing the flickering.
[Please log in to post a comment]
