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

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
:^)
[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