Tom.. wrote on 2022-04-25, 17:28:

Windows XP x86,AMD Athlon 64, Radeon 9800 Pro - Does not work , Shader Model 2.0 only..

Since the Geforce 210 driver is rather picky in GLSL shader syntax, It was useful for back-porting the shaders to older versions. I made a GLSL 130, 120 and 100 derivative. Attached here. They all run with the Geforce 210.

For 120 and 100 I had to remove the 3d.fsh smoothing-code for the edges of transparent textures. These sprites get a darker outline then intended, which can be seen on the water surface among other things.

So maybe one of these allows the Radeon 9800 to run Tomb1Main?

Windows XP x86,AMD Athlon 64, Radeon 9800 Pro - Shader Model 2.0 - DirectX 9.0

Windows XP x86,Pentium 4 3000 MHz,Geforce 7300GT - Shader Model 3.0 - DirectX 9.0c

Nothing has changed . These computers are too old, I also added a Pentium 4 test . Graphics card compatible with DX10 is the weakest card on which "Tomb1Main" will run 😉

Indeed. Thanks for trying again anyway. You obviously have a lot of computers for testing.

I updated the package on my website with just the earlier "130" to "330" modification of the shader files, and suggested the developer at Tomb1Main github to do the same.

What I read since, is that proper fallback from GLSL v330 to v130 cannot be achieved solely by changing the external shader files. Because the v130 absence of "layout(location = something)" must be handled in the source code with glBindAttribLocation.
But doing that won't give much benefit in itself, because to make this remake playable on older graphics cards, it needs a faster renderer as well. There are currently no volunteers for coding that.

Windows XP x86, AMD Athlon XP, Geforce 6600 GT - Shader Model 3.0 - DirectX 9.0c

I did one more test on the latest available 307.83 drivers for the Geforce 6/7 cards.
The program crashed immediately without an error message ..
Do you know if SDL 2 requires a processor with sse2 instructions?

Tom.. wrote on 2022-04-28, 10:20:

Do you know if SDL 2 requires a processor with sse2 instructions?

Simple question, but it took some effort to answer.

This is in SDL 2.0.14.0 CMakeLists.txt

1set_option(SSEMATH             "Allow GCC to use SSE floating point math" ${OPT_DEF_SSEMATH})
2set_option(MMX                 "Use MMX assembly routines" ${OPT_DEF_ASM})
3set_option(3DNOW               "Use 3Dnow! MMX assembly routines" ${OPT_DEF_ASM})
4set_option(SSE                 "Use SSE assembly routines" ${OPT_DEF_ASM})
5set_option(SSE2                "Use SSE2 assembly routines" ${OPT_DEF_SSEMATH})
6set_option(SSE3                "Use SSE3 assembly routines" ${OPT_DEF_SSEMATH})

Official SDL2.dll has lots of xmm instructions inside, but I cannot recognize if it is also SSE2 or SSE3 from assembly.
Tomb1Main.exe XP mod has no xmm instructions inside.
I added a newly compiled SDL2.dll to the Tomb1Main XPmod package, in the "No-MMX" folder. For building this one, all the above options were disabled. Also I verified it has no xmm instructions inside.

I've restored my XP image to my test desktop and am going through all the ports now and testing compatibility. Soon will be updating them in vogonsorg with last working versions for XP and then up, then back around to 9x.

When I did that I took the latest 368.81 drivers and replaced the Display.Driver folder with the one from the 355.98 drivers so now have a driver package with the working driver with scaling and the latest other drivers from 368.81.

Did some testing with some HDMI to displayport adapters with my 980ti on my 2560x1440 monitor to see if I could limit refresh rate with those.....well it worked but at 24hz 🤣. So RefreshLock it is if I want to use my 2560x1440 monitor. Currently using my 1920x1200 @60hz monitor for compat testing since I'm too lazy to put my 2560x1440 monitor into landscape mode and tilt it back.

Looks like nblood was affected as well by the eduke32 breakage so identified last working version for that.
nblood_win32_20211015-12587.zip
https://lerppu.net/wannabethesis/nblood/

Latest BuildGDX works fine on XP as long as you use a 32bit build of Java.

gerwin wrote on 2022-04-28, 20:31:

Simple question, but it took some effort to answer. […]
Show full quote

Tom.. wrote on 2022-04-28, 10:20:

Do you know if SDL 2 requires a processor with sse2 instructions?

Simple question, but it took some effort to answer.

This is in SDL 2.0.14.0 CMakeLists.txt

Copy code to clipboard

1set_option(SSEMATH             "Allow GCC to use SSE floating point math" ${OPT_DEF_SSEMATH})
2set_option(MMX                 "Use MMX assembly routines" ${OPT_DEF_ASM})
3set_option(3DNOW               "Use 3Dnow! MMX assembly routines" ${OPT_DEF_ASM})
4set_option(SSE                 "Use SSE assembly routines" ${OPT_DEF_ASM})
5set_option(SSE2                "Use SSE2 assembly routines" ${OPT_DEF_SSEMATH})
6set_option(SSE3                "Use SSE3 assembly routines" ${OPT_DEF_SSEMATH})

Official SDL2.dll has lots of xmm instructions inside, but I cannot recognize if it is also SSE2 or SSE3 from assembly.
Tomb1Main.exe XP mod has no xmm instructions inside.
I added a newly compiled SDL2.dll to the Tomb1Main XPmod package, in the "No-MMX" folder. For building this one, all the above options were disabled. Also I verified it has no xmm instructions inside.

Thanks for the compiled SDL2.dll , despite attempts Tomb1Main won't start on these old computers.. Thanks for your help

DosFreak wrote on 2022-04-29, 01:11:

I've restored my XP image to my test desktop and am going through all the ports now and testing compatibility. Soon will be upda […]
Show full quote

I've restored my XP image to my test desktop and am going through all the ports now and testing compatibility. Soon will be updating them in vogonsorg with last working versions for XP and then up, then back around to 9x.
....
Looks like nblood was affected as well by the eduke32 breakage so identified last working version for that.
Latest BuildGDX works fine on XP as long as you use a 32bit build of Java.

Thanks for the effort and the information.
Curious on how you will populate the vogonsorg github with builds. Is the emphasis on builds with github autotools, or local builds from whoever can supply them?
Would it be possible, for example, to fork that Stratagus, and change "cmake.toolset" from "v142" back to "v141_xp", then build it with the autotools?

Will go through and test compatibility for all the repos currently on vogonsorg for all windows os
Next open an issue and note last working build for each and attach build.
For each repo make sure repo is current and syncing.
For last working build create a release, if source repo had one then great, if not then create one.
If source repo creates builds then use their process, if not then create one.
If source cannot be compiled via github then use local build, if local build vm is all open source then upload somewhere for everyone.
If source cannot be compiled with open source OS and compiler then create guide to create os and compiler vm.
Once build process verified working and last known working build compiled then start working upward to identify where breakage occurred and or review commits for likely breakage, in most cases the compiler or compiler settings or hird party libraries will be the breakage.

I haven't looked at stratagus but yes should definitely be possible assuming github still allows a XP target for their environment, it did last I checked months ago. May run into issues though since last I checked alot of projects used msys for some idiotic reason instead of cross compiling from Linux. Also if using precompiled third party libraries then they usually are compiled with a compiler that requires posix so only XP and above are supported. So for less than xp and if unable to use github environment for less than XP then will need to use a local environment assuming no one wants to pay for hosting elsewhere heh

If anyone else wants in on this let me know, the compatibility testing itself takes quite some time and is arguably the most important.

I have no interest for controversial associations for vogonsorg so any people banned here then those projects won't be forked.

DosFreak wrote on 2022-04-30, 23:48:

I haven't looked at stratagus but yes should definitely be possible assuming github still allows a XP target for their environment, it did last I checked months ago.

From what I read regarding the Microsoft tools, (first summary from Wikipedia):
32-bit and 64-bit: Visual C++ 2015 (also known as Visual C++ 14.0) was released on July 20, 2015.
32-bit and 64-bit: Visual C++ 2017 (also known as Visual C++ 14.1) was released on March 7, 2017.
32-bit and 64-bit: Visual C++ 2019 (also known as Visual C++ 14.20) was released on April 2, 2019.
Strictly 64-bit: Visual C++ 2022 (also known as Visual C++ 14.30) was released on November 8, 2021.

VC2019 has the v141_xp toolset option. See https://stackoverflow.com/questions/58755564/ … toolset-v140-xp.
More about the v141_xp / v141 difference: https://stackoverflow.com/questions/67334007/ … th-v141-toolset.

In cmake in a github project it looks like this:
"cmake.generator": "Visual Studio 16 2019",
followed by one of these three, with my take on the results behind it:
"cmake.toolset": "v141_xp", = Works in Windows XP right away
"cmake.toolset": "v141", = Usually the same result as v141_xp, but always with NT6 requirement in the PE header, so a hexedit is worth a try.
"cmake.toolset": "v142", = Implements NT6 calls, for XP it is KernelEx wrappers or bust.

(If this was already clear to you, then just consider it a note for my own reference.)

See https://github.com/vogonsorg/prboom-plus/issues/2 for an example

I've created a v141 target for Prboom-plus which generated a working artifact that works fine on XP without any modification just in case something breaks with the official builds as far as the exe goes.

name: "Visual Studio 32-bit v141", os: windows-2019, build_type: "Release", extra_options: " […]
Show full quote

name: "Visual Studio 32-bit v141",
os: windows-2019,
build_type: "Release",
extra_options: "-A Win32 -T v141_xp",
package_name: "vs_win32 v141"

It's been awhile since I've had to use it but there is always EDITBIN which could be tried with the v141 target
EDITBIN from VS2005 C++ Command prompt "editbin /subsystem:windows,4.00 /osversion:4.0 filename"

Something else to keep in mind is that newer builds of the VS2019 redist broke XP support awhile back so you have to use an older version.

Well finally finished with the first QNAP that I converted to using ZFS. Took forever (forgot that using /Z with robocopy significantly slows down transfers). 68TB, now on to the next two which should go much faster. Data compression resulted in 4TB more of free space so that's nice.

File transfers are crazy, on my 10GB NIC download speed is 1000MB/s to my desktop and upload back to the QNAP is 700MB/s. 😁

For Vista this is the last working build for nblood....although getting the same issue on Windows 7 and 11.....
https://lerppu.net/wannabethesis/nblood/20220420-13109/

Receive the following with anything newer even using software

1.7768s ERR| Unable to set video mode: SDL_GL_CreateContext failed: Could not create GL context: The parameter is incorrect..

For Vista this is the last working build for eduke32 for Duke Nukem 3D and Ion Fury those without OpenGL 2.0
This build does not work with Shadow Warrior. use build 9607
https://dukeworld.duke4.net/eduke32/synthesis … 9651-a891732fd/

For Vista this is the last working build for eduke32 for those WITH OpenGL 2.0. JFC!
This also works with the 11-17-2021 Ion Fury and Shadow Warrior
https://dukeworld.duke4.net/eduke32/synthesis … 9782-661883a52/

So yeah one of the first projects would be to get XP to use build 9651 instead of 9631, next would be nixing the OpenGL 2.0 requirement and/or making it an option.
Also need to look into that SDL 2.0.5 patch for Windows 2000, get that patch ported to the lastest SDL version to get 9651 working on Windows 2000.
Next would be getting XP to be able to use 9710 so it can run the 11-17-2021 build of Ion Fury.
It looks like this build is the first working build for the 11-17-2021 build of Ion Fury https://dukeworld.duke4.net/eduke32/synthesis … 9710-43cd843e0/
Eduke32 should just get rid of "software" since ever since they switched software to requiring OpenGL it's just confusing.
Think that mess was made back in 2018 with http://dukeworld.duke4.net/eduke32/synthesis/20180612-6917/
For less than 2000 need to see what the latest build of eduke32 that compiles with SDL 1.2 and work from there. The last compiled build I have is eduke32_win32_20131012-4097 for XP, eduke32_win32_20100425-1623 for 2000 and then eduke32_src_20091015-1531.tar which eduke32 for 95 was created from.

or
just use BuildGDX for duke3d and shadow warrior

It looks like DevilutionX 1.4.0 requires Windows 7 now.

Looks like OpenMW 0.42.0 is the last working build for XP and Vista, 0.43.0 doesn't work but possibly somewhere in-between may.

Dark Mod 2.10 requires Windows 7.
Use 2.09 for Vista 64bit and 2.08 for Vista 32bit (might be stable)
2.07 for XP
2.06 for 2000 (BWC)

Use 2.06 if in doubt for all 32bit systems, have had issues using any newer versions. (Haven't played around with PAE or the like)

RedNukem Last working build for Vista
https://lerppu.net/wannabethesis/rednukem/202 … 20117-12734.zip
Last working build for XP
https://lerppu.net/wannabethesis/rednukem/20211015-12587/

So was checking out Vista 64 and decided to see if Ion Fury would run.
The build with 11-17-2021 grp does run but it has the same issue as later builds of eduke32, ran it through dependency walker and saw this: https://docs.microsoft.com/is-is/windows/win3 … readdescription
So guess later builds of eduke32 are for Windows 10/2016+ 🙄

This eduke32 build works for the current 11-17-2021 build of Ion Fury for Vista+ with >=OpenGL 2.0, sigh: eduke32_win32_20211112-9782-661883a52
Use this build for Vista with <OpenGL 2.0 with builds of Ion Fury older than 11-17-2021 eduke32_win32_20211006-9651-a891732fd
For XP use eduke32_win32_20211006-9631-cbb598f10

This is interesting for Windows 2000 compatiblity:

The following latest version of these quake ports work on 2000
FTEQW
Quakespasm
Tyrquake

The following latest version of these quake 2 ports work on 2000
FTEQW

The following of these quake 3 ports work on 2000
quake3-1.32e-20201031

The following latest version of these quake 3 ports work on 2000
FTEQW

The following latest version of these Hexen ports works on 2000
FTEQW

The following latest version of these Doom ports work on 2000 haven't tested 9x yet:
DelphiDoom
DoomXS
FPCDoom
zdaemon

DosFreak wrote on 2022-05-08, 13:10:

It looks like DevilutionX 1.4.0 requires Windows 7 now.

You are right, it appears the newly required discord integration dll adds most of the NT6 calls.
I build a DevilutionX v1.4.0 Windows XP compatible package yesterday. It is on my website. No discord integration in that one, I disabled the multiplayer/internet option as well.