Page 1 of 1
SWP source code question "For programmers who know Build/SWP/JFSW well"
#1 Posted 07 August 2016 - 07:51 AM
Hi All
I had previously asked about SWP in the SW HRP thread, but do not want to clutter that up with non-HRP questions.
Working my way through SWP source code as I wanted to have a go at building it myself and started with current version from Hendricks266's port as that's probably the most up to date. Fixed many warnings and a couple of bugs but still testing.
I am methodically fixing warnings to get it to compile cleanly with the latest MinGW GCC but I have run into a roadblock. The palette entry type has the usual RGB values, but also a mysterious member 'f' where the alpha might normally be. Its only use seems to be "if negative, put 255 in tile data". However, the palette entry data is all unsigned, so the comparison always fails. Should this really read if (col->f &0x80) instead of if (col->f <0)? Or is there something more subtle going on? I have been programming for over 30 years and have contributed code to ZDoom in the past, but know little about the BUILD engine.
Any help would be appreciated, thanks!
I had previously asked about SWP in the SW HRP thread, but do not want to clutter that up with non-HRP questions.
Working my way through SWP source code as I wanted to have a go at building it myself and started with current version from Hendricks266's port as that's probably the most up to date. Fixed many warnings and a couple of bugs but still testing.
I am methodically fixing warnings to get it to compile cleanly with the latest MinGW GCC but I have run into a roadblock. The palette entry type has the usual RGB values, but also a mysterious member 'f' where the alpha might normally be. Its only use seems to be "if negative, put 255 in tile data". However, the palette entry data is all unsigned, so the comparison always fails. Should this really read if (col->f &0x80) instead of if (col->f <0)? Or is there something more subtle going on? I have been programming for over 30 years and have contributed code to ZDoom in the past, but know little about the BUILD engine.
Any help would be appreciated, thanks!
#2 Posted 07 August 2016 - 09:39 AM
Is that line in the engine or in the game? If the engine, compare with JFBuild or EDuke32. I can't think of what purpose that if statement can serve at all.
#3 Posted 07 August 2016 - 10:39 AM
Hendricks266, on 07 August 2016 - 09:39 AM, said:
Is that line in the engine or in the game? If the engine, compare with JFBuild or EDuke32. I can't think of what purpose that if statement can serve at all.
Thanks. It's in the engine, in gamep.h written by Ben for SWP and it seems to be reserved for WMF pallete entry flags defined by Microsoft in Win32. However no value defined by them has the MSB set or in any way could be said to be negative.
I shall just have to try and see what happens if I write it as "&0x80" instead of "<0" and see what breaks or suddenly works properly. Yuck
Thanks again
#4 Posted 07 August 2016 - 11:38 AM
It could be that it means "if (col->f >= 128), use the transparent color" == "if alpha >= 50%". I don't know when that circumstance would arise. Is this code connected to the supplemental ART tiles that are included in the exe (the status bars)?
#5 Posted 07 August 2016 - 12:07 PM
Hendricks266, on 07 August 2016 - 11:38 AM, said:
It could be that it means "if (col->f >= 128), use the transparent color" == "if alpha >= 50%". I don't know when that circumstance would arise. Is this code connected to the supplemental ART tiles that are included in the exe (the status bars)?
Yes it's when loading the ALT HUD, plus alt UZI & alt riot ammo. It certainly seems to be that way only presumably the palette flag (f) was int or signed char at some point, hence testing for < 0 as that's another way of doing & 0x80 (i.e., >= 128u), but only works if palette flags is signed. However, if the code is left as it is, the compiled .EXE behaves like the last Ben Smit SWP. Making the comparison work as if signed <0 compare leaves most of the ALT HUD blank (very minimal, just the numbers) and crashes the display driver, presumably because the transparency is an issue somewhere.
So without knowing what Ben intended there I will leave well alone and just disable that comparison. The ALT HUD looks nice enough as it is though takes up some screen space. Maybe it was experimental code for what eventually became the GZDoom style ALT HUD (called "modern" in SWP).
I don't know how much time you have to spend on SWP at the moment, but you'd be welcome to this code when finished. While I enjoy cleaning up code and fixing minor bugs I don't know enough about the BUILD engine to do any more than that. But saving and loading games seems to work at the moment and I seem to recall people complaining that was buggy so maybe this is worth something.
EDIT: Even wierder - making the comparison (col->f > 127) does the same thing with the display but doesn't crash anything. The resulting very minimal ALT HUD gets rid of the borders, backgrounds and symbols, leaving just numbers such as shuriken left and so on, but it works and looks reasonable in-game but text-only. Whether this is what was intended is anybody's guess, though
This post has been edited by Martin Howe: 07 August 2016 - 12:20 PM
#6 Posted 07 August 2016 - 12:10 PM
I would certainly welcome your contributions despite my rapidly fading interest in maintaining SWP. When you're ready, try making a pull request on GitHub.
#7 Posted 07 August 2016 - 12:33 PM
Hendricks266, on 07 August 2016 - 12:10 PM, said:
I would certainly welcome your contributions despite my rapidly fading interest in maintaining SWP. When you're ready, try making a pull request on GitHub.
Sure - it'd be nice to have this maintained as not having a modern SWP is a real bummer and I understand you likely won't have time to take your EDuke32 SWP port any further.
I'll do that Git thing when I've had a chance to finish this and fully test it. Of course as I'm more used to SVN maybe I'd better fire up Google and find out exactly what a pull request is and how to make one - I see it on ZDoom forums all the time LOL
#8 Posted 07 August 2016 - 01:12 PM
Make a new port for SW, bug free.
Just a port, don't add extra fancy shit.
Port.
Bug free.
Maybe improved multiplayer.
Just a port, don't add extra fancy shit.
Port.
Bug free.
Maybe improved multiplayer.
This post has been edited by Robman: 07 August 2016 - 01:14 PM
#9 Posted 07 August 2016 - 03:46 PM
I don't remember. What were some of the major or minor bugs with SWP? I used it lot and didn't notice anything. But then I'm not a rabid fan that knows the game inside and out.
#10 Posted 07 August 2016 - 10:17 PM
SWP hadn't evolved much past JFSW. EDuke32 has done all kinds of things that I can only dream of in SW, like not broken sound code, digital music, and a video renderer that can automatically make skyboxes which look much nicer when looking straight up/down.
#11 Posted 07 August 2016 - 10:54 PM
Honestly, I would rather prefer if SW gets integrated into EDuke32 and everyone would use that instead of using SWP.
#12 Posted 07 August 2016 - 11:50 PM
FistMarine, on 07 August 2016 - 10:54 PM, said:
Honestly, I would rather prefer if SW gets integrated into EDuke32 and everyone would use that instead of using SWP.
So would I but Hendricks266 right now seems the only person who might have the expertise to do so and he seems to have enough on his plate. TX no doubt is too busy with EDuke32
So a less buggy SWP is about all we can hope for.
#13 Posted 08 August 2016 - 01:06 AM
Here's the program as it currently stands: executable source
If you're using a very fussy web browser (e.g., Google Chrome) you may need to confirm the download.
There is no new functionality but it should be less buggy (though I do know of one or two to do with when music plays).
I have had the occasional savegame load crash but nowhere near the "it always does that" that some people have been reporting.
It just needs testing before submitting it to H266's repository in a pull request and I'd rather not do that until I'm sure I haven't put any new bugs in!
For the programmers among you, the (col->f > 127) fix is redacted because it was probably not intended - the ALT HUD in the HRP textures looks like the original (non-minimalist) version SWP displayed in non-HRP mode when the "use 255" wasn't being acted on.
Again for the programmers among you, a diff (spoilered for size):
If you're using a very fussy web browser (e.g., Google Chrome) you may need to confirm the download.
There is no new functionality but it should be less buggy (though I do know of one or two to do with when music plays).
I have had the occasional savegame load crash but nowhere near the "it always does that" that some people have been reporting.
It just needs testing before submitting it to H266's repository in a pull request and I'd rather not do that until I'm sure I haven't put any new bugs in!
For the programmers among you, the (col->f > 127) fix is redacted because it was probably not intended - the ALT HUD in the HRP textures looks like the original (non-minimalist) version SWP displayed in non-HRP mode when the "use 255" wasn't being acted on.
Again for the programmers among you, a diff (spoilered for size):
Spoiler
#14 Posted 02 September 2016 - 09:32 AM
Martin Howe, on 08 August 2016 - 01:06 AM, said:
Here's the program as it currently stands: executable source
If you're using a very fussy web browser (e.g., Google Chrome) you may need to confirm the download.
There is no new functionality but it should be less buggy (though I do know of one or two to do with when music plays).
I have had the occasional savegame load crash but nowhere near the "it always does that" that some people have been reporting.
It just needs testing before submitting it to H266's repository in a pull request and I'd rather not do that until I'm sure I haven't put any new bugs in!
If you're using a very fussy web browser (e.g., Google Chrome) you may need to confirm the download.
There is no new functionality but it should be less buggy (though I do know of one or two to do with when music plays).
I have had the occasional savegame load crash but nowhere near the "it always does that" that some people have been reporting.
It just needs testing before submitting it to H266's repository in a pull request and I'd rather not do that until I'm sure I haven't put any new bugs in!
A little bit of background before I get started - I originally tried running Hendricks's 4.3.3 build and ran into an issue, noted here: http://swforum05.pro...s.com/post/1086
Yes, I was (and still am) running Vista. Yes, I'm aware it isn't great, though hopefully it isn't what turns out to be the impedance on possibly squashing any bugs.
That outta the way, I've downloaded and ran your executable with the Sw.GRP yoinked from the free Steam download of the old Shadow Warrior and... it works! Well, kinda.
I can get it up and running past the launcher without problems (or rather the same problem I was running into with the last build Hendricks had done) so that's a definite plus.
But something new comes up when playing after what seems like a random amount of time (I've not been clocking it and... as far as I can tell you don't have anything outputting crash dialogue (? though maybe I'm missing it) so it'd be a rough guess unless I break out the stopwatch): that is, the game will just stop. The screen will go black for a brief moment, then I'm kicked back to the desktop with the routine "xxxx has stopped working" Windows notice. It's happened twice to me thus far.
Just out of personal curiosity (and being somewhat aware that I probably shouldn't do it), I decided to be cheeky and swap out the SWP.exe in Hendricks's 4.3.3 build directory with your SWP.exe and see what happened. The end result was more or less the same, at least based on what was output to the crash log (which potentially will be of no use to you or it might?):
Caught exception 0xC0000002 at 0x75CD012F: {Not Implemented} The requested operation is not implemented. 0x75CD012F : C:\Windows\syswow64\kernel32.dll : RaiseException 0x62EE2878 : C:\Windows\system32\WindowsCodecs.dll : WICCreateColorContext_Proxy 0x62E4ED87 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E370B1 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E37026 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E36F98 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E3A7C5 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E5282D : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x62E281AC : C:\Windows\system32\WindowsCodecs.dll : [unknown file] 0x6EDF16BA : C:\Windows\system32\IconCodecService.dll : [unknown file] 0x758CA3E7 : C:\Windows\syswow64\USER32.dll : MessageBoxIndirectW 0x758BB730 : C:\Windows\syswow64\USER32.dll : DdeInitializeW 0x758B6B6A : C:\Windows\syswow64\USER32.dll : LoadStringA 0x758D6E79 : C:\Windows\syswow64\USER32.dll : CreateIconFromResource 0x758D9121 : C:\Windows\syswow64\USER32.dll : DdeConnectList 0x77BDE4B6 : C:\Windows\SysWOW64\ntdll.dll : KiUserCallbackDispatcher 0x72CD6567 : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x72CD67DF : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x72CD7223 : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x0050B8FA : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x77C0E54E : C:\Windows\SysWOW64\ntdll.dll : tan 0x77C144CC : C:\Windows\SysWOW64\ntdll.dll : RtlAllocateHeap 0x77BED38A : C:\Windows\SysWOW64\ntdll.dll : RtlNtStatusToDosError 0x016857A8 : [unknown module] : [unknown file] 0x003A0043 : [unknown module] : [unknown file] 0x0057005C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00650073 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00730072 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x004F005C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x006E0077 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00720065 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0044005C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00730065 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0074006B : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0070006F : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0073005C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00700077 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0034005F : [unknown module] : [unknown file] 0x00330033 : [unknown module] : [unknown file] 0x0062005F : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00740065 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00330061 : [unknown module] : [unknown file] 0x0053005C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00500057 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0065002E : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00650078 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00700000 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00620064 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00700000 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00620064 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00650000 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0070006C : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0070002E : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00620064 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00730000 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0070002E : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00620064 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00640000 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file]
And I decided to give the Hendricks build another run just in case it was a freak occurrence back in March that was causing me issues. No joy there, as I appear to have received the same crash log.
Caught exception 0xC0000002 at 0x74AC012F: {Not Implemented} The requested operation is not implemented. 0x74AC012F : C:\Windows\syswow64\kernel32.dll : RaiseException 0x64962878 : C:\Windows\system32\WindowsCodecs.dll : WICCreateColorContext_Proxy 0x648CED87 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648B70B1 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648B7026 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648B6F98 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648BA7C5 : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648D282D : C:\Windows\system32\WindowsCodecs.dll : DllGetClassObject 0x648A81AC : C:\Windows\system32\WindowsCodecs.dll : [unknown file] 0x68FF16BA : C:\Windows\system32\IconCodecService.dll : [unknown file] 0x75FBA3E7 : C:\Windows\syswow64\USER32.dll : MessageBoxIndirectW 0x75FAB730 : C:\Windows\syswow64\USER32.dll : DdeInitializeW 0x75FA6B6A : C:\Windows\syswow64\USER32.dll : LoadStringA 0x75FC6E79 : C:\Windows\syswow64\USER32.dll : CreateIconFromResource 0x75FC9121 : C:\Windows\syswow64\USER32.dll : DdeConnectList 0x76F5E4B6 : C:\Windows\SysWOW64\ntdll.dll : KiUserCallbackDispatcher 0x70376567 : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x703767DF : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x70377223 : C:\Windows\system32\DDRAW.dll : GetSurfaceFromDC 0x005698A7 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00566772 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00542E19 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0041C8AF : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x004236E5 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00423CB0 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x004277B1 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x00429AD1 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0056311D : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x0056FCED : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x004013E2 : C:\Users\Albinoid\Desktop\swp_433_beta3\SWP.exe : [unknown file] 0x74B2F964 : C:\Windows\syswow64\kernel32.dll : BaseThreadInitThunk 0x76FBE369 : C:\Windows\SysWOW64\ntdll.dll : RtlCreateUserProcess 0x76FBE57B : C:\Windows\SysWOW64\ntdll.dll : RtlCreateProcessParameters
#15 Posted 28 November 2016 - 02:45 PM
Ouch. Odd that I should come here at a time like this. I was going to vent about the awful state of the source code
Seriously, I am fed up with Microsoft's attitude and am fearful of a move to software as a subscription when Windows 7 runs out. So I am switching to Linux. Only games are in my way now.
ZDoom, GZDoom, EDuke32 - built and run fine.
Half a dozen Quake 1 ports build OK and run. Still choosing. Will probably go with the latest incarnation of FitzQuake, which apparently is QuakeSpasm. Not played Quake seriously for years. Oh and I ran Tenebrae but did not inhale (too dark).
However, SWP is another matter. The source code is practically un-buildable on Linux. Dear God, while you are blessing America, please spare a little time to curse something as well. Specifically, Australia, South Africa and whatever pit of Hell spawned Ken. Oh, bother, that one IS America. Can't curse them. Trust me God, you can easily change the laws of physics to resolve this paradox. But try changing the source of SWP and we'll need a new god. The SWP source is a tapeworm-ridden, toxicaragondii-infested pile of dog turd. How the hell that mess ever compiled to a working program given all the defines, redefines, macros, compatibility layers and other obfuscation I will never know. /RANT
So right now I will not likely be running SWP on Windows again, never mind building it. All I did is make it a little less flakey than before. However, I don't like the thought of random crashes so at some point once I have enough time and have ingested enough alcohol to give me the required Dutch courage, I will have a look at building SWP again. I may be gone some time.
Seriously, I am fed up with Microsoft's attitude and am fearful of a move to software as a subscription when Windows 7 runs out. So I am switching to Linux. Only games are in my way now.
ZDoom, GZDoom, EDuke32 - built and run fine.
Half a dozen Quake 1 ports build OK and run. Still choosing. Will probably go with the latest incarnation of FitzQuake, which apparently is QuakeSpasm. Not played Quake seriously for years. Oh and I ran Tenebrae but did not inhale (too dark).
However, SWP is another matter. The source code is practically un-buildable on Linux. Dear God, while you are blessing America, please spare a little time to curse something as well. Specifically, Australia, South Africa and whatever pit of Hell spawned Ken. Oh, bother, that one IS America. Can't curse them. Trust me God, you can easily change the laws of physics to resolve this paradox. But try changing the source of SWP and we'll need a new god. The SWP source is a tapeworm-ridden, toxicaragondii-infested pile of dog turd. How the hell that mess ever compiled to a working program given all the defines, redefines, macros, compatibility layers and other obfuscation I will never know. /RANT
So right now I will not likely be running SWP on Windows again, never mind building it. All I did is make it a little less flakey than before. However, I don't like the thought of random crashes so at some point once I have enough time and have ingested enough alcohol to give me the required Dutch courage, I will have a look at building SWP again. I may be gone some time.
#16 Posted 28 November 2016 - 05:33 PM
Martin Howe, on 28 November 2016 - 02:45 PM, said:
The source code is [/size]practically[size="2"] un-buildable on Linux.
The shadow warrior code base isn't the worst code base I've seen in my carrier. I agree its convoluted in places, but its definitely not as bad as your making it seem. As far as getting it to compile on Linux, if your good at software development, you can get it to compile on Linux. It took me a week I think to get the dos SW code ported to EDuke32 and have it run on Windows.
This post has been edited by icecoldduke: 28 November 2016 - 05:34 PM
#17 Posted 28 November 2016 - 11:27 PM
Shadow Warrior and JFSW's code is fine. SWP... was only ever meant to build on Windows.
#18 Posted 01 December 2016 - 02:06 AM
LOL you may think so but the "latest" JFSW has various issues "out of the box" (I tried it) and SWP will need a lot of work to get it natively on Linux. It also means getting to grips with graphics programming and associated standards such as OpenGL or on Windows DX, which is a new venture for me, so there is a lot to take in; my background is data processing, engine logic and so forth, not putting pretty pictures on a screen (if you can call the Cycloid Emperor pretty )
Nothing I can't handle, and it will be sorted eventually one way or the other -- but I'd rather be playing games than getting them to work
Nothing I can't handle, and it will be sorted eventually one way or the other -- but I'd rather be playing games than getting them to work
Share this topic:
Page 1 of 1