2DArraybeen working on some wacky shit lately
here's that recent "goblet" tweetjam, but this time running inside a unity game
interacting with pico8 carts to cause stuff to happen in 3D-space
more crane-themed shenanigans
no pictures to show here, but today i improved my burst-compile-times because they were getting way out of hand - used to be about 3 minutes, now it's about 10 seconds
it's compiling about 70 jobs, and when it was slow, the time was spent almost entirely on one relatively small job (!!!)
the culprit: making two temp native-hashsets (fine), and passing them as parameters to a bunch of function calls (NOT fine). hand-wavey guess: this seemed to cause an N^2 compile-time cost somewhere
gonna need a stronger character-controller eventually (to deal with moving platforms in a less jittery way), but here's a little car operated by a #pico8 control panel
added some lines to show the positions of the stacks of boxes, which makes it (much) easier to aim your swings
by the way, here's where this project started, if you wanna see some earlier progress (starting with "get pico8 emulation at least partially-working inside unity")
upgraded the player-controller to make it handle moving platforms more smoothly/cleanly
also fun fact, the motion and IK for this crane is solved inside the #pico8 program, and the C# side just copies out the elbow and cabin positions into 3D space
finally bit the bullet and implemented the lua feature which had the worst "how much do i want it vs how much do i dread it" ratio: comma-separated values (outside of function-args and table-definitions)
first pic is a #pico8 cart which involves a multi-local-declare, a multi-assign, and a function with multi-return-values. second pic is the generated C#
C# tuples help out a ton with this problem!
new grammar for "one or more identifiers"
describes how the pattern-set called {identifiers} can match stuff like...
x
x.child
x[2]
x[4].child.veryChild
x, y, z
x, y[2+i], z.child[2]
it's going reasonably well so far. missing some "delete line/option" stuff but beyond that it's about ready to start getting into the runtime side of things
delete line, delete player-choice, undo
getting into the runtime part - you guessed it, it involves another #pico8 cartridge, this time on a little phone device
(common disclaimer: windows-screen-recorder adds a little vertical offset to the mouse-cursor position. it looks accurate in-game!)
doing some extremely normal burst stuff. see uh this is legal inside a job, but just "oy" as a plain string-literal would be illegal
added a glitchy effect for unauthorized communications
improving my dialogue-editor UX by adding more keyboard controls - doubletapping enter creates a new line (first tap is "confirm my edit"), and tab or shift-tab cycles to the next or previous line
doing some #pico8 emulator improvements by seeing how much it takes to get this old game to run correctly
spoiler: it's gonna need a bunch of new features. gonna ignore audio for now...there's plenty of other stuff to figure out
it's going well...got the script to parse (~2k lines!), and have been whittling away at the resulting compiler errors. some lua-side highlights:
- for-pairs, for-all, while, break
- revise names if C# considers them illegal (like a var called "byte" or "readonly")
- exponent operator
- better handling of local-var scope and local-var-shadowing
last remaining compiler fixes: "value or default" notation and overwriting deep-elements in tables
then...on to the missing P8-API functionality!
okay good news and bad news
the good news: tiny-platformer compiles successfully!
the bad news: the burst compiler takes 4 minutes to optimize it
next time i work on it, i'm gonna try doing some pre-optimizations of my own to (hopefully) cut that down - most notably, identifying all the types that a variable will contain (number, string, table, bool, nil), so most of them can be a concrete type, instead of every value always being a union every time
took a stab at that type-detection optimization, and it almost worked but i got myself tangled up so i reverted it (may try again later). weirdly the compile time doesn't seem as bad anymore, dunno what happened
so instead, i've been getting map() to work
getting somewhere...
btnp() just acts like btn() so far, needs camera() support, still no #pico8 color-palette, and i'm not sure why the fire doesn't render - but yeah, look at this little runny-jumper go!
moving camera, animated fire-blocks, and some other less-interesting improvements
a few notable things still left to bring this cart to parity:
- fillp() to draw the background circles correctly
- emoji-glyphs for certain tutorial text
- screen palette
- audio ☠️ (still planning to skip this for now)
fillp support (visible on the circles in the background)
added emoji-glyph support (visible in the cart on the right)
but that's kinda boring, so here's the giant spider machine at the end of the game
connected the official #pico8 palette and did some doodling on an LCD-screen shader
(...masto video compression isn't as bad as twitter, but in this case it janks up the image a bit at medium viewing distance)
detecting when values (global vars, local vars, function return values) are known to be one specific type, so they can be declared as that concrete type (like P8Number, P8Table, bool) instead of the usual "every possible type" union (P8Value). doesn't really speed up the runtime performance, but for the platformer game, it cuts almost half of the burst-optimization time, which is nice since that bastard takes forever
adding a soft-mouse-cursor for gamepad users, since some panels have "click and drag" style inputs, and those are pretty awkward with an FPS-camera on a controller
adding some tutorial popups, so i ported my input-sprite handling from Completion Lawncare - in that one, i was using Rewired, but now i'm using unity's new InputSystem. i don't have user-rebindable controls at this point, but so far it seems noticeably simpler to detect the bindings for an action which match a certain input-device-type!
in the clip, it switches between gamepad and keyboard controls based on which device was used most recently
saw a neat GoMechaBall tooling clip today and it made me wanna try some "hotspot" meshing
hotspot paneling!
porting my existing levels to use the hotspot-voxelizer (it works!!)
i added some auto-lights recently which i haven't ported over to this system yet, so they're all very dark for the moment
added some sound effects today
ended up writing a "top-down convex-hull of a cube" generator today for this puzzle inspired by the crane game
("which crane game?" THE crane game)
may have gone a little overboard with the cables here
goofed it up a bit by screenshotting the scene-view instead of the game-view. now with post-processing
pretty neat that the voxelizer-greybox-tool makes it super easy to make stairwells. this is three boxes (one long diagonal box for each flight of stairs, plus one axis-aligned cube-ish box for the transition area between the two flights, where the camera is located)
upgrading my instanced-renderer to some instanced-indirect stuff: split each mesh into 64-tri clusters, and then it can draw multiple authored-meshes in the same drawcall (since it's all cluster-soup) and do culling in a compute shader
currently it's only drawing one cluster per mesh, so there are a buncha holes all around - but that's a problem for tomorrow
Vile Lasagna@2DArray fancy schmancy! Melikey!
.ex//weis
Chris Renfrow@2DArray nonsense
dbat 
@2DArray One does not simply underdo cables! 🤏
ruby0x1 
@2DArray where's the downside
@ruby0x1 the cables all over your walkable space make it seem like they should react to the player somehow! maybe worth it eventually, but it's not as easy as something like "spiderwebs get destroyed when you walk through them"
(for now I just added a rule that they can't hang too close to the ground)
Oblomov
jminor
Paul Nicholas 
@[email protected] Noiice! 🤓👌