AnotherGrunt

@Bedingungsl.Grundeinkommen : Although with old legacy ports in mind I believe. So far, there is not one thing blocking progress in old ports. Just out of curiosity, I've tested Sigil2 in GZDooom along Torr's soundtrack. Do not take me wrong, I don't want to sound ungrateful or anything (is good soundtrack), but my opinion is it doesn't fit. Midi soundtrack is just good and much better fitting. MP3 soundtrack should have been used for Quake or something. Next thing is something stronger in arsenal. At the beginning of E6M3 Super shotgun (or similarly powerful weapon) would be just handy. In MBF is possible to use -ssg switch and SSG.WAD. But to acquire SSG, one must cheat. And last question is if anyone knows what are original sky-boxes used in SIGIL2. I would love to fit in and maybe dither a little. Would be nice touch for DOS.

Thank you very much. This time, I've decided to buy WAD right away. As I'm not expecting "another Daikatana". Play-tested first level and it seems to work pretty fine. Only bug I've noticed is weird tiled Skybox. Only disappointment is, maps are even less optimized for DOS than last time. My usual setting of custom prepared DOSBox and fixed 26800 cycles and 486 CPU won't cut it. Is pure slideshow. Are there recommended settings to play this WAD? At what CPU speed (cpu cycles) are you playing? I don't need full 35fps experience, on the other side <10fps slide-by-slide isn't much amusing either. Or should I try to optimize BSP tree before playing? Anyway, Merry Christmas everyone.

Do not try me Dragofly. I've said I'm not doing it, not "it's not possible".

Great. I'm not porting this thing to DOS. No way. I'm simply NOT…

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