Doom 3 engine release and game code

[revelator]

Btw motorsep small notice if you are using dhewm3 compiled with anything but the msvc compiler then you cannot use any mods previously compiled with msvc.
The problem is that mingw compiled game dll's have different exports compared to msvc ones so dhewm3 cannot import them if its compiled with mingw

Ok tested it thourogly and seems the dynamic resolution scaling works as it should ill zip up a build and start making patches.

[motorsep]

Then don't compile dhewm3 with MSVC

I compile and cross compile dhewm3 on Linux with gcc (for Linux and Windows 32/64 bit). Works fine. I can also compile dhewm3 with gamelibs on Windows using MSVC, but what's the point? Maybe when time comes for distribution, I will compile Windows builds on Windows and Linux builds on Linux.

[revelator]

More problemtic on windows i guess so on windows to keep compatibility with existing mods which we dont have the source code for we need to use msvc.
Rather irritating as it compiles fine with mingw64 but it breaks mod compatibility on windows

[motorsep]

oh, dhewm3 is 100% incompatible with all mods for Doom 3. So you would have to either recompile mod against dhewm3 or you are out of luck. That engine was never meant to be compatible with Doom 3 original mods. iodoom3 won't be compatible with mods either from what I've heard.

[revelator]

It works if game code is recompiled with the same compiler using dhewm3 as the game sdk the biggest bugger is that many mods dont include there game dll source code so its impossible to port those else i would make compatible dll's for dhewm3.

[motorsep]

but dhewm3 was not designed to be compatible with mods. Afaik it was designed to run Doom 3 as best as it can, and serve as base for new games using idTech 4. Most of the bugs you guys were discussing here have been fixed in dhewm3 long time ago.

[revelator]

also introducing a few new ones like the sdl alpha texture bug. Atleast it can be reverted easily.

As for mod support im just pointing out that it does indeed work if game dll's are recompiled with dhewm3 as the sdk

[motorsep]

The alpha bug came with the attempt to comply with Wayland. I selectively update my personal repo from dhewm3. So mine doesn't have SDL2 for example.

[revelator]

Me either im using SDL-1.2 and the alpha bug is indeed there still.
From discussion on the dhewm3 page it seems not to affect all gfx cards but some like me with a nvidia it goes totally bonkers causing interactive screens to show static and the doom logo to show up as some weird stripes.
Tried SDL2 and though it loads it cannot grab input correctly on windows (not only mouse but also keyboard) :/ well its still in development stage so.

[revelator]

btw promissed update.

[revelator]

Anyone had a chance of trying it out yet ?

[motorsep]

I haven't tried and I kinda dumped that idea for now because my implementation doesn't work with the menu (adjusting SCREEN_* variables on the fly based on aspect ratio)

[revelator]

with my changes its unnessesary everything will scale with current resolution.
As for a menu option one needs to be created by modifying the existing gui script in pak000.pk4 but else its perfectly controlable via the r_customwidth r_customheight variables.
I found out after some testing that all the other gunk is totally unnessesary as doom3 has a function that sets SCREEN_WIDTH and SCREEN_HEIGHT allready. the define of SCREEN_WIDTH=640 and SCREEN_HEIGHT=480 are just defaults in case no other resolution was set it works like a pointer

[motorsep]

Where is the source for your modifications ?

Btw, I don't use r_custom* cvars. I simply added most common resolutions to the list of resolutions.

[revelator]

list still needs to be activated the r_mode struct simply just adds these as supported.

i got my source on github but i havent uploaded the new changes yet as i was waiting for people to try it out for feedback.