Omg.. there are makefiles for MSVC and something else but there are no for mingw :-(
Could anybody PLEASE tell me in simple steps how can i compile it with MinGw ? I'm begging you! ;-(
Edit: Ok.. ive downloaded OpenWatcom... how do i compile with it? :( Errors and errors... look:
http://2a.pl/~gp25039/errors.txt
Awesoken at
Apparently, Open Watcom 1.3 WASM is stricter than the version from Watcom 11.x. To fix the errors, add "byte ptr", "word ptr", or "dword ptr" in front of the offending lines. Here are some examples:
Change:
mov [apatch7+2],bl
To:
mov byte ptr [apatch7+2],bl
Change:
mov [apatch3+2],ebx
To:
mov dword ptr [apatch3+2],ebx
As a general rule, if you see one of the 8-bit registers (al,bl,cl,dl,ah,bh,ch,dh) in the line, put a "byte ptr" in front of the memory operand (usually denoted by square brackets []). If you see a 16-bit register (ax,bx,cx,dx,si,di,bp,sp), use "word ptr". For 32-bit registers (eax,ebx,ecx,edx,esi,edi,ebp,esp), use "dword ptr".
WASM used to do this stuff automatically. I suppose Scitech felt they were helping sloppy assembler programmers by requiring the size specifier. IMHO, all it did was break a lot of perfectly good code. I think it's important to support Open Watcom, so I'll see if we can get these errors fixed by the next release.
ProAsm at
Besides the .wasm and .masm files there are several other changes required as well.
jnstub.c
Line 1337:
replace
getnumber = getnumber256;
with
getnumber = getnumber256(tempbuf, data, 65536L, 1);
Line 1342:
replace
getnumber = getnumber16;
with
getnumber = getnumber16(tempbuf, data, 65536L, 1);
Keyboard.c
Line 285:
replace
setkeypresscallback(KB_KeyEvent);
with
setkeypresscallback((void(*)(long,long))KB_KeyEvent);
Inv.c
Line 1062:
replace
InventoryDisplayString = DisplayMiniBarSmString;
with
InventoryDisplayString = 1;
Line: 1112
replace
InventoryDisplayString = DisplaySmString;
with
InventoryDisplayString = 0;
If you crash to the desktop everytime you pickup most inventory items:
Line 1107:
replace
InventoryDisplayString(pp, x, y, 0, ds);
with
InventoryDisplayString = 1;
Line: 1112:
replace
InventoryDisplayString(pp, x, y, 0, ds);
with
InventoryDisplayString = 0;
The other way is to make the InventoryDisplayString routine 100% compaible with the DisplayMiniBarSmString and DisplaySmString routines.
The above changes is required for both Watcoms WMAKE and M$ NMAKE.
Makefile.msvc This needs its MAKEDIR defined beforehand else it looses its path.
You also need to switch its Assembler to wasm instead of masm.
AS=wasm
Also change all masm to wasm.
Also dont forget your DXROOT=c:\sdks\msc\dx7
It might pay you to add the -a and /a to the appropriate batch files as well.
JF must use a very forgiving comlpiler - probably Vcc ;)
JonoF at
I was oblivious to the release of OpenWatcom 1.3 until yesterday, so I've updated and fixed the more serious problems it highlights. Here are GNU unified diffs for the 20050531 source distributions of each port: JFDuke3DJFSWJFBuild. OpenWatcom 1.3 seems to have tightened its belt a bit from previous releases and vomited a whole barrage of new warnings as a result, most of which are entirely benign, but a few are more serious. With OW1.3 Duke and SW have developed some nasty crashes in the assembly code for the classic renderer and the sound mixing that I'm hunting down. I'll post patches for them when I sort them out.
To apply the patches you need GNU patch and follow this procedure:
Line 1337: replace
getnumber = getnumber256;
with
getnumber = getnumber256(tempbuf, data, 65536L, 1);
Line 1342:
replace
getnumber = getnumber16;
with
getnumber = getnumber16(tempbuf, data, 65536L, 1);
Erm, not quite. The declarations for the GET_NUM_FUNC and PRINT_MSG_FUNC types should be updated to reflect the proper form for getnumber16/256 and printmessage16/256:
This also means you then have to update all the instances of getnumber() in jnstub.c by adding a fourth parameter of 0. Not a big issue, just takes a few minutes.
Keyboard.c
Line 285:
replace
setkeypresscallback(KB_KeyEvent);
with
setkeypresscallback((void(*)(long,long))KB_KeyEvent);
This is better solved by changing the declaration of KB_KeyEvent to take two longs, and making the function static for good measure since it no longer has to be visible outside the jmact\keyboard.obj object like it was before. It shuts up the warning too.
Inv.c
Line 1062:
replace
InventoryDisplayString = DisplayMiniBarSmString;
with
InventoryDisplayString = 1;
Line: 1112
replace
InventoryDisplayString = DisplaySmString;
with
InventoryDisplayString = 0;
These two warnings aren't worth worrying about unless you're seriously pedantic since it's caused by a mismatched "signed char *" and "char *" parameter. Annoying to see, but not the end of the world.
EDIT: In fact, change the InventoryDisplayString declaration on line 998 to read:
Makefile.msvc This needs its MAKEDIR ... JF must use a very forgiving comlpiler - probably Vcc ;)
Why are you using the MS Visual C makefile with OpenWatcom? There's a makefile for it named Makefile.watcom. wmake -f Makefile.watcom. Things work without modification that way.
Jonathon
ProAsm at
Why are you using the MS Visual C makefile with OpenWatcom? There's a makefile for it named Makefile.watcom. wmake -f Makefile.watcom. Things work without modification that way.
I'm not using the MS Visual C makefile, for the MakeFile.msvc Watcom supplies a NMAKE.EXE which is supposed to be MS compatible and the changes are for that.
Personally I use Watcoms WMAKE but I just wanted to see whats needed to get the NMAKE working :)
Thanks for the info on the Watcom 1.3 as that will be very usefull as currently only 1.1 works with both SW and DN and its been like that since the start.
ProAsm at
patch.exe - Unable to Locate Component
This application has failed to start because msys-1.0.dll was not found.
Re-installing the application this may fix this problem.
:(
Any chance of mailing me the updated files or putting them somewhere.
flaht at
ProAsm said
patch.exe - Unable to Locate Component Any chance of mailing me the updated files or putting them somewhere.
I would be very greatefull too...
JonoF at
Ok, I've cross-compiled a fresh patch.exe so it ought to work now. http://jonof.edgenetwork.org/misc/patch.exe
Patch.exe as well as the diff file are in the F:\Patch\Duke3d folder, why does it now go to some other temp path, can it not use the current folder as its temp folder.
I managed to do most manually but the gamedef.c somewhat eludes me.
*** Edit
I also tried moving everything to the C drive but still the same.
If I look at the file it has 0 bytes.
C:\Documents and Settings\ProAsm\Local Settings\Temp\pra00988
*** Edit 2
Please mail me the updated files at info@ut2vote.com
JonoF at
A version of patch that actually works is up, and the patches themselves have been updated with DOS line-endings so that Windows users can apply them without too much hassle. Unix folks will probably have to use dos2unix to convert to unix endings. And, for the supremely lazy, here's the files already patched.
Addendum: For reasons I'm completely unable to determine, OpenWatcom 1.3's assembler or linker (can't tell which is at fault) is not using the right addresses for external symbols in a.wasm and we end up with such things as the bufplce[] array pointing at some address way off the map, and therefore it all falls to pieces in a crashing heap. My suggestion? Use OpenWatcom 1.2 instead. It doesn't have this problem.
Jonathon
ProAsm at
Thanks JF and yes I agree, Watcom 1.3 is a total nightmare as I tried it on other stuff as well and it fails everytime.
However, since I changed the InventoryDisplayString as you suggested everything has stabilized and now works great with Watcom 1.1
Before it would cause a desktop crash when the inventory wrote the % value to the statusbar.
JonoF at
One last thing before this topic slips into the past: I made a ZIP of the necessary DLLs and whatnot for running TortoiseMerge, a visual diff tool that can apply patches and comes as part of the TortoiseSVN client for the Subversion version-control system I use. Some folks here might find it useful if I create further patches. Grab it here if you need it.
Jonathon
ProAsm at
Btw, when you compiled with Watcom 1.2 did you try running the game ?
Well only today did I up to v1.2 and add your patch and although it all compiles great now, but when you run the game all you get is a black screen.
You can hear the game running perfectly in the background but you cannot see a damn thing.
This goes for both Duke and SW.
So its back to version 1.1 and everything compiles and works 100% - pity though :(
JonoF at
Hmm. I don't recall any problems back when I tried it since I had to verify it wouldn't crash like it was with 1.3. I'm using 1.2 now and it works. I'll have to check out an older revision to be sure.
Jonathon
ProAsm at
mmm thats very stange because I tried re-installing etc but still the same.
I took your original files of the 31st May and just added the files from the patch.
The only other thing I had to do was change my DXROOT= to point to mine.
Everytime I start the game, the screen goes black and stays that way.
I have to wait for the game to get past the introduction, then hit the up arrow to get to Quit and exit :)
Can you possibly mail me the Duke3d.exe or Sw.exe that you compiled with v1.2 so I can see if I get a black screen here.
Maybe its a graphic card issue or something.