logo
Page Index Toggle Pages: [1] 2  Send TopicPrint
Hot Topic (More than 10 Replies) Building UTGLR d3d9/ogl for other UE1 games (Read 1559 times)
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Building UTGLR d3d9/ogl for other UE1 games
Jul 25th, 2016 at 4:40am
Print Post  
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.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #1 - Jul 25th, 2016 at 12:52pm
Print Post  
[]KAOS[]Casey wrote on Jul 25th, 2016 at 4:40am:
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.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #2 - Jul 25th, 2016 at 5:13pm
Print Post  
I'll try changing the signature in the headers to match this and see what happens.

Thanks Han.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #3 - Jul 25th, 2016 at 6:56pm
Print Post  
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?
  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #4 - Jul 25th, 2016 at 7:39pm
Print Post  
han wrote on Jul 25th, 2016 at 6:56pm:
/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?
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #5 - Jul 25th, 2016 at 9:28pm
Print Post  
[]KAOS[]Casey wrote on Jul 25th, 2016 at 7:39pm:
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.

Quote:
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:
Quote:
                 guard(DumpNames);
                 debugf( TEXT("------------ Dumping Hardcoded Names ------------------") );
                 for ( INT i=0; i<FName::GetMaxNames(); i++ )
                 {
                       FNameEntry* Entry = FName::GetEntry(i);
                       if ( Entry && (Entry->Flags & 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.

Quote:
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.
  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #6 - Jul 26th, 2016 at 12:07am
Print Post  
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.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #7 - Jul 26th, 2016 at 1:27am
Print Post  
[]KAOS[]Casey wrote on Jul 26th, 2016 at 12:07am:
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\<CppClassName>.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.
  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #8 - Jul 26th, 2016 at 2:24am
Print Post  
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.
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #9 - Jul 26th, 2016 at 2:29am
Print Post  
[]KAOS[]Casey wrote on Jul 26th, 2016 at 2:24am:
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.
  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #10 - Jul 26th, 2016 at 6:50pm
Print Post  
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. Smiley




« Last Edit: Jul 26th, 2016 at 11:24pm by han »  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #11 - Jul 26th, 2016 at 10:00pm
Print Post  
Hmm. Wonder if the frames get passed to the renderer somehow to just draw as a sprite? Still, progress!
  
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #12 - Jul 26th, 2016 at 11:23pm
Print Post  
[]KAOS[]Casey wrote on Jul 26th, 2016 at 10:00pm:
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. Smiley
« Last Edit: Jul 27th, 2016 at 5:05am by han »  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
han
Global Moderator
Unreal Rendering Guru
Developer Team
*****
Offline


Oldunreal member

Posts: 595
Location: Germany
Joined: Dec 10th, 2014
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #13 - Jul 28th, 2016 at 3:14am
Print Post  
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. ~
  

HX on Mod DB. Revision on Steam. Löffels on Patreon.
Back to top
 
IP Logged
 
[]KAOS[]Casey
Developer Team
Betatester
Offline


nedm

Posts: 3214
Joined: Aug 7th, 2011
Gender: Male
Re: Building UTGLR d3d9/ogl for other UE1 games
Reply #14 - Jul 28th, 2016 at 6:11am
Print Post  
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.
  
Back to top
 
IP Logged
 
Page Index Toggle Pages: [1] 2 
Send TopicPrint
Bookmarks: del.icio.us Digg Facebook Google Google+ Linked in reddit StumbleUpon Twitter Yahoo