search

nesbox / TIC-80

TIC-80 is a fantasy computer for making, playing and sharing tiny games.
https://tic80.com
MIT License
4.97k stars 481 forks source link

[Discussion] Improve the Code Editor #723

Open carlsmith opened 6 years ago

carlsmith commented 6 years ago

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:

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

Awesome. Thank you.

ephetic commented 4 years ago

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 commented 4 years ago

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

ephetic commented 4 years ago

Whoo hoo!

kindfulkirby commented 3 years ago

I've been thinking about a text mode for TIC-80 all morning, and I did some math.

Double resolution (well, 2x which is actually four times as many pixels) gives us 480x272 (same resolution as the PSP!), which would give es 80x34 characters with a per character resolution of 6x8 (5x7 plus whitespace between letters, maybe even 5x6 to avoid clashes between lines). Any smaller font becomes impractical, I fear.

Assuming 1 byte for the character (0-255) and 1 byte for the fore- and background color (4 bit each, as usual):

80 * 34 * 2 = 5440
16320 - 5440 = 10880

So there'd be 10880 bytes of VRAM left, perfect for a separate text mode font? (That feels like there's too much RAM left? Is my math off?)

Assuming 256 characters and a 6x8 1-bit font, we'd need 6 bytes per character or 1536 bytes for a whole text mode font. And there'd still be enough RAM left over to do the whole thing again.

Text mode should definitely have box-drawing characters and other useful things. It could even be made user-definable?

Sadly I'm rubbish at C and SDL things, so I'm afraid I won't be able to implement this myself… :(

EDIT: Two nice 6x8 fonts from old portable computers: https://int10h.org/oldschool-pc-fonts/fontlist/font?hp_100lx_6x8 https://int10h.org/oldschool-pc-fonts/fontlist/font?portfolio_6x8

The first one has lots of characters beyond the basic ASCII range, the second one actually fits all characters (except box-drawing), into 5x6 pixels, avoiding letters "connecting", e.g. a y above an i.

EDIT 2: This collision of ascender and descender (or whatever) on two letters could be avoided even better with a 6x9 font, resulting in 30 lines of text and 2 lines of pixels going unused.