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…

Hello guys, could you please recommend some IWAD (not PWAD) which would fit into one regular 3½″floppy disk? I.e. file size limit 1440kB or less. My initial thoughts were how I'm gonna take Shareware DOOM 1 extract map or two in SLADE, copy PLAYPAL, needed textures and sounds and it's going to work and bam. Just textures little over 2MB. It is not so easy. It is even possible to fit WAD into floppy?

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.

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.

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.

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?

Which is exactly what I'm doing, but unfortunately MBF2.04 (or EE) isn't so fast. I had to use it, so I noticed a missing HUD. FDOOM these days is just way to go ;-) Don't forget these are patches and they have to be drawn and redrawn every frame. This is why HUD has a background. It is irrelevant in MBF2.04 because it isn't targeted at low-spec PC but I feel FDOOM should be better. This is why I suggested one patch. Of course, drawing keys/ammo or whatever would be better but if so again somehow, I don't know…minimalistic. And fast. Text is better because it is just printf() as fast as it gets. It's your port, so the choice is yours. Just keep in mind the name: FastDOOM.

Not in FDOOM. And yes, RUDE shows how minimalistic HUD is a very good concept. Shame there is no DOS build.

I see V_DrawPatchDirect() defined in v_video.c (BTW: Can I borrow it?). It would be sin not to use it. Use it like the floppy icon. Just one patch, updated as needed.

So I have a small feature request/bug report. There is a bug in FDOOM (at least in VGA/VESA versions): No HUD in automap mode. Usually, I play DOOM in fullscreen mode and highest windows size (aka without HUD) and most source ports have a way of letting player know how much health and ammo he has. In vanilla 1.9 I use fast double-tap TAB key just to look at statistics but in FDOOM there is no other way than just make player window smaller. Would it be possible to just draw player's avatar in full windows size (to keep it fast), something like this?: And then just have statistics bound on key and write them on screen while key pressed. I personally like minimalism and fast gameplay so I think just having DOOM-face to roughly know how much HP is left is just enough and it shall be fast to render.

This is why I personally "like" YouTube so much. No support for any other pixel format than yuv420p, not good support for small resolutions, no choice of video codec but: Ads Copyright Age restrictions Licenses Monetization Simply BS Why there are no technical settings for YouTube. Not relevant for its users?