UDK, TextureRenderTarget2D, SetExternalTexture() and Scaleform 4

May 18th, 2012 Edit: It appears that the May 2012 release of UDK fixes this issue (reference). Thanks to Steven Webster for letting me know!

Punch UDK in its stupid face!

Perhaps I'm not being clear enough. So a couple weeks ago, I decided to build the user interface for my Senior Project (a UDK based game) using Scaleform 4, a recent addition to Unreal. Up until the November 2011 release, UDK only supported Scaleform 3, which in turn only allowed developers to use ActionScript 2.0 when creating interfaces in Flash. The last time I touched ActionScript 2.0 was when I was in the eleventh grade. I think I made a pong game. So obviously, I was pleased to hear that I could use AS3, which I had learned to a reasonable extent only a few years ago.

Bad move.

Since then, I've been running into issue after issue, and it was really my own fault. I shouldn't have expected such fresh features to be well supported. A lot of major elements are quite broken. For the most part, there have been solid workarounds, but now I've run into something that I cannot avoid.

I've been trying to incorporate a preview window for 3D components for things like the inventory screen, where clicking on an item would load up a rotating view of the object. I found out how to do this, in theory - it involves taking what is essentially a camera (SceneCapture2DActor) and having it render directly to a texture (TextureRenderTarget2D). Then, SetExternalTexture() is used to replace an image texture in the Scaleform UI at runtime. Effectively, you are given a sneak-peak at something rendered from off screen. The technique relies heavily on the notion of dynamic textures, which can be used to create computer screens, water reflections, etc. (Check out these links for more information on Rendering to Texture and Swapping Render Targets into Scaleform UIs).

Unfortunately, where the plan fell through was at the very end - SetExternalTexture(), unfortunately, causes the whole program to crash when used with a TextureRenderTarget2D. I found some complaints about this on the Epic forums, but unfortunately it doesn't seem to be high on the list of priorities. People have been complaining about it since early December at least, and to my dismay, the January 2012 release (which came out today, or very recently) has the same problem.

So, I've decided to bite the bullet and revert to the October 2011 release of UDK, and switch out in favour of AS2. I'm really frustrated, but since I'm more familiar now with a lot of the processes and issues, I should hopefully be able to redo the work I did in the past couple of weeks in much less time. Unfortunately, I have a meeting with my Senior Project advisor on Friday, and I will definitely be falling short of my biweekly goals. Gat dangit.

UDK Woes

So yesterday I buckled down and spent the whole day working on getting the main menu hooked up for my senior project game. Needless to say, I didn't get anywhere near as far with it as I would have liked, but I really figured a lot of stuff out - stuff I didn't expect to be quite so challenging. Granted, some of those things were due to my own stupidity (accidentally saving maps in the folder of an older UDK release and wondering why it kept complaining about external packages, and also not noticing when my debug log statements were showing up in the window amongst all of the other crap UDK feels like printing).

So it seems that taking the ActionScript 3 route was not the greatest decision - it's only been supported in UDK since the November release, so needless to say they're still working out the kinks, and some of the AS3 specific details are sparsely documented. Still, I truck on.

I ran into a couple major issues - one of those being that my custom GFxMoviePlayer class' WidgetInitialized method not being called. At all. Funny thing! This is supposed to be the official, supported method of having UnrealScript recognize the initialization of various components within a flash file (buttons, for example - so you can hook up event listeners and have UnrealScript handle the clicks). Totally busted. The developers are aware of this, however, and the problem's fixed on their end - so it should be out in the next release. Unfortunately, I have to get these things working now. More info here.

Thankfully, the link above suggested a convenient workaround, which brings us to the very rudimentary elements of flash-unreal communication. Using ExternalInterface.call lets you call any UnrealScript method within the custom GFxMoviePlayer class from ActionScript. Generally used as follows: ExternalInterface.call("myFunctionName","firstParameter","secondParameter",...)

Unfortunately, I hit another speed bump soon after - Adding event listeners in UnrealScript doesn't seem to work! So I could (I think) send the button objects to unreal, but couldn't do anything with them. Some forum posts suggested that the name of the event type had changed from 'CLIK_press' to 'CLIK_buttonPress', but it still didn't work for me. So at the end of the day, I decided to rely on the flash end to handle everything to do with the input, and just send data to unreal using ExternalInterface.call. I'm not sure how this would affect performance, but since it's a relatively unintensive menu system, it shouldn't be too bad.

At the end of the day, I ended up only managing to get a menu system with the Quit button working... but it's something.