VOGONS

Common searches


Ion Fury - A new Build Engine game

Topic actions

Reply 61 of 132, by GrandAdmiralThrawn

User metadata
Rank Newbie
Rank
Newbie

Thank you! This seems to be similar to adding /D "FURY=1" to the command line directly. I tried adding FURY=1 to the preprocessor definitions, but the resulting binary seems identical (compared file size, but not checksums). The only difference appears to be that I get lots of warnings and notes during compilation of the final eduke32 project, just like when I tried adding /D "FURY=1" to the command line. Here's an example:

x:\build\eduke32\eduke32\source\duke3d\src\common_game.h(52): warning C4005: 'FURY': macro redefinition (compiling source file ..\..\source\duke3d\src\common.cpp)
x:\build\eduke32\eduke32\source\duke3d\src\common_game.h(52): note: command-line arguments: see previous definition of 'FURY' (compiling source file ..\..\source\duke3d\src\common.cpp)

The code behaves identical to before. Duke Nuk'em 3D works, Ion Fury crashes.

Edit: The source code is the latest revision 8090 from the eDuke32 repository, in case it matters.

Proud User of a 3dfx Voodoo5 6000 AGP (HiNT Rev.A3 3400) prototype

Reply 63 of 132, by GrandAdmiralThrawn

User metadata
Rank Newbie
Rank
Newbie

Interestingly, there are no preprocessor #ifdef, #if defined or #if !defined to be found anywhere in conjunction with "FURY".

X:\Build\eDuke32\eduke32\source>grep -r "FURY" . | grep "#"
./duke3d/src/common_game.h:#define GAMEFLAG_FURY 0x00000080
./duke3d/src/common_game.h:#define FURY (g_gameType & GAMEFLAG_FURY)

There is just a definition of it in common_game.h:

#define GAMEFLAG_FURY       0x00000080

And a bit below:

#define FURY                (g_gameType & GAMEFLAG_FURY)

The only conditionals I can find don't even look like preprocessor stuff (I think?), like in config.cpp, just one example:

    if (FURY)
{
for (auto const & button : buttonsFury)
button.apply();
}
else
{
for (auto const & button : buttonsDuke)
button.apply();
}

There are many like those, but I can't find out where and how to set that variable properly. The preprocessor definition FURY=1 doesn't seem to work at all, even if I remove #define FURY (g_gameType & GAMEFLAG_FURY) from common_game.h and leave the preprocessor definition in. It doesn't complain about the macro redefinition then, but it doesn't compile anything that would work with the Ion Fury data files either...

Unfortunately I'm not really a programmer, and most assuredly not a C/C++ programmer (scary language), and I don't understand Microsoft's toolchain well enough to know how to do this properly. 🙁

How hard can it be to set a GNU make flag equivalent in VS... uh.

My apologies for spamming around here, but I'd really love to provide a 32-bit build of eDuke32 that "just works" with Ion Fury on XP out of the box.

Edit: Ah, I somehow managed to compile a build that works! It appears that some of the Ion Fury-specific definitions have changed names or something, like NETCODE=0 is actually called NETCODE_DISABLE and STANDALONE is called EDUKE32_STANDALONE. Disabling the FURY definition in common_game.h and setting FURY=1 as yet another preprocessor definition now finally produced a 32-bit build that works with the Ion Fury data files.

However, the Polymost renderer is broken, it works only with Polymer and Software. Polymer looks ok, but is unusably slow (Core 2 Quad Q9505 + GTX 285), software works fine. Polymost presents the black screen other users have reported. But ok, at least it compiles (somewhat) properly now.

Polymer is also very memory-hungry. Where Software and Polymost appear to eat around 280MiB of RAM, running Ion Fury with Polymer takes almost 1GiB of main memory...

ionfury-customeDuke32build-1.png

Edit 2: Here's my first build, I hope it really works as I described it.. should not require any binary hacks, as it's not using GetTickCount64() anymore, and it should no longer need SSE or SSE2 (though I cannot confirm that part):

Filename
eduke32-IF-win32-r8090-20190910.7z
File size
3.18 MiB
Downloads
240 downloads
File license
Fair use/fair dealing exception

Will not work on Windows 2000 out of the box though.

Proud User of a 3dfx Voodoo5 6000 AGP (HiNT Rev.A3 3400) prototype

Reply 64 of 132, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
GrandAdmiralThrawn wrote:

How hard can it be to set a GNU make flag equivalent in VS... uh.

Well hold up there - a make flag isn't the same thing as a preprocessor definition. Visual Studio is a compiler/editor, GNU make is a build system so they perform different functions. The VS equivalent to make would be nmake which hardly anyone bothers to use.

Reply 65 of 132, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Thanks for confirming that people claiming large requirements are too lazy to use software mode. Going to test that today on a Pentium M.

For Windows 2000 you either have to use the unofficial SDL 2.0.5 for 2000 or using the Blackwingcat patch if you want to use SDL2.
https://www.tapatalk.com/groups/win2kgaming/s … 2000-t1073.html

How To Ask Questions The Smart Way
Make your games work offline

Reply 66 of 132, by gerwin

User metadata
Rank l33t
Rank
l33t
GrandAdmiralThrawn wrote:

Here's my first build, I hope it really works as I described it.. should not require any binary hacks, as it's not using GetTickCount64() anymore, and it should no longer need SSE or SSE2 (though I cannot confirm that part): ...

Cool!
But I get the NTCreatefile-API error. Which AFAIK means it is missing DLL files. I tried adding msvcp140.dll + vcruntime140.dll. But it is not enough.

Attachments

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 67 of 132, by GrandAdmiralThrawn

User metadata
Rank Newbie
Rank
Newbie

It should depend on the Visual C++ 2015 redistributable, but nothing other than that. It's been compiled using the v140_xp toolset.

@jmarsh: With GNU make, you just do "make FURY=1". When looking at the Makefile, it seems to set a few preprocessor definitions whenever that flag is set to 1, which I just copied over to VisualStudio after grepping through the source code to make sure to get the definition's names right. That made it work (for me..).

In the meantime I tried to compile many different revisions, but the older ones (just a bit before rev.8000) fail to parse the Ion Fury CON scripts. This expecially affects all revisions where the FURY flag was still called IONMAIDEN. None of those work. All the newer ones I tried had a broken Polymost renderer, at least on my machine. Still need to find out why it fails for you, gerwin. I just have so many XP machines to test with, and most are VMs. 🙁 And none of them are clean anymore. I guess I would need to set up a fresh installation somewhere, even if only for testing software mode.

If I have time tomorrow, I'll set up a fresh XP SP3 VM just to see if my build works or breaks there.

Proud User of a 3dfx Voodoo5 6000 AGP (HiNT Rev.A3 3400) prototype

Reply 68 of 132, by gerwin

User metadata
Rank l33t
Rank
l33t
GrandAdmiralThrawn wrote:

It should depend on the Visual C++ 2015 redistributable, but nothing other than that. It's been compiled using the v140_xp toolset.

Nevermind, that was on the laptop. It seems to work fine on my desktop as is. It is like this:
- In Software Mode it shows the menus properly and runs fine when I start a new game and play the first part.
When I load my old savegame with the first 'hub' area it crashes after about 30 seconds in the game.
- In Polymost mode the menus are not visible, but I can keep pressing enter and the ingame 3D view then appears. It looks very much like software mode, with unfiltered textures, and is a bit slow. But it actually does use more then 256 colors.

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 69 of 132, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Well this partly explains the odd behavior I noticed in Vmware:
Ion Fury - A new Build Engine game

https://forums.duke4.net/topic/10756-building … post__p__329349

I suspect this is due to eduke32 using OpenGL even in software mode to blit the rendered image to the screen (this also makes switching between software and OpenGL modes seamless since it doesn't have to switch to a different backend)

How To Ask Questions The Smart Way
Make your games work offline

Reply 70 of 132, by GrandAdmiralThrawn

User metadata
Rank Newbie
Rank
Newbie
gerwin wrote:

[...]
- In Polymost mode the menus are not visible, but I can keep pressing enter and the ingame 3D view then appears. It looks very much like software mode, with unfiltered textures, and is a bit slow. But it actually does use more then 256 colors.

Huh, that's interesting. I just tried it, and it works as you say. On my XP machine it appears to be smooth as well when it comes to frame rate. That's on the same box as above, Q9505+GTX 285, 1920×1200. The funny part is, if you hit <Esc> and pick "End Game", it returns you to a now-working main menu.

If you start another new game from there now, you can also see the initial cutscene properly. It seems that as soon as the 3D view has been initialized once, everything is suddenly ok for Polymost.

I tried to fool around with the CON scripts in fury.grp to kind of enforce that behavior, mostly scripts\screens.con, but I couldn't find a way. I eliminated the initial cutscene and the 3DRealms logo as well as the main menu background. But none of those were responsible for this issue. I'm not quite sure what else to try. This might require a source code patch after all?

Edit: Further testing has shown that my build is highly unstable, no matter which renderer you use. I can usually play for 2-3 minutes, but then it would crash in a way that is not reproducible. In other words: It can crash anywhere, anytime. 🙁

Proud User of a 3dfx Voodoo5 6000 AGP (HiNT Rev.A3 3400) prototype

Reply 71 of 132, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Alright. Looked around tonight and noticed still no readily available Ion Fury builds based off eduke32.

Went back to the previous link posted and noticed a new version post that is still only compatible with Vista+
http://www.mediafire.com/file/w70bv4yddm2ccos … 0190821.7z/file

I modified the files inside with the stellaris patch to allow it to work on XP 32bit and XP 64bit.

https://drive.google.com/open?id=1Ux7qvRw-Z3f … h4a0M12vXIZh_ps

This is ridiculous.

How To Ask Questions The Smart Way
Make your games work offline

Reply 72 of 132, by truemaster

User metadata
Rank Member
Rank
Member

sorry if i misunderstanding but i found a video showing running on dosbox. its struggle to run but on decent pc running dos or win9x it might be better what you thing?

https://www.youtube.com/watch?v=aJh7gq5UrIY

Reply 74 of 132, by gerwin

User metadata
Rank l33t
Rank
l33t

What may be good to know: Normally I look for texture filtering to make sure OpenGL mode is functional. Though since about a year OpenGL texture filtering is disabled in EDuke32, because it is incompatible with palette cycling or something.

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 75 of 132, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

Did some testing and it looks like eduke32 works with Ion Fury data files now. 32bit build works on XP 64bit+ for Ion Fury.
Same ver of eduke32 works with Duke3D on XP 32bit.

For XP (32) if you want to use the previously mentioned builds you'll need to run them with an older version of the game.

How To Ask Questions The Smart Way
Make your games work offline

Reply 77 of 132, by gerwin

User metadata
Rank l33t
Rank
l33t

I tested some recent eDuke Win32 builds in Windows XP x86.
Last one to be compiled for NT5 and working properly is:
eduke32_win32_20210927
https://dukeworld.com/eduke32/synthesis/20210 … 9607-9741acb51/

This one also runs Ion Fury quite well. Better then the earlier special Ion Fury builds.
This one has texture filtering enabled for Duke 3D, though no filtering for VoidSW (=Shadow Warrior).
(The current latest does not have filtering for VoidSW either)

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul

Reply 78 of 132, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

https://dukeworld.com/eduke32/synthesis/20211 … 9631-cbb598f10/ appears to work

It looks like they messed with their compiler and/or code
https://dukeworld.com/eduke32/synthesis/20211 … d/ChangeLog.txt

commit a891732fda15e186f0088ce8d304332063c1bb51 Author: Richard Gobeille <richard@voidpoint.com> Date: Wed Oct 6 16:13:27 2021 […]
Show full quote

commit a891732fda15e186f0088ce8d304332063c1bb51
Author: Richard Gobeille <richard@voidpoint.com>
Date: Wed Oct 6 16:13:27 2021 -0700

MinGW build fix... I'm going to hell for this one

This works around what looks like a problem with the MinGW cross-compiler toolchain in Debian.

See https://voidpoint.io/terminx/eduke32 for more details.

Yes, yes you are.

https://voidpoint.io/terminx/eduke32/-/commit … 83ab6692485dae5

How To Ask Questions The Smart Way
Make your games work offline

Reply 79 of 132, by gerwin

User metadata
Rank l33t
Rank
l33t
DosFreak wrote on 2022-04-25, 19:16:

Yes, yes you are.

Yes, I noticed that too. I also noticed that before his compiler adjustment, the build right before it, from the same day, has a broken voidsw.exe. It crashes right away.

--> ISA Soundcard Overview // Doom MBF 2.04 // SetMul