TempleOS General

  • 🐕 I am attempting to get the site runnning as fast as possible. If you are experiencing slow page load times, please report it.
I decided to get an early start this year and make a second attempt at writing a 3D software renderer for TempleOS. I've gotten further than before including:
-Per-Vertex Normal Blending
-Skeletal Animation
-Multi-Bone Influence
-Per-pixel dynamic point light fragment shader using a monochromatic palette without dither to optimize for VGA transfer (TempleOS only updates dirty chunks)
-Near plane clipping
-Backface culling



Though I confess I didn't write this in HolyC. It's C program that I build with GCC into a freestanding ELF shared object. I can load an execute this ELF on TempleOS using a ELF loader/linker written in HolyC along with a HolyC engine harness. This gives me access to single precision floats and SIMD instructions, plus the gains from having an optimizing compiler. I stole code from musl to provide the fundamentals and math functions. HandmadeMath for SIMD math. stb_sprintf for string formatting. Dynamically linked to SDL so the ELF linker can patch in TempleOS functions. If it wasn't for a handful of #ifdef's you can run literally the exact same .so file on TempleOS and Linux, natively.

Shout out to Alec Murphy for creating the ELF/SDL proof of concept.
 
Last edited:
  • Winner
Reactions: Lieutenant Rasczak, AnitaSarsleezian, Bruno Powroznik and 5 others
Cavalier Cipolla said:
Well, the thing is, If I am not mistaken, much like modern CPUs have different internal instruction sets behind an x86-64 frontend, GPUs have their own instruction sets that vary from architecture to architecture. Nevertheless, hardware acceleration isn't completely off the table. You could just use VESA 2.0 features which should be supported by any GPU that's at least from around 1999. Even EGA has some basic hardware scrolling support, enough so that you don't need to deal with as much bit shifting mess as you'd normally do on CGA or Tandy. It's only with sprites that you'll need to do that. Of course, if you don't want to stick with NES or Master System tier sprite counts and sizes and go Neo Geo mode but with much less colors, there won't be much of an improvement. But something like the first two Contra games should work fine, despite what the legit DOS port might suggest. VESA 2.0 does have proper scrolling support according to Wokipedia, where you change the screen viewport, as well as hardware blitting, so you can go Neo Geo or even Super Scaler mode if you wish to do so. Did God say anything about using VESA 2.0 features directly without the OS assistance?
Click to expand...
If the game is confined to 2D rendering, hardware acceleration does not matter at all.

For the record, RuneScape 2 (as it was in 2004) did software-based 3D rendering because that was a limitation of Java portability at the time.

If you want to do efficient 3D math on a coprocessor of any kind, there is no generic way to do that. There never was a generic way to do that. Microsoft wanted the driver-addicted systems programming world we live in today, and then ATI and Nvidia realised they had the same incentive MS did to force users to depend on binary blobs made by theirs truly.

Vulkan is a testament to how far along we have come in undoing that disaster, and even then we all know it is captured entirely within the existing paradigm of driver vendors that binds us at a binary level to begin with.
 
So like I've implementation approximately a million things into my crossplatform TempleOS-first 3D game engine. Next on the list is implementing shadow mapping so I can properly light the models based on the light positions used to bake the lightmaps for the level. Obviously super WIP, not even the color palette is setup right. But I wanted to record TempleOS running at 60FPS without color tearing.


Popular brogrammer Primeagen did a code review on Slendi's HolyC lexer
 
  • Like
  • Informative
  • Winner
Reactions: AnitaSarsleezian, Bruno Powroznik, Lord Xenu and 2 others
Holy fucking shit, the farms are back online! Finally!

Libertarian Wario said:
and then ATI and Nvidia realised they had the same incentive MS did to force users to depend on binary blobs made by theirs truly.
Click to expand...
Actually, that wasn't much of a problem. Remember, back in the DOS era, most games only supported up to VGA 320x200 resolutions, even when graphics cards capable of 16 bit color 640x480 were on the market. Thing is, you needed to talk DIRECTLY to the graphics card. If you wanted those fancy modes, before UniVBE, you needed to have different code for each different graphics card. And god knows if it would work on newer graphics cards.

Those binary blobs had a reason to exist. As otherwise you'd be on the mercy of the current universal VESA standard. Tomb Raider only worked with the Voodoo 1 (or maybe the Voodoo2 as well, not 100% sure) because it didn't even use Glide, but directly interacted with the registers. But it did run well on a 486. And note that OpenGL also existed, and exists today, so it wasn't even that they depended on Microsoft as much.

Now, with programmable shaders, it's even more problematic. You'd need to remain stuck with one instruction set and pray that it will be feasible for the future. And then the fixed function
Back in the 90s, PCs (in a broader sense, not just IBM compatibles) had various instruction sets. You had x86, 68k and PowerPC in the mainstream, as well as MIPS and ARM in the more niche sections. All coexisted with one another. Which one of those are still used today?

Not to mention, those binary blobs were a godsend for backwards compatibility. Unreal Tournament '99 worked perfectly on my old Windows 7 64 bit PC. I am fairly confident even Windows 10 would run it just fine. Not to mention, it also reduces development time. Today the development time for games is in years. If devs had to tailor the code for each graphics card instruction set and not only make some broadly targeting optimizations for certain architectures, dev times would be double digit years.

But indeed, Vulkan is a very good thing to come by, combining best of both worlds. And as expected, id software is one of the dev studios that probably embraced it the most.
 
Cavalier Cipolla said:
Remember, back in the DOS era, most games only supported up to VGA 320x200 resolutions, even when graphics cards capable of 16 bit color 640x480 were on the market.
Click to expand...
You could do 640x480x4 without anything extra, same as 320x200x8 - they were both part of IBM's VGA standard. The reason a lot of games ran 320x200x8 is for the 256 onscreen colors, and speed gains from having less than a quarter of the pixels of the full 640x480.
 
Gargamel said:
You could do 640x480x4 without anything extra, same as 320x200x8 - they were both part of IBM's VGA standard. The reason a lot of games ran 320x200x8 is for the 256 onscreen colors, and speed gains from having less than a quarter of the pixels of the full 640x480.
Click to expand...
I wasn't talking about the 16 color 640x480 mode. I was talking about the 16 bpp (65536 color) mode at 640x480.
 
You must log in or register to reply here.
Back