Todo: refactor rendering to avoid using direct GL calls, instead I've
read that you could use a `BufferBuilder` but need to do more looking
into that.
Also need to update some block entity things, since some calls are also
gone.
Without the blocker layer even VBOs didn't work with shaders. So instead
I put the blocker back and made it mask both color and depth buffers,
which fixes the bug with chests and water drawing over monitors. Since
it now masks color I hoisted it up to be drawn before the terminal, and
made the terminal slightly offset to solve z-fighting with VBO renderer.
Somewhere along the line the gl state was being mangled and I'm still
not sure where! I moved the monitor blocks from the cutout render layer
to the default solid layer, which obviates the depth blocker. I don't
think the transparent front of the monitor blocks was ever visible so
this should be fine. Then the terminal quads are moved slightly outward
to prevent z-fighting with the now present block front.
Finally I noticed some chests were not rendering correctly around
monitors, so I paired an endDrawing() call with our sneaky hack of
calling startDrawing() to force the rendering state. This fixed the
chests. Hopefully we haven't messed up the render state in more ways :)
Replaces the jankson implementation with night-config. Night config is
what the forge api uses so it's easy to produce .toml files in the same
structure as CC:Tweaked.
All config options and comments from CC:Tweaked are implemented. Some
of these options are ignored in various bits of implementation but that
is another problem :)
Also splits the config into a client and server file. The server file is
saved per-world. Names and locations are consistent with CC:T.
Made a top-level fabric package so mixins and their ancillary classes
can be grouped together. Also removed a stub duck interface that got
left behind somewhere along the line (MixedFirstPersonRenderer).
OptiFine seems to cause NullPointerException when it cannot find loader.spriteAtlas::getSprite method in ModelItemPropertyOverrideList constructor.
Fixes#1
This only renders the bounding box on non-screen edges of the monitor,
meaning you have an uninterrupted view of the screen when hovering
hover.
Closes#219
Rendering an item worked in principle, but had several caveats:
- The terminal did not fit well within the item's texture, so we had a
rather large border.
- The "correctness" of this was very tied to Minecraft's item rendering
code. This changed a little in 1.13, causing problems like #208.
Instead we effectively reuse the computer GUI rendering code, though
also handling coloured pocket computers and rendering the modem light.
This fixes#208, and hopefully fixes#212.
Look, I originally had this split into several commits, but lots of
other cleanups got mixed in. I then backported some of the cleanups to
1.12, did other tidy ups there, and eventually the web of merges was
unreadable.
Yes, this is a horrible mess, but it's still nicer than it was. Anyway,
changes:
- Flatten everything. For instance, there are now three instances of
BlockComputer, two BlockTurtle, ItemPocketComputer. There's also no
more BlockPeripheral (thank heavens) - there's separate block classes
for each peripheral type.
- Remove pretty much all legacy code. As we're breaking world
compatibility anyway, we can remove all the code to load worlds from
1.4 days.
- The command system is largely rewriten to take advantage of 1.13's
new system. It's very fancy!
- WidgetTerminal now uses Minecraft's "GUI listener" system.
- BREAKING CHANGE: All the codes in keys.lua are different, due to the
move to LWJGL 3. Hopefully this won't have too much of an impact.
I don't want to map to the old key codes on the Java side, as there
always ends up being small but slight inconsistencies. IMO it's
better to make a clean break - people should be using keys rather
than hard coding the constants anyway.
- commands.list now allows fetching sub-commands. The ROM has already
been updated to allow fancy usage such as commands.time.set("noon").
- Turtles, modems and cables can be waterlogged.
