For direct access use https://forums.oldunreal.com
It's been quite a while since oldunreal had an overhaul, but we are moving to another server which require some updates and changes. The biggest change is the migration of our old reliable YaBB forum to phpBB. This system expects you to login with your username and old password known from YaBB.
If you experience any problems there is also the usual "password forgotten" function. Don't forget to clear your browser cache!
If you have any further concerns feel free to contact me: Smirftsch@oldunreal.com

Building UTGLR d3d9/ogl for other UE1 games

Post Reply
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

I just tried to build UTGLR for X-Com enforcer (engine ver  420) and I get black screens but the UI works (I can hear menu selection sounds.)

I also have to replace all "apppow" calls to "powf" and "apptan" to "powf" because it seems the libs I generated for x-com enforcer do not contain apppow and apptan for some reason.
Last edited by []KAOS[]Casey on Mon Jul 25, 2016 4:41 am, edited 1 time in total.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

I also have to replace all "apppow" calls to "powf" and "apptan" to "powf" because it seems the libs I generated for x-com enforcer do not contain apppow and apptan for some reason.
It does contain appPow, but the signature uses FLOAT instead of DOUBLE.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

I'll try changing the signature in the headers to match this and see what happens.

Thanks Han.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

I'm giving building headers for X-Com Enforcer a shot today. Currently I have UCC, Launch and SampleNativePackage working, haven't tried building RenDevs yet.

I'm using ut432pubsrc as a base and a bit out of Loki/OpenUT sources as they reflect a somewhat earlier engine version.

As far as I can currently tell, the most differences are inside Window.h, as this was heavily changed during development of the UED2 UI. GetOptimizedRepList misses the last parameter, otherwise it currently looks mostly unchanged compared to ut432pubsrc headers.

/edit:
ut436-opengldrv-src-090602 builds and runs, and is especially not black. You did rebuild Engine.u to get an updated EngineClasses.h file, didn't you?
Last edited by han on Mon Jul 25, 2016 7:28 pm, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

/edit:
ut436-opengldrv-src-090602 builds and runs, and is especially not black. You did rebuild Engine.u to get an updated EngineClasses.h file, didn't you?
I thought it was going to come down to something like that. I knew that a header or two was probably not valid for the specific build, but I wasn't sure where to begin.


By the way, Visual Studio 2013/15 have problems with Time.h, because #define clock seems to obscure "clock" defined in a C header. Is there a proper fix for this? I currently just changed #define clock to #define clock2 and edited UTGLR sources to match this since it is a compile time only change.

So for others information, the steps you should take for building these renderers is

Grab headers from a somewhat-close engine version,
rebuild Engine.u for EngineClasses.h regeneration, copy that back into the source tree,
then attempt to build, fix any linker inconsistencies (like appPow/Tan having different signatures)
then you're probably ok?

Should Core also be rebuilt, or are there almost no changes for that to be an issue?
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

By the way, Visual Studio 2013/15 have problems with Time.h, because #define clock seems to obscure "clock" defined in a C header. Is there a proper fix for this? I currently just changed #define clock to #define clock2 and edited UTGLR sources to match this since it is a compile time only change.
I can remember that I had this issue before, but I can't remember how I worked around it. Probably putting some #define clock clockbla before including the header and some #undef clock afterwards.
So for others information, the steps you should take for building these renderers is

Grab headers from a somewhat-close engine version,
rebuild Engine.u for EngineClasses.h regeneration, copy that back into the source tree,
then attempt to build, fix any linker inconsistencies (like appPow/Tan having different signatures)
then you're probably ok?
In case of Enforcer yes, but usually it isn't quite that easy/minor work. Usually you need to verify the vtables of a shitload of classes, often even the binary layout which gets rather tricky. Other things one should do is to dump the hardcoded names table for UnNames.h (unchanged in this game), the following code does the trick:
guard(DumpNames);
debugf( TEXT("------------ Dumping Hardcoded Names ------------------") );
for ( INT i=0; iFlags & RF_Native) )
{
if ( Entry->Flags & RF_HighlightedName )
debugf( TEXT("REG_NAME_HIGH(%4i, %-17s)"), Entry->Index, Entry->Name );
else
debugf( TEXT("REGISTER_NAME(%4i, %-17s)"), Entry->Index, Entry->Name );
}
}
debugf( TEXT("------------ End of Hardcoded Names Dump ------------------") );
unguard;
return 1;
Throwing in VERIFY_CLASS_SIZE macros for every class you can is also helpful. In case of RenDevs usually not much work is needed, if sth. won't work, taking a look at UPlayer/UViewport will usually do the trick.
Should Core also be rebuilt, or are there almost no changes for that to be an issue?
Core has no autoexported headers, UObject binary layout is usually unchanged, for UCommandlet you can just check if the variables do match the ones in the headers (also not needed for just a RenDev). Checking the virtual layout of UObject is on the otherhand sth. one should always do.

But well the above is just the best case, often you can't even get sth. compiling running to just dump the hardcoded names, then there is nasty stuff as changed NAME_SIZEs or in case of KnowWonder, heavily modified UProperty based classes, or like in KHG where basically everything is different. Usually the Engine was heavily modified by the licensees, especially in case of Undying.

But basically it is like, if you just touch a few parts of the engine from the outside like the RenDev does, you don't need to have much right in the headers, but if you want to do other stuff you usually end up beeing required to put a lot of effort into it.

And for some games you even need to figure out how they implemented an additional feature (e.g. in KnowWonder games the DrawTriangles, LipSynch in Deus Ex, StopSound in Deus Ex/Rune/Undying(?), etc.)

In any case I'll put together some "PubSrc" for Enforcer in the next couple of days like I did for Nerf, KHG, HP1.
Last edited by han on Mon Jul 25, 2016 9:29 pm, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

YEah, recompiling Engine did it. I also had to add the #include "AActor.h" that was missing to the bottom of AActor's definition.

Looks like D3D9 doesn't support BINK video playback, since it's probably never been designed to do that.

It seems that sometimes it hard freezes before it gets in game, probably due to the BINK video. I'm sure there's some way to bypass this so it's not a problem.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

YEah, recompiling Engine did it. I also had to add the #include "AActor.h" that was missing to the bottom of AActor's definition.
Actually those lines get added automatically if some Inc\.h file is present and there are quite some more you probably missed that way.

I haven't checked for Bink playback, but doesn't look like any long time freeze for me other then detecting render devices. Actually I was too lazy to search for the Enforcer DVD, so I went on to get Launcher to compile/work before any other stuff. But I should probably check again with original Launcher.

/edit:
As an additional idea, someone could donate Smirftsch a copy of Enforcer, so he can make ALAudio builds for it. And if, one could use the approach I used for Nerf to move CD playback to UMusic playback by changing a few lines in Engine.LevelInfo.

/edit2:
As far as the bink videos are concerned, seems that Launcher plays them back at startup, probably without any relation to the Unreal Engine at all. There is also some Credits and some sort of "Play Again" bink video. So imho there isn't much lost when those won't play with another launcher.
Last edited by han on Tue Jul 26, 2016 2:26 am, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

I'm pretty sure ALAudio and FMod are both made for the community by the community and as such are not legally bound to being unreal only and anyone with a copy can build it for whatever they want.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

I'm pretty sure ALAudio and FMod are both made for the community by the community and as such are not legally bound to being unreal only and anyone with a copy can build it for whatever they want.
Basically the reason is that I prefer Smirftsch maintaining the builds, while I just contribute code to ALAudio and don't provide any builds.
Last edited by han on Tue Jul 26, 2016 2:30 am, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

BinkPlayback seems to be deeper integrated into the Engine then I initially assumed. Turns out UViewport got a bunch of new variables and some bink playback interface.

Code: Select all

      UBOOL BinkPlaying;
      INT BinkSavedSizeX;
      INT BinkSavedSizeY;
      INT BinkSavedSizeColorBytes;
      HBINK BinkHandle;
      s32 BinkSurfaceType;

      virtual UBOOL PlayBinkMovie( TCHAR* Filename )=0;
      virtual void DoBinkFrame()=0;
      virtual void EndBinkMovie()=0;
The Launcher calls PlayBinkMovie( TEXT("InfoLogo.bik") ) to start playing of intro and inside the MainLoop if BinkPlaying is set, Engine->Tick() is skipped, but later on DoBinkFrame() is called.

With these changes the recompiled launcher plays the intro with the original D3DDrv, however the new compiled D3DDrv/OpenGLDrv still won't play these, but at least thats a start. :)




Last edited by han on Tue Jul 26, 2016 11:24 pm, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

Hmm. Wonder if the frames get passed to the renderer somehow to just draw as a sprite? Still, progress!
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

Hmm. Wonder if the frames get passed to the renderer somehow to just draw as a sprite? Still, progress!
It is a bit more complicated (and odd). What I figured out so far is, that there are basically two modes for rendering bink frames: One direct mode and one RenDev gets a command and does it on it's own.

The direct mode gets selected whenever UWindowsViewport::dd is not NULL, the other mode otherwise.

What is pretty odd is that UWindowsViewport::dd is just NULL if either UseDirectDraw=False, -noddraw commandline switch is used or GameRenderDevice setting is either D3DDrv or GlideDrv. So this mode is basically intended for SoftDrv where ScreenPointer is the locked DirectDraw surface. In this case WinDrv directly writes the Bink frame into the DirectDraw surface/ScreenPointer.

This mode is in any case suboptimal for any hardware based RenDev, though it should work to read the rendered Bink frame out of Viewport->ScreenPointer into a NPOT texture during URenderDevice::Unlock(), but one should keep in mind that this would be the whole screen, and somewhere in the center should be the actually 640x480 Bink video frame.

For the second indirect mode I haven't figured out much detail yet, however at the start of playing the bink file, the UWindowsViewport calls RenDev->Exec( TEXT("SetBinkType"), this ) and for each frame RenDev->Exec( TEXT("DoBinkFrame"), this ). My best guess is that the RenDev handles getting the bink frame on it's own as the relevant Bink handle seems to be exposed over the additional UViewport variables (I have updated the post above to reflect what I figured out about these in the meanwhile).

So in any case it most certainly ends up, that another RenDev needs UseDirectDraw=False option, I should probably just add that to the first time wizzard.

In other news:
AudioSubsystem receives a Audio->Exec( TEXT("SetBinkAudio"), this ) call at the start of the playback of the first Bink movie, this probably needs further evaluation too.

Also I found a bink header and lib here.

/edit:
In direct mode the RenderLockFlags have the very unusually value 0x821. So that would be at least a way to detect it inside the RenDev.

/edit2:
Actually copying data out of Viewport->ScreenPointer requires the use of BLIT_DirectDraw flag so the surface gets created, locked etc. and ScreenPointer ends up non zero, but this in turn would probably cause more trouble than it's worth in case of OpenGLDrv. Maybe (though it is most certainly a bad idea to start with, is one allocates memory inside RenDev's Lock() for Viewport->ScreenPointer and sets Viewport->BinkSurfaceType accordingly. Maybe this works... but this gets more and more nasty this way. ~

/edit3:
Nasty idea out of edit2 actually works. :)
Last edited by han on Wed Jul 27, 2016 5:05 am, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

Okay, now the OpenGLDrv supports both Bink playback for UseDirectDraw=True/False, so this should suffice for everyone else who wants to add the Bink playback support to his RenDev.

Also I added some Bink scaling option (Off, Full, Touch Inside, Touch Outside) and changed startup wizzard to set UseDirectDraw=True for SoftDrv and UseDirectDraw=False otherwise.

What remains before I release the PubSrc is basically:
- Add Bink playback support to the D3DDrv Src.
- Headers for Enforcer.dll/ParticleSystems.dll

Optionally:
- Headers for Editor package.
- Figure out how I fixed the crash for log output longer then 1024 in my Launch project.
- Maybe remove CORE_API macro from FString and add a lot of fixes (I basically need this for building HTK)
- If there is some interesst, I could add the code to Opt-Out of DEP if system policy is Opt-Out.
- Maybe do some code cleanups on the OpenGLDrv src/backport some code of my current OpenGLDrv project, but I kind of wan't to keep the OpenGLDrv src simple in the PubSrc. ~
Last edited by han on Thu Jul 28, 2016 3:14 am, edited 1 time in total.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
[]KAOS[]Casey
OldUnreal Member
Posts: 4497
Joined: Sun Aug 07, 2011 4:22 am
Location: over there

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by []KAOS[]Casey »

Excellent, Han.

I vote for:

definetly... opt-out of DEP. Does 227j have this? If not, it really should.

and maybe the OpenGLDrv cleanups.

Clean openGLdrive is good.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

Excellent, Han.
definetly... opt-out of DEP. Does 227j have this? If not, it really should.
Ok, I'll add the code for it. Afaik Smirftsch added it for 227j.
and maybe the OpenGLDrv cleanups.

Clean openGLdrive is good.
I wouldn't mind making some resonable implementation of the old URenderDevice interface with the old odd rendering in sRGB colorspace (or sth. like that) instead of linear. In the last years I have figured out quite a lot of stuff about it...

Also I have a Laptop which only supports OpenGL 2.1, so I could target OpenGL 2.1 which should keep things simple enough, yet should offer enough to do things resonable.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

Oh and Bink playback works now in D3DDrv too, but without scaling. It basically locks the backbuffer, makes the bink call which writes to it and afterwards flips front and backbuffer, so it shows a bit of a different method for doing it.
HX on Mod DB. Revision on Steam. Löffels on Patreon.
User avatar
han
Global Moderator
Posts: 686
Joined: Wed Dec 10, 2014 12:38 am

Re: Building UTGLR d3d9/ogl for other UE1 games

Post by han »

Some small status update. Basically I haven't touched the source until today for the whole time.

Prior to that I already added Bink playback support to D3DDrv and build headers for the ParticleSystem.dll.

Today I made a few changes to the the headers to build ALAudio, and added initial support for Enforcer to ALAudio.

For bink playback and the audio subsystem it is basically just adding some one time exec command which inits audio for bink playback, otherwise you get no sounds in the movies. Using the bink wav out seems to work without an issues for ALAudio.

As far as CD playback is concerned, they seem to have implemented their own set of cd playback exec command and maybe have disabled some of the music transition code. I added the execs as stubs to ALAudio already and the current idea is that one could implement the exec commands for cd playback basically as playing back ogg files from the harddrive. Some batch script or something similiar conveniant to the user for ripping them of the cd would be nice if someone would like to contribute that.

So basically I just create headers for Enforcer.dll, add the dep code (why did I ask -.-) and will release it...
HX on Mod DB. Revision on Steam. Löffels on Patreon.
Post Reply

Return to “X-COM: Enforcer”