In-game serial console visualization

[fnuecke]

Add a GUI / in-world rendering of the serial console's output (instead of just dumping it to Java's stdout).

• [x] Store current state of serial console.
  • How wide and high?
• [x] Synchronize changes to client.
• [x] Render to screen (requires #7).
  • [x] Add font renderer? (Codepages would be good enough for this)

[iamgreaser]

Well, that was less painful than expected (point 1 has now been ticked):

• b8801a1 adds a serial console screen state tracker, while outputting lines to stdout.
• dd6b085 refactors it a bit, and outputs to MC global chat instead.

TODO: ANSI escape codes. But those can come once we have it rendering to a screen.

Either 40x25 or 80x25 will do. It's now stored based on two adjustable parameters (three if you count the tab stop parameter), so feel free to adjust them to suit.

• 40x25 is more MC-friendly, and seems to be a good "Tier 1" for the GPU stuff (2KB gets us 16 bits per B/W char, or 8 bits per B/W char + 128 chars + invert bit, or 160x100 B/W graphics).
• 80x25 looks better when using 1:2-ratio chars (e.g. 8x16).

Here, this screenshot should be a good motivation for getting screens working: https://i.imgur.com/dtUoBsH.png

[fnuecke]

Looks great! I agree, 40x25 should be fine for this.

OK, so, next up. For syncing to the client the synchronization stuff is sadly not ideal (as it'd send the full buffer). I'm thinking scheduling a callback on change (once, until it's run), simple put all unprocessed input into a buffer (maybe StringBuilder could even be more efficient if it avoids boxing the chars?), and send the buffer in the callback then clear it - then apply the changes the same way the server does on the client.

Alternatively I might add a SynchronizedDiffedByteArray (name pending) that'd make the assumption that the size doesn't change (often) (when it does, full thing is sent), then keeps the previous sent state and builds a simple diff to send to the client (sending value+indices (less overhead) or the full thing (if there are too many changes)). Downside: the first approach would allow dynamic throttling, this wouldn't (not as easily anyway).

Better ideas?

(I've been thinking of writing a basic RPC framework, but at least a simpler way for components to send data to their client/server part. I can look into that this evening.)

[iamgreaser]

Second approach looks good, simple, pleasant, and potentially reusable for VRAM-based GPUs.

You can still throttle by frameskipping and/or interleaving.

While I designed the buffer system to be fast to write to even when scrolling, it seems that this also has the side effect that when you scroll, you don't get a massive diff, as each unchanged line remains in the same place it was in memory before you scrolled it.

[fnuecke]

Allright, synching of the state is in, as is the rendering API (screen calls a render callback on a device that can draw, in this case the serial console). Currently it just uses the first thing it can find; will be configurable later.

There's still a bug somewhere, in that it doesn't show it's previous state anymore after quitting and reloading the world. Not sure if it's the synching or the serialization. Will test more tomorrow or so. Sleep now.

But yay, progress.

Edit: so much for sleep .-. Fixed it.