I'll check about that DJGPP stuff, but I'm only doing what Q1's driver is doing.

Anyways, pushed the slightly tweaked code and added your third person code (untested).

To use TGA skyboxes set sw_load_tga_skybox 1. It's disabled by default because sierra.bsp's TGA skybox was immediately exiting WIN32. Any other map I tested worked fine. Obviously there's some loss of quality in this downscaling which can be seen by loading base1, the dithering is a bit off, but otherwise it's better than having no decent PCX file for the custom maps on weapons mod server.

To see some special debug output about TGA loading attempts use developer 32 to see graphics renderer developer printfs.

I uploaded new binaries with your code from now on all new builds will always be at this URL: https://bitbucket.org/neozeed/q2dos/downloads … S_EXE_LATEST.7Z

Thanks for finishing the tga patch. I'll test it out, and take a look at the djgpp near_pointer issue. I'll try to update the 1st post of the thread with my other changes.

I fixed the skybox crash. In software renderer, somewhere, there is a limit of 256x256. There's a few maps out there that must have been meant for new engines with high res.

I'm having trouble uploading to bitbucket right now.

That's great work! Also, that information is invaluable about the (current) practical limits of this renderer. If people want a map that is an outlier in terms of compatibility, then they can always convert it. I read tutorials to do this and they seem straightforward. Perhaps leilei can offer suggestions on the best methods to convert the typical problematic maps for running in the software renderer.

Perhaps the bitbucket issue is global for the hosting service. I hope they fix it soon. There may be some way to export your content from bitbucket, if you haven't done this already, and see if there are import facilities available in other git or git-like hosting services.

I went ahead and added nearptr_disable in sys_quit and sys_error as well. I didn't see any thing funny when quitting the program so I guess it's OK. I get a feeling though that CWSDPMI probably already does this.

That's good work! Also, you may bookmark this page if you didn't already test the important bits of this "cookbook" code: http://www.inversereality.org/tutorials/graph … omodesvesa.html

fixed my bitbucket issue and uploaded latest code again. I don't know if we need TGA loading for anything else right now except skyboxes are the biggest issue. I got tired of joining custom servers and having hall of mirrors because TGA only skybox or you get a really bad PCX conversion where they didnt bother adding the palette.

The only real issue right now with some image stuff that annoys me is whale's wod server has some shitty WAL files that the transparency is OK in OpenGL but not in software and I don't think I'm using GL_Upload8 properly to convert it. If I redo the files in GIMP they work ok on opengl and software so I guess he screwed the palette up. I said something to him about it and he basically laughed at me for using DOS and Software mode and said this is 2015, 🤣. I told him OK and you're playing a game from 1998 so I fail to see the difference here.

Anyways,
Thanks for finding the tutorial.

Well done! Honestly, I don't know much about the (quake2) image formats, so it's a hurdle to test them, so much for debugging them.

I had also "scoured" the q2max code base for all changes not in q2dos. I mainly tried the particle enhancements, but they are reliant on external image files and opengl friendly parameters (much like the transparency is presumed targeted to opengl, at least during their testing of the maps/models). They particularly enhanced their code for dday mod and some star wars mod, at least the abbreviations suggested that (and some of the names in the source code). It doesn't seem worthwhile and probably slows the gameplay down to 1fps, given the renderer doesn't crash in the process (seen this in action quake 2 maps with their "enhancements"; they report this too and to turn it off given any issues - which there are).

I think if there aren't that many WAL files, then converting them in GIMP seems like the better solution.

Oh, found the functions for the exit routine (in addition to disable near_pointer), given the 2nd call is relevant:
__dpmi_free_physical_address_mapping(&mapping);
__djgpp_nearptr_disable();

It's here: http://www.delorie.com/djgpp/doc/ug/graphics/vbe20.html

Just so we're clear. I am not adding any kind of graphical enhancements like badass particles, shadows, coloured dlights, and high res shit. The only reason I'm doing the TGA stuff is because of the custom map problems. I want to be able to play the game looking stock. It probably would require a decently fast computer.

Also, why is everyone concerned about this nearptr_disable shit all of the sudden? Are you talking to Rayer? I still believe his problem is that shitty UIDE and FreeDOS combo. I only guarantee this code to work properly in MS-DOS 7.10.

I've said it like 10 times now that Quake 1 doesn't even do this.

Sorry to sound nasty here, but Rayer has really been on my ass about this like I know what the issue is. I can't test his hardware. He's convinced all his problems are from this. I think it's something we're missing in the libau code that's not allowing his audigy 2 to work properly in certain situations. From what I understand as soon as the memory is accessed for a nearptr like dma buffer write for the soudn card or updating the video memory pointer then nearptr becomse disabled on its own with unix sbrk

Entirely agree on the particles! I tried it just to see if it was very simple to do and out of curiosity.

I don't know Rayer. I did see the discussions at bitbucket and had been always curious about vesa initialization. Your way is considered ideal by the djgpp faq and by ID themselves. I don't know how Q2 would affect his UIDE anyways, especially since Dos isn't a multitasking OS.

UIDE.SYS is a driver for FreeDOS (but can be used with MS-DOS) for hard drive cacheing. Like smartdrv, but with way higher limits.

I've used UIDE.SYS in an custom dosbox a bit. I recall there is a parameter for cache size, but it sounds more like he wants that libau code fixed on his schedule. :)

The biggest problem for me to fix it is that I don't own the hardware. I'm a Gravis UltraSound man for life 😜. I also don't trust FreeDOS for a project this complex. He may have issues there too, but whatever.

Sarah@PCem had that issue. If they can't make a bug report in a civil tone, then they don't have to post in your forum. :)

FWIW Engoo's new particle system is literally hijacking Quake's elaborate sprite drawing code (which is very stripped in Q2's renderer) and drawing blended sprites. There's also color modulation on them for colored additive particles like your typical GL featurecreep engine. Relies on one external .spr for it to work. It ignores the sprite's orientation parameter and forces it accordingly to particle for stuff like fake decals and rotating smoke.

Not that i'm suggesting that mind you but it's what I had to do for 'badass' particles. I did it because I could, just to clear my dreams 😜
it COULD be adapted to faithfulish "GL" particles with that 8x8 particle texture in the GL versions with some kernel dithering to give it the smooth edge appearance. Engoo has a "GLQuake" preset that imitates/mocks GLQuake's shortcomings and apperance in software for the careless accidental fullbright-using filter-envying 'this mod requires glquake' cases out there.

leileilol wrote:

<snip>

Don't get me wrong, I respect all your graphics work that you have done for engoo and other adventures but it's not my realm of coding and it's also something I'm not interested in introducing to my ports.

Though I do admire your quest for the perfect voodoo filtering emulation 😀

Q2Max mainly relied on it for dday. There is the concern that additions like that will, even if they don't cause engine problems, negate the advantage of the tight association between assembly and C code. AQ2 mod has some effects, and they sometimes lead to overflow issues which the author notes - it must occur in the gl mode, too! However, it may be worthwhile to code in an effect or two which doesn't rely on an external image, or so I would think.

That's the other issue and I'm sure leileilol has ran into the same problems. If you start fooling with the software renderer it really pays to know ASM which I know nothing about. On modern computers it's not such a big deal, but for the target machines I'm aiming for (about the same target hardware as original Quake 2) it can become a huge setback.