Get rid of KTC1, update Everest

KTC1.md

@@ -1,52 +0,0 @@
-# KTC1 Specification
-
-KittenOS Texture Compression 1 is an image compression format that, while not
- size-optimized or performance-optimized for OC screens, is optimized for
- streaming from disk, and always produces precise results.
-
-KTC1's concepts are "inspired by" ETC1, and it was conceived after evaluating
- ETC1 for use in KittenOS NEO. ETC1, however, is not optimally fit for
- OpenComputers rendering, and thus KTC1 was created to provide an equal-size
- solution that better fit these requirements.
-
-A 256-colour palette is assumed, and it is assumed that the palette is provided
- outside of KTC1's context.
-
-A KTC1 block is one OpenComputers character (2x4 pixels), and is 4 bytes long.
-
-The format amounts to a background palette index, a foreground palette index,
- and a Unicode character index in the Basic Multilingual Plane.
-
-The unicode character is displayed with the given colours at the position of the
- block.
-
-The renderer does not get more complicated when more blocks are involved.
-
-Simply put, blocks that are overlapped by a previous wide character are to be
- totally ignored.
-
-The size of this format is equivalent to 4-bit indexed data and to ETC1.
-
-For standardization's sake, the container format for KTC1 has an 8-byte header:
- "OC" followed by two 16-bit big-endian unsigned integers, for width 
- and height in blocks, the bytes-per-block count for this format (4) as 
- an unsigned byte, and the amount of "comment" bytes that go after the image,
- as another unsigned byte.
-
- Example image, showing a 4x4 white "A" on black, with a standard text 
- black "A" on white underneath:
-
-  4F 43 00 02 00 02 04 00
-  FF 00 28 6E FF 00 28 B5
-  00 FF 00 41 00 FF 00 00
-
-## Additional Notes
-
-A KTC1 file is theoretically a "lossless" screenshot under the limits of the
- OpenComputers system assuming the palette is correct.
-
-The Basic Multilingual Plane access allows mixing images and text inside a
- KTC1 file, and covers all characters that OpenComputers supports.
-
-This makes KTC1 an interesting option for use as a mixed text/image interchange
- format between applications.

README.md

@@ -8,12 +8,19 @@ That's what the "SYSTEM HEROES" thing is about.
 
 ## Known Issues (That Aren't KittenOS NEO's Fault)
 
-Touch calibration is off because OC's setPrecise seems to offset coordinates down and right by a character. OCEmu's does not. I consider this an OC bug. This is known to occur on at least `OpenComputers-MC1.12.2-1.7.2.67.jar`. If you want to check my routines, see sys-everest, search for the lowest instance of `"touch"`. Or just use OCEmu, which doesn't change anything when precise is set, and thus can't be doing anything different than the setPrecise(false) behavior.
+Touch calibration could be off if the setPrecise support mess didn't work properly.
 
 Wide character support *may* encounter issues due to performance-saving tricks in some old OC versions. The 1.12.2 version being used at LimboCon doesn't have the issue, so it's been dealt with. Point is, not a KittenOS NEO bug if it happens.
 
 ## Known Issues (That Are KittenOS NEO's Fault But Aren't Really Fixable)
 
+Having a window around that uses the palette-setting interface can cause funky graphical issues on
+ a window that does not receive or lose focus when the palette changes.
+The alternative is rerendering all windows on palette change, or attempting to detect this particular case.
+This isn't very fast, so the graphics corruption is considered worth it.
+Critical UI gets protected from this by having a set of 4 reserved colours,
+ but this can't be expanded without hurting Tier 2 systems.
+
 If you move a window over another window, that window has to rerender. The alternative is buffering the window. Since memory is a concern, that is not going to happen. Some windows are more expensive to render than others (`klogo` tries to use less RAM if the system is 192K, at the expense of disk access) - move the most expensive window out of the way, since once a window is top-most, moving it around is usually "free".
 
 If the system runs out of memory, the kernel could crash, or alternatively the system goes into a limbo state. You're more or less doomed. Given that almost everything in Lua causes a memory allocation, I'm not exactly sure how I'd be supposed to fix this properly.

code/apps/sys-everest.lua

@@ -353,15 +353,13 @@ local function handleSpan(target, x, y, text, bg, fg)
 end
 
 local basePalT2 = {
- -- on T2 we provide 'system colours'
- -- by default
+ -- on T2 we provide 'system colours' by default
  0x000000, 0x0080FF, 0x000040, 0xFFFFFF,
- -- stuff above cannot be altered by
- -- user applications to prevent
- -- graphical glitches
- 0xFF0000, 0xC04000, 0x808000, 0x40C000,
- 0x00FF00, 0x00C040, 0x008080, 0x0040C0,
- 0x0000FF, 0x4000C0, 0x800080, 0xC00040
+ -- stuff above cannot be altered by user applications, to prevent graphical glitches.
+ -- Provide some shades of grey to try and prevent accidental chroma.
+ 0x182828, 0x404040, 0x686868, 0x909090,
+ 0xB8B8B8, 0xE0E0E0, 0x800080, 0xFF0000,
+ 0x808000, 0x00FF00, 0x008080, 0x0000FF
 }
 local basePalT3 = {
  -- on T3 we provide the Tier 3 pal.
@@ -382,25 +380,28 @@ local function setSurfacePalette(surf, pal)
  if rb then
   monitorResetBF(m)
  end
+ local ko = -1
+ local unlocked = false
  if not rawequal(pal, nil) then
   neo.ensureType(pal, "table")
+  if depth < 8 then
+   ko = 3 -- start overriding at indexes 4+
+  end
  elseif depth < 8 then
-  pal = basePalT1
- else
   pal = basePalT2
- end
- local ko = -1
- if depth == 4 then
-  ko = 3 -- start overriding at 4+
+  unlocked = true
+ else
+  pal = basePalT3
+  unlocked = true
  end
  for k, v in ipairs(pal) do
   -- prevent graphical glitches for
   -- critical system colours on T3
   local av = v % 0x1000000
-  if av ~= 0xFFFFFF and
+  if unlocked or (av ~= 0xFFFFFF and
      av ~= 0x000000 and
      av ~= 0x0080FF and
-     av ~= 0x000040 then
+     av ~= 0x000040) then
    local ok = pcall(cb.setPaletteColor, k + ko, v)
    if not ok then return k - 1 end
   end
@@ -413,11 +414,11 @@ local function changeFocus(oldSurface, optcache)
  optcache = optcache or {}
  if ns1 ~= oldSurface then
   if oldSurface then
-   setSurfacePalette(oldSurface, basePal)
+   setSurfacePalette(oldSurface, nil)
    oldSurface[6]("focus", false)
   end
   if ns1 then
-   setSurfacePalette(ns1, basePal)
+   setSurfacePalette(ns1, nil)
    ns1[6]("focus", true)
   end
   updateStatus()
@@ -694,6 +695,7 @@ local function performClaim(s3)
  if gpucb then
   local w, h = gpucb.getResolution()
   table.insert(monitors, {gpu, s3, w, h, -1, -1})
+  setSurfacePalette({#monitors}, nil)
   -- This is required to ensure windows are moved off of the null monitor.
   -- Luckily, there's an obvious sign if they aren't - everest will promptly crash.
   reconcileAll()

repository/docs/us-evrst

@@ -38,7 +38,21 @@ Window fields:
   values.
   This is meant only as a hint to
   Everest, and may be ignored.
-  Returns 0.
+  Returns the amount of entries set.
+  NOTE: Up to 4 colours may be used
+   by the implementation as "base"
+   colours, and thus cannot be set as
+   past of a palette to prevent any
+   use of the application-controlled
+   indexes in the major UI.
+  This is because the palette-setting
+   interface leads to graphics issues
+   with multi-tasking, even in those
+   programs not using the interface,
+   so a set of reliable colours is
+   required to keep a multitasking
+   system usable in these edge cases.
+
  close(): Close the window.
 
 Events:
@@ -53,6 +67,16 @@ Events:
  api, id, "focus", hasFocus
  api, id, "line", lineIndex
 
+Palette advice for artists:
+ *Use 16-colour images*, and ensure
+ the viewer software uses the palette
+ functions. Always use a 2x4 grid to
+ check cell colour limits. If your
+ palette contains any reserved
+ colour, make it last in the palette,
+ so that they are not wasted if not
+ used.
+
 -- This is released into
  the public domain.
 -- No warranty is provided,