Today has totally, completely, sucked. It turns out it's expensive and hard to ship big things. I wasted the whole day, spent a ton of money, generated a huge logistical headache for next month, and ensured that I'll be scrambling on Monday to get everything done. Stressing out 🤬

Although I do find myself using sync.Semaphore a lot, which uses channels under the hood github.com/golang/sync/blob/ma (Third try at posting this without typos, maybe three times is the charm! )

Realized that lately I almost never use channels when writing Go code, opting instead for sync.Mutex etc. That's a big shift from back when I first started writing Go and used channels a ton. Wonder if it's just me or if the wider community has seen a similar shift.

byte.co/ looks good - had me laughing within minutes of install. It could be a hit, fortunately for national security.

Even in the case of that physics API, there's a SetPhysicsProperty(id, property, value), entity-attribute-value style, which means it could be made even more explicit and rigid.

Rigidity, unwieldiness, and safety vs. simplicity, flexibility, and fragility. Classic type tensions.

This first example is a work in progress of the physics API, which explicitly & exhaustively lists all arguments in all calls. The second example is an event system where you just get byte arrays associated to ids, and it's up to the caller to decide what that byte array means.

I've been designing a WASM-based mod API for Soundboxing the past few months, and it has been a constant back-&-forth decision process between explicitly listing arguments using WASM types, resulting in a large API surface area vs. passing byte arrays with an enc/decode step.

My favorite show on TV is the Bon Appetit YouTube channel, and it's not even close.

Lenovo! Standalone VR! They know how to make headsets - they make the Oculus Rift S. Hoping beyond hope that this is more open than Quest. If they let me ship software to it, I will! This could be the headset to watch.
news.google.com/articles/CAIiE

Felt like I was holding a lot of TODOs in my head & stressing me out, so I decided to write them down, one line per thing to do. Two pages later, this exercise was worthwhile! So that's work items done, check, now for the TODOs about the apartment...😭

And every time you try to drill down into those checkboxes and import only what you need, some random thing depends on some asset you didn't import, because why wouldn't you import the entire asset tree each time? And then you're back to cursing while reimporting.

Really wish vendors that provide Unity SDKs would split out their sample scenes and assets from their core libraries. Every time I switch Unity platforms, as I sit there watching it re-import your sample files for the Nth time, I think of how I might remove your library entirely.

Anyway, hope this was interesting and not just noise. It's not any groundbreaking new concept, but my own path of discovery that I hope you find useful too ✌️

In all, I would recommend this and do it again as a way of rapidly developing a shared library for Unity. And next time the conversion into from web-DLL to real-DLL would be faster, now that I understand how to connect Go and Unity. I'm really happy with how it turned out!

Turns out, the conversion took one focused day of work, including the nerve-wracking false start and debugging session that ensued. Basically, I had to learn how to pass true C byte arrays, rather than try to use higher level language helpers with wrong assumptions for this.

At this point I started getting worried. I'd built all this under the assumption that since it was possible to compile as a shared lib, it'd be easy enough to do so. After a naive attempt at converting to a library, Unity was crashing whenever an arg was passed to a func. Uh oh?

But given the way mobile platforms work, it's essentially a requirement to be able to compile it as a true library. Even on desktop, the websocket stack was an unfortunate source of memory pressure for the GC, so loading the lib in-process and avoiding the network is much better.

One cool thing that I even tried was running this "web-DLL" on another computer on the same network as the Unity client. It worked surprisingly well, even called per frame. Imagine instead of rendering on PC & streaming video frames to mobile VR, offloading compute in this way?

Last, it meant that in order to maintain performance, the library had to be designed to minimize data transfer over the network barrier. Good practice normally, made essential by design.
This all ran fast, like, it could ship! Spin up a subproc, listen on localhost, you're good.

Show more
Mastodon

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!