GUI objects access ImageMaps

#1 Unfortunately, the GUI is core-TGE and I can't see this happening in the short-term. I know that sounds a little brutal but changing the core-TGE at this point is no small undertaking. I do share the ideal though and a common scheme would be wonderful, almost essential I'd say.

- Melv.

#2 Would it require changing core TGE? I haven't spent any time in that code, so I certainly don't know one way or another. However, is it not possible to derive a set of "T2D" windows from the current TGE GUI windows, such that the derived classes can draw themselves using one or more imagemaps?

#3 I have a "hack" solution that I am currently developing that may do what you want. It works in a similar fashion to the guiBitmapCtrl but instead of rendering a bitmap, it renders a t2dSceneObject. The guiT2DCtrl class (as I call it) contains the string name of a t2dSceneObject that it uses to render. I also had to make custom rendering code (I call these functions renderAt) to make a scene object render at a specific GUI location rather than the scene object's current scene location. If you wish to render a t2dSceneObject *only* in the gui and not in the t2dScene *and* gui, there's still further modifications that need to be made. Long story short, with this method, a scene object must exist somewhere in a scenegraph to be updated and rendered properly. So if you want to share bitmaps between the torque GUI and T2D scene, what you would do is create a t2dStaticSprite and add it to the guiT2DCtrl class so that it can hijack the scene object's rendering code.

Like I said, all of this is a hack solution. It does, however, appear to work. I can currently render scene objects inside the gui. My current problem is converting t2d coordinates into GUI coordinates so that the scene object appears at a respectable size instead of rendering really tiny. When I get this done, I'll post a resource. Unfortunately the resource will require some significant modifications to almost all the scene objects and derived classes (we need to add the renderAt functions) unless we can convince Melv and Co. to add this functionality for us. "renderAt" or something similar, has other potential uses as well, so perhaps this is not an unreasonable request...

#4 I guess more information on what exactly is required would help. Talking about the "GUI" is very broad but I think I understand the basic problem; TGE GUI only supports a FULL frame file-image for objects such as bitmap-button or bitmap-background etc. Presumably we are not talking about GUI skins here as that is a whole different ball game altogether?

There are resources showing how to use T2D objects as GUI element although only basic ones such as buttons. Are you only interested in buttons and background-image controls?

It's obviously not possible to pass the TGE GUI controls image-map references directly so a solution would be to create some new GUI controls that meet your needs? These can easily utilise T2D image-maps as they are globally available. Here's one I put together this evening for you (because it's Xmas and I'm feeling particularly happy) ... guiT2DBackgroundCtrl. Add this to T2D (at least alpha#1).

This took about 30-mins to do. Add it to the GUI using the GUI-editor as normal; you can even use child controls within it if you like. Using the GUI-editor, select the image-map/frame to display and toggle the optional "wrap" field to select if you want the frame to be wrapped within the control-window. See Image Below.

As you can see, you can quite easily use the image-map system for your own purposes.

Hope this helps,

- Melv.

#5 Melv, I don't know about the intent of the original poster, but I personally would like to see something
like this:
guiT2DCtrl.zip

My "guiT2DControl" could feasibly render any T2D component, including animated sprites, inside a standard
torque GUI. The current implementation is admittedly hackish, but if we could get something like this integrated into the next release of T2D, I think a lot of people would find it useful.

I do appreciate your "guiT2DBackgroundCtrl" as well though. This is probably a better solution for simple images and the like. I'd like to see it in the next release as well.

#6 Finally got around to trying those 2 solutions...

Melv: guiT2DBackgroundCtrl is really cool and easy to use, but doesn't actually work for what I need, basically because I want to use blendcolour to make a variety of colors out of the same graphic

Matt: guiT2Dctrl totally looks like it will totally work for me, but I can't get it to compile. There are enough errors that I got overwhelmed trying to decipher the problems myself. Are those files working in the new Alpha, or...?

Both of these things are really impressive!

#7 @Spider: I believe that code works with the first alpha. What errors are you getting? Sorry for taking so long to reply. I've been busy with work related activities :( I should be around more now.

#8 @Matthew

Okay, I started over and tried it again, from the top, and made some progress. I don't know what I did before, but this time I got only 2 compile errors and had to change this line:

getParentPhysicsModel().renderCollisionPoly();

to

getParentPhysics().renderCollisionBounds();

I don't even know if this is right, but I am not going to be using collision bounds, so I don't care too much.

Now to see if I can make this thing work in my game...

#9 @Matthew:

Hmmmmm. When I try the sample, I see the sprite in the middle of my scenegraph, but I don't see it in the GUI. I wonder if I'm setting it up properly. Do you think you could copy me the actual gui declaration code? Maybe I'm not doing that right.

#10 I have updated the zip (link in previous post) with the client.cs and mainScreenGui.gui I used to create this:

The small asteroid is the actual t2dSceneObject sprite. The large asteroid is the sprite displayed as part of a standard Torque GUI (the asteroid's rendering function was hijacked). Unfortunately, you will note that the sprite displayed in the GUI does not take up the entire bounding GUI bounding box like it should. I am still uncertain why this happens but I also haven't had time to give this problem a lot of thought lately. I am certain the bug is something fairly simple. The point of this demo is: it is possible to render T2D scene objects inside the standard Torque GUI and it would be *nice* if the T2D dev team gave us functions to make things like this easier *hint* *hint*.

#11 Agreed. This would be a sweet feature that, I suspect, might slowly take over the whole GUI system... T2D objects have an awful lot of nice features that the GUI would do well to incorporate.

#12 I agree that allowing T2D objects to meld better with GuiObject is a good idea, specifically adding something that allows an arbitrary call into the render function. Time is the only thing stopping me at the moment.

I'll try my best to come back to this over the next few days and see what input I can provide. Pretty sick at the moment with flu-like symptoms. Hopefully I'll feel better soon, bah!

If I don't them please kick me. ;)

- Melv.

#13 Hey, that's awesome Melv. Knowing that you see the value of this is enough for me. I know it'll get done when it comes up in the priority list.

GET SOME REST! DRINK SOME TEA! I know you are working your ass off on this and if I were in the same city I'd come over and make you a big thank you soup:)

#14 As soon as any commercial TGE/TSE client asks about drastic changes to the GUI system, we point them at using T2D as a "super-gui" layer. It's just too powerful to try and re-implement all the awesome things that it can do to recommend otherwise!

#15 I've added a feature request to T2D (#1197).

- Melv.

#16 I spent a little time this evening looking at this issue. One of the things that is obvious is that adding a special render function to each and every object isn't going to work. Alright, it'd work but it'd suck major booty.

Something like adding a special core "renderAt()" would seem better but after looking at this for a few minutes, it becomes obvious that the best way to deal with this is the same way that the t2dSceneWindow does, after all it's just a standard GuiControl-based component rendering T2D objects. The only difference is that it renders a specific graph of objects. Here we only want a single selected object so things are much easier.

So what I've done as a test is to create a "guiT2DObjectCtrl" control, specifically renamed just so it doesn't conflict with the one above. It works almost identically to Matthews "guiT2DCtrl" object with differences in how it handles the object-pointer but more importantly, it renders the selected object (no matter what object it is), into the gui-controls bounds and doesn't require any special interface contract with T2D objects.

As before, use "setSceneObject(t2d-object-id/name)" on the control to specify the object to render. The control references the object using a smart-pointer so if the object gets destroyed, the control will simply render nothing.

This thing is totally unsupported apart from for those people who've already posted on this thread so far so please go and try it and let me know your results/comments. There's plenty of functionality that can be added, some sizing/scaling ones are probably the most important to have next, especially if you select things like particle-effects or tile-maps (yes you can selected these, I did say any object) ;)

Anyway, here's the code, a little movie of it working and a picture just because too much text makes baby Jesus cry.

guiT2dObjectCtrl ZIP - Add this to T2D alpha#3b. If you used another alpha, you may need to alter the header paths a little.

guiT2dObjectCtrl Movie



Enjoy.

- Melv.

#17 Well, I'm impressed. Feel free to assume the simpler name if you're so inclined. It doesn't seem like anyone is going to use my more complex solution if you've come up with something that works in the existing frame work. Can't wait to look at the code and see what you did ;)

#18 Don't be too impressed Matthew, it's essentially your code with the coordinate conversion you were looking for in the render function. You are most welcome to it though. :)

If you've any ideas on how you think it'd be best to add some kind of scaling functions then be all means let me know.

- Melv.