[KeldorKatarn]

Is anyone working on this?

In principle it should be an alternative to the current hud, using colored ANIs or EFFs and their frames to display the gauges.
For shields more frames would be needed for the shield status since the technique that's used with the monochrome ones to have frame per quadrant wouldn't work.

Saga is especially interested in this, since in conjuncture with being able to position each gauge per fighter we'd be a giant step closer to replicating the WC3 HUD layout and appearance.

I tried playing around a bit in the code, trying to draw a colored ani frame to the HUD, but somehow I didn't look through the graphics code. I managed to draw the thing, but it apeared monochrome white, no matter what I did. Some colors where left away and not displayed so the ani had gaps. I suspect the rendering states have to be set differently but since the graphics API is not exactly well documented I don't really see where the problem is.
I know there's a code freeze but if anyone has the time to help me with the rendering part, I think I could get the logic part of the code done by myself and to be included once 3.6.10 is out.

Also for some reason I couldn't get an eff to be displayed at all although from what I can see those are handled exactly like anis, just the loading code is different. But as those are 24/32bit they are probably not configured right in terms of the render states or the render target.

Any insights here would be appreciated. I BASICALLY would already be happy if someone could tell me how to draw a colored bitmap onto the screen from inside the HUD code.

[Topgun]

Why not just send the HUD file along with the game (or mod)?

[Backslash]

Why not just send the HUD file along with the game (or mod)?

Read it again.  The 'hud file' only controls the single color for each gauge.  The HUD currently takes a ANI in grayscale, colors and saturates it a color from the options screen.  He (and I) want to make gauges that show ANI (or EFF) files as they truly are, with 8-bit or even 16 or 24-bit color.

[portej05]

hmm, this is my first foray into this section of the code.... so I'm probably going to be wrong here (forgive me... please!)
In my checkout of the code (5004), the gauges seem to be drawn at line 1906 of hud.cpp using GR_AABITMAP(a,b,c) defined in hud.h:

Code: [Select]

#define GR_AABITMAP(a, b, c) { int jx, jy; if(emp_should_blit_gauge()) { gr_set_bitmap(a); jx = b; jy = c; emp_hud_jitter(&jx, &jy); gr_aabitmap(jx, jy); } }

So it sets the bitmap and then calls gr_aabitmap which is really (at least, in the OpenGL build) gr_opengl_aabitmap.
I'm not sure why gr_opengl_bitmap has been commented out, but it probably breaks something.
I'd try adding code just before the

Code: [Select]

if(image_ids[i].first_frame != -1) on line 1904 of hud.cpp checking for a flag to say 'use full colour gauges' calling gr_opengl_bitmap, but I haven't got the time to try this out at the moment.
Could one of the code wizards (yes, you! ) advise if I'm totally insane and off the beaten track?
I'm not sure about side effects of these functions (including gl states) or how to go about adding such a flag.

[Nuke]

i always thought we should have the option to use 24/32 bit textures (and effs) for hud elements. it would sure as hell make the hud easyer to work on. the huds limitations to images with fixed pallettes and 16 shade animations for the sake of color customizability has always annoyed me. id rather abolish that or at least make an iption to allow for colored hud graphics. it would look better than the current hud. it would be wise to make it global and allow new formats to be used on all icons, for briefing, loadout, and anywhere else that uses 2d icon images.

[portej05]

I think (but can't confirm atm) that the flashing effects are obtained by changing the alpha value of the bitmap. I'm not sure how this would work with full colour elements.

Can someone enlighten me about #ifdef NEW_HUD - there's no point taking a crack at this if someone else already is

[Nuke]

well if the hud uses hardware surfaces like it should, think it would be possible to dynamically change the alpha values, otherwise animate the blinks.

i just think 16 color images are ugly and should be replaced by something more modern.

[chief1983]

Me too let's do SVG images for the HUD

Seriously though, a bit of an update could be nice but I'm hoping for the RTT HUD on a cockpit myself.

[JGZinv]

FringeSpace needs more of the animated capability for the HUD, although some simple
things are possible with a lot of tweaking now.

If I could say even work with making animated GIFs, it'd be easier than having
to do PCXs.

Being able to set the colors of the art would be nice, taking it from the file itself.
However I think the adjustable color system of the current setup has it's purposes too.
A blend would be best solution if at all reasonably possible.

[Nuke]

Me too let's do SVG images for the HUD

Seriously though, a bit of an update could be nice but I'm hoping for the RTT HUD on a cockpit myself.

i should probibly work on that some more, though lately ive been more intrested in programming with opengl. id like a system where every hud element is rtted to a texture (in an array of hud elements). then you can not only move these textures around on the hud (possibly on the fly with the mouse) but also apply them to anything else you can stick a texture on. the alternative would be to render the whole hud as one texture, which could optionally be drawn on some polygons in the cockpit model. it would be better for the dynamic hud idea, however theres the added math of determining certain hud elements, like lead indicators, based on view angle, distance from the camera, fov, etc. 

you can recreate the gauges in scripting and render those to the panel, but it seems somewhat redundant if you ask me. then again the hud is supposed to be a simplified version of the panel, so more complex instruments might look better down there. frankly im not sure i understand how scripting works anymore (you never see my scripts run newer hooks for example).

[portej05]

Actually, modifying this is going to be a lot more complex than just one code change - components of the HUD are drawn in lots of separate functions (anyone got any documentation?)

[Swifty]

Me too let's do SVG images for the HUD

Seriously though, a bit of an update could be nice but I'm hoping for the RTT HUD on a cockpit myself.

i should probibly work on that some more, though lately ive been more intrested in programming with opengl. id like a system where every hud element is rtted to a texture (in an array of hud elements). then you can not only move these textures around on the hud (possibly on the fly with the mouse) but also apply them to anything else you can stick a texture on. the alternative would be to render the whole hud as one texture, which could optionally be drawn on some polygons in the cockpit model. it would be better for the dynamic hud idea, however theres the added math of determining certain hud elements, like lead indicators, based on view angle, distance from the camera, fov, etc. 

you can recreate the gauges in scripting and render those to the panel, but it seems somewhat redundant if you ask me. then again the hud is supposed to be a simplified version of the panel, so more complex instruments might look better down there. frankly im not sure i understand how scripting works anymore (you never see my scripts run newer hooks for example).

I'm actually toying with that. I've been experimenting with rendering HUD elements to a texture using OpenGL render targets and making the HUD texture available for drawing by creating methods in LUA called drawRadar(), drawTargetBox(), etc. That way if you have a display on a cockpit model you want the target box on, you can just call drawTargetBox() on a texture, then replace the display screen texture with the one you just rendered on.

[WMCoolmon]

I think (but can't confirm atm) that the flashing effects are obtained by changing the alpha value of the bitmap. I'm not sure how this would work with full colour elements.

Can someone enlighten me about #ifdef NEW_HUD - there's no point taking a crack at this if someone else already is

NEW_HUD was a HUD designed with the idea that every gauge would be implemented as its own separate class that depended on an object pointer that could be any ship whatsoever, which would be fully object-oriented and flexible like the gauges in hud_gauges.tbl. There's some drawing code to do different shapes for the HUD and so on, as well as an integrated variable class that lets you specify strings and integers and so on and autoconverts those to whatever form is needed. It's been years since it was worked on. Might be a good starting point for a new HUD system but I thought somebody else was working on something completely different, and much more ambitious.

hmm, this is my first foray into this section of the code.... so I'm probably going to be wrong here (forgive me... please!)
In my checkout of the code (5004), the gauges seem to be drawn at line 1906 of hud.cpp using GR_AABITMAP(a,b,c) defined in hud.h:

Code: [Select]

#define GR_AABITMAP(a, b, c) { int jx, jy; if(emp_should_blit_gauge()) { gr_set_bitmap(a); jx = b; jy = c; emp_hud_jitter(&jx, &jy); gr_aabitmap(jx, jy); } }

So it sets the bitmap and then calls gr_aabitmap which is really (at least, in the OpenGL build) gr_opengl_aabitmap.
I'm not sure why gr_opengl_bitmap has been commented out, but it probably breaks something.
I'd try adding code just before the

Code: [Select]

if(image_ids[i].first_frame != -1) on line 1904 of hud.cpp checking for a flag to say 'use full colour gauges' calling gr_opengl_bitmap, but I haven't got the time to try this out at the moment.
Could one of the code wizards (yes, you! ) advise if I'm totally insane and off the beaten track?
I'm not sure about side effects of these functions (including gl states) or how to go about adding such a flag.

AABITMAP is right. gr_aabitmap draws the current bitmap (gr_set_bitmap) in shades of the current color (gr_set_color). There is an analogous function in scripting that you can play with (drawMonochromeImage) that basically just calls aabitmap. A hud_gauges flag or something would be the quick and easy solution.

[portej05]

Does anybody want me to pursue this (i.e. If anybody is already working on this squeak now - a duplication of efforts is a pain in the rear end)
Are there any documents on how the bitmaps section works?

[Backslash]

I've been working off and on, on the coordinates part of this... basically I'm expanding hud_gauges.tbl to include every gauge and part.  This has the nice bonus of being able to customize the hud per-ship.  It's taking me longer than planned, Real Life reared up and bit me in the meantime...

Unfortunately I started this a while ago so it was based on the old 'head' 'branch' which we now call unstable.  I'm in the process of porting it to a trunk build.  I'm not sure what you plan to work on, but I'd be glad to share my work with you if you're interested.  I'm not the best coder, so it'd be nice to have someone else help fill in my gaps.

[portej05]

ah cool
The basic plan is to execute in a few steps:
1) Create some documentation for the HUD system (how it works and where it pulls data from)
2) Find some documentation for the drawing system (I've got no idea how it works atm)

This is my first real foray into the codebase, so I'm going to be a little slower than if I knew it.
I think the aim at the moment (hence figuring out how it currently works) is to add some support for full coloured bitmaps, but it is starting to get ugly - you've just pointed out another dependency that I missed!

There appears to be an earlier effort to create a new HUD system - is this a path you want to go down? or would you prefer a cleanup and tack on the full coloured bitmaps?

I'm going to be a bit slow over the next week or two (real life!), but after that I will have some larger chunks of time to look at this

I'll PM you my email address (I'm not sure if you can just email me from the forum software...) - if you could send me what you've done, that would be great!

EDIT: Fix dodgy some grammar
EDIT2: Fixed*

[portej05]

Any insights here would be appreciated. I BASICALLY would already be happy if someone could tell me how to draw a colored bitmap onto the screen from inside the HUD code.

The closest I can figure (I haven't tried this yet - haven't figured out how to get a coloured bitmap into the system yet!) is to do this:

Code: [Select]

gr_set_bitmap(bitmap_id);
gr_bitmap(x, y);
Where bitmap_id is the index of the bitmap you want to use and x and y are the 640x480 or 1024x768 coordinates
There's another function g3_draw_2d_poly_bitmap, but it is wrapped by gr_bitmap, so I'd use that rather than g3_draw_2d_poly_bitmap.
Hope that helps

[WMCoolmon]

Yeah, that's right. Several of the scripting functions implement 2d drawing stuffs so you might want to take a look at those in lua.cpp. They do use more advanced functions for resizing/cropping the image, and also use absolute screen coordinates where possible.

[portej05]

hmm.. there have been a lot of ideas in this thread 

Does anybody know how they want to proceed with this?

Looking at the SCP Dev Roadmap, the HUD is on the hitlist for 3.7.0.
I do like the SVG idea for HUD elements .

[chief1983]

That dev roadmap, really doesn't mean much these days I don't think.  With the hopefully accelerated release process, it'll be more, get a few features in, test them, release.  All that roadmap really represents is the amount of time and complexity estimated for each feature on it.  If it's done in Lua then it really has nothing to do with the roadmap.  And if any code changes aren't as bad as people expected them to be, then it shouldn't be an issue to get them in during the next open commit cycle.