 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
The BFG's unfinished though. Not only did I not put in ammo consumption (I plan for 30 cells per shot), I need to make the initial impact sprite appear (which doesn't even though I literally took the original explosion code alongside doom's sprites, I can't find a solution to this, same goes to the Rocketman's rocket explosion sprites which doesn't appear even though it's the same explosion code as vanilla) and as for the sphere going through gibbing enemies, I have to find a way to destroy the initial projectile and make a new one while still using the first projectile's speed and angle (I have no idea how to do this).
I plan on adding a weapon similar to Daikatana's Shotcycler (but with more power to it, think actual 6 consecutive SSG shots) as well as adding a Berserk powerup (that will add a lot of IF in the code...) But since I'm using hipnotic's source code tacked on, nicely placed weapon HUD won't be a thing, since Preach told me I can't add nor change HUD elements, only modify the icons. A shame. I could've at least make an Infantry Gun, Gatling Gun and BFG9500 weapon icons if I used rogue's sourcecode, but I guess that's too late now. "You only have three options as to how the HUD works. You can have the HUD like it is in vanilla, or the HUD from mission pack one, or the HUD from mission pack two. You can customise the icons themselves, but there is no way of rearranging them or adding more than what the mission packs have. The mission packs got special customisations to the engine code before the source was released, it's not something the QC gives you any ability to change. "
Something like Darkplaces would overcome it I think, or hell, a port to a new engine to really break engine limits (which would mean no more bit slots and modifiable HUD).
But I want Schlossherr to be compatible with the most clients possible (yeah there's colored lighting and skyboxes but whatevs), so rendering it DP-only is a no-no to me. fourth method:
csqc can change huds however it wants. obviously this requires people to use an engine that isn't basically crippleware. fifth method: either svc_showlmp or tei_showlmp extensions. while limited and a real pain to use (on account of not knowing the user's screen size, these can provide simple additions that are usable from ssqc. oh noes! an extension! I shall surely burn in hell for suggesting that! sixth method: make a guess at the user's video resolution and spam centerprints at them, with enough new line chars that the visible text appears just above their hud. this one truely is evil. and hacky on account of not knowing their resolution, and can't do images. But hey, if your user doesn't want to give you any possibilities of using extensions, they'll be the ones to suffer by having to explicitly tell the ssqc what resolution they're using so that the mod can waste enough of their bandwidth with new lines to put the text in the right place. seventh method: directly hack an engine so that your mod stops working correctly as soon as the user tries to use an engine version which doesn't crash on the next limit-breaking map or whatever. yay hacks. 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. |