CSQC HUD only extension

[Urre]

Seeing as most people seem to only see the HUD-side of CSQC when ever it's mentioned, would it be possible to make a sort of minimal CSQC extension, which basicly only supports the 2D drawing routines? I'm asking this because, it seems to me that CSQC is quite an undertaking for engine-devs, but people constantly keep asking for HUD-drawing features/tips/tutorials, be it CSQC or non-CSQC related, why not have a HUD-only kind of CSQC, which is still compatible with regular CSQC in the sense that it could be expanded with the rest of the features?

Seeing how I've made my CSQC HUD, I use entities to contain info about the HUD elements, so clientside entities would be a requirement in my opinion, atleast as data containers (physical representation features wouldn't have to be implemented).

[mh]

What I'd really love to see is a csprogs.dat that just replicated the entire default Q1 render. Nothing else at all.

Coupled with the sample implementation we would then have something that could be used to both implement CSQC and verify our implementation's correctness.

[ceriux]

yeahhhh =/

[Teiman]

Theres also the SHOWPIC extension (or whatever vas called) to make HUDS via TE_ events.

Also, I supported images as entity models, and a way to encode the screen into the position of such images. So 2D games are possible with Telejano. Something like: setmodel( dog, "dog.png"); setmodel( lifebar, "80%.tga");

[ceriux]

maybe you should write a tutorial in the programming tutorials section on how to implement it into engines? it seems like it would be a good thing to have!

[mh]

No, it may be clever but it's also quite evil. Aside from the butchering of the setmodel builtin, the whole architecture of the server sending HUD pictures to the client every frame encoded in entities is just wrong on far too many levels. Damn clever though.

[Teiman]

Humm... yes. Another way can be to look for the references to TEI_SHOWLMP2 in the FTEQW code. Probably the Spike code is better than mine.

[Spike]

how's butchering setmodel any different from using sprites and viewmodelforclient? :P

But regarding CSQC, what is there that isn't useful for huds?

entities from the server? radar. team locations, etc
stats? NEED.
rendering ents clientside? just think about q3's hud.
okay, so a little excessive thought there.

if viewsize is locked to 120, and all rendering is only in 2d, then a simple minimal csqc mod with strings, cvars, stats, and 2d drawing functions only is easy to make a spec for. But you'll want entities to store data too, most likely. Where should it stop?

[Urre]

Spike: My thought exactly, but I figured it might be worth discussing, seeing as the main interest people have in CSQC is HUD, why not start there?

I'd say sending stats yes, sending entities no, 2D drawing only, with clientside entities only for data storage.

[xaGe]

..Good idea's...

..BTW Tei its good to see you active around the forums lately.

[Spike]

and scoreboard too, I assume

[goldenboy]

Don't forget sounds etc people... I would very much like real EXT_CSQC support in all engines - I see a 2D/HUD-only implementation as getting sidetracked. Let's have the whole thing.

I definitely want to do moving sounds, keyboard input etc.

[Urre]

goldenboy: the idea is actually much more than I initially let out. It's not sidetracking, quite the opposite.

The idea is, CSQC is quite a daunting task to implement, and document. What if there was a smaller framework which featured the most wanted part only? If that framework was in, it'd be less daunting to take it to the next level, implementing the rest of CSQC. Picking it apart into modules like that makes it easier to document, easier to know where to start.

The problem is, I have no idea how much of CSQC is framework, and how much is straight up features, so I have no idea if it'd make any significant difference stripping out most of it like this. I hope Spike can answer this. Could a new, simpler framework perhaps be constructed in the case the difference is not significant enough in its current form?

And isn't scoreboard part of "sending stats"?

[mh]

goldenboy: the idea is actually much more than I initially let out. It's not sidetracking, quite the opposite.

The idea is, CSQC is quite a daunting task to implement, and document. What if there was a smaller framework which featured the most wanted part only? If that framework was in, it'd be less daunting to take it to the next level, implementing the rest of CSQC. Picking it apart into modules like that makes it easier to document, easier to know where to start.

The problem is, I have no idea how much of CSQC is framework, and how much is straight up features, so I have no idea if it'd make any significant difference stripping out most of it like this. I hope Spike can answer this. Could a new, simpler framework perhaps be constructed in the case the difference is not significant enough in its current form?

And isn't scoreboard part of "sending stats"?

That's kind of along the lines I was thinking. I know however that Spike has said in the past that there's a huge upfront implementation, with CSQC basically needing a progs interpreter and builtins system that can coexist peacefully alongside the server-side stuff.

I get the idea that Baker might be shortly going to pull some magic out of the hat, but it's up to him and I know he's busy with his usual 25,000 other things at the same time, so I wouldn't pressure him on it.

[Spike]

CSQC has multiple logical parts.
2d drawing (builtins for drawing pretty pictures).
3d drawing (builtins to set up the 3d scene, and add entities/lights/particles/polys to it).
stats (which fields to send, how to receive them, how to tell the csqc about them).
player info/scores (frags, pings, captures, combined team scores, which team you're on).
entity replication (sending, receiving, prediction).
legacy hooks (stuffcmds, centerprints, bprints, splitting chat, etc).
sound (locating the listener, starting sounds).
utilities (string concat/split/etc to make 2d drawing with strings from numbers easy, etc).

The way EXT_CSQC is set up is that it invokes a qc function to draw the entire screen. The csprogs is expected to set up the 3d view, and then draw the 2d stuff over the top. Logically the client says 'draw stuff' and the csqc draws everything.

If you want a hud-only version of csqc, the engine would still draw the 3d view, and only invoke the csqc for just the 2d part.
This is not entirely incompatible, and a single csprogs could support both engine types reasonably easily.
So yeah, add a qc entry point to draw just the hud. A full EXT_CSQC mod can just call the hud drawing function directly, while an engine that supports only huds would call the hud draw function from the engine, instead of the full view stuff.
But this requires that the csqc knows the size of the view. Really the only way to make it easy is to use viewsize 120, otherwise you're not quite sure where the border is meant to be (border is technically part of the hud).

Then just only implement the builtins that are useful.
But note that stats will be needed, and stats require higher limits and ought to have a few extra svcs.

The scoreboard can contain anything. Player frags, number of times players have captured the flag, number of deaths, rapid-kill status, etc.

So really, most of it is just features. Change it so csqc draws just the hud and not the view, and you reduce the framework to just 2d drawing, along with the code to do that 2d drawing, and the code to obtain the info (stats) needed to decide whether things need to be drawn.

CSQC has documentation on FTE's SVN. There's a text file on there somewhere. There's a couple of fixmes, but the vast bulk is there, and I don't think those fixmes affect 2d stuff in any way.
So yeah, change the entry point, and then its just a subset, supposedly.

Okay, so there's the VM, and that's a biiig chunk of code, but easy enough with that version of qclib in that winquake port. It won't conflict, but its duplicate (it can exist as a dll, there's only two functions that would need to be imported).