Re: Capabilities, Anybody?

On 3/13/2024 8:32 PM, Chris M. Thomasson wrote:

On 3/12/2024 5:02 PM, BGB wrote:

On 3/12/2024 2:11 PM, Chris M. Thomasson wrote:

On 3/10/2024 4:30 PM, Chris M. Thomasson wrote:
[...]

Something akin to my old alignment code:
>
https://groups.google.com/g/comp.lang.c/c/7oaJFWKVCTw/m/sSWYU9BUS_QJ

[...]
>
To BGB / cr88192, your are the same person that replied to me in that thread, right? Back in 2009?

>
Looks like me, but off-hand I don't remember the contents of this thread, and this mostly predates my current projects...
>
At the time, I would have been taking college classes, roughly mid 20s.
>
>
IIRC, projects I was working on at that time:
   A 3D engine (*);
   A VM for a JavaScript/ActionScript inspired language;
     Was being used as a scripting language for the 3D engine project.
   ...
>
At this time, it would have still been mostly a Doom 3 clone; as I didn't switch over to trying to imitate Minecraft until several years later.
>
>
This was also sometime around the time I wrote the first version of BGBCC, based on a fork of the previous VM, modified to be able to parse C. However, initially, it wasn't very successful, and ended up mostly relegated to be a header-parser tool and FFI generator.
>
I had used garbage collectors and similar more often back then, but have since largely ended up moving away from GC, as it is difficult to make it "not suck".
>
>
I have been on usenet for a while...
>
>

 Well done. Btw, do you happen to know anything about DirectX 12? I know OpenGL, but I might need to move into DirectX land...

I never really got into DirectX, and had always used OpenGL.
DirectX requires giving up on the ability to run code on non-Windows targets. Meanwhile, OpenGL had generally kept options open (code written for OpenGL in one context can be adapted to another context; but, if one uses Direct3D, they are basically stuck with Windows...).
By the time Vulkan came around, I was already scaling back a lot on graphics stuff, and it wasn't until a few months ago that I got a graphics card actually capable of the whole RTX.
So, in terms of graphical features, ironically, my first 3D engine was the fanciest. My later efforts were generally simpler, aiming more to try to limit code complexity, improve performance, reduce resource utilization, etc.
So, first BGBTech engine (BT1) ended up being around 1 MLOC, and tended to use several GB of RAM. I had ended up using 64-bit builds, mostly because otherwise it kept running out of 32-bit address space much past around 1km^2 of chunks.
As can be noted, it was using a hybrid Doom 3 like rendering strategy.
For small/dynamic light-sources and entities, was using Depth-Pass stencil shadowing (at the time, someone had patented the Depth Fail stencil shadow strategy, forcing people to use of Depth Pass instead as a workaround).
For the sun and world terrain, had used shadow maps (using stencil shadows for the sun was not viable). General idea here is that one renders to a depth texture from the perspective of the sun, pointing in the general direction of the player. Then, when drawing the lighting for the sun, the fragment shader could compare the position (in terms of distance from the sun) with the texel in the depth-texture, to determine whether this location is in line-of-sight of the sun.
I lost direction near the end of this project, as moving forward with "gameplay" became less obvious, and so it mostly went out in a flurry of me screwing around with using videos as texture-maps (seemed semi-novel at the time). But, sticking random videos onto geometry does not make for compelling gameplay (and in practice, I mostly just ended up using it for animated textures; which is admittedly kind of overkill).
Second BGBTech engine (BT2) was around 150 kLOC. Was also able to get it to run OK in a 256MB footprint, and on a RasPi and early 2000s laptop. Had also done a WASM build, so it could run in a browser.
It had switched to a simpler design, namely just doing the lighting using vertex colors (more like how Minecraft seemed to work). Shaders ended up as optional and were not used as significantly (the engine still worked acceptably with fixed-function rendering); and generally the rendering could all be done in a single pass.
Initially, when designing things (in terms of graphics and other UI aspects), had also taken some inspiration from Undertale and similar (which was relatively popular in the mid/late 2010s).
This project mostly fizzled out, as I didn't have enough motivation to work on both this and my BJX2 project, and personally I found my BJX2 project to be more interesting.
Third BGBTech engine (BT3) is around 30 kLOC and fits into around 60 MB of RAM (though, one can add another 24 kLOC if one counts TKRA-GL in the budget; but it can also work with native OpenGL). Where TKRA-GL in turn exists because of a prior attempt of mine at implementing OpenGL in software, which was (in part) because I had a laptop with a GPU that was sufficiently bad as to make implementing the OpenGL API on top of a software rasterizer seem like a valid option. Imagine a Vista era laptop with a GPU (Intel GMA) weak enough that its claim to fame is that it can give "mostly acceptable" framerates in Half-Life and Quake 3 Arena; or one can just use Half-Life's software renderer, ... Well, along with disabling Vista's Aero UI, mostly as it made everything unpleasantly sluggish (well, nevermind if apparently the GPU didn't actually support shaders in hardware; so all the transparency and blur stuff was presumably being done in software), ...
The third engine mostly existed because the second engine was still too heavyweight to be usable on the BJX2 core. Compared with its predecessors (and actual Minecraft), its design is less well-suited to larger draw distances (it scales poorly).
At present, BT3's codebase is smaller that my Doom engine port.
Partial contrast is ROTT, which was based on the Wolf3D engine, and weighs in at around 130 kLOC. Though, ROTT is one of the larger programs I am running on BJX2 at the moment. Quake3 is bigger (around 300 kLOC), but I still haven't gotten around to finishing the Quake3 port (and I don't expect it to be usable; even with a bunch of hacks to try to reduce memory usage and similar).
In this case, both the BT1 and BT2 engines had worked by building per-chunk vertex arrays. Then, for any potentially visible chunks, the arrays were drawn.
In the BT3 engine, a different strategy was used:
 From the point of view of the player, a bunch of rays are fired off in every direction (in a roughly spherical pattern with randomized jitter being added), and any block/face which a ray hits, is added to a list;
Then, for any block in the list, any visible faces are added into big global vertex arrays, and then these vertex arrays are rendered. Similarly, any blocks which haven't been hit recently enough end up being removed from the list (along with blocks which are too far outside the draw distance).
To some extent, this aspect of the engine was partly inspired by the ROTT and Wolf3D engines, which use a ray-sweep to find any visible walls, and also to build a list of visible sprites (say, if a ray passes through a tile with sprite-entities in it, they are added to a list of things to be drawn).
One possible strategy I considered (before my BT2 effort fizzled out) was to try to allow larger draw-distances by rendering chunk faces to textures, and then for distant chunks, rather than draw the chunk geometry itself, one draws a cube with each face representing the chunk as seen from that direction (in an orthographic sense).
Similar could also be possible for BT3, as a partial workaround for the small draw-distances. Another possibility could be to use some projection trickery, and then prerender a view from within each region (a 128x128x128 meter cube in BT3) as its own cubemap. Cube faces could then be rendered (with alpha blending) before rendering the visible blocks.
Otherwise, for BT3, had reused the texture atlas and similar from BT2.
Though, comparably much cruder (quick/dirty) sprite artwork (comparably, for BT2, had used higher resolution sprites, and for BT1 had used 3D models).
Partly the use of sprites in BT2 was for aesthetic reasons, and partly also because it is a lot less effort to draw sprites than to 3D model stuff (could have re-added 3D models if I wanted).
Had otherwise been tempted to try to take inspiration from Stardew Valley, but gameplay in Stardew Valley is very different (it is mostly focused on prescripted character interactions in an top-down 2D environment; with farming-sim and dungeon-crawler aspects), and it is not obvious how to integrate them (and the worlds are also built manually rather than procedural generation).
I have a few times missed my past in 3D engines, but sadly I don't really have the time and motivation to work on multiple "semi-big" projects at the same time.
And, not that many people seemed all that interested in my past 3D engine projects. And, I have tended to fail at the things that lead to any sort of "actually compelling" gameplay experiences.
Like, would be more motivated to work on games, if I could make something which:
   Was actually interesting to play;
   Had some chance of anyone "actually giving a crap".
Which, seemingly, means needing an "actually interesting" idea for something to make. I am also not great at coming up with fictional characters and how to script social interactions with them, ...
...
Though, OTOH, there is some overlap in terms of technical aspects between my projects.
Like, there isn't that huge of a gap between the technologies I had used in my 3D engines, and those I am using in BJX2 and TestKern. Many similar sorts of technologies end up being needed in both cases (say, for example, hierarchical filesystems capable of dealing with mount points, ...).
...