 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
I could try csqc but that thing's barely documented and is DP exclusive. Where can I get that/those extensions?
DP exclusive
no offsense, but that's bullshit. FTE's implementation is much more versatile. And if you want something more like quakespasm (and by that, I mean crippleware) then RMQe's implementation is sufficient for most huds. which part of http://triptohell.info/moodles/fteqcc/csqcsysdefs.qc do you believe to be poorly documented? Imho its better documented than vanilla ssqc was (but then I'm biased as I wrote that stuff and thus understand it perfectly). Yes it is also more versatile/complex than vanilla ssqc and thus does kinda need more docs, you can't win them all. That said, if 'use the source' worked for carmack, then I'm going to be lazy too... :P I'd be nice to add better/more complete descriptions to it, but I'm a) lazy. b) terrible at explaining things without getting annoyed at how verbose you need to be to fully explain things, and how fully explaining things does NOT aid with idiot-proofing at all and it being those people who actually need it to be fully explained. What can I say? Mutual exclusions annoy me. Anyway, once you know the name of something, you can generally search insideqc.com's forums and get further info that way, and I'd like to think that most of it is fairly self explanitory once you know that the builtin exists. If you still have any problems, post about them (ideally on insideqc) and in that way the available 'documentation' will hopefully improve enough to help someone else, even if you yourself are defeated by it. here's my old poopy hud code: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/quakec/csqctest/src/cs/hud.qc?format=raw you need some CSQC_RenderView function that called clearscene();setviewprop(VF_ENGINESBAR, FALSE);addentities(3); renderscene();Hud_Draw(...); and you should have something that looks somewhat like vanilla but is fully defined by qc. I'm sure you can find nicer examples out there if you look. basically, use getstatf to read the various STAT_* values (clientstat in ssqc to define custom ones starting at 32+), then call drawpic, drawfill, drawstring accordingly to throw it all at the screen. DP requires some other functions, which you can provide stubs for easily enough. RMQe is a bit more basic in that its qcvm requires a very specific defs layout, and has multiple omissions. Additionally, here's my attempt to repeatedly insult anyone who complains that csqc is poorly documented: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/specs/csqc_for_idiots.txt?format=raw - once you have a basic understanding of the various concepts, the entire thing becomes much more aproachable. if you want nehahra's svc_showlmp, then: WriteByte(MSG_ONE, 35); WriteString(MSG_ONE, "slotidentifier"); //just a name/id, not visible to the user in any way. WriteString(MSG_ONE, "gfx/foo.lmp"); //the image to display WriteByte(MSG_ONE, xcoord); //might be a short in one of dp's other protocols, good luck guessing what it'll expect. nehahra used bytes. WriteByte(MSG_ONE, ycoord); //yes, this means that the image is probably limited to the top left of the screen. you have no idea how big the screen is either, so that's probably for the best. you can then move/replace it by using the same series of writes. To remove it completely: WriteByte(MSG_ONE, 36); WriteString(MSG_ONE, "slotidentifier"); note that while the extension is called 'showlmp', engines will probably also support tgas too, but they *might* still depend on the lmp to determine the proper image size (hurrah for the lack of width+height args). Or they might just display your high-res image at a really really high resolution... yay engine-specific behaviour. this particular extension should exist in nehahra (of course), dp, markv, and fte. you can find documentation for tei_showlmp2 in http://triptohell.info/moodles/fteqcc/fteextensions.qc but there's no real descriptions. this extension came from telejano, hence the prefix. there's a bit more functionality to it, in that it has a 'zone' argument, so you're no longer limited to only the top left of the screen, and you no longer have to guess the screen size. the coords can be a bit weird though, as tei opted to require 8000 to be added or something like that rather than use signed offsets. its also utilised via builtins rather than having to guess whether the current network protocol is using shorts or bytes. however, it only exists in fte+telejano, and its been years since I heard anyone else even mention telejano. shame really, but oh well. as the original showlmp works in fte anyway, you're probably best focusing on that prior extension and only using this extended extension if there's a compelling need for something that'll only work in only one current engine. looks like I wrote another essay... meh, screw proof reading. My mistake on believing it was DP only.
Though while it looks interesting, I don't really understand how it works, nor its functions. I guess I should've said instead of lacking documentations, more like it lacks tutorials, since I don't see many people use it that much, so I don't really get what does what. Still, I'd like to know more about CSQC. Maybe after working on that HUD stuff I could see if I can move the weapon viewmodel around the screen, like nQuake did (though purely for cosmetic reasons, sometimes I like me some side weaponmodel, better if I can switch that on while looking at demos). when you start using extensions - any extension - you can find yourself tempted to use just one more... CSQC's versatility makes this so very tempting.
There really is no harm with just making a hud and stopping there. I keep thinking that I ought to write a patch for quakespasm or markv to provide hud-only csqc support, except that I'd probably end up overcomplicating it or something, plus I've got enough other stuff demanding my attention. Here's a fixed start.bsp derived from the vanilla GPL release:
Download I've fixed all the texture misalignments that annoyed me, plus some brushwork. Also added _dirt -1 to some light entities and compiled it with -dirtscale 1.25 and lit liquids. fixed textures can make all the difference in the world. thank you mankrip. misaligned textures in original q1 are terrible with hd textures.
- jakub I've modified some things in the chiaroscuro lighting, because the models were getting too bloody dark when they shouldn't: Explore or Die - map gameplay.
I've died in a humiliating way in that video, but the video as a whole was nice to watch so I've not re-recorded it. A really cool map, one of my favourites. The video looks really dark on my screen, maybe try a YT filter or brighten it up with Video Editing Software like Windows Movie Maker.
I'll re-record it with a higher gamma setting in the game. It looks really good when playing, but YouTube compression is really bad on dark areas.
I'll try to find out a good balance between dark areas and YouTube compression; one of my goals with these videos is to learn how to make the game look better on YouTube videos. Video compression is really bad for a visual style built around per-pixel grainyness. On a side note, it's curious how this video didn't suffer from the same hiccups of the previous ones. I don't know if playing a heavily colored-lit map in an engine that doesn't yet support them was the best idea.
For the purpose of testing the image fidelity between the engine and YouTube, that's enough.
Right now I'm focusing on gamecode, there's a lot to do.
|
|
| You must be logged in to post in this thread. |
|
| Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors. |