Been playing around a bit with samply to fix some performance issues in Minart (especially polygon rasterization and convolutions).

Ended up making a bunch of things quite faster, so now my old 3D Stanford Bunny demo went from ~12 FPS to 20 FPS on my machine.

But, since I was able to also make convolutions faster, I can add two hackish depth of field passes while keeping the old performance numbers.

#scala #screenshotsaturday

About 4 years ago (24th of June 2021, according to my old tweet: https://x.com/JD557/status/1408166583575449601) I got a KaiOS phone (Nokia 8000 4g) for emergency use.

It has proven to be pretty useful over the years.

Mostly as a WiFI hotspot when abroad (that way I don't have to buy a data plan for me and another for my girlfriend, and we save our smartphone battery a bit), but it's also pretty nice to have a phone with a long battery life that lets me do some normal modern day stuff (such as check ActivityPub).

Yesterday it also proved pretty useful. Due to the Iberian blackout, I was without power and comms during most of the day, so having a radio around was great to listen to the news without having to be in my car.

I wouldn't recommend anyone to buy this particular mode though, as the keyboard is garbage.

Recently, Lorenzo Gabriel released https://github.com/lolgab/scala-native-jdbc, a JDBC implementation for Scala Native, which allows libraries that rely on JDBC (such as Scala-SQL) to be used in a native environment.

I've been slowly playing around with adding DuckDB JDBC compliant connector to it, and it's looking pretty nice. I did have to use some trickery to avoid hitting issues with SQLite/DuckDB dialect mismatches, though.

I plan to open source this eventually, but first I want to make some more tests and clean the code (there's quite a few manual memory management involved).

I also need to figure out how this should be distributed... On MacOS DuckDB is distributed via a dylib with an rpath, which is a bit annoying to use on Scala Native... TBD

Last Christmas my brother and I purchased a 3D Printer (Bambu Lab A1 mini).

Even though I haven't been an heavy user, it has already proven quite useful, especial for custom supports and organizers that one would have an hard time finding in a store.

It feels quite magic to be able to code something in OpenSCAD and have it appear in the real world.

Today I built a couple of supports for some Krakebs that I had lying around. I think they turned out pretty cool, so I uploaded the model to MakerWorld.

Not that I think that anyone will print that, but I should build the habit of sharing some models.

For some reason, Youtube has been recommending me a ton of wave function collapse videos, so I decided to play a bit with it for map generation.

I think my code still has some bugs, but I'm happy enough for now. Maybe I'll pick it up in the future if I decide to use it for an actual game or demo.

#screenshotsaturday

I've been working on a collection of small minigames (inspired by 1x111) with simplistic graphics (inspired by He is Coming)

It still needs a bit more polish, and I want to add some more games before releasing it, but it's cool how easy it is to write simple games with some very basic primitives such as AABB collision. The code for some of the games is surprisingly short.

#scala #screenshotsaturday

Published a port of https://github.com/nayuki/QR-Code-generator to Scala, cross-compiled to JVM/JS/Native.

It's now easier than ever to generate QR codes in Scala.

Check it out at https://index.scala-lang.org/jd557/qrgen

I've been working a bit with Clojure, and found their concept of truthy/falsy values quite refreshing for a dynamic language: Only false and nil are considered falsy values, everything else is truthy.

None of that confusion of "Is 0 true or false? What about the string "0"? What about empty strings and empty lists?".

Maybe this will bite me in the future, but so far it looks like a good decision.

On that note, I've also learned that Java's Boolean actually provide (now deprecated) constructors that break reference equality (and in turn break Clojure's checks).

Namely new java.lang.Boolean("true") eq new java.lang.Boolean("true") is false while the recommended alternative java.lang.Boolean.valueOf("true") eq java.lang.Boolean.valueOf("true") is true.

I guess it makes some sense, but I always thought that there was no public Boolean constructor.