amjoshuamichael

Unfortunately, no :( I was hoping someone would recognize the book and reply...

I think CSS tools like that appeal to people who learned web development in a kind of ad-hoc way. When I first started, I just wanted to make designs I had in my head. I kind of went from "header, text, and image on the page" to, "how do I center this?", "how do I change this color?", "how do I space these elements out?" It wasn't long before I had developed a toolkit of CSS ideas, but once you do that, you lose out on a lot of the finer details that make CSS work well. I knew how to work around weird issues using position: absolute and transform, but I wasn't familiar with block formatting contexts, or the intricacies of the box model. When all of your CSS knowledge is just band-aids placed on your other shoddy CSS knowledge, you're working on fumes. At that point, you could imagine the appeal of grabbing a prebuilt toolkit of composable styles that takes away your access a lot of the available CSS footguns.

What changed things for me was reading an short online book-style series about learning HTML/CSS from the ground up. It introduced everything from first principles, and had an approach where they explained why things were the way they were. They didn't just give you their "top 10 ways to center a div" and ask you to leave. I read the whole thing in an afternoon and it changed the way I think about web development. For the life of me, I can't remember what the book was called. If anyone's read something similar I'd love a reference, it was a while ago now and I'd still like to reference it. I specifically remember them saying "display: block is like a word document, and display: flex is like how you'd expect things to work," which illuminated a lot for me, not just about the display property, but generally about the way HTML & CSS were designed.

That's a really good way to think about it! (Bonus points for ASCII diagrams.) IIRC, I had some similar visualizations in the article but I cut them. And nice paper, interesting way to solve that problem.

JavaScript! It's not perfect, but it's the easiest language to run in the browser :)

Haha, I don't know why I didn't think to include a raycast scene, especially since that's what I was using the algorithm for!! Glad you liked it.

Original author here. I've been reading this website for years. Imagine my shock when I saw my own article on the front page! I'm glad people are enjoying it.

Quick fact about the way the interactivity is done, all of the code for it is in this blogpost.js file: https://aaaa.sh/creatures/blogpost.js, which is only about 100 lines long. Each block has a list of scripts that it pulls from like so:

<div class="code-example" scripts="grid-sm 2d-vector-gfx-lib draw-grid full-algo-intro feather-canvas-edges"></div>

and then there's a set of script tags with those ids. I figured it was a nice solution!

My argument is that using these non-standard extensions to do important things like memory management in a C library is malpractice—it effectively locks down the library to specific C compilers. I'm sure that's fine if you're writing to clang specifically, but at that point, you can just write C++. libfreetype & stb_* are used and continue to be used because they can be relied on to be portable, and using compiler-specific extensions (without ifdefs) defeats that. If I relied on a clang-specific `defer`, I'm preventing my library from possibly being compiled via a future C compiler, let alone the compilers that exist now. To me, that's the point of writing C instead of C++ for a library (unless you're just a fan of the simplicity, which is more of an ideological, opinion-based reason).

For me, the point of writing something in C is portability. There were C compilers 30 years ago, there are C compilers now, and there will almost certainly be C compilers 30 years from now. If I want to write a good, portable library that's going to be useful for a long time, I'll do it in C. This is, at least, the standard in many gamedev circles (see: libsdl, libfreetype, the stb_* libraries). Under that expectation, I write to a standard, not a compiler.

My understanding is that the only qualifier for something on hackernews is that it has to be "deeply interesting":

https://news.ycombinator.com/newswelcome.html

Deeply interesting tech, or otherwise.

Maybe I'm wrong and this is new to a lot of people! I have a limited perspective based on my programming journey, which winds mostly through gamedev, graphics programming, and DSP, both (typically) low level domains. But I think if the title if the article were more accurate, (e.g. "What are pointers?"), my reaction would be more clear. I'm also kinda taken aback by the "old grey beard" comment. Look at all the kids using Rust, Zig, even C and tell me that this is obscure knowledge.

When I took my first programming class at RIT, visualizing the stack, variables, and pointers was one of the first classes we had. It's one of those beginner diagrams that I feel like everyone is familiar with. But I can understand that there are programming domains with equivalent complexity which don't require that base knowledge. I apologize if I came off as elitist.

Absolutely, like I said, there's no problem with what this person is doing or the way that they're exploring computers, I'm just confused as to why it's being posted here.

Yeah I found this article super weird. Explaining pointers & dereferencing is reasonable, but doing it in the context of Zig specifically, like Zig is the first language to feature dereferencing, is odd. Especially since pointers are such a fundamental part of low-level (really, any) programming. Also not sure why it's posted here?

Edit: Going through this author's website, it seems like a lot of their posts are about rediscovering low-level programming concepts through Zig. Like this article, where they discover you can't compare strings directly, and you have to use memcmp:

https://www.openmymind.net/Switching-On-Strings-In-Zig/

They claim that they blog because they "find that [they] retain things better when I write about them." No problem with that. Just a little odd to see on the hn front page, I suppose.

What do you mean by "motivational?" Are you talking about how the creator is against adding new features to the language? I actually think that's perfectly fine. One of my favorite things about Odin is the simplicity; the entire language and all of its rules can be understood by reading the Odin overview document. I'm actually thrilled to have a creator that doesn't want to bloat the language.

Fair, though when I say "quality decline" I'm mostly talking about extraneous useless features and overly complicated node-based architectures that require GUIs. There are simpler ways to do all of this stuff. This engine, Tramway, is proof of that. Godot sits somewhere in the middle, I've used it a little but I don't know enough about it to say whether it's overly complex or not.

You are correct: I definitely agree that not all gamedevs should be making stuff from scratch, but I also think that Unity is a little too much. There's a good middle ground somewhere slightly above raylib.

My argument is that the promotion of engines that live near this middle ground is blocked by education: people who want to be able to sell long courses to the people who look up "how to make a video game."

I don't think that the developers of Slay The Spire were taught by complexity loving professors, no. But education does more than influence the people at universities. Education informs norms, traditions, and styles that permeate through industries. An example from outside tech: the music notation app Finale found a strangle hold on the education market, and now it's one of the standards for notation, despite being the worst option (source: have you tried Finale?).

I've never played the game, but my understanding is that Slay the Spire largely impresses on a design and artistic front, not a technical one. Its engine requirements were not based on feature set or code quality, but on what developers knew. So they probably picked Unity because it was ubiquitous. Education starts the problem, and then devs who need something common they care hire for continue the problem. I don't blame devs for this, it's the right choice to make and obviously Slay the Spire is great, but I am saying that this is a force that drives down the quality of game engines.

Oh, absolutely. I maintain the engine for my video game and it's ultra-minimal tailored to my needs. That leads to better performance, and a much slimmer build size. (currently sitting at ~900KB for the optimized build of a nontrivial game, assets bundled separately). It's also a better development experience, imo.

My argument was mainly about these more generalized engines, like raylib, 'Tramway', or Source.

It's all done using the HTML canvas API.

I'm starting to believe there is an external force that drives down the quality of game engines over time. In most tech, the things that catch on are the things that are the easiest to develop curriculum for. The shape of a node-based editor like Unity is uniquely suited to explaining over a number of classes. (Source: I had to learn Unity at my University) On the other hand, an engine like raylib can be grokked in an afternoon, so a university-level raylib class wouldn't work. So you have all these amateur game developers and programmers coming out of diploma mills, and all they know is Unity/Unreal, so companies hire Unity/Unreal, so universities teach it, etc. See also: Java being popular. Then of course, all these companies have wildly different needs for their Unity projects, so Unity, being a for-profit company that serves its customers and not a single disgruntled programmer, has to conform their engine. So you end up with 'turbobloat.' (amazing term, btw)

The Half-Life and Morrowind engines are in a unique situation where they're put together by enthusiastic programmers who are paid to develop stuff they think is cool. You end up with minimal engines and great tech, suited to the needs of professional game developers.

This seems like something that sits in between a raylib and a Unity. I haven't used it, but I worry that it's doesn't do enough to appeal to amateur programmers, but it does too much to appeal to the kind of programmer who wants a smaller engine. I could be very wrong though, I hope to be very wrong. Seems like the performance here is very nice and it's very well put together. There's definitely a wave of developers coming out frustrated from Unity right now. As the nostalgia cycle moves to the 2000's, there's a very real demand to play and create games that are no more graphically complex than Half-Life 2.

Anyway, great project. Great web design. Documentation is written in a nice voice.

Personally, I don't care about the library, and just want the pure math implementation for shaders and such. For that, they have the algorithm available here in GLSL, vec3 mixbox_lerp is the function you want:

https://github.com/scrtwpns/mixbox/blob/master/shaders/mixbo...

I don't have time to whip up a demo, but it seems like it's pretty well optimized and it looks really nice in the examples. Great work from these folks.

Odin has a builtin heap allocator that works the same way you would expect any other high-level language to do memory allocation–it's just that you have to free the memory yourself. Plus, Odin's built in `context` system makes it really easy to change what kind of allocator is used for different sections of code. For my use cases, I've never needed any more than a heap and an arena, detailed in this talk:

https://www.youtube.com/watch?v=nZNd5FjSquk

Personally, my large Odin project uses a series of arrays to store specific data, and then everything else is stored in a temporary allocator, which is wiped between frames. Besides some graphics initialization & path resolution at initialization time, the heap allocator is never used. I never really have to worry about memory. That's similar to the design detailed in this talk by Ryan Fluery:

https://www.youtube.com/watch?v=TZ5a3gCCZYo

Odin also has a tracking allocator which can be used to check for leaks or double frees. In debug mode, my program will print out all un-freed memory left after shutdown. If you're working outside of Odin, I've heard good things about Valgrind for C/C++:

https://valgrind.org/

Matrices, like any other primitive data type, are stack-allocated. Do you want matrices to be allocated on the heap? If you're looking to do Pandas-style data science, you'd have to write your own implementation, where you could adjust for exactly how you want to do the multiplication. The builtin matrices are typically pretty small (~4x4 or 3x3), a very common use case in graphics or games programming.

I've seen some interesting work in doing Wayland by hand:

https://gaultier.github.io/blog/wayland_from_scratch.html

I'd also look at the work done on minimal wayland projects like [foot](https://codeberg.org/dnkl/foot), which supports wayland well and seems to be written by hand (see: https://codeberg.org/dnkl/foot/src/branch/master/wayland.c)

Yeah, I've been looking for a minimal SDL alternative for a long time and I was really excited reading through this as that solution, but the lack of Wayland support is a huge dealbreaker for me.

Are there any good minimal windowing utilities that support Wayland? SDL does a lot I don't need and I try to maintain minimal dependencies. I suppose I could just use glfw & libsoundio, haven't tried that yet.

I tried that initially, but I found that it still wasn't quite satisfactory. My game's art style has a lot of straight edges, to be fair.

Graphics programming analysis done using examples written in WebGL–genius. Hypertext that takes full advantage of the medium. This reminds me of something I'd see on https://pudding.cool/, but it goes far more in depth than anything there. Absolutely fantastic article.

I've been using MSAAx4 in my rendering engine for some time and only recently have considered switching to a FXAA / TAA implementation. I'm actually not sure I'm going to go through with that now. I definitely learned a lot here, and will probably use the analytical approach for UI items, I hadn't heard about that anywhere.

Not often you see graphics-programming stuff on HN. For anyone interested in more graphics write-ups, this list of frame breakdowns is one of my favorite resources:

https://www.adriancourreges.com/blog/

I keep coming back to this idea as the (albeit ideal) future of the web. HTML keeps morphing and changing to fit the increasingly complex requirements of modern web apps. I mean the W3C spec is 114 million words (1). I think that web apps as a concept are a good idea, but I just can't believe that HTML/CSS/JS are the best technologies to fill that out. I'd love to see someone tackle a new, "micro-sized app format", with a much simpler document format, and something like a FORTH as a scripting language. Uxn (2) and Decker (3) are good examples of this, but obviously a proper implementation would have to be built with the full range of possible UI and accessibility in mind, not just monochrome bitmap displays.

A web standard so simple, anyone can implement it!

One can dream...

(1) https://drewdevault.com/2020/03/18/Reckless-limitless-scope.... (2) https://100r.co/site/uxn.html (3) https://internet-janitor.itch.io/decker

EDIT: There is Project Gemini (https://geminiprotocol.net/), but it doesn't support styling or scripting.

This seems to be Swift-exclusive, but the idea is absolutely there. Imagine when this gets expanded to any codebase. Imagine all the spaghetti code you could visualize as real spaghetti!

THIS! So much this!!

With the jump from 2D screen to AR-based UI, we have the chance to re-think all of the conventions that have gripped UI/UX design over the past few decades. How many apps would benefit from being able to visualize data in a 3D space? How many new ways could we interact with computers, if we could reach out and touch things? Text editing, video editing, image editing (visualizing Photoshop layers?), 3D modeling, sketching, gaming: all revolutionized by a new input paradigm. That's partially what I thought Apple would accomplish. They have a history of totally rethinking every part of software when a new input device comes around. I mean, think about the jump from the iMac to the iPhone. ["I just take my finger, and I scroll."](https://www.youtube.com/watch?v=FSv5x3V_KHY) I shudder to think how many drugs Apple employees had to take in order to think around traditional desktop conventions and come up with this stuff. I figured with the Vision Pro, we'd see traditional apps reformed to a new, never-before-seen standard, but I have unfortunately seen very little of that. If you scrape off all of the high-budget polish, Vision Pro feels like a device that another company would create that Apple would then do correctly. By extension, the Meta Quest lineup feels the same way.

But this is the kind of thing I absolutely want to see more of. There's a physicality to this text editor that feels intuitive, but more importantly, it feels comforting. When things appear and disappear on screens instantaneously without any animation, it triggers our brains that something is wrong, because that's unusual behavior. There's a purpose for animation, it's not always all for show. Bringing physicality like this to a 3D interface in mixed reality is, in my opinion, the next step in UI design. This text editor isn't getting super crazy with its effects, but in my opinion, you can already see the potential. As these devices come down in price and more developers get their hands on them I hope to see more like this. Hell, seeing this is the closest I've ever gotten to splurging on a Meta Quest so I could whip up a 3D modal text editor. I want a digital kitchen timer I can physically wind and unwind for Pomodoro timing. I want to pick an album to listen to on Apple Music from a stack of records projected onto my floor. Impractical? Perhaps. But look at early skeuomorphic iPhone apps and tell me those are practical. If all we cared about was using computers to get from point A to point B, we'd all work in TUIs, and r/unixporn wouldn't exist.

I don't know what it is, but feel a fundamental lack of interest in this new input paradigm, both from companies like Apple & Meta and from developers. Hopefully open source projects like this will show people the real potential of this new hardware.

I don't think Dreams gets enough credit because it came out at the end of the PlayStation 4's life and it didn't get a lot of marketing, but it absolutely is fantastic. I'd say it's the best implementation of visual scripting I've ever seen, and that's using a traditional game controller (or two PSMove controllers) instead of a mouse/keyboard. That's not even including the modeling tools or music tools.

As someone who makes games, I often hear people ask me "how do I get started?" And my first answer is always "learn C." When they look at me funny, I say, "Try Dreams on Playstation."

The issue with these kinds of meeting services seems to be that as the population of the online community goes up, the overall quality, and likelihood that you'll meet a real, friendly person, goes down. It's not guaranteed, but the ideals and culture of hackernews could help realize the full potential of that dream. As it says in the welcome page, "A community site that becomes popular will decline in quality... by making a conscious effort to resist decline, we can keep it from happening." I definitely think it would be something worth trying.