Path: ...!eternal-september.org!feeder3.eternal-september.org!news.eternal-september.org!.POSTED!not-for-mail
From: BGB <cr88192@gmail.com>
Newsgroups: comp.arch
Subject: Re: Capabilities, Anybody?
Date: Thu, 14 Mar 2024 00:32:28 -0500
Organization: A noiseless patient Spider
Lines: 234
Message-ID: <usu27p$1ei22$1@dont-email.me>
References: <usg40i$1udfo$3@dont-email.me>
 <1951488caf6138e90c4bac62ee6ac41d@www.novabbs.org>
 <_Y_GN.75295$LONb.13164@fx08.iad> <usibg4$2ffdn$1@dont-email.me>
 <usif12$2g7eq$1@dont-email.me> <usinhj$2i2nn$1@dont-email.me>
 <6b75cd0221ee827b49cd2275f2c65789@www.novabbs.org>
 <Qry*XE3Ez@news.chiark.greenend.org.uk>
 <7da2a6f0e0878f914dee2286db833dc2@www.novabbs.org>
 <Qry*d14Ez@news.chiark.greenend.org.uk> <uslfqc$37b8q$1@dont-email.me>
 <usq9ct$ev5l$1@dont-email.me> <usqqhh$ip3r$1@dont-email.me>
 <ustk30$18dah$1@dont-email.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Injection-Date: Thu, 14 Mar 2024 05:33:46 -0000 (UTC)
Injection-Info: dont-email.me; posting-host="e246796ede20208964964aa8d7229656";
	logging-data="1525826"; mail-complaints-to="abuse@eternal-september.org";	posting-account="U2FsdGVkX19JvYG1gNd7VQR9UKR24EriE1/hk81t8h4="
User-Agent: Mozilla Thunderbird
Cancel-Lock: sha1:QA0DHuFkTGeq+NIr7Am+UPmhrUo=
In-Reply-To: <ustk30$18dah$1@dont-email.me>
Content-Language: en-US
Bytes: 11861

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).


========== REMAINDER OF ARTICLE TRUNCATED ==========