[WMCoolmon]

Since this is what kicked off scripting in the first place, what are people's current plans or thoughts regarding redesigning the HUD with scripting in FS2_Open?

[Wanderer]

Well for 3D HUD.. to be honest unless (certain) current HUD elements can be 'extracted' into scripting and from there via RTT put back on screen a full scripting HUD is going to be pretty massive and probably pretty slowly running monstrosity given that everything that is used in the HUD would have to be rewritten in Lua..

As for 2D.. an option to 'allow' graphics to be drawn 'beyond' the screen limits would be welcome as otherwise moving hud elements either have to be restricted into working only in 'center region' to avoid odd element disappearance (left/top edges) or scaling events (right/bottom edges).

Some new 'gauges' have been tested and also used in some measure (though afaik not in mods or tcs.. just locally either by me or Nuke).. I have made something simple like 'escort reticle' and 'bomb reticle' both to highlight respective objects ingame without actually targetting them.

[Snail]

How about 3D targeting brackets? The lead indicator's throwing me off my aim because my HUD is "crapped out."

[Nuke]

i havent worked on my hud much lately. but one thing is for certian, we need more vars. if experimented with drawing 3d gauges using drawTechModel(), i think. its been awhile sence ive scripted anything. been busy with work and stuff, sisters moving in in a couple weeks and all the preparations are eating up all my time.

3d gauges through drawTechModel can be rather cumbersome, as that was designed for tech room interfaces and loadout screens. not actual hud use. it requires table entries for any models used. also the system for manipulating orientations for the models is kinda wierd. id rather just be able to give it a matrix. id like to be able to give it a pof file directly rather than use up table space. actually a 3d hud element object would be nice with fields such as .Model, .Texture, .ori and so on. should be streamlined to be as fast as possible. defining objects in lua is incredibly slow so having it done in c makes it faster.

im also concerned with the time it takes to render a fully functional hud. ive had cases where calling too many un/rotateVector() functions droppedme to 15-30 fps (on a 8800gts, where i usually get 75). this case was using my remote turret funcs on a deimos, so it called unrotate 6 times per turret, every frame. most of the time this can be avoided but if youre doing something like a custom radar, where you need to call rotateVector() multiple times in a loop, it could drop you to a slide show.

2d huds can probibly be sped up my using more bitmap elements to reduce loops requiring of math (drawing curves uses of trig functions). bitmaps also look better. is far as 2d rendering goes i think we got everything we need. target boxes can be drawn easily in lua, as we can get an objects radius and distance. though a size on screen var would be better, as it would more accurately conform to the ship's footprint on your screen.

another annoyace is that getScreenCoords doesnt return offscreen coordanates. i want to draw flightpath boxes on the hud (like the kind you see in frontier, orbiter, some flightsims) which indicate a path you must follow. parts of theese boxes may only be partly on the screen in some cases and i still want to draw lines that are at least partly visible. you can also render a scripted subspace node or any line based representations of 3d objects on the hud.

i also want to do rtt panels and animated controls, some of which ive done already. the rtt stuff has given me problems though, usually not working and slowing the game down.

id like to see more hud table-scripting integration. main reason would be to be able to mix and match c based gauges with lua based ones. say i want to keep the com menu, but rework everything else. or what if rendering a radar in lua is too slow and i need to use the orb radar.

[takashi]

how about repositioning, redisining? i would like a directive box that looks like a post-it note.

[Snail]

Oh, and have the pong hud thing become a toggle-on-off feature for those long escort missions.

[takashi]

can do....if i have time with all his making of overpowered weapons to stick on the NGTSVRBT spiky fish shaped watergun (AKA colathanasheput).

[Nuke]

oh no, he found the scripting board

[WMCoolmon]

Hmm, that reminds me, I still have a build to release sometime...

[Nuke]

ive been busy with work and re-learning c

[takashi]

i fixed your wacky pong physics nuke. now it behaves like the arcade original. all i need to do is make the ball a mara and tha paddles erinyes.

[Snail]

Can you release the scripting.tbl of pong before you change them to Erinyes and Mara?

[takashi]

Code: [Select]

#Global Hooks

$GameInit:

[

--HudPong (tm)
w = gr.getScreenWidth()
h = gr.getScreenHeight()

poneh = 0
ptwoh = 0
gameh = 200 --you can change this to what
gamew = 220 --ever resolution you want. changed to the shape of a ping pong table.
gamex = w / 2 --set what coords to draw (now set to above reticle)
gamey = h / 5 --the game at here (game center, Y axis).
ballx = gamex
bally = gamey
ballxvel = 2 --changed to make
ballyvel = 3 --it act more like a ping-pong ball
balla = 255
deathmsg = "GAME OVER"

drawpongarea = function(x, y, sx, sy) --pong box here
gr.setColor(0,200,1,255) --pong green
gr.drawLine(x-sx, y+sy, x+sx, y+sy)
gr.drawLine(x-sx, y-sy, x+sx, y-sy)
gr.setColor(0,100,1,20)
gr.drawRectangle(x-sx, y+sy, x+sx, y-sy) --now featuring a transparent back, which is even better now.
end

drawpongpaddle = function(x, y)
gr.setColor(0,10,200,255) --change these number values and change how the paddle looks
gr.drawRectangle(x+5, y+15, x-5, y-15, true)
end

drawpongball = function(x, y, a)
gr.setColor(200,10,10,a) --change these and change the ball
gr.drawCircle(10,x,y)
end

--im nuts

]

$HUD:

[

--HudPong

drawpongarea(gamex,gamey,gamew/2,gameh/2) --draw playing area every frame

if w >= 1024 then --compensate for resolution
maxis1 = ((ms.getY() /  769) * (gameh * 0.9)) --paddels, fixed by takashi to act slightly more realistic
maxis2 = ((ms.getX() / 1019) * (gameh * 0.9))
else
maxis1 = ((ms.getY() / 490) * (gameh * 0.9)) --paddels, see above comment, now in lowres!
maxis2 = ((ms.getX() / 640) * (gameh * 0.9))
end


poneh = (maxis1 + (gamey - (gameh / 2))) + ((gameh - (gameh * 0.9)) / 2)
ptwoh = (maxis2 + (gamey - (gameh / 2))) + ((gameh - (gameh * 0.9)) / 2)
drawpongpaddle(gamex + (gamew/2) - 5, poneh)
drawpongpaddle(gamex - (gamew/2) + 5, ptwoh)

ballx = ballx + ballxvel --move and draw the ball
bally = bally + ballyvel
drawpongball(ballx, bally, balla)

if bally < (gamey - (gameh / 2)) + 5 or bally > (gamey + (gameh / 2)) - 5 then
ballyvel = ballyvel * -1 --bounce off borders
end

if ballx < (gamex - (gamew / 2)) or ballx > (gamex + (gamew / 2)) then --tell the player when he gets castrated and reset the game
gr.setColor(200,200,100,155)
gr.drawString(deathmsg, gamex - (gr.getStringWidth(deathmsg) / 2) , gamey)
balla = balla - 8
if balla < 1 then
ballx = gamex
bally = gamey
balla = 255
end
end

if (ballx < (gamex - (gamew / 2)) + 15 and bally > ptwoh - 15 and bally < ptwoh + 15) or (ballx > (gamex + (gamew / 2)) - 15 and bally > poneh - 15 and bally < poneh + 15) then
ballxvel = ballxvel * -1 --bounce off paddles
end

--nuts indeed

]

#End

small math fixes. nothing more. and a few color tweaks....

[Nuke]

al you really did was change a couple numbers.

[takashi]

see previous statement.

[Cobra]

I didn't see this till now, but would it be possible to work the HUD into (or onto) a cockpit, like for Wing Commander Saga? Or is that basically what Wanderer said?

[WMCoolmon]

In theory, yes, if RTT stuff is working.

[Nuke]

ive never managed to get it working. i was under the impression that i had to wait for shaders to have it work fast enough to be playable. on  the other hand ive already got ships with working throttles/stickcs, ect. but im still pretty much just testing it. theres still the matter of every little lever and gismo slowing down the renderer though.

[WMCoolmon]

That's a modeling issue. You should be UVmapping all the HUD components to a separate texture. One separate texture. There's no point in having more textures than necessary, but whatever texture is used for the HUD will have to be redrawn each frame.

Although if you wanted to reduce the workload, you could use a static texture and only redraw the HUD components every 5 frames or so. I don't know what the best number of frames is to use; Bobb is more well-versed in the differences between static and dynamic textures.

And you'd probably be best off storing a variable of the setting that actually controls model movements (Eg a Throttle_pct variable) and only changing the model's submodel positions when that changes, to reduce the calculations done each frame that the HUD is drawn.

[Nuke]

id probibly go for a refresh every 15 frames, drawing the gauges on the 14th frame so that all the 15th frame needs to do is draw that info to the texture. i actually created a simple plane once and tryed to get hud pong to draw to it, but it never really worked. can you by any chance update your old hello world example script?