As I keep telling people about Pico8, I always relate it back to NES/Game Boy as a way to convey the "retro-ness" of it. But just for my own curiosity, how does Pico8 compare to real 8-bit era consoles?

I'm always looking back at my favorite games for ideas and things I loved, but need to keep reminding myself that Pico8 is not an NES (nor that it should be).

And I guess, do learned Pico8 skills translate to the skills needed for those old machines? Or does Pico8 make it so nice and easy that it's like night and day?

Just for conversation :)

Speaking about graphics and resolution, I saw some atari 7800 games today and some games seemed very similar with the pico8 style. I think all the 3 versions (2600, 5200 and 7800) can serve as inspirations. Now about programming, I think the games were programmed in assembly, so the skills were very different. But the style and gameplay can be apllied.

@ Rafael
exactly - and I just posted a atari demake to second your comment : https://www.lexaloffle.com/bbs/?tid=3620

This is another great example: https://www.lexaloffle.com/bbs/?tid=2801
Qbert is another game I'd like to see in Pico8.

One thing that Pico-8 reminds me of are 80s microcomputers: Commodore64, Amstrad CPC, ZX Spectrum or the Atari 8bit line (400, 600, 800). They probably don't mean much to USA users, but any European will be able to relate.

From what I take of it, it's more a 4-bit system. The control scheme is similar to NES or Game Boy, and it's close to the screen size IIRC, but the color scheme is incredibly simplified and the memory is tighter.

Somewhere halfway between Atari 7200 and NES is about the right area. I kind of want to compare it to NGPC, for some odd reason.

Heh. What's a 4 bit system? Even simpler than the Atari 2600?

Anyway, Pico8 doesn't really compare in technical terms. It uses very few colors. Less than the NES for instance, but uses framebuffer graphics so you can do as much as you have CPU time for, which it allows vastly more of than any 8-bit home system did.

It's also vastly easier to program since you get to use a fair amount of memory, and a fairly modern programming language instead of assembly code or BASIC.

Don't forget the huge amount of memory beside the systems RAM and the vast speed of execution. No, Pico-8 doesn't compare in any way to existing machines, as it is more of an environment than a real emulator.

Hmm. I never worked on an 8-bit console. I worked on SNES, but not NES. Also 8-bit computers, like the Apple ][ or VIC-20 or C64, but those were mostly a lot more primitive.

In memory layout, it bears most resemblance to an 8-bit computer architecture. Usually your addressable memory space (albeit not necessarily your actual ram) would be twice as wide as your data width: 8-bit data, 16-bit pointers.

In background graphics, it's superior to 8-bit computers and, to my knowledge, NES-era consoles. 8-bit computers typically only did two colors per 8x8 or, with double-wide "multicolor" pixels, 4 colors per 4x8. Quite often one or two of those colors were either transparent or shared across the entire screen, making the per-cell palette more limited. PICO-8 lets you use all 16 colors at all times, which is miles above in terms of versatility. It also allows you to align tiles off of 8-pixel boundaries or have multiple layers if you're willing to draw your map more than once. It's a good call, as talent could deliver nearly the same content even with the limitation, but the pain was huge and not really called for in a fantasy console.

Foreground graphics (sprites) are also superior, by far. If you had sprites at all, you could only display maybe 8 of them at a time, at least on one scanline. You'd have to do tricks to get more than 8, and only if you know there'd never be more than 8 on a line. Similar to the backgrounds, they were typically two colors, and one was transparent, but you could up that to four (one transparent) if you sacrificed half the horizontal resolution. Also, the size was quite limited, so you weren't making fighters half the height of the screen without raster trickery.

Performance-wise, PICO-8 is again quite superior. I'm not sure exactly what constitutes a cycle, but my guess from some simple benchmarks is that it simulates a 16MHz clock. 8-bit computers were usually about 1-4MHz. EDIT: Redid my benchmark code and discovered an error. Looks like PICO-8 is about 4MHz (if an add operation is one cycle), not 16MHz. My bad.

Using Lua vs. BASIC is probably a good call, though there are some things I really detest about Lua. It's very simple, structurally, and lets you do variable-sized data handling without all the pain. Writing a game in oldschool BASIC, or asm itself, was not enjoyable, and PICO-8 is supposed to be fun and easy, albeit with restrictions. I think, for what this is, it's probably a good choice. I'd have preferred python, but that's probably a lot more hell to put in a fantasy console. :)

In short, it's similar in look and feel, but a lot less pain to work with, which is probably what everyone really wants.

Several 8-bit computers had a more restricted palette than pico-8, which is nicely chosen. Zx spectrum has 16 colors, but they are quite ugly (even if some people managed to make amazing things with it (http://zxart.ee/eng/user-data/favorites-lists/favorites/oldmaster/). The same for c64. Amstrad and Atari had a wider range of colors. Yet, I find the pico-8 colors very enjoyable.

I guess pico-8 can help to prototype a game and possibly make things easier for porting it to a 8-bit computer or console.

I like pico-8 is using Lua. Python really sucks, especially the rigid indentation, if you copy/paste code from a web browser (or use a different text editor), it can easily be messed up and no longer working. It wouldn't work for pico-8, or be at least a p.i.t.a. Using invisible elements as a part of the syntax is kinda stupid, but it was topped by the decision to make python3 incompatible with python2.

Zep actually did a great job with the palette. I don't blame him for putting it under a license.

I also worked on a most-useful 16-color system palette at one point. The goal was to maximize potential ramps and blending opportunities in typical usage scenarios. Annoyingly, 16 colors feels like it's one color short of what you need to get it perfect. Anyway, the one I came up with is almost identical to his. Only one or two colors are markedly different, hmm... let me look for it...

Ah, here it is. I arranged it differently, ideally so artists would have an easy time picking ramps. One ramp is L-shaped, one is 7-shaped, the grayscale is on the diagonal, and in all but two cases neighbors are generally suitable for blending.

Here, I edited it to show my order, then reordered to match PICO-8, then the actual PICO-8 palette.

It's remarkable how similar they are, really. Basic needs are basic needs, I guess. I will say, I think if I had iterated more, I probably would have come up with something closer to zep's, as the bold cyan was bugging me and feeling less than useful. I think he went the extra mile to make a truly versatile palette, given the restrictions. The mauve where I have a sort of blue steel is probably a better choice, for instance.

I also love the P8 palette, though I have to say that I really dig your ordering!

@Felice wow that's crazy how similar your palette is to PICO-8's! I've never tried to design a general-purpose palette before but I guess there's more objectivity to it than I previously assumed...

Following up on something I said that turned out to be incorrect:

Performance-wise, PICO-8 is again quite superior. I'm not sure exactly what constitutes a cycle, but my guess from some simple benchmarks is that it simulates a 16MHz clock.

I redid my benchmark and discovered an error. Looks like PICO-8 is about 4MHz, not 16MHz. My bad.

(I don't have an exact number, but if an add operation takes one pseudo-cycle, it looks like you get around 140000 pseudo-cycles per frame at 30fps. If the clock runs at exactly 4 mebihertz (mebi=10241024, mega=10001000), it would be 139810 cycles per frame, so I'm guessing that's the actual number. That's the limit on how much work you can do per frame.)

Hi Felice, it does run a little "faster" than that because I believe that all operations take the same number of clock cycles to complete. For example an ADD is just as expensive as a DIVIDE, when divide should be something like 4x slower. The upshot is that a lot of old 8 bit optimization a don't see to be necessary.

I think a couple of major differences are how the palette and graphics work and also the programming language.

The Nes has way more colors but a lot of rules about how they can be used. For example the background uses 4 pallets of 3 colors plus a background colors and you can only have one pallet per 2x2 tiles square. And you can only have 8 sprites per scanline without flickering. Pico8 seems to be a lot more relaxed about which colors are used where and has some "useful" colors which the NES doesn't like a solid yellow and flesh tones. It also doesn't have (I THINK?) any restrictions for sprites per scanline.

The major difference for me is ASM for NES is very very hard to use, there is no IF command, only very basic maths (inc / dec by one and add / subract) no multiplication / division or sin / cos, you have to be very aware of Vblank timing or the graphics go bananas which is kind of fun sometimes, no while, no circ/rect fill, no print etc. You get the picture. So doing something like "Hello world" is a fairly major undertaking needing a few hours of study.

Also Pico8 has loads more waveforms to playwith but no samples.

@electricgryphon:

Yeah, I have to say it bothers me to see people do "x%128" instead of "BAND(x,127)", but it seems that an op is an op on PICO-8, as far as cycles go, so I try not to make a stink about it. :)

Mind you, for anyone learning to program on PICO-8, it's kind of a bad habit to pick up. Always do a shift-right if you can avoid a divide, always do a bitwise-and if you can avoid a modulo. Division may not kill you on PICO-8, but it'd kill you on lots of other architectures.

On an N64, a bitwise op was 1 cycle, a multiply was 8, and a divide was 63. Oh, the PTSD I have from that.