JFDuke is 8) but C portability issues are ... :evil:
Well after much tearing out of hair I have got the setup program to compile cleanly on my system with MinGW/GNU and MSVC-2003.NET. In case anyone is remotely interested, the modified source and makefiles etc can be found here:
There are NO functionality changes over Jonathon Fowler's originals, only portability issues have been addressed. Do what you like with it. Ignore it, use it, feed it to the cat, whatever. If it saves some poor sod from having to do all that themselves, then fine. And yes, the setup program IS evil. I can vouch for that :D But then, so is MSVC :)
BE SURE TO READ THE README.TXT FILES IN THE ARCHIVES IF YOU USE THEM!
GothOtaku at
Great! Not that I use MSVC (which likes to throw standards out the window) but it 's still nice that someone went through all the trouble to fix this up for those that'd want to have a look and modify it.
martin_howe at
GothOtaku said
Great! Not that I use MSVC (which likes to throw standards out the window) but it 's still nice that someone went through all the trouble to fix this up for those that'd want to have a look and modify it.
Well, it's nice to be platform-inclusive where possible and not everybody fully trusts GCC (see below), though as you rightly point out, Microsoft don't do themselves any favours. Tried LCC-Win32, but the IDE doesn't support more than one project at a time.
There's now kgroup on MSVC (but untested on actual files as yet, just printing filelists, filtering out directories and such) using Ken's original find-file method updated to use the Win32 equivalents of findfirst/findnext. However... you should see the amount of hair I tore out getting wad2map to work. It's not clear when/if Jonathon is going to port the rest of the build utilities so I thought I'd at least have a look at wad2map. Have to make these available for download when they've been tested a bit more.
I don't know what drugs Ken used when he wrote his square-root routine, but believe me you wouldn't need LSD when looking at some of his code :) I had to leave the GNU version as pure C, even with -DNOASM, because of a GCC assembler bug that outputs FP store instructions with the wrong sizes thus trashing memory. Then there's GAS syntax being src->dest with all those damnable percent signs and MSVC/Watcom assembler being the other way round. I willl surely kill whoever invented the AT&T assembler syntax if I ever get hold of them :twisted: Yuck! Anyhow, while it doesn't seem to work with user maps and it makes a right pig-cop's ear of E3M8, the original DOS4/GW one does the same and it sure is 8) to play E1M1 of DOOM with Duke Nukem -- not to say WEIRD :)
TX at
Why did you change the JFBuild and JFDuke Makefiles? It's always built fine under MSVC. JonoF uses it for releases, as I recall.
Awesoken at
I don't know what drugs Ken used when he wrote his square-root routine ... I had to leave the GNU version as pure C, even with -DNOASM, because of a GCC assembler bug that outputs FP store instructions with the wrong sizes thus trashing memory. Then there's GAS syntax being src->dest with all those damnable percent signs and MSVC/Watcom assembler being the other way round.
You can save yourself a lot of trouble by copying the ksqrtasm routine (which is already ported to GNU, etc..) out of JonoF's KenBuild source code distribution. The assembler code in WAD2MAP.C looks slightly older than that of the Build engine - probably because I didn't update it.
Alternately, you could replace ksqrtasm with the standard sqrt routine if you want. Since ksqrtasm is an approximation, the side effect of doing this would be that a few wall textures have slightly more accurate horizontal texture-mapping scale factors, although I think this is hardly a problem.
Ksqrtasm is a highly optimized integer square root routine for the Pentium processor. I spent many hours finding the best lookup table size and instruction order. It is used in many places in the Build Engine - where speed does matter. Remember, this code is 10 years old. On today's machines, the best way to approximate a square root is with the "RSQRTPS" instruction. And BTW, I have never used any illegal or programming-enhancing drugs. :P
martin_howe at
TX said
Why did you change the JFBuild and JFDuke Makefiles? It's always built fine under MSVC. JonoF uses it for releases, as I recall.
Yes it did seem odd and indeed EDuke32 also needed that on my system (the middle-of-block variables thing, as TX will recall, was just a standards-compliance problem that M$ ought to fix in the next MSVC - not that I'm holding my breath). However, I've been looking into this since my original postings on this forum and now know what the problem is. Apart from changing the SDK paths and "uname"-related stuff (see below) it now compiles fine using a pure unmodified copy of Jonathon's JFBuild archive, as long as it is started from "Visual Studio Command Prompt".
The problem was that never having used the MSVC command-line compiler before, I had often wondered idly what "Visual Studio Command Prompt" was for, since the PATH on my system always contained loads of VC stuff, even in a "default" command prompt. Recently, that stuff has gone away. Uh-oh :( I'm not stupid enough to claim "but I didn't change anything recently", but sure would like to know what the culprit was.
There is still a potential problem with Jonathon's build for MinGW - not all MinGW's come with a uname, so the PLATFORM doesn't get set to WINDOWS in Makefile.shared and it thus fails to build; however, according to various comments found via Google, this is apparently a common problem with MinGW. I used this one and hacked Makefile.shared accordingly (to look for "MINGW_WinNT" instead of "MINGW32"). If anyone knows of a uname for MinGW that actually works out-of-the-box with Jonathon's build makefile, please could they tell us where to get it?
Basically, the hacked makefiles were just a case of what worked for me; but I guess they're redundant now. Sorry about that, everyone :oops: There are a few useul things in them, but only to do with warnings - stuff like /Gf being deprecated from MSVC 2003.NET onwards and optimizing compiler not supported in the standard compiler and such - nothing of any immediate consequence. Ditch 'em!
The Makefile.msvc and split into Makefile.deps etc in "JFSetup" in is still needed because there wasn't one in Jonathon's setup archive. There were several warnings in MinGW and a bit of work needed for MSVC due to things like a global _argc and global _argv not defined, strcasecmp vs stricmp, unistd.h and stuff like that. I have left my hacked "jfsetup" archive where it was, but for the purists, here's one that has been modified just enough to get it to compile at all with msvc and no more; a -ur diff file is included.
Other notes: I have been working on the build utils - there's no support for them in Makefile.msvc - but see Ken's posting and my eventual reply to it for details of that.
martin_howe at
Awesoken said
You can save yourself a lot of trouble by copying the ksqrtasm routine (which is already ported to GNU, etc..) out of JonoF's KenBuild source code distribution.
Thanks, but where is it hosted? All I can find on his downloads pages are jfsetup and jfbuild and the latter only includes some, not all, of your utilities.
Awesoken said
Alternately, you could replace ksqrtasm with the standard sqrt routine if you want. Since ksqrtasm is an approximation, the side effect of doing this would be that a few wall textures have slightly more accurate horizontal texture-mapping scale factors, although I think this is hardly a problem.
Cool. I had to do that anyway for GNU as the only version I have of Wad2Map.c is your watcom original. After all, on modern machines, the performance issue isn't a severe problem (this has been discussed on the ZDoom forums recently and we reached much the same conclusion).
It just seemed a nice idea if there could be, along with jfbuild and jfduke, all of your original build utilities on Win32 to go with them; however, since the jfbuild source archive doesn't include them all, it wasn't clear if Jonathon was ever going to complete the set or not. I don't have the time or graphics I/O expertise to do them all, but wad2map seemed simple enough, so I thought I'd "have a go".
BTW, is there any reason why wad2map doesn't always translate user-written DOOM maps? Some complexity-related thing, maybe? For example, EVIL_E is a typical 1994 DOOM PWAD; it is quite small and pure vanilla Doom, no sprites, flats, DEHACKED, DOOM2 monsters or anything like that. There are a few map errors, such as unclosed sectors, but even after fixing these in DoomBuilder, it still didn't translate. Any ideas?
Awesoken said
And BTW, I have never used any illegal or programming-enhancing drugs. :P
Niether have I :) But seeing LEA used as a 3-operand multiply instruction is the next best thing :wink:
JonoF at
Thanks, but where is it hosted?
My site, here, in the "JFDuke3D source code 20050228 (net test update)" package. Look in pragmas.h in the include directory of the package.
it wasn't clear if Jonathon was ever going to complete the set or not.
The reason I only updated kextract, kgroup, and transpal is because they're the most useful ones on Linux. Windows users still have the original DOS versions and they still work, so I didn't bother porting over wad2{map,art}. Editart is very likely to not get the update treatment in a huge hurry because if anyone's looked at it they'll see why, but since it seems there's still some people who think it's worth converting Doom maps to Build I guess I can convert the wad2* stuff over as well.
Jonathon
martin_howe at
JonoF said
Thanks, but where is it hosted?
My site, here, in the "JFDuke3D source code 20050228 (net test update)" package. Look in pragmas.h in the include directory of the package.
it wasn't clear if Jonathon was ever going to complete the set or not.
The reason I only updated kextract, kgroup, and transpal is because they're the most useful ones on Linux. Windows users still have the original DOS versions and they still work, so I didn't bother porting over wad2{map,art}. Editart is very likely to not get the update treatment in a huge hurry because if anyone's looked at it they'll see why, but since it seems there's still some people who think it's worth converting Doom maps to Build I guess I can convert the wad2* stuff over as well.
Jonathon
First off, thanks for all this stuff. Second, unless you can do it quickly, I wouldn't ask you to deviate from your own agenda. Hell, I think I can speak for a lot of people in being grateful that you have done all this work; it would have taken me ages to learn all the graphics stuff like DX and SDL. As I said to Ken, it's more of a "completist" thing. That and the problem that nobody knows how long it'll be before DOS-extended programs stop running on Windows altogether, especially when the big move to 64-bit Windows materialises.
As for Wad2map. I already have that working. Neither the DOS-extended original nor mine work on some of the PWADs I tried and sometimes the DOS-extended original refuses to run at all or simply aborts with no output. I must be on the right track,though, because both versions commit the same errors; for example, the entrance door on E3M8 is blocked even after the door opens.
The problem is solely about getting the GNU assembler to assemble properly; the assembler emits FSTPQ when you code FSTPL. This is a known problem for GAS, apparently.
Anyway, something must be amiss because the JFDuke source file you mentioned (filename jfduke3d_src_20050228.zip) doesn't have an include directory and the corresponding jfbuild archive (filename jfbuild_src_20050228.zip) does have a pragmas.h but this doesn't include the text strings "sqrt" or "root". These are fresh copies off EdgeFiles five minutes ago, so what might I be doing wrong?
JonoF at
Ack, sorry. Gave you the wrong link. Here, in "JFBuild source code 20050228 (net test update)". I double-checked and it turns out I was way off with the file. It's in src/engine.c named 'nsqrtasm'.
Jonathon
Awesoken at
stuff like /Gf being deprecated
Good point. JonoF, in the MSVC makefile, please change: "/G6fy" to: "/G6Fy".
is there any reason why wad2map doesn't always translate user-written DOOM maps?
I probably tested it on 1 or 2 PWADs and was satisfied. WAD2MAP was a quick project mainly intended to convert the original Doom IWADs. I know there are problems with PWADs. I just never had much interest in fixing all the bugs since I never collected PWADs myself. Perhaps you would like to tackle these issues, Martin? : )
JonoF at
Ken: Change made. I should probably verify too that the aggressive optimisation options I have disabled by default in the Build MSVC makefile are safe to reenable.
General: I've updated the kgroup and kextract utilities to compile properly on VC and Watcom, and I also got wad2art and wad2map going. If anyone is interested in my versions of these things I'll make the code available for public consumption, but otherwise I'll just batch it up for the next release. Any objections to leaving the {conv,back}map* programs untouched for now?
Jonathon
martin_howe at
JonoF said
It's in src/engine.c named 'nsqrtasm'.
Thanks for that! I'm not sure if it isn't betterto use the "real" sqrt function anyway, given what the improved accuracy that would result plus the fact that Wad2Map isn't a real-time program unlike the game itself and (to a lesser extent) the editor, but it's nice to know where the updated one is. After all, an integer square root routine that uses the FP registers isn't an integer routine :)
Awesoken said
Perhaps you would like to tackle these issues, Martin? : )
I will certainly be having a look in more detail when I have the time because the idea is kinda fascinating. Anyway I would love to see EVIL_E in DN3D; it's got a weird quirky feeling to it that I rather like :)
Finally, here's a -ur diff of the 20030528 source so that all four utils compile on both MSVC and GNU/MinGW. A copy of Wad2Map.c is included, using pure C and the old sqrt for now. There are a couple fixes (such as missing/unused includes and trying to printf a file's handle instead of its name) but otherwise minimal changes. Jonathon: if you wanna hack this stuff to your coding conventions and put it in the next release, feel free.
And now I'm off to play E4M3 in DN3D. I may be gone some time... :)
maniac1701 at
no objections considering im more interested in getting the network play solid
JonoF said
Ken: Change made. I should probably verify too that the aggressive optimisation options I have disabled by default in the Build MSVC makefile are safe to reenable.
General: I've updated the kgroup and kextract utilities to compile properly on VC and Watcom, and I also got wad2art and wad2map going. If anyone is interested in my versions of these things I'll make the code available for public consumption, but otherwise I'll just batch it up for the next release. Any objections to leaving the {conv,back}map* programs untouched for now?