Re: "The provenance memory model for C", by Jens Gustedt

On 7/13/2025 3:55 PM, Chris M. Thomasson wrote:

On 7/13/2025 1:10 PM, BGB wrote:

On 7/12/2025 7:30 PM, Chris M. Thomasson wrote:

On 7/11/2025 1:48 AM, David Brown wrote:

On 11/07/2025 04:09, BGB wrote:

On 7/10/2025 4:34 AM, David Brown wrote:

On 10/07/2025 04:28, BGB wrote:

On 7/9/2025 4:41 AM, David Brown wrote:

On 09/07/2025 04:39, BGB wrote:

On 7/2/2025 8:10 AM, Kaz Kylheku wrote:

On 2025-07-02, Alexis <flexibeast@gmail.com> wrote:

>

...

>

>

[...]

It is worth remembering that game code (especially commercial game code) is seldom written with a view to portability, standard correctness, or future maintainability.  It is written to be as fast as possible using the compiler chosen at the time, to be build and released as a binary in the shortest possible time-to-market.

>
Love this one:
>
https://forums.parallax.com/discussion/147522/dog-leg-hypotenuse- approximation
>
[...]

>
I looked at the post and initially didn't recognize it as I didn't use the same term (I usually called it "distance approximation").
>
But, yeah, variations of the first algorithm were used frequently in a lot of this code. For example, it was the main way of calculating distance in Wolf3D and ROTT.
>
Not sure about Doom, would need to find the relevant code, but wouldn't be surprised.
>
>
In terms of coding style, ROTT had considerable "hair".
>
In my initial porting effort, spent quite a long time trying to deal with all of the places where memory access was going out of bounds (though, in many cases, just ended up masking the access by the size of the array or similar; or in some cases rewriting the logic to not depend on particular out-of-bounds access behaviors).
>
Also had to deal with the mess that a lot of the drawing code depended on the specific way they were using the VGA hardware:
320x200 on screen, but 384x200 in memory, but divided into 4 planes of 96x200 (and doing tricks with the plane mask register).
Kinda needed to write wrappers to fake a lot of this crap.
>
But, it seemed like Apogee / 3D Realms liked this mode, vs id mostly staying with the standard 320x200 256-color VGA mode (which can be mapped directly to a 64K array).
>
>
>
FWIW, my most recent 3D engine also used this strategy for distance math in many places.
>
>
Can note that in this 3D engine, world coordinates are primarily expressed in a packed fix point form:
   (23: 0): X coord, 16.8
   (47:24): Y coord, 16.8
   (63:48): Z coord, 8.8
>
With the base unit roughly 1 meter, albeit informally subdivided into 32 "inches", with the exact handling of the 25% error on the size of the inch relative to the "standard inch" being subject to interpretation.
>
>
Though, for sake of hand waving, in 3D engines one can also say that meters and yards are "basically the same thing" as well (if one redefines the base unit as "yard", the inch discrepancy drops to 12.5%...).
>
Though, in my case, I just sorta instead used "decimal inches", where there is only around a 4% discrepancy between 1/32 of a meter, and the decimal inch.
>
Another factor is the size of the player:
   In Minecraft, IIRC "Steve" is 1.85m tall, this is atypical (~ 6'2").
   In my 3D engine, decided to adjust is so the player 1.60m tall (5'4").
>
This small difference has a notable effect on how big the blocks look.
>
>
>
>
Note that in this engine (like my previous 3D engine) has a world that is modulo in X and Y.

 For some reason, this reminds me of an example from my experimental 3d engine:
 (FlyMatirx ver(0.0.0))
 https://youtu.be/VSPgb51Hry8
 :^)
 

I have no good videos online of my 3rd engine it seems...
Here is a video of my 2nd engine:
https://www.youtube.com/watch?v=trUZl4onzqI
(as noted, from 7 years ago).
Another video from 2nd engine:
https://www.youtube.com/watch?v=LGB53L7f314
This effort fizzled with the rise of my ISA project eating most of my time, and me starting to run out of ideas or motivation to continue working on it.
And, first 3D engine:
https://www.youtube.com/watch?v=WTrfNAfWV8o
Which started out trying to be a Doom 3 clone before being turned into a Minecraft clone (it used stencil shadows and similar).
But, my 3rd engine seems the most limited thus far. But, as noted, its design priority was more "less RAM use" than "looks good or modern".
In its most recent form, I had also made a hit/miss attempt at moving over to using 16-color artwork and trying to integrate some "text parser game" mechanics (similar to 1980s era Sierra games, like Kings Quest and similar). But, it is a bit of a mystery how to best integrate this stuff with a vaguely Minecraft like world structure.
In the more recent form, my newer 3D engine has experimented again with using 3D models (previously, it, like my 2nd 3D engine, was using exclusively sprite graphics).
Generally, the current 3D modeling tech is based on CSG rather than mesh models.
Though, I did the questionable thing of basing the CSG language on 1980s style BASIC (or, like, the bizarre hybrid offspring of early BASIC and Emacs Lisp). Partly this is because while I was partly tempted to clone and modify the OpenSCAD language with the features I wanted, this would have been more effort.
Kind of ironic is that despite the wonk, my wacky BASIC variant can generally express 3D models in fewer lines (in both cases, the languages work by writing code to express the geometry one wants; as opposed to using a 3D modeler).
These convert to a mesh-model format which is what is actually used in=engine, generally with a skeletal animation system.

[snip]
 I need more time to give your response a proper read! Well done. Am busy with other things right now. Fwiw, check out an interesting 3d model of mine on SketchFab:
 (ctHyperField)
https://skfb.ly/pyP9E
 (ctWorms (0.0.1))
https://skfb.ly/pyXH6
 (InfaRing)
https://skfb.ly/py7Mu

My stuff is generally less abstract...
Here are some pictures from my 3rd engine, showing off a few of the 3D models:
https://x.com/cr88192/status/1921809223639322962/photo/2
It is unclear if the 16-color thing is really working...
And, even then, in some places I cheated and used a 32-color palette; with additional darker shades of the first 16 colors.
The color palette here is based on the CGA/EGA palette (as opposed to the default 16-color VGA palette, which is "similar but different").
Well, and this is also combined with the distortions caused by DXT1 texture compression, which also does not preserve the 16 colors all that well and also limits how colors could be used in blocks. To be authentic, one would need to limit use to 2 colors per 4x4 block, and possibly also ensure that mipmaps also maintain 16-color integrity. I didn't go that far.
The main alternative being to just stay with the usual RGB555 hi-color that is being used otherwise.
For the design of the 3D guy, was partly also trying to take some inspiration from the humanoids in the "Money for Nothing" video, though in this case slightly more minimalist. Tried to go more minimal, but it wasn't really working for me. Minecraft style models likely only really work because they have texture maps (and flat colors increases the minimum geometric complexity needed).
...