Tic-80: [Discussion] Improve the Code Editor

[carlsmith]

I quite like the current code editor, but it's still needs fixing. I'll explain why in the comments, so you can skip that bit if you already agree.

Thinking about TIC-80 like an OS, we could treat the bar along the top of the UI as separate from the rest of the UI, a bit like the menubar in OS X.

OS X uses the menubar to merge the system menu with the currently focussed window's menu to save space, which is similar to what TIC-80 does.

Text and Graphics Modes

If TIC-80 had a graphics mode (which was just how it works now) and a text mode (with a higher resolution, but limited to a grid of glyphs, each with a foreground and background colour), then the console and code editor could use the text mode, and everything else continue to use the graphics mode.

TIC-80 could define a desktop mode (which just means that the menubar is visible at the top) and fullscreen mode (without the menubar).

Assuming we want to keep everything else the same:

• console: text mode in fullscreen
• code editor: text mode on desktop
• other editors: graphics mode on desktop
• running games and demos: graphics mode in fullscreen.

The Numbers

To get the text mode, the 240x136 resolution could be doubled to 480x272, which would still only allow 80 characters if they were 6px wide (really 5px, with a 1px space). Tripling the resolution to 720x408, gives us 9px per character, which seems perfect.

Having the text mode use a multiple of the graphics mode will ensure that everything still looks pixel perfect when the (graphics mode) menubar is above the (text mode) code editor.

Having higher definition text would also make it possible to integrate documentation into TIC-80, maybe using a man or docs commands.

A TIC-80 text mode should probably use memory mapped glyphs too??

[carlsmith]

The reasons why I think external editors are a problem...

If a user asked for GIMP integration in TIC-80, because they found the built in sprite editor too limiting, they'd be told to use a different tool or a workaround. The same goes for tile maps and audio, and should apply to text editors equally. You can argue that programmers are particular about their tools, but pixel artists and chiptune musicians are just the same.

The problem (in my opinion) is just that PICO-8 designed an editor that is too limiting, and then allowed external editors, because they couldn't think of a solution. Other fantasy consoles copied the same approach, and ended up with the same compromise.

External editors break the sense of actually working on a fantasy console (ruining the suspension of disbelief). They're clunky (you can't hit Escape to get to the shell, or Ctrl-Enter to run the code, F2, F3 etc). They force new programmers to look at one set of docs for the TIC-80 computer, and another set for their editor (complicating things for educators and tech writers too), and a lot of new programmers use TIC-80 in their browser, where they don't have another editor.

[nesbox]

I think we could double the resolution to 480x272 decreasing the color bits from 4bpp to 2bpp in the Code Editor. This won't break the rules and still fit VRAM size. So, we can move in this direction...
Interesting ideas, thanks.

[carlsmith]

Awesome. Thank you.

[ephetic]

How about a few enhancements like highlighting matching bracket and rudimentary completion? I'll research the history, but I wouldn't be surprised if they existed on Vic, Amiga, etc.

[Anrock]

@ephetic matching brackets were merged couple of days ago: https://github.com/nesbox/TIC-80/issues/1075

[ephetic]

Whoo hoo!