moth-fuzz

As someone who’s worked with many different OpenGL versions the big things I noticed were ‘missing’ from WebGL 1.0 are the following (some were available as extensions, but they are now standard):

- uniform buffer objects. OpenGL is limited to how many uniforms you can pass to each shader via glUniform* calls, making things that use a lot of uniforms (such as skeletal animation or instancing) effectively a no-go. Uniform buffers enable uniforms to use much much more memory.

- vertex array objects. Previously, you had to rebuild and respecify vertex attributes, in addition to actually pointing them to the right data, dynamically every frame. Vertex array objects capture all that state into one structure, which is usually built at the start of the program, so that it’s nothing more than a single pointer swap per-frame to render different kinds of models. It can be faster or slower depending on the hardware and driver but it’s faster for developers, at least.

- depth textures. Previously the depth buffer was pretty much write-only, making things like shadow mapping impossible without hacks like writing the z-coordinate to an extra color buffer off-screen.

- instancing. Now you can render many copies (‘instances’) of a model in just one draw call by passing a ‘count’ parameter, rather than making N draw calls. This is almost universally faster, where applicable.

I remember way back when memes used to come in a variety of affects, expressing different things. Memes for humor, memes for grief, memes for libido, memes for political commentary, and yes, there's also of course memes for nothing other than establishing in-group/out-group.

But I can't help but notice every new 'meme' these days is a variation on "this thing is good" "this other thing is bad". It's the same format with the same intended message but with different images swapped in and out.

I think it might reflect the immense polarization of society combined with social media's general push for 'engagement' i.e. antagonization of each other. But I don't get why every new 'meme' these days has to draw some line in the sand.

I'm not sure I like this change. I liked interface{} since it just works out naturally from Go's relatively simple type system, and anyone could come to the conclusion without actually being told "use interface{} to represent any possible value" just by having an understanding of that type system. Adding what is simply a type alias, multiple words for the same underlying concept, to me just feels like jargon. I admire Go for its simplicity and clarity and this change gives me anxiety that that will be obfuscated.

My DX7 is still one of my favorite synths, sonically speaking. I had no idea how intuitive yet novel the circuitry was until I began reading this article.

In particular, I found it suprising that the sine waves were generated by indexing a wave table - you'd think a sine wave would be easy enough to generate without a table, but the way it implements phase distortion ('FM') on those sine waves by simply offsetting the index into that table is quite interesting. Sorta like having different mathematical functions for 'i' in a for loop.

Dracula is a fine theme, however, I feel like it's more convenient than it is pretty. I admire Dracula, Nord, and Gruvbox and how committed they are to their own aesthetics - my personal favorite, similar to Gruvbox, is Alduin[0] but sadly it's for Vim only.

I only wish popular themes didn't feel like they had to use every primary color for the text. I wish we took the popular themes and made them even more opinionated, fewer colors with greater emphasis. At the end of the day most themes nowadays are just different shades of all rainbow text over your choice of a light or dark background. Dark or light... It reminds me of that theory about how early humans, before having words for different colors, only had light and dark to describe things.

Does anyone have any recommendations for opinionated color schemes with limited palettes with emphasis on particular colors instead of just dark/light?

0. https://github.com/AlessandroYorba/Alduin

> Be as it may, I've seen the 'fake 3D' claim before and I'm starting to wonder if I'm missing something in my understanding of this technology, maybe someone can offer a third opinion?

I agree that all 3D is 'faked' in the sense that it's drawn to a 2D grid of lights eventually, I guess it just depends on where in the pipeline you make that fundamental transformation. I only meant faked in that the GPU itself is 2D, whereas the GTE is just math. So it's kinda like doing CSS transformations to make a web page all 3D-looking (a gross understatement I know, but, nevertheless). Though, semantically, I guess the '3D' part of a modern GPU is also 'just math'. Well now you've got me thinking about it harder...

Wonderful article by the way! I've read yours a few times myself.

This is an excellent article, a good insight into the particularities of the hardware. I particularly admire the explanation of why the polygons snap to the pixel, and why that's not the fault of floating-point mathematics but rather the rasterizer itself. One thing the article approaches, but doesn't really quite get to the bottom however, and which is the crux of all the ps1's 'flaws' is that its GPU was 2-dimensional fundamentally. That's why things snap to pixels, that's why the textures do not have a depth component and are thus not perspective-correct, that's why there is no z-buffer, because it had no z-coordinate. Essentially, every single PS1 game 'faked' 3D by using the GTE (which was separate from the GPU) to project 3D points and polygons into a 2D rasterizer. And it worked quite well! For the time.

Another thought - I also wrote a similar renderer under similar constraints a while back, just for funsies, and I'm wondering what would have came if I thought "I should write an article about this". I generally don't think to write articles over every side project I do, what's the impulse for when someone decides to detail their work to the internet?

You can still install windows 11 straight from an image and it’ll ignore the processor and TPM requirements - they’re considered ‘soft’ requirements even if Microsoft doesn’t say so outright. I currently have it running on my desktop with an i7-6700k and my laptop as well with an even older i7 and TPM 1.2.

You’re absolutely correct in that they ‘drew a line’. They have a specific set of guidelines[0,1] they want CPUs to meet going forward, and it’s more of a matter of ceremony and certification rather than anything concrete nor technical.

0. https://docs.microsoft.com/en-us/windows-hardware/design/com...

1. https://docs.microsoft.com/en-us/windows-hardware/drivers/de...

It definitely wasn’t meant as a criticism - I think Rust is uniquely suited to writing web applications as well. I just find it funny that writing web apps is easy enough in Rust that it almost minimizes its opinionatedness, since you don’t really need to worry about difficult lifetimes or ownership when it’s JSON in, JSON out, and the database is just an externality, and you don’t have hard performance requirements despite Rust being made for performance. It seems like an impedance mismatch but it works out.

C++ is a fully compiled language, and will not compile code that has type errors (barring you hack your way out of the spirit of the type system). Templates are no exception - they are type-safe once instantiated because they transform at that point into normal C++, which is type safe. Templates themselves are not types and are not meant to be, they’re meant to be templates, yes, more akin to macros, but not at any cost or defecit because of it. Frankly I don’t understand the criticism; I don’t care if I get a compiler error during template evaluation or during compilation or during linkage, a compiler error is a compiler error. Code that works works and code that doesn’t doesn’t.

I mean, if you could tell from my original post, I like C++ templates. The point is not to constantly write templates in your calling code, the point is to architect a library with templates that affords flexibility and dynamism so that the calling code is easy to write, read, and reason about. Consider, for example, the sol2[0] example usage code vs the actual source code itself[1].

0. https://github.com/ThePhD/sol2 1. https://github.com/ThePhD/sol2/blob/develop/include/sol/func...

I loooove Zig - my only gripe with Zig is that it feels somewhat arcane at times, and the documentation was borderline absent last I checked. I follow Andrew Kelley on twitter and am fascinated by his exploits. Crystal has a similar macro system that I enjoy, from what I've used of it. Rust macros are similarly satisfying in what you can accomplish with them, but the implementation is so immeasurably difficult, it's almost never worth it to bother, from a general design standpoint.

As far as C replacements go, Zig has my vote for the most approachable but also the most well thought-out. I couldn't sing its praises enough.

Trait objects are still no replacement for the areas in which subtype polymorphism excel, and Rusts' generics are a pittance compared to the completeness and expressiveness C++ templates. I know that sounds like flamebait, and yes I've read STL source code in all its underscored and abbreviated glory, and yes I've read that one snippet of the std::ranges proposal that people like to throw around. But the thing that always gets me is that most Rust proponents I've talked to simply define out of the equation Rust's problem areas - an oft-repeated mantra is that Rust 'pushes you to a good design' as if what is inherently a good design are what Rust is capable of and the areas it is less so are simply inherently poor designs anyway.

Sure you can do everything you'd want to do in C++ in Rust, but the developer experience when actually writing code is agonizing most of the time. I deeply miss C++ templates in most other languages, excepting fully dynamic languages, and D. Rust is, to me, more of a replacement for places I'd write C, and be in a C mindset. C++ (well-written, modern C++) is so much more than C, and so much more than people give it credit for. A true C++ contender would have to pass not just the C bar but the C++ bar as well, rather than looking at C++'s strengths over C and saying "actually those are bad things" like it's been popular to do for the last 10 years.

Speaking of replacing C, Rust is not without its strengths: the one place I find Rust truly a joy to write is OS dev, and similar low-level projects, in which the concepts and limitations of the language map to quite nicely to the expectations of the system. It seems like the obvious candidate for these types of applications (including embedded development) but there's little surrounding literature - it always baffles me that most people seem to be using Rust to write ... web services?

This is an interesting happenstance in the Rust community that I think is largely cultural rather than technical. Backlash against some figurative idea of OOP is popular. ECS is popular as the messianic retort to that OOP figure. But when you look at it from an architectural standpoint, ECS is quite possibly one of the hardest things to do in Rust compared to other designs. Let me get this straight - you want to avoid shared mutability but you have all your gamestate in centralized stores? That systems will necessarily have to have shared, mutable access to? Possibly concurrently? I think it's a good idea architecturally, but also I think it's a tough problem to solve, and I think the claims that Rust lends itself to that architecture are false. It's even tougher in Rust than in other languages, I'd say. And though I've read the source code to many Rust ECS libraries, they all do it in different ways, and all of them feel like hacks.

I definitely feel like the most "rustic" way to do game design, just based on what's easy to do in the language itself without resorting to workarounds, is to have individual actors maintain their individual state, and then have a common interface via a trait that would call update() or render() virtually in a loop or whatever. Then have them message each other via mpsc channels. That's pretty much rust straight from the book, and, it's also a bog standard GameObject architecture straight outta the 2000s.

I agree. I feel like generics make more sense in a language like Rust or D or C++ (templates) where you need the performance of compile-time constructs, and generics specifically have that semantic. In Go, it doesn't make as much sense to not simply use an interface for the same purpose since the language is less bare-metal (or, rather, implementation-specific) by design.

The key phrase is identity politics - I hope internet discourse begins to move away from this framework, but as of now politics is entirely focused on the nouns - who, what, when. The immutable states of ones’ person. The answer is to move to a verb-based politics: what does this person do? What have they done? What do they say? What do they think? Are the dialectics good? Is the methodology sound? Does it make sense? Does it help? Does it hurt?

People will say “listen to black people” while simultaneously dehumanizing all black people into a monolithic and tokenized opinion-vessel. I personally know black people, gay people, trans people, disabled people, who are exhausted of being that vessel. Of being a walking textbook for other people to memorize. The truth is that black people, and all people of color, are diverse culturally, emotionally, and intellectually and in order to be a good ally you have to not only listen to All of them, as well as your own heart, and you must use your critical thinking skills to determine what you personally think is correct - and act on it. You must be active and competent, and you must not regurgitate. At the end of the day there will be black people who agree with you and black people who disagree with you, but you can hope your efforts at activism will help both groups regardless.

I feel like vaporwave was dead as soon as people started taking it seriously. Seeing the genre at its inception - a critique on how corporations will use substanceless nostalgia to bolster sales - turned into that very thing with this faux-80s-revival music, that for one reason or another sounds nothing like what was actually popular in the 80s, has left quite the sour taste in my mouth.

Like, the very idea was to take old “nostalgic” stuff and mangle and distort into something only vaguely resembling that. The idea was to provoke those feelings in you while also detaching from what might actually make one nostalgic. After all, most of the audience can’t remember the 80s or 90s having been a child or not born yet. The idea is to poke fun at how corporations manufacture nostalgia by doing exactly that, except in a ridiculous and obvious way so that people would be in on the joke and so that it would be a transformative work of sorts. But people fell for the trick anyway and now we have kids who weren’t alive in the 80s yearning for the 80s listening to music that doesn’t resemble 80s music. It’s weird.

In short: I agree with the author. There are burgeoning genres and music cultures that may resemble vaporwave if you don’t know what it’s origin and intentions were, but the actual message behind vaporwave is lost to history in lieu of its aesthetic. The irony was, in fact, lost.

Pointers are not slow because they are pointers. Pointers are slow because (usually) they point to random locations in memory, incurring cache misses. Pointers that point to contiguous memory can be just as fast as that same memory being accessed via an array directly, as long as the data stays contiguous.

I feel like I'm in the minority in not finding C++ complicated. C++ has gotten significantly LESS complicated c++11 and onward, I'd say. Inheritance hierarchies with private/protected/friends and virtual methods lead to significantly more complex codebases than flat templates and judicious use of constructors and destructors to handle things' lifetimes. When you've got a nice templated API, writing the client code almost feels like writing in a scripting language.

I'd say the only really hard part is understanding move semantics, but even then that's not really necessary and the verbiage on the internet is way too academic in that regard when it's really simpler in practice than it is when explained.

I got one of these a few years ago for 30$ because they were 'hip' in the lo-fi music community. Unfortunately it stopped working and sits in my closet now. I was going to get another one, but now they're even more hip and even more expensive. This piece is a perfect little insight into how memetic the used gear market is, IMO.

Dwarf Fortress is one of my favorite games if not my favorite so props for citing its internal representation. I definitely think ECS makes sense in many contexts, and I think it's at its most powerful in tandem with a more encapsulated actor system. Example -

  struct Player: public Actor {
    Component<Sprite> sprite;
    Component<Transform> transform;
    void update() override {...}
  };

Where Component<T> is a handle to some backing storage indexed by an Actor's ID. This way, you can go the traditional route of having Player update itself in its own update() method as well as being able to Component<Sprite>::iter() along with other components for the render loop ECS-style.

My point now and my point then was going all-in on ECS as the basis for your entire architecture rather than taking a more principled approach drawing the strengths of OOP and DOD is dogmatic and difficult.

It's interesting that you mention web services - I have a lot of respect for databases and I enjoy the process of using them, however, I wouldn't ever program a web app in SQL. That's what pure ECS feels like to me. I agree that having objects manipulate the state via upholding internal invariants is the way to go. Whether you call them Actors, or Systems, or Controllers, it's kinda one and the same. That's why I love DOD as a base architectural layer to be abstracted upon, but dislike ECS as a programming paradigm.

Back when I was trying to design an ECS engine I had a class Prefab<T...> which you would inherit from using CRTP to define entities with stronger static typing. For example, Player would be

  class Player: public Prefab<PlayerController, Transform, Sprite> {};

or something like that. C++ is infinitely flexible in that regard. I was never quite able to work out what would happen if you were to add/remove components at runtime to such Prefab classes. The semantics never quite made sense to me in terms of static typing, because it's no longer static.

Honestly I find ECS dogmatic and difficult. Data oriented design as a general practice is a good thing, but there’s layers to all things. OOP is a very broad category of practices and designs, and ECS usually refers to one specific architecture.

The specific architecture in question tends to be full of soft dependencies - most ECSes don’t allow you to simply store a piece of data without opting in to all systems matching the data type executing arbitrary code on it. So much for separation of data and behaviour. No, now they’re even More dependent than they are in the usual OOP sense and you might not even know it.

Furthermore, usually when you want to think about in-game entities, you want to look at a single class. Now all entities’ data is split into numerous components and all entities’ behaviour is split into numerous systems and you don’t know frame by frame how they’re gonna interact, provided you even know about all systems in the first place. It’s total spaghetti code.

I’m much more inclined lately towards a shallow actor system . If I want to know how player’s behaviour functions, I need only look at player.cpp and nothing else. Then, to reap the benefits of data oriented design, certain objects can use a certain allocation scheme that makes sense for the object in question. In the general sense, any Component<T> can just have a vector<T> or an unordered_map<T> of all components and the memory access is abstracted away without it being detrimental. That’s C++’s whole deal actually, zero cost abstractions.

I wouldn’t call an entire paradigm shift in which one rewrites everything from memory allocation all the way up to ‘use WASD to move’ zero-cost in any sense.

In C++ it is trivial to overload new, or derive from some class which does, or to write a custom allocator, and frankly there is zero need for the same person who’s writing ‘use WASD to move’ to know about memory management.

This has been precisely my experience. Windows 7 was fast on an HDD and blazing fast on a SSD. Windows 10 is unusable on an HDD and usable on an SSD. Still kinda sluggish, even then, for what it's worth.

Not to mention the applications. A slow operating system that uses so much resources merely idling plus Applications-That-Are-Actually-Web-Browsers make day to day usage almost innavigable for someone with quick reflexes used to a Linux CLI.

It's very interesting that you make the distinction between a 'developer' and a 'user-programmer'. I've never thought of it that way before, but I've come to the realization that all the programs I write are not written specifically for my computer, my computer is simply one of many compile targets and platforms which they can run on. It would be incredible if I could actually program the normal operations of my computer from user space, instead of writing programs for an abstract x86_64 device which, at runtime, happens to be my computer.

Either I'm doing something wrong or there isn't really any syntax highlighting for C++, other than numbers and strings.

Also, there's no syntax option for plain C, but that's an understandable oversight since a good 99% of C's syntax is shared with C++ anyway.

Lastly, when writing C/C++ it auto-detects Objective-C. Just a few things I detected as a primarily C & C++ developer.

Other languages seem to come out great, and it's really a very nifty tool in the end.

Update: C# and Java seem to have a similar lack of coloring.

Personally I’d like it to be thick (and possibly heavy) enough that I can open the lid without having to hold down the bottom. I yearn to be able to set a laptop down on my desk and not have it slide around or move when I’m adjusting the screen.

It seems everybody who tries out a Linux distro has individual problems with various UI stacks, rather than Linux itself. The bigger the software (i.e. GNOME, KDE) the harder it fails. And often in unexpected and unpredictable ways, too.

The kind of people who use GNOME or Ubuntu or whatever the 'windows competitor' is always seem to be having problems, but are also the kind of people who see needing to use a terminal as a problem in itself.

I've never ever had a problem with i3, emacs, firefox, and simple <20 line configs. Terminal is fine, it's what most GNU tools are built around in the first place. It's apt that people who really love Linux and appreciate what it does out of the box, and who don't feel the need to turn it into Windows or MacOS, also seem to have the least issues with it.

I feel like this is an underrated sentiment. A lot of Rust’s design decisions (lack of inheritance, borrow checking, immutability by default) are complete non-issues when you’re reading a JSON string into some business struct or an enum and then serializing it back out to a DB again. Everything can be flat data types and functions can be pure and stateless.

But not if you actually have to keep things around in-memory. Then all the sudden your functions can’t be pure, you have to add additional parameters to each method to account for additional state, and you can’t design flat structs anymore since you have many different object types and they have to go somewhere and you can’t just declare N variables line by line. So you have to grapple with the limited definition of trait objects, or non-extensible enums, or throw everything out and use Any. It gets complicated.

my only problems with meson wrap today are its lack of packages, and the fact that it's source-only. Actually, I tried to use SDL_image and while the page for the package exists on wrapdb[0], it has no versions listed and so building with SDL_image fails. Source builds on windows for SDL2 fail because it presumes a UNIX-style build and fails looking for 'unistd.h'.

I've found the real 'one true solution' for my needs to be conan + meson. Conan includes a build script that supplies pkg-config files to Meson for dependency handling, and with conan you can use the gigantic repository of packages along with bincrafters for an even gigantic-er repository of packages. I have not yet found a package I needed that wasn't on either conan center or bincrafters. And on Linux I can download the source to build if I really want to, but on Windows I'm happy just downloading the binary .lib files. And it's so easy to use. cd build && conan install .. && conan build .. is all you need to download and compile everything.

Before this setup I used vcpkg with cmake and I'm never going back to that. Yet before vcpkg I used ExternalContent, which I would also never go back to. Ergonomics are extremely important with this kind of thing. I think that's why cargo is a huge hit in this space.

0. https://wrapdb.mesonbuild.com/sdl2_image