AnotherGrunt

Oh, so it is. It make sense. Well, if there is a reason to praise John Carmack, here is one. All engines he ever wrote are long time open-source (as far as possible, I guess). It would be really nice to have native 64-bit binaries compiled for release:

Guys what? Unreal engine hasn't been open-sourced? I've seen somewhere (years back) shared binaries for UT99 with all debugging symbols embedded in so I lived in illusion, Unreal engine had to be open-source. And I was wrong all along?

Thanks a lot. Actually, motivated by this accomplishment I wondered, would be still possible to build a little newer version of EE in DOS? So a little more recent version (3.37.00 'Sekhmet' -- 01/01/10): So of course, it crashes on linker and tons of unresolved/undefined references. But dir djobj/*.o is full of DOS-executable object files. Shame the DJGPP version has been abandoned in course of development. I believe it would work just perfectly fine.

@viti95 Well, as I see it, it is intentional. Red and Green bits are the most important colors. So my wild guess is first bitplane (Plane 0) is more important than the second bitplane. Make update as 2-pass write function. In first pass update "Plane 0" bitplane and then "Plane 1" and only even-numbered scanlines, return from ATI640_DrawBackbuffer(), let routine R_RenderView() update backbuffer and then the same thing for odd-numbered scanlines. If lucky you'll be able to catch CRT ray as is updating CRT screen and color artifacting won't be crazy. Happy computing, COMMODORE ;-)

This part is the culprit. It simply cannot be fast. Isn't there some ASM example of how to write into ATI's VRAM?

@Maes It probably isn't ISA bus speed itself but how transfer instructions are structured. Look at this. Is it really done by 8-bit ISA transfer?

Sorry, but I don't own D3 - Full version. Just demo. But as I don't like D3 gameplay very much anyway, for my purposes it is just enough. On the other hand: DarkMod is Doom3 Mod and it works in the same engine (idTech4). Surprisingly, as DarkMod looks far less complex, it's just that more demanding. To get (sometimes) a slideshow, settings have to be reduced almost to DOS game level. But it looks interesting at least. Doom3 is much better optimized and uses engine features (dynamic lighting and full-color range) little better. Recommended on low resolution (512x384/288) and NN filter.

https://en.wikipedia.org/wiki/List_of_most-disliked_YouTube_videos Hmm, I smell Justin Bieber involved ;-)

Well, There is not much difference between playing it in r_mode 1 on GPU and CPU. On my PC only difference is CPU fan constantly throttling.

TL;DR version: Just start any Doom3 port in Linux with LIBGL_ALWAYS_SOFTWARE=true variable, crank down the resolution, and other parameters and it should work. As you may know, DOOM3 or any other idSoft game starting from idTech3 onwards never ever used software renderer (CPU). It always relied on GPU to render the game. DOOM3 especially heavily relies on the graphic card because GPU shaders are used for rendering (at least then) groundbreaking game graphics (Shadow volumes, unified lighting model, blending and some in-shader executed special effects). If you didn't owned a reasonable enough graphic card back in the day, you were done. Just as I was. For this reason, I haven't been interested in DOOM3 very much. But lately, for some weird reason I've ended up testing software rasterizers in GZDoom (discussed in a different thread here). And guess what… As I was already there, I had to try it. It is possible to load DOOM3 without an operational GPU? Well, yes! Sorta. In GNU/Linux, OpenGL (and Vulkan and other graphics API) is implemented in library called Mesa3D. And alongside HW device drivers, there are three software driver implementations: swrast/softpipe –⁠ the legacy Mesa rasterizer and "a Gallium reference driver" both using just CPU. Probably slow but they are there. llvmpipe –⁠ "a software rasterizer that uses LLVM to do runtime code generation". Just softpipe but translated to x86/x86-64 machine code. Very fast, multithreaded, and able to use SIMD Extensions. OpenSWR –⁠ "a high performance, highly scalable software renderer targeted towards visualization workloads". Surprisingly even better than LLVMpipe, but if you have enough cores/CPUs. I think it's clear now, how to play any OpenGL-designed game using a software rasterizer. Simply start it using any Galium software driver. llvmpipe preferably. Either as statically linked library (libGL.so) or systemwide library but with llvmpipe forced by environment variable. I'm using dhewm3, so LIBGL_ALWAYS_SOFTWARE=true ./dhewm3 it is. That's all. Should work out-of-box. Even in 4K resolution, AA on and Ultra-Details as shader-effects as Gallium has pretty complete OpenGL implementation in software rasterizer. And probably like one frame per second, maybe two if lucky. Just idTech4 engine renderer itself uses two parts, frontend and backend. Ideally, both as separate threads each on their own core sending GL commands to GPU where results are accumulated via additive blending¹. So if you want to try it without GPU, I recommend something like modern Intel i5 with two or four cores or relative equivalent. No less. And even so on the default setting, it will propably run like slideshow more than a game. Recommended reading: Mesa Performance Tips. And few performance tips of my own: Turn off anti-aliasing, multisampling and anisotropic filtering (r_multiSamples 0, image_anisotropy 1) right from the beginning. No texture filtering. image_filter = GL_NEAREST. Or GL_NEAREST_MIPMAP_LINEAR. Big performance boost but with small resolution, it is like DOOM2 vanilla without 8-bit palette. And fonts are not adjusted for small resolution, so good luck with Cuneiform-like font decryption. Reasonable resolution. 800x600 is good, 640x480 is better. Fullscreen or windowed. It is even possible to switch it to 320x240. Not in the setting menu, but by cvar r_mode 1. And I recommend at least trying GL_NEAREST and 320x240 for fun sake. It's like DOOM2 but with DOOM3 visuals and guns. Crispy DOOM3. 320x240 is good on my mobile Intel i5 even with the best texture resolution, bump mapping and height mapping on. 640x480 is better without shadows. Surprisingly higher resolution isn't much visual gain but definitely a burden on CPU. No (shader) special effects as there are no dedicated GPU shaders for them. No texture compression and preCaching necessary as textures are already in memory and transfers should be fast. 16-bit color depth is better than 24-bit color depth, but I have suspicion X11 system-wide depth is irrelevant for internal color depth which is always RGB + Alpha. And MESA_NO_DITHER has no effect on dithering as this variable has been removed a few years back. So no idea here. No need to lower texture resolution (High details are good) and there is no need to disable texture-related operations (bump mapping) as they gain little performance (MESA doesn't have dedicated VRAM). But if you want totally potato mode, it is possible. And little more advanced performance tips: export MESA_BACK_BUFFER = ximage –⁠ not completely sure but it might be necessary to enable rendering into XImages in order to XShm extension to work. Not sure. export GALLIUM_DRIVER=swr –⁠ if you want to try OpenSWR. Should be better if you really have something like AMD Ryzen Threadripper. export MESA_GLX_DEPTH_BITS = 16 –⁠ it is possible to set bit depth for the depth buffer. Lower values shall result in faster processing but possibly visible z-fighting. in file neo/renderer/tr_backend.cpp is routine called RB_SetDefaultGLState() responsible for OpenGL state initialization. Here we can set global GLStates: qglDisable( GL_DITHER ); //as recommended by Mesa Performance tips but at least I'm not able to spot any difference. It still looks dithered. Not sure why. qglDisable( GL_MULTISAMPLE ); qglShadeModel( GL_FLAT ); // model shading is for someone with GPU power not for us ;-) qglPolygonMode (GL_FRONT_AND_BACK, GL_FILL); //not sure if only front-face culling isn't faster. here we can comment qglEnable( GL_BLEND ); to completely disable blending. It is really fast then. But as fonts are implemented in alpha channel it isn't very useful. But for ultimate potato mode, here it is. If you have any other performance tips, please don't forget to share them here. All attached pictures are results of the Mesa3D library.

My opinion: There is absolutely no need to show any number at all. They just confuse user/player anyway. At least I can see how much HP I have in fullscreen. Thank you @viti95

Holy Guacamole. Best HUD I've ever seen. It is released or it will be released? No, no. Health (numerical value) isn't important and remaining ammo as well. There is no graphical representation for armor so I guess this value is important.

Both are pretty capable to run in FullHD. Vanilla maps (polygon count under 256) run very smoothly (>35fps). As long as no filtering, aliasing, or special effects are used. 320x200 is for VGA/VESA. Even DOOM3 is capable to run in 640x480 pretty good. And I haven't tried 16-bit depth yet. It's a software render! Not touching GPU at all. Old software render (8-bit) - good old DOOM engine same as in Vanilla Doom. Affine texturing with mouselook but it's the fastest. TrueColor Software render - from QZDoom still affine textured but with 16-bit or 24-bit color depth and possible texture filtering. Still very fast, at least on modern PC. Softpoly - Perspective correct texturing. It's more like Quake engine. I guess it requires FPU to do calculations. OpenGL, Vulkan - all magic done in GPU. Well… I suppose some games are better with at least (bi)linear texture filtering and maybe little antialiasing. Hey, but for 2-core mobile Intel, all done in CPU it is good enough.

Yup. As predicted. Tested just now in Debian (no native GZDoom for Debian? Shame). Surprisingly fast with OpenGL ES, full-screen resolution (1366x768) and 32-bit depth but: No texture filtering. Not even antialiasing. It's usable only for small maps. As fill-rate grows llvmpipe gets totally clogged and result is jerky. Then is softpoly more useful. Of course, both are miles away from DOOM software renderer (affine texturing). Full OpenGL is just a slideshow. But yeah, it works. My opinion is, there is still place for Softpoly render. Just fix transparency and it will be as good as any software rasterizer. Right now I'm interested how good could DOOM3 be done with a software rasterizer. ;-) Well, it's Windows. No wonder.

Just to add something. Linux: Mesa's LLVMpipe - tested on Quake and Build engine games and on modern multi-core works pretty fine. No reason why it shouldn't work with GZDoom. Windows: WARP - not tested by me, but it's there. How much is Softpoly faster in comparison?