Hard Light Productions Forums
Modding, Mission Design, and Coding => FS2 Open Coding - The Source Code Project (SCP) => Test Builds => Topic started by: Swifty on October 15, 2012, 01:55:29 am
-
A gift from Diaspora. Seeing how DRADIS RTT has been tested, I feel general HUD to cockpit RTT is now ready to apply to other gauges. It's not an exhaustive proof of concept, but just enough to get modders to play with this feature.
I used Vasudan Admiral's Terran cockpit and Scooby's Banshee cockpit. (Scooby plz)
(http://i.imgur.com/q5kYv.png)
(http://i.imgur.com/sehzH.jpg)
Extract into your Freespace2 installation and set the Launcher mod to cockpitmod. Run the included EXEs. Use either the Ulysses or the Myrmidon. The binaries are based off of fs2open/trunk revision 9263 without any modifications.
http://www.mediafire.com/?2xvyf7gq8k6v20h
-
oh goodie, i can delete a massive swath of bugridden rtt script.
-
That's awesome !!
-
I wanna adapt my fighters to use this, looks boss.
-
Finally. :yes: Can't wait to play around with that.
-
Whoaaa ! :eek:
That add's a lot of immersion to the game.
Congrats for adding this new function to a game engine that never ever had such a thing. That's 1337 skill ;)
-
I wouldn't say that it was exclusively my 1337 skill that let this happen. :D
It was mostly a combination of a lot of efforts from different programmers over the years. Taylor had already written in framebuffer object support which let us have render to texture capabilities. Nuke's cockpit RTT scripts helped me prototype the feature before I was able to solidify the code structure and interfaces in the game engine.
-
good thing those scripts were useful to someone. scripting is an awesome place to prototype new engine features.
any chance of getting an on gauge draw scripting hook (render context sensitive of course, stuff could either end up being drawn to the hud or texture as per hud_gauges.tbl configuration), and a dummy gauge type that doesnt do anything (other that get used in aforementioned hook as a scripted gauge)?
-
Woooooo :eek2:
I just found this thread. I need to know how to implement this :)
-
Diaspora did it.. check their modpack.
-
Just tried your tables with saga's engine build... no go, I'll have to wait till i convert things over to a newer build.
-
Well, Saga locked and forked their build long before any of the features necessary for this made it into the official trunk. It's never going to work with their build, unless they decide to update.
-
Ya, I'm going to have to someday rebuild/import the most important tables from saga into the newer builds (weapons, ships, sounds). Hardest part is one table effects another table effects another table... ugh
-
Yaaa got it to work... but I just noticed something: $Base: (1440, 800) Thats ok if your running at that resolution, we need a way of automating this.
Also do you lose all your other hud display controls when this is active?
-
what you can do is just make a separate gauge config with no resolution filters with your HUD displays defined in there.
For resolution specific gauges, just make with their respective resolution filters as usual. Kind of clunky, sorry.
-
Wait..what? I'm a bit confused now. Is the display offset, display size and canvas size based on the screen resolution or the hud texture resolution?
edit: looks like some of it's based on texture resolution.
Correct me if I'm wrong but:
Display Size = how big of the area in the texture this covers
Display Offset = where the area in the texture starts at [top-left corner]
$Base = size of texture (i've noticed putting in a much smaller value will cause the hud to be displayed in the original location)
position = sorta an offset that gets used for the rendered hud (let's you pad the hud mesh)
canva size = not exactly sure what this does :confused: All i know is putting smaller numbers produces larger scaling values. Is there any formula for this?
Also on another note (perhaps because i have a crummy GT610, but when the hud is visible i lose half my framerate.
-
They will always be based off the HUD texture resolution. When defining a gauge to render to target, it will ignore base resolution.
-
Also just learned that the uv area size of hud texture doesn't seem to matter much, which is a good thing and bad thing (I can squeeze more controls into the hud, but i have to redo the ship cockpit uv).
Still haven't found out how canvas size exactly works.
-
Canvas size defines the scale factor of your gauges before they are actually drawn to texture.
Say you have a 500x500 gauge but want to shrink it down to a 250x250 section on a texture. You set the Canvas Size to 500, 500 while the Display Size is set to 250, 250.
Say you have a 250x250 gauge but want to enlarge it up to a 500x500 section on a texture. You set the Canvas Size to 250, 250 while the Display Size is set to 500, 500
-
Some of it's making sense.. still confused about other parts.
Let me get this right, let's say I have a player shield thats coords on the texture are (0,767) and goes down to (256, 1024)... basically (256*256).
so...
Position:(0,0)
Canvas Size: (256,256)
Display Offset (0,767)
Display Size (256,256)
The result is a shield icon that's taking up less than 1/4 the actual area it's suppose to. In face i have to take Display size up to (550,550). Any clue why?
On another note... there's +Center Recticle, but are there any other aiming controls? Freespace has those curved arches on both sides (sorta like this: http://www.firingsquad.com/games/freespace-2/images/28.jpg) And on that note, transparency, does this do anything for it or should the hud texture have transparent areas?
Edit: Nope that doesn't work, it makes the hud part invisible. :blah:
-
Ok I'm getting completely confused. You can scale up but you can't scale down?
My weapons gauge is somehow being clipped ("Promethus ") instead of ("Promethus S")
If canvas width == display size width, everything looks ok, just goes beyond the hud mesh
If canvas width < display size width, the gauge gets stretched out
if canvas width > display size width, the gauge gets cropped out too soon ("Prom") and the rest is black. There doesn't seem to be any scaling on the gauge and the cropping rapidly increases as the difference becomes bigger (20 point difference completely hides the gauge)
If I leave canvas out completely, display size is irrelevant (you can throw huge numbers in there and it looks the same)
BTW this is 3.7 RC 1 build.
-
Hmmm was playing around with the hud model and I found something interesting. The weapons display border fills up the complete area correctly but the name of the weapon gets cut off.
I don't see anything in the wiki about text width just text height, is there something missing?
(http://img.photobucket.com/albums/v356/Shodan_AI/screen0001.jpg~original)
-
i'm having the exact same problem with my cockpit mod, only that it gets cut off to the left....
what is weird: this doesn't happen always, sometimes it's fine too
what is even more weird: with some weapons equipped it's always cut of, with others only sometimes
-
Ohhh I think I just had a light bulb come on.... You basically need to know the size of the hud control before-hand. Hmmmm.... :confused:
Edit: nope that doesn't seem to help... Radar.ani is 105*85. Canvas size: (105, 85), Display Size: 105, 85) only part of the radar shows up.
Double edit: Also it seems the talking head animation isn't effected by this. The word "Message" will change in size but the ani won't.
-
I think talking heads may be kind of tricky because the talking head animations use a seperate render path from the HUD.
If you guys want me to look into any specific bugs, please feel welcome to upload any assets and data files that replicate potential bugs.