Notices by Drew DeVault (drewdevault@fosstodon.org), page 3

@PuddleOfKittens I think that LSPs serve a purpose for a programming subculture that I am not a member of and do not understand very well. For that reason I don't judge it too much. But I will say that the complexity floor seems uncomfortably high and that this subculture tends to have a laissez-faire relationship with software complexity that I do think is "bad".

"How many types in total are in your program?"

Rust: tens of thousands
Hare: probably less than one hundred

Generally skeptical of programming languages that require an IDE (or an LSP, which is the same thing) to use effectively

That said I do want to write a language server for Hare at some point because I think that would be useful to certain kinds of programmers

But the LSP specification is, uh, quite a doozy

"A brommobiel (moped car) is a moped on more than two wheels and is classified under the group of non-motorized vehicles. A moped has an engine and is therefore also a motor carriage."

The taxonomy of traffic participants in Dutch law is the brainchild of an orangutan on cocaine

The worst offender is brommobiels, and whoever invented those can get fucked

To any reasonable person this is just a small car, but under the law it's a moped, but unlike mopeds it has to follow the traffic rules for cars, but like mopeds it is a motor *carriage* but not a motor *vehicle*, whereas a car is both.

This is all on the exam.

(I am aware that this taxonomy is not the result of drugged up orangutans, but in fact is the result of people inventing new and increasingly contrived means of transport with the explicit aim of circumventing tax and/or licensing requirements, which are then regulated after the fact by an exasperated road authority)

Happy enough with this performance to move on from optimization for now, but for future reference I have noted a few low-hanging fruits: splitting chunks into smaller pieces (16x16x16 being obvious) for better frustrum culling and faster tesselation updates; reducing the size of vertex attributes and offloading some additional computation to shaders; and possibly moving tesselation off of the main thread

Optimize it and crank that render distance up baby

Bonus points for anyone who recognizes the seed

Back up to a more reasonable framerate with unloading of distant chunks and frustrum culling in place (note C is given as a ratio now)

However, lots of verticies still need to go by making chunk tesselation aware of neighboring chunks (and not unconditionally rendering faces on chunk boundaries).

Improved state of the Nether

World by /u/LegalBottle147

Oh, and at some point I plan on reducing the average tesselation load by caching more tesselated chunks than are actually being rendered, so that the tesselation distance exceeds the render distance under normal conditions

So they fixed blender in Alpine which means I actually have to learn how to use it

That's probably all for today. Not bad for eight days of work :)

Had a lot of Real Work to do today so that's probably all for betamine today. Tomorrow I might do "onequads" (like rails and ladders) and set it up to fetch chunks from regions dynamically (and explore the whole world).

"FIRETEX!", my old friend

Got the "twoquads" done

Blender is broken in Alpine and let me tell you manually trial-and-erroring vertex positions and UV mappings in its absence is not very fun