Scoreboard

[Kr3m]

This isn't so much an issue with wolfcamql as a question.

So it seems the scoreboard is no longer handled by the TA HUD scripting as it is in TA. I noticed this when copying a custom TA HUD I'd created for my Team Arena+ mod. I was thinking about porting some of your code to upgrade the TA HUD scripting to support widescreen and some of the other features, but man does this look cumbersome. You've clearly put a lot of work into this. I'm also hoping not to break my existing HUD-scaling features. The problem I'm having is depending on the mod, my codebase is based on either the baseq3a SDK licensed code base or the GPL version of baseq3a that I recently released with permission from Cyrax rather than ioquake3.

I'm still not as experienced with Q3A code as I'd like to be, and honestly only touched C a handful of times in the past 20 years until last year. I've made a lot of progress and have worked on some pretty cool stuff, but I'm wondering if you might have some tips on how best to port at least the widescreen code to start out with before I dive into adding some other features that could be useful.

[brugal]

Take a look at the "cg_widescreen" section in the README-wolfcam.txt. id's solution to keep supporting 640x480 coordinate values in widescreen was to have 3 potential areas where the HUD could be rendered unstretched: left, center, and right. A 'widescreen' property was added to HUD elements that lets you specify if the coordinates where meant to be aligned right or left or centered. Ex:

menuDef {
name "AmmoMenu"
widescreen WIDESCREEN_CENTER
fullScreen MENU_FALSE
visible MENU_TRUE
rect 145 425 99 50
...

To support that you would need to pass that value down to all the drawing primitives. Ex:

code/ui/ui_shared.h

typedef struct {
qhandle_t (*registerShaderNoMip) (const char *p);
void (*setColor) (const vec4_t v);
void (*drawHandlePic) (float x, float y, float w, float h, qhandle_t asset, int widescreen, rectDef_t menuRect);
void (*drawStretchPic) (float x, float y, float w, float h, float s1, float t1, float s2, float t2, qhandle_t hShader, int widescreen, rectDef_t menuRect);
void (*drawText) (float x, float y, float scale, const vec4_t color, const char *text, float adjust, int limit, int style, int fontIndex, int widescreen, rectDef_t menuRect);
float (*textWidth) (const char *text, float scale, int limit, int fontIndex, int widescreen, rectDef_t menuRect);
float (*textHeight) (const char *text, float scale, int limit, int fontIndex, int widescreen, rectDef_t menuRect);
qhandle_t (*registerModel) (const char *p);
void (*modelBounds) (qhandle_t model, vec3_t min, vec3_t max);
void (*fillRect) (float x, float y, float w, float h, const vec4_t color, int widescreen, rectDef_t menuRect);
void (*drawRect) (float x, float y, float w, float h, float size, const vec4_t color, int widescreen, rectDef_t menuRect);
void (*drawSides) (float x, float y, float w, float h, float size, int widescreen, rectDef_t menuRect);

[brugal]

btw, should have mentioned that it was probably done that way in order to not break all the custom HUDs players had already created. The older ones would still work the same way as before (stretched) and then players could update them by adding 'widescreen' variables where appropriate.

[Kr3m]

Very cool and super informative. Thank you. So, the coordinate values between 640x480 are relative to the locations of RIGHT, CENTER, and LEFT then right?

[brugal]

You're welcome. Yes, you can think of it that way. If you were designing a new widescreen HUD system from scratch you probably wouldn't do it that way but it's kind of a cool hack to also support older huds.