Pretty much like C64 allowed it. Changing the font would have few limitations compared to using spritedata:

• Each character would be 1-bit ONLY (e.g. pixel is either on or off)
• Changing characters will affect how code editor and command mode is rendered (mainly to give you live preview of your changes) so if you like writing in flowers and bushes, that's your problem ;).

This would allow to customize our games even more.

I second this request. I'm teaching kids how to code using pico-8 and being able to select a "regular" font would help the M's look more like M's. Same with the # sign and a few other characters.

I would like this too. Especially if it can be changed in size, to say 4x8 instead of 4x6 as it is now.

I can think of so many things one could do with a changeable font. At the same time, the kind of systems pico-8 is inspired by had plenty of text and none of that was "built in" so to speak.

I'd definitely appreciate an easier-to-read editor. I know every time I want to dig into serious code, an external editor is almost a requirement. (with basic hilighting I had to set up manually)

I throw out a compromise of sorts - don't touch what we currently have when a game is running, but double or triple the (text) resolution in the editor. (and embiggen the font) It would make more serious endeavors that much more approachable, and that's where I think pico-8 really shines, both in interesting limitations and power/flexibility.

@tyroney I second that. the devkit part should not suffer from the limitations of the console part.

even editing at 320x200 would be great in comparison:
40x25 with an 8x8 font including lower case! (amstrad, 1985)

also even pocketchip is @ 480x272.

That's a great compromise idea, tyroney. Preserve the retro feel but make it easier for heavier work to be done in the editor.

Notepad++, etc, works but it breaks the feel of the system for me. I like the immersion.

Yep, UB, or even (if we can get a little greedy now), 800x600 pixels ! And the ability to change the 16-colors to your own custom palette.

Can you imagine the games made - with the ability to code their own personal and custom 16-color palette ? I think that'd be a great benefit.

Now if space is a consideration, the current PICO tile of 8x8 w 16-colors possible per pixel takes 32-bytes. 8*8=64/2=32.

The old 8-bit NES, however, used an interesting idea. Their tiles were also 8x8 but with 4-colors possible per tile and took 16-bytes in all. 88=64/8=82=16.

If PICO allowed this unique resolution, you would have 16-bytes left over. 12 of which could be used to define the RGB of the 4-colors to this tile, and you would still have 4-bytes left over, perhaps giving the ability to add animation and cycling codes.

But yes, PC and PSP use the resolution of 480x272, and that would definitely be great to have it available.

nah, dw. I think the console part is mostly ok as it is.
the devkit, however, doesn't need such a strong fake retro feeling. I don't think anybody ever edited code directly on a nes, you had a devkit connected to a pc. pico8 is closer to a home computer, most of which could do at least 320x200 with a readable font (and lower case).
if 480x272 is the lowest resolution pico8 ever runs on, let's just have that in the devkit, that would be awesome.

I'm good with 480x272 ! Turns out I can actually run PICO on my PSP 1000. Unfortunately it requires hardware that broke a long time ago. Heh - I have a little Santa Sticker over the area so dust doesn't get in.

I can kind of see why a limitation is in order on tiles, audio, and mapping - as you can PASTE as binary code a whole cart directly in a message in here.

Were it really big, it might hang the tab that has the forum open, or worse yet, the whole browser.

I'm working on my main project. It's slow going. I'm thinking someone in a future post is going to say DING ! I wrote an external GUI for PICO for those of you interested.

And I will undoubtedly check it out. :)

There are a couple of third-party cart editor apps already, but that shouldn't discourage you from writing your own. It's fun! :)

P8Coder by movAX13h: https://www.lexaloffle.com/bbs/?tid=3351
Tools section of the Awesome PICO-8 list: https://github.com/felipebueno/awesome-PICO-8#tools

Just tried P8Coder. It doesn't recognize my source - and not too surprising since I don't use the defaults of _init, _update, or _draw.

Just want to add my vote for having access to the chargen bitmap, maybe both the live version during runtime and also the default one used for editing.

On the other hand, I don't vote for having a different resolution. I like that pico-8 is a self-contained dev system in the style of, say, a c64, and in that case, you didn't get an option of a higher-resolution screen when editing. Just my opinion. I think an external editor would be better for those who want that.

Might as well share the font I have in mind. Originally I geared it for Gameboy Advance, but I think it'll work here in a pinch.

Oh - can't find it. I'll redraw it shall I ? Thing always look better the 2nd time around.

This is just the letters, notice they are SHARP (and by that I mean few diagonals). This is geared for a SMALL screen (like the Gameboy Advance), they show up very nicely. If you want this size for a larger screen, there are more diagonals included and that is a different font entirely.

This could be a disaster for legibility.

When every cart uses the same font, you get accustomed to reading that font; it becomes very legible to you. You stop noticing the font; it's about the text, rather than the font.

If a cart uses a different font, now you have to work hard to read it because you do not already know it. You notice the font, and it's hard to focus on the text. Combine this with the fact that making legible fonts at such a small resolution is actually a very challenging thing, and you have a recipe for frustration, without much benefit, I'd argue. If you really want a custom font that badly, it's not that much work to use the sprite sheet and implement your own font drawing routine.

Anyway, if we are talking about changing the glyphs but keeping them the same size, I don't even see much point, since there are only so many ways to fit each letter into 3x5 pixels. If we are instead talking about allowing the glyph size to be customized, that suddenly becomes much more work to implement, and thus less likely to happen.

I do see a potential benefit to using a different font for the code editor only, but again that is probably nontrivial to implement since it breaks the whole graphics model of everything being at 128x128.

In short, I think it's fine how it is :p

P.S.
tyroney's compromise idea (i.e. for the code editor only, use the same resolution, but scaled up by even numbers so that the glyphs can each have a higher resolution) seems the most realistic to me though, if anything was going to get implemented.

This is not to replace the system, Kittenm4ster. You do understand the system font is 4x6, right ? Mine is 4x8. A total overwrite would be necessary breaking PICO, you must see this.

No - this is for in-game use only for others who want to add a little legibility to their lowercase letters.

Not everyone is out to get you - only half of us. :)

dw817: Right, it is 4x6, but if you want spacing between letters, it is effectively 3x5 as far as the letter is concerned.

> Not everyone is out to get you - only half of us. :)
Yes they are! That's why I wear this tinfoil hat!!! And don't talk about THEM that way...THEY CAN HEAR US! :O

Mine would be then 3x7.

Now you're sounding like me off my meds. :) I actually did have some vivid hallucinations last nite, but I'll save that for my weekly shrink.

3x5 would be a challenge. Actual visual size 2x4 ? I don't think an uppercase K would look very good.

Let me know if anyone wants the serif for the 3x7 or the remaining characters to make up 96 for the 'sharp.'