From: cr88192@gmail.com   
      
   On 8/20/2024 3:31 PM, Paul Edwards wrote:   
   > "BGB"  wrote in message   
   > news:v7na8l$12737$1@dont-email.me...   
   >   
   >> But, now I am an aging millennial and have arguably not accomplished all   
   >> that much with my life.   
   >   
   > Didn't you email me decades ago to get some changes implemented   
   > to PDPCLIB and you mentioned you were writing a phenomenal   
   > number of lines of code per day? Where did all that effort go?   
   >   
      
   FWIW:   
      
   I ended up with a 3D engine, which was around a 1 MLOC, sort of like   
   Minecraft with a Doom3 style renderer. No one cared, performance wasn't   
   so good (was painfully laggy), and this project fizzled.   
      
   Part of the poor performance was the use of a conservative garbage   
   collector, and rampant memory leaks, ... Another part was was "Minecraft   
   style terrain rendering and stencil shadows don't mix well". Though, for   
   small light sources, could subset the scene geometry mostly to a   
   bounding-box around the light source.   
      
   But, the sun, well, the sun was kinda evil. Did later move to   
   shadow-maps for the sun though (though, IIRC, did RGB shadow maps to   
   allow for colored shadows through colored glass).   
      
      
   Then I wrote a new 3D engine ground-up, which was smaller and had better   
   performance. Few people cared, I lost motivation, and eventually it   
   fizzled as well. Was roughly around 0.5 MLOC, IIRC.   
      
   It had replaced the complex dynamic lighting with the use of   
   vertex-color lighting (with a single big rendering pass).   
      
      
   I started on my CPU ISA project, which checking, is around 2 MLOC (for   
   the C parts.   
      
   It is ~ 3.8 MLOC total, if one includes a lot of ASM and C++ code; but a   
   fair chunk of this is auto-generated (Verilator output, or debug ASM   
   output from my compiler).   
      
   There is also around 0.8 MLOC of Verilog in my project; but this drops   
   to 200 kLOC if only counting the current CPU core.   
      
      
      
      
   Ironically, the OS for my current ISA project has reused some parts from   
   my past 3D engine projects.   
      
   In the course of all this, ended up doing roughly 3 separate   
   re-implementations of the OpenGL API (the 3rd version was written to try   
   to leverage special features of my ISA; though was originally written to   
   assume a plain software renderer, and since implementing a ).   
      
   In my current project, I have ports of GLQuake and Quake 3 Arena working   
   on it; though performance isn't good on a 50MHz CPU.   
      
      
   Ironically, parts of PDPCLIB still remain as a core part of the "OS",   
   though I had ended up rewriting a fair chunk of it to better fit my   
   use-case (the "string.c" and "math.c" stuff ended up almost entirely   
   rewritten, though a fair chunk of "stdio.c" and similar remains intact).   
   It was also expanded out to cover much of C99 and parts of C11 and C23.   
      
   Some wonky modifications were made to support DLLs, which ended up   
   working in an unusual way in my case:   
      The main binary essentially exports a COM interface to its C library;   
      Most of the loaded DLLs have ended up importing this COM interface,   
        which provides things like malloc/free, stdio backend stuff, ...   
      
      
   It also has a small makeshift GUI, though mostly just displays a shell   
   window that can be used to launch programs.   
      
      
   Besides my own ISA, my CPU core also runs RISC-V.   
      
   There is a possible TODO effort of trying to implement the Linux syscall   
   interface for RISC-V Mode, which could potentially allow me to run   
   binaries letting GCC use the "native" GLIBC, which could make porting   
   software to it easier (vs the hassle of getting GCC to use my own   
   runtime libraries; or trying to get programs to build using my own   
   compiler as a cross-compiler).   
      
      
   Though, I did more or less get my compiler to pretend to be GCC well   
   enough that for small programs, it is possible to trick "./configure"   
   scripts to use it as a cross compiler (doesn't scale very well, as apart   
   from some core POSIX libraries, most anything else is absent).   
      
   Where, for my own ISA, I am using BGBCC.   
      BGBCC is ~ 250 kLOC, and mostly compiles C;   
        Also compiles BGBScript, which sorta resembles ActionScript;   
        And, BGBScript2, which sorta resembles Java mixed with C#;   
          Albeit, unlike Java and C#, it uses manual and zone allocation.   
        Technically could be mixed with C, all using the same ABI;   
        Also an EC++ like subset of C++.   
          But, kinda moot as no "Modern C++" stuff has any hope of working.   
        But, for my current uses, C is dominant.   
      It is sorta wonky in that it does not use traditional object files.   
        It compiles into a stack-oriented bytecode and "links" from this.   
        The bytecode IR could be loosely compared with MSIL / CIL.   
        ASM code is preprocessed and forwarded as text blobs.   
      The backend then produces the final PE/COFF images.   
        Though, this mutated some as well:   
          Lacks MZ stub / header;   
          PE image is typically LZ4 compressed.   
            LZ4 compression makes the loading process faster.   
        Resource section was replaced with a WAD2 variant.   
          Made more sense to me than the original PE/COFF resource section.   
          Compiler also has a built-in format converter.   
            Say, to convert TGA or PNG into BMP (*1), ...   
      
   *1: General resource-section formats:   
      Graphics:   
        BMP, 4/8/16/24/32 bit.   
          Ye Olde standard BMP.   
          For 16 and 256 color, fixed palettes are used.   
        BMPA, 4/8 bit with a transparent color.   
          Basically standard, but with a transparent color.   
          Generally, the High-Intensity Magenta is transparent.   
            Or, #FF55FF (or, Color 13 in the 16-color palette)   
        BMP+CRAM: 2 bpp 256-color, image encoded as 8-bit CRAM.   
          Supports transparency in a limited form:   
            Only 1 non-transparent color per 4x4 block,   
            vs 2 colors for opaque blocks.   
        QOI: An image in the QOI format (lossless)   
        LCIF: Resembles a QOI/CRAM hybrid, lossy low/intermediate quality.   
          Though, BMP+CRAM is faster and has lower overhead.   
        UPIC: Resembles a Rice-coded JPEG   
          Optimized for a small low-memory-overhead decoder.   
          Lossy or Lossless, higher quality, but comparably slow.   
      Audio:   
        WAV, mostly PCM, A-Law, or ADPCM.   
      
      
   BGBCC originally started as a fork off of my BGBScript VM, which was   
   used as the main scripting language in my first 3D engine.   
      
   By the 2nd 3D engine, it had partly been replaced by a VM running my   
   (then) newer BGBScript2 language, with the engine written as a mix of C   
   and BGBScript2.   
      
   While I could technically use BGBScript2 in my TestKern OS, it is almost   
   entirely C, only really using BGBScript2 for some small test cases (it   
   is technically possible to use both BS and BS2 in kernel and bare-metal   
   contexts; and there is partial ISA level assistance for things like   
      
   [continued in next message]   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)