Turning HUDs into a .txt file instead of engine code ...

[Baker]

It occurs to me that most things that someone is going to do with a HUD in engine coding aren't very complex.

DarkPlaces uses effectsinfo.txt or whatnot to specify particles effects. Some sort of similar text file should be able to obtain most of the flexibility here too.

Although Quake's status bar, as an example, uses flashes for item pickups, aside from that there isn't too much aside from that other than ...

1. x, y coordinates in a 320x240 scale
2. the graphic representing an item, ammo, etc.
3. And although Quake doesn't use this, most people want some sort of alpha blending control.
4. And the ability to specify color for certain ranges, like red numbers when health is low or if ammo is under a certain amount.
5. Ability to draw a bar or circle of some sort based on a percentage, like health as a percent of 100.
6. Plus obviously a desire for things like a radar
7. And the ability to juice up the crosshair or on-screen display a bit, like the sniper rifle zoom in Kurok.

(The crosshair should really be considered a sub-set of the HUD/status bar)

In the coming days and weeks, I'm likely to try to reduce this to a text file with most of the above functionality.

But I'd like to gain any thoughts as I think about doing this.

It is dumb to have to do engine coding only for a HUD and CSQC in my mind is overkill for most HUDs that can be rather easily described with x,y plus graphic name for the most part or x,y, "number"

Then again, if a mod is using a wildly different item inventory, I'm not sure the optimal way to deal with that curveball ... it would be nicer to include something like IT_SHOTGUN in the text file than something meaningless like the numeric constant value. Not sure the ideal way to handle alternate weapon and ammo constants in the most user friendly way.

Either way, I'd like to expose fun and flexibility on the fly.

[Same with the menu system, for the most part, but I don't want to do "too much" at once. Never a good idea ...]

[Spike]

If I'm using widescreen, where is the hud drawn?

Q2 actually has a hud script which is executed each and every frame. It has stuff to draw stat S at location XY as a big number. Draw P if stat J has bit Q set, etc.
Its somewhat limited, but it gets the job done.
It also includes scoreboards. Which is how Q2's scoreboard sucks so much.
Q2 has image precaches as well, in order to get this stuff running slightly faster.

[frag.machine]

It occurs to me that most things that someone is going to do with a HUD in engine coding aren't very complex.

DarkPlaces uses effectsinfo.txt or whatnot to specify particles effects. Some sort of similar text file should be able to obtain most of the flexibility here too.

Although Quake's status bar, as an example, uses flashes for item pickups, aside from that there isn't too much aside from that other than ...

1. x, y coordinates in a 320x240 scale
2. the graphic representing an item, ammo, etc.
3. And although Quake doesn't use this, most people want some sort of alpha blending control.
4. And the ability to specify color for certain ranges, like red numbers when health is low or if ammo is under a certain amount.
5. Ability to draw a bar or circle of some sort based on a percentage, like health as a percent of 100.
6. Plus obviously a desire for things like a radar
7. And the ability to juice up the crosshair or on-screen display a bit, like the sniper rifle zoom in Kurok.

(The crosshair should really be considered a sub-set of the HUD/status bar)

In the coming days and weeks, I'm likely to try to reduce this to a text file with most of the above functionality.

But I'd like to gain any thoughts as I think about doing this.

It is dumb to have to do engine coding only for a HUD and CSQC in my mind is overkill for most HUDs that can be rather easily described with x,y plus graphic name for the most part or x,y, "number"

Then again, if a mod is using a wildly different item inventory, I'm not sure the optimal way to deal with that curveball ... it would be nicer to include something like IT_SHOTGUN in the text file than something meaningless like the numeric constant value. Not sure the ideal way to handle alternate weapon and ammo constants in the most user friendly way.

Either way, I'd like to expose fun and flexibility on the fly.

[Same with the menu system, for the most part, but I don't want to do "too much" at once. Never a good idea ...]

This idea already assaulted me some times. I even have the begins of a quite elaborated markup language implementation based on FitzQuake that I called QML (Quake Markup Language), but never finished that. If you have any interest I can donate to you what I have implemented, so you can read, try to understand and salvage something useful or at least some concepts.

[Jukki]

Ability like this would be awesome to have, not only it makes easier to do hud code but also makes players happy because they can edit their hud as much as they like

[Baker]

This idea already assaulted me some times. I even have the begins of a quite elaborated markup language implementation based on FitzQuake that I called QML (Quake Markup Language), but never finished that. If you have any interest I can donate to you what I have implemented, so you can read, try to understand and salvage something useful or at least some concepts.

I'm going for something more basic and primitive than an XML-like definition ... like "get it up and running now, maybe some day do something fancy later" kind of thinking.

The textfile in my head would be like

Code: Select all

//Weapons
if weapon1 graphic weapon1.lmp at 24,192 alpha 1
if weapon2 graphic weapon2.lmp at 32,192 alpha 1
//Health: first hit is command
if health under 10 number red at 64,64 alpha 1
if health under 50 number yellow at 64,64 alpha 1
if health under 9999 number white at 64,64 alpha 1

Although the first implement might be more primitive than that because I just want to get it started.

That being said, I would like to see you implementation to see if I can draw ideas from it or benefit from your concepts for sketching out future ideas in my head.

If I'm using widescreen, where is the hud drawn?

Quake uses an adjusted 320x200 canvas with a bit of y fudging. But the "canvas width" is always 320.

Ability like this would be awesome to have, not only it makes easier to do hud code but also makes players happy because they can edit their hud as much as they like

It'd make me happy too. Plus it could probably be reloaded on map start so you could edit it on the fly. Would speed up playing around with HUDs a lot.

I'd have some cvar turn the feature on.

[Spike]

canvas width is not 320 in deathmatch.
unless you want to stick with an sbar and not a hud.

keep keywords short (ie: < rather than under) as it simplifies parsing.

imho coords ought to be relative to a screen coord, be it topcenter/bottomleft/center/etc.
if your ifs require braces, you can skip over their contents more easily (though line endings are okay I suppose), but more importantly you nest them (read: simpler popups/easy viewsize).

stats should permit numbers as well as names, for mods that use writebytes to update stats (note: mods should avoid adding to <32 as that results in incompatibilities).

loops?

[frag.machine]

This idea already assaulted me some times. I even have the begins of a quite elaborated markup language implementation based on FitzQuake that I called QML (Quake Markup Language), but never finished that. If you have any interest I can donate to you what I have implemented, so you can read, try to understand and salvage something useful or at least some concepts.

I'm going for something more basic and primitive than an XML-like definition ... like "get it up and running now, maybe some day do something fancy later" kind of thinking.

The textfile in my head would be like

Code: Select all

//Weapons
if weapon1 graphic weapon1.lmp at 24,192 alpha 1
if weapon2 graphic weapon2.lmp at 32,192 alpha 1
//Health: first hit is command
if health under 10 number red at 64,64 alpha 1
if health under 50 number yellow at 64,64 alpha 1
if health under 9999 number white at 64,64 alpha 1

Although the first implement might be more primitive than that because I just want to get it started.

That being said, I would like to see you implementation to see if I can draw ideas from it or benefit from your concepts for sketching out future ideas in my head.

Fair enough. Here is the link. It's far from complete, and was developed dettached from the Quake source because was something made during an idle period at work . But I believe it would be quite trivial to plug it even into vanilla GlQuake. I'm happy this won't end up just collecting dust awaiting the flames of the recycle bin after all... have fun.

[Baker]

canvas width is not 320 in deathmatch.
unless you want to stick with an sbar and not a hud.

True. Note that I also want to simplify and streamline the kludge that is [cl_]sbar.c at least for myself. Few files express relatively simple operations in so many lines of code.

Back to topic ... maybe in the keep it simple theme

1. Condition (how to make long int and human readable friendly w/o constants?)
2. Canvas type
3. X, Y coords (relative to canvas)
4. Draw command (graphic, line, box, etc.)
5. Draw parameters
6. Blending function
7. Statiistic (like health, ammo)

{ITEMS & IT_WEAPON1, GRAPHIC, CANVAS_320X200, 24, 184, WEAPON1.LMP, SOLID, 0}
{HEALTHUNDER 50, BOXFILLED, CANVAS_320X200, 24, 24, 100, 16, RED, ALPHA, 0.5} // Draw health box at 24, 24 with width 100 and height 16 red if health is under 50

Still thinking ... dodges a lot of other subtle things

Maybe a limited set of formal named text constants should be parsed.

[frag.machine]

This is the example file I used to test my parser:

Code: Select all

<qml/>
<%if ${abstime} > 0 />
   <%pic src="gfx/plaque" x=0 y=50% alpha=75% red=0.5 green=0.9 blue=100% />
   <%txt value="ALL YOUR BASE ARE BELONG TO US" x = 0 y=95% red=1.0 green=0.5 blue=10% alpha=25% />
<%endif/>   
<%mdl value="progs/armor.mdl" x = 0 y=80% red=100% green=100% blue=100% alpha=50% />
<%if ${armorvalue} > 75 />
   <%if ${armortype} == 0 />
      <%pic src="gfx/plaque" x=0 y=50% alpha=75% red=0.5 green=0.9 blue=100% />   
      <%txt value="NO ARMOR" x = 0 y=95% red=1.0 green=0.5 blue=10% alpha=25% />
   <%endif />
   <%snd src= "misc/armor.wav" />
<%endif/>
<%snd src= "misc/null.wav" />

[Downsider]

Why don't we remake CSQC so it's more easily implemented and cross-platform?

That would be the fix-all.

[Baker]

Why don't we remake CSQC so it's more easily implemented and cross-platform?

That would be the fix-all.

CSQC for the drawing stuff reads much like OpenGL engine code, as far I can remember ... right? (No time to check, I gotta run ...)

Not newblar friendly.

/Correct me if I am wrong. But rummaging through the Nexuiz QC source, I didn't see any evidence that some non-OpenGL literate person is going to understand the start of a frame and the end of a frame and the OpenGL functions. However, this has been a while and my memory could be all wrong and well ... I only have time to do this post and not enough time to do some quick looking.

[Downsider]

Why don't we remake CSQC so it's more easily implemented and cross-platform?

That would be the fix-all.

CSQC for the drawing stuff reads much like OpenGL engine code, as far I can remember ... right? (No time to check, I gotta run ...)

Not newblar friendly.

/Correct me if I am wrong. But rummaging through the Nexuiz QC source, I didn't see any evidence that some non-OpenGL literate person is going to understand the start of a frame and the end of a frame and the OpenGL functions. However, this has been a while and my memory could be all wrong and well ... I only have time to do this post and not enough time to do some quick looking.

There's no reason to bother with inflexible, generic text files when you can have a remade, easy-to-implement version of CSQC available, with a nice little HUD library of sorts made by one of the QC gurus on the forums.

[mh]

I had code that executed "hud scripts" defining a layout, but no images. These were just standard .cfg files containing cvars; x position, y position, left offset (negative numbers are right), top offset (negative numbers are bottom), center in x axis, center in y axis, etc for each element. It worked fine but nobody used it (or at least nobody complained when I took it out).

Can I say right now that whatever you come up with, please please please make it COM_Parse-compatible? Having to include yet another text file parser in an engine every time someone goes off and invents yet another text file format is damn annoying.

Pretty please?

[frag.machine]

I had code that executed "hud scripts" defining a layout, but no images. These were just standard .cfg files containing cvars; x position, y position, left offset (negative numbers are right), top offset (negative numbers are bottom), center in x axis, center in y axis, etc for each element. It worked fine but nobody used it (or at least nobody complained when I took it out).

Can I say right now that whatever you come up with, please please please make it COM_Parse-compatible? Having to include yet another text file parser in an engine every time someone goes off and invents yet another text file format is damn annoying.

Pretty please?

COM_Parse is OK for key/value storage (like config files). But try to define an animation sequence for the weapon pickup icon using this. Good luck with that.

You guys need to think what fits best also to the modder, not only to the engine developer.

[mh]

You guys need to think what fits best also to the modder, not only to the engine developer.

I think each needs to bow to the wishes of the other from time to time. Something that's more convenient for modders will get zero (or at best very limited and niche) uptake if it's a pain in the arse to implement - just look at CSQC for the ultimate example. Modders also need to be considerate towards engine coders too.

(You're talking to someone who's working with an awesome mod team at the moment and has experienced first hand what happens when modders and coders get in sync. This needs to happen more often.)