badsectoracula

The fact the site died after being posted here might be an indication why :-P.

Doom 3 was SOTA in terms of realtime lighting and shadows, but that's basically it. In terms of visuals, Half-Life 2 with its baked lighting in directional lightmaps (essentially calculating three lightmaps for each surface for lighting coming from different directions, then using those with normal maps during rendering) with radiosity indirect lighting did a much better job with how good environments looked (and it scaled much better than Doom 3 which in lower settings looked worse than Quake 3). Doom 3's character rendering was also subpar compared to Half-Life 2 - let alone character animations mentioned elsewhere (Source/HL2's facial expressions were SOTA for several years after the game was released). Doom 3's physics were also not as complex as HL2's and the game didn't use them much (the expansion did better use of the physics engine and IMO the Grabber feels superior and more seamless in its use compared to the Gravity Gun but the expansion came later and while the Grabber is nice, the rest of the expansion suffered from focusing too much on gimmicks).

In general while Doom 3 has the better (and probably more forward thinking) rendering tech, HL2 also had some very good tech for its time and did a much better use of the tech they had available than Doom 3 did.

That said, personally i enjoy playing Doom 3 much more than HL2 but that is largely because Doom 3 plays more like a traditional shooter with very little scripting / storytelling to get in your way (and the little there is you can ignore it without losing anything) - you just shoot demons, find keycards/PDAs to open doors and that's it for the most part. I often just put it in low volume and play some podcast in the background :-P.

As for Far Cry, the game looked too plastic IMO, i remember playing the game and the characters' muscles had specular reflections :-P.

Usually one would start with "is there a measurable performance bottleneck here?" :-P.

TBH i haven't played Elden Ring but from what i've seen there are so few "active" NPCs around that i highly doubt there'd be any performance issue coming from this.

The article keeps on mentioning about the performance issues of the decision tree that somehow this approach avoids, but it doesn't seem to actually put any real detais about the why here. Especially considering that:

1. Many scripting languages you'd find in games are implemented by evaluating the syntax tree directly (IIRC WitcherScript in Witcher 2 and 3 is implemented like that)

2. A behavior tree can be "compiled" down to a bytecode VM similar to what some scripting languages use

Though if any of these two approaches makes any difference in performance i'm not sure and i'd expect it'd depend heavily on how exactly they're implemented (my kneejerk reaction would be to expect the VM approach to be faster because parsing a bytecode sequence might be more cache friendly than jumping through pointers, but i also suspect that since game AI scripts/behaviors wont do any real computation themselves and instead 99% of the code would be engine/native calls, any potential benefit would be diminished -- but as i haven't tried to implement the same stuff with a realistic setup using both approaches to compare, i cannot say one or the other for certain).

This is game AI, games called this sort of thing "AI" for a long time. Behavior trees is (among others) one of the most common things someone with the role of game AI programmer will implement.

This has been the case since at least the 90s, it is not a new thing.

The original Pascal didn't had a string type, that was introduced by various dialects.

FWIW all Pascal dialects since the 90s have a string type that allows more than 255 bytes. In Free Pascal strings are pointers to the first character with a header in a negative offset indicating the length, reference count and codepage (these fields are aligned depending on the CPU). For C compatibility the string is also null terminated so you can pass such a string to a C function and it'll work as expected. AFAIK Delphi also does the same.

Free Pascal strings (and i assume Delphi as they are sometimes compatible) are pointers to the first character of a null terminated string with a header in a negative offset before the first character indicating the string's length, reference count and codebase.

AFAIK a "Pascal string" is basically another way to say "length-prefixed string" (as opposed to null terminated string) and Free Pascal (and Delphi) are like that (and they're Pascal dialects too, so their strings are literally Pascal strings :-P).

FWIW pretty much all Pascals since the 90s use a similar approach.

In Free Pascal for instance, strings are pointers to the first character with a header in a "negative address" containing information about the length, reference count (strings are reference counted and use copy-on-write to avoid passing around copies all the time) and codepage (FP can convert strings between different encodings "transparently").

For a long time i had a small Pentium III PC (released in 2000, though the hardware inside wasn't the best you could get at the time as it was meant to be compact instead of performant - it was in an almost pizzabox sized case) running Windows 98 for retro games and software (though mainly games). At some point i installed Visual Studio 6 to it too - and IME it launched instantly[0].

In general everything ran fast... except stuff that had to do a lot of disk access, obviously (i.e. installers and such). But i never though that the system didn't feel responsive.

Also many modern programs have splash screens too. E.g. have you tried to launch Gimp or Krita recently? Or Eclipse? "Heavy" applications never stopped having those.

Of course computers are much faster now, nobody is saying otherwise. What people are saying is that it often doesn't feel so. If my Pentium III can open Visual Studio 6 faster than my 3700X can open Calculator, then yes, things do feel more performant on the Pentium III running Windows 98 even if the modern machine is much faster.

[0] https://www.youtube.com/watch?v=h79Bt7h5ceo

Impressive. I guess this isn't only the renderer made to use CSS but also a full recreation of the engine and logic right? My guess is because a bunch of things do not behave like the original game, e.g. some buttons need to be shot instead of touched to activate, some secret doors open by touching them instead of being shot, etc.

Theoretically yes, but in practice you don't need the full repository, but even in mid-2010 (when i first encounter Perforce in a gamedev company - previously the companies i worked on used Subversion which was also able to handle some huge repositories -- one had all their games from the 90s to early 2010s in a single Svn repository, including code and data) a workspace with just the game's code and data in the engine's format (i.e. excluding everything a programmer wouldn't need, like the "source data" for assets such as max/maya/etc files) was around 250GB or so. IIRC the entire repository (all versions, not just latest) had crossed a petabyte in size :-P though that company put absolutely everything in Perforce.

> I’ve also worked on games that have required a bunch of different standalone services just for core logic

Don't make your game be a spaghetti mess of dependencies.

Or.

When you decide on your dependencies, make sure they are compatible with the regulations. The chances of middleware developers not updating their middleware and/or licenses to comply with these regulations are practically zero: there will 100% be market need for compliant middleware and others to provide it, so the existing middleware developers will update theirs too.

> What if I rely on steam, or epic for P2P and they shutter the service?

That's the easiest of the bunch because Steam already has at least one opensource reimplementation of the API (probably multiple) so all you have to do is drop a DLL in your game's directory and you get Steam independence.

> Yes, just use and IDE

The best the IDE can do is display a tooltip or something like that which is cumbersome when reading the code because you need to move over everything to figure out what the types are. And sometimes for whatever reason even that fails.

And this is only useful in the context of using an IDE: code can be found outside IDEs too, even if all you do is use an IDE for your development (not everyone does), the code can still be found in patch files, pull requests and code review platforms none of which have any IDE functionality to know what the types are.

> There’s no reason to repeat type definitions. If you can use auto, what that means is the type is already statically known

I'm not a compiler though.

> It doesn't matter what the type is, that's the whole point!

Except it often does.

> You don't need to know any more.

I need to modify and/or review the code so, yes, i do need to now more.

Be happy your readers use an ePub reader that supports (or at least, ignores) something like `max-width` in the first place :-P.

TBH i've being using an ePub reader that i occasionally had to edit ePub files so i get rid of the superfluous styling that made it either not work or show things weirdly/wrong and i've heard comments from others that a bunch of files i had no issues with personally were unreadable for them, which makes me think that unless you really and absolutely need any fancy formatting (i.e. math stuff that can't just be made images - and you really tried to!) then you should stick with the most basic HTML imaginable - things that not even IE4 would render (too) wrong.

And in turn, since i doubt this will ever happen, i sometimes ponder making an "epub reconstruct" tool that attempts to reconstruct epubs so that they use the simplest HTML/CSS :-P (ideally configurable for maximum compatibility).

> How important is that, the ability to be certain of the type of some iterated value from a container from one line in total isolation?

As important as the code to be readable.

> The odds are very good that it's clear from the context

As i wrote, if the actual type can be seen somewhere nearby (close enough to be included in diffs) then that's fine - it is already in the context. Though that is not usually the case and i personally had to work with code with which i was not familiar and which used `auto` all over the place and had to go hunting for the actual container declaration to see what it is (Visual Studio was not helpful in its tooltips).

So my actual experience is that i'd rather see the actual type.

However...

> anyway, in this case the real win probably is the range-based for loop

...yes, the range-based for loop is often the better choice when it comes to readability. And when compared with the iterators, it is pretty much always more readable than them :-P. `for (const Foo& foo : foos)` is basically what i'd prefer to see. It is the use of `auto` i pointed out.

> for (auto const & ess : esses) {

The problem with this is that whoever is reading the code as-is does not know what type "ess" is. Sometimes you get the definition somewhere nearby, in which case it is probably fine - assuming it is close enough that it'll be included in a diff - but more often than not you don't know.

Yes, an IDE can probably tell you (probably, depends on the IDE and assuming everyone uses one) but even that requires some extra action like moving the mouse over the definition and hoping it'll give you something. However this wont show up in diffs, PRs, code reviews, etc.

IMO `auto` is one of those C++ features that really needs discipline to use - and when in doubt, i'd rather ban its use (except where you cannot do otherwise) than rely on everyone doing the right thing.

> Originally, I had meant to compare with X11 sessions as well, but with KDE removing them soon, I dropped it.

Last time i checked X11 without a desktop compositor (very important) still provides the least latency of any environment, so even if KDE Plasma (not KDE as a whole AFAICT) drops support, there are other WMs/DEs that will work with it and have minimal latency on desktop.

It isn't a lot but i wouldn't say it is rare either.

Yeah, that is basically what i did around 2009 when i was making a 3D engine in Haxe for Flash, RayFaster 2 (it was the successor to another Flash game engine, RayFaster, which did Wolf3D-like raycasting and i used to make a simple FPS[0] though with Flash's input limitations i couldn't do mouselook and didn't feel that great).

The engine used Build/Doom-like maps and would simply raycast against the camera's current sector (sectors could be any shape not just convex) and used connections between sectors as portals to recursively follow the (2D) map until it hit a solid wall - so basically Build's portal rendering approach except using raycasting instead of trapezoid rasterization. It could also do sprite rendering (you could have both sprites facing the camera and "aligned" sprites that could be used for decals) and even had some simple 3D model rendering (the triangles were sorted and clipped against the portal during rasterization). Unfortunately Flash isn't available in browsers anymore and Ruffle isn't compatible with it (it can run the engine -much slower than real Flash- but the palette is all wrong), so i took some shots using the standalone Flash "projector"[1][2][3][4]. Also making maps for it was certainly much more laborsome than making maps for a Wolf3D-like game and that combined with me losing interest in making Flash games meant i never made a game with it.

[0] https://www.youtube.com/watch?v=Z81NhEbl3q8

[1] http://runtimeterror.com/pages/iv/images/01feb493af6dd3184b8...

[2] http://runtimeterror.com/pages/iv/images/136a8753b211ed7e3d1...

[3] http://runtimeterror.com/pages/iv/images/84c2012258982b82053...

[4] http://runtimeterror.com/pages/iv/images/e94cc334c7735e1aacb...

> A pointer to 0xA0000 was all you needed

Though your extender could make things a little more annoying on that front :-P

(DJGPP and Free Pascal -which use the same "go32" extender by DJ Delorie- do not do a full linear mapping so you need to do a bit more juggling to get stuff on screen there)

Yeah, even this model[0] i made a few years ago for a game i wanted to make for the OG xbox (which has a GeForce3-like GPU) has ~2230 triangles and the entire first level of Post Apocalyptic Petra is ~5800 triangles, so you could say that even a turn of the century 3D character has more or less the same polycount as an entire 90s level (the game i wanted to make would have many characters on screen so i kept the polycount low but i've heard games having 5-6K character or more - e.g. Kingdom Under Fire had ~10K triangles for the main character and a game like Dead or Alive where there are few characters on screen had 15-20K triangles).

Meanwhile more current games have much higher polycounts, easily going above 100K triangles - e.g. Dante from DMC5, a ~7 year old game, apparently has ~190K triangles and that had to run on the more anemic PS4/XBone hardware :-P (though i'm not sure if it used the full 190K model there or some cut down version).

[0] http://runtimeterror.com/pages/iv/images/1073c7062db40837240...

Unless you plan on rendering the level on some very retro hardware (think S3 Virge, maybe Voodoo 1) you can render the entire level in OpenGL with just zbuffer and alpha tested sprites and it'll run perfectly fine - if anything with such low polycount, chances are you're going to make the renderer slower by trying to do occlusion culling on any GPU released in the 21st century :-P. If you pack the geometry in a few vertex buffers (for each unique texture) even per-frame, you'll get four digit FPS in any relatively modern GPU.

As an example this[0] video shows the benchmark from Post Apocalyptic Petra running on my previous GPU (RX 5700 XT) which all it does is build a per-frame (client-side) vertex-buffer in OpenGL 1.1 (the engine was made for actual retro PCs running DOS and Win9x so it does some rudimentary occlusion culling but that mainly affects 90s hardware, not anything released since 2000 or so). If anything, the rendering has so little overhead that half of the framerate is "eaten" by the FPS counter overlay :-P.

[0] https://www.youtube.com/watch?v=64ysz5rXkzw

As a side note, the visual style in the game reminds me a lot of Exhumed / Powerslave :-).

> Duke Nukem as well used a BSP engine

The Build engine didn't use BSP, it treated connections between sectors as portals and rasterized the walls as (90 degree rotated) trapezoids while performing clipping against those portals. This allowed it to have dynamic wall geometry (e.g. moving trains, rotating light fixtures, etc) as well as "room-over-room" setups as long as you couldn't see both rooms at the same time (in both Blood and Shadow Warrior they found a workaround for it allowing to create more "3D" spaces by making identically shaped sectors with the floor of one sector acting as a portal to the ceiling of the other sector - supposedly this wasn't "natively" supported by the engine, but it was flexible enough for the game studios who used it -without even having access to the source- to do it themselves).

The first level of Duke Nukem 3D does use a few Build tricks - e.g. another one is that sprites can be "axis aligned" instead of following the camera and they can also have collision - this can be used to create rudimentary 3D geometry by treating each sprite as an axis aligned quad and in the first level it is used to make a bridge between two buildings (right before the level exit button).

A lot of boomer shooters nowadays have a female protagonist, e.g. Selaco[0], Supplice[1], The Citadel[2] and its sequel[3], Zortch[4] (and its upcoming sequel[5]), Nighmare Reaper[6], COVEN[7], Viscerafest[8], Hedon[9], etc. If anything i'd say that nowadays there are way more boomer shooters with female protagonists than not :-P (combining the tags "boomer shooter" with "female protagonist" on Steam search gives 143 results, though that includes games where you can either choose your character's gender or you play as a woman for a part of the game even if you play as a man for most of it).

[0] https://store.steampowered.com/app/1592280/Selaco/

[1] https://store.steampowered.com/app/1693280/Supplice/

[2] https://store.steampowered.com/app/1378290/The_Citadel/

[3] https://store.steampowered.com/app/3371240/Beyond_Citadel/

[4] https://store.steampowered.com/app/2443360/Zortch/

[5] https://store.steampowered.com/app/3807500/Zortch_2/

[6] https://store.steampowered.com/app/1051690/Nightmare_Reaper/

[7] https://store.steampowered.com/app/1785940/COVEN/

[8] https://store.steampowered.com/app/1406780/Viscerafest/

[9] https://store.steampowered.com/app/1072150/Hedon_Bloodrite/

Nice, i've used similar approach for the lighting in Post Apocalyptic Petra[0] though i did use per-pixel LUT offset calculation[1] because it uses a generic 3D triangle rasterizer (the levels are based on grids like in Tomb Raider but they're rendered as triangles). Later i added sprite support for another gamejam but i never ended up finishing it and the sprite support is very rudimentary (and unoptimized - i just noticed i'm doing the LUT lookup for every pixel when drawing shaded sprites which isn't necessary).

I did write a tool for generating the sprites from 3D models though[2]. It uses plain old OpenGL 1.1 to draw the sprite and grabs the framebuffer directly. It is drawn fullbright so i can paint the lighting directly on the sprite's texture (using a Krita plugin i wrote[3][4] - the model is something i threw together with Blender's default generated UV since i didn't care for the details).

I wonder if doing some sort of postprocessing (after rendering with with shading) like you do with your game would help with the finer details since i also found that rendering from 3D models to sprites creates very "mushy" results most of the time because of all the details getting lost. I notice the colors also become more saturated after postprocessing in your examples, is this after it finds the closest color in the palette or the result of the postprocess? I'd like to keep the overall hue+saturation of the model so maybe doing post-processing on a grayscale render to shade the shadows/dark areas but keep highlights as-is and then multiplying that with the fullbright image would produce results that wont shift the saturation.

[0] https://bad-sector.itch.io/post-apocalyptic-petra

[1] https://codeberg.org/badsector/PetraEngine/src/commit/14ca16...

[2] http://runtimeterror.com/pages/iv/images/95ddebc51e4dfa8a5af...

[3] http://runtimeterror.com/tools/kritaview3d/

[4] http://runtimeterror.com/pages/iv/images/535f0e09e590d8a1731...

Well, for a more positive comment (since everything seems to be negative - and nobody brought that up) the site is very fast. In fact pretty much everything changes instantly when i click on stuff, which is very rare. The only exception seems to be when looking at some files with a long history (not sure why the history needs to be displayed by default though).

That said, from a UX perspective, personally i prefer Forgejo - which isn't that much slower either (judging from Codeberg, it isn't instant but it is fast enough to feel "fast").

It is not about being able to make static binaries or really anything that has to do with anything technical. It is more of a cultural thing - the culture in some languages is to link dependencies dynamically (C/C++) whereas the culture in others is to link dependencies statically (Go, not sure about Rust).

Personally i do not even write Go myself yet when i see some webapp made in Go i'm pretty much always sure that it'll be a self-contained static binary. Yes, there are probably exceptions (and i haven't surveyed all webapps made with Go) but it has been common enough to feel as the standard approach to me - and if i ever decide to make a binary webapp, i'll probably reach for Go to do it.

Not the person who wrote that but i also avoid anything related to Flatpak. The reason is that it adds a lot of extra friction to anything it touches (despite what its proponents may claim), apps ignore various settings, it wastes disk space with pointless duplication and a bunch of other issues i do not remember right now (it isn't like i write those down - i just sometimes decide to try it for something exactly because i forgot all the issues i faced and somehow someone convinced me things aren't as i remember, then recoil in horror afterwards as it turns out things are as i vaguely remember -- of course the main thing i always remember is the distaste i have for the thing, not the individual microdetails that led to the distaste).

Ultimately if something isn't in my distro's repository, i try to compile it from source and if that isn't available, i just use something else.