 News | Forum | People | FAQ | Links | Search | Register |
Log in |
|
|
Hrm, well when you think about it, the grenades and rockets traveling are point sized. Theoretically, they ought to collide once in a while if you play deathmatch....or maybe when you are fighting an ogre. Whens the last time you saw that happen? Never. So does / would traceline collide with a point sized ent? Just for fun, one time I gave the missile a.think which set its size randomly between point, and I believe half point. Collisions failed when you hit specific parts of the q1bsp sch as corners or angles mostly, but I was able to see a "point to point" collision of sorts with another missile during some tests in dm with another player. So thats why I said earlier, velocity seems to have a factor. Maybe Im being redundant, but I'm curious if the engines are checking the collision boundaries with velocity factored in, or if they stop the ent each frame for the check?
point size
What you are saying doesn't make sense, unless you think point size means "1 pixel size", which it doesn't. Point size is mathematically zero size, i.e. a point. bbox<->bsp collisions are aligned to the bbox's min position.
This means changing size_z leaves the monster sitting on the ground still, but changing size_x or size_y can allow the monster to (obviously) move into walls on one side but not the other. Thus its generally much better to just use fixed x+y mins+maxs values, while z values can be more accurate with much less regard to hulls (note that hexen2 uses mins_z set to 0, because why not). engines that support rotating bsps do so by rotating the start+end positions of any tracelines/boxes around the bsp object. This has the effect of rotating the bbox too, meaning that the top or bottom surfaces (in a non-rotated position) of the bsp are further away than its side edges, when standing on top of said surfaces after rotation. bbox<->bbox collisions do support arbitrary sizes, but as the same mins pos affects the bsp collision offset, and the size field affects the hull that is used, you're still limited in terms of bbox sizes. note that bboxes don't rotate, which generally means that the corners of the bboxes can become excessively obvious with large bbox sizes (side note: doom used cylinders, thus didn't have this issue). I just realized you can type in small or big.
Is this a feature for case-sensitive OSs? In Windows version it does not seem to be a useful feature, because if you happen to use a capital letter in a console command it says 'unkown command'. http://quakeone.com/forums/quake-help/quake-clients/11993-quake-osx.html
"Also, only the software renderer is currently available for video - though, to render frames to the screen, I decided to use the new Metal framework available for both desktop and mobile devices" Usually someone porting the original Quake to an operating system they like comes up with inventive ways to handle video, sound, input. Darkplaces Engine Bug [EDIT]
Posted by Teknoskillz [73.142.34.180] on 2016/02/07 21:51:33 Was not sure if this is ok to start a new thread , so feel free to move it to the right one if Im making a mess here. The last engine related topic I was posting in got moved someplace, I cant find i it now? Anyway , on the chance there may be some experienced people here using DP, and may know whats going on, heres a screenshot of the problem: [ http://imgur.com/jpSHrW0 ] It happens when you set r_showbboxes to non zero. Its some kind of artifacting / re-replicating going on and its been a while since I first saw it, but I seem to remember I was playing with another graphics related cvar before I set showbboxes again during testing, so I am pretty sure its related to the other cvar, just what one, I cant remember? Any help appreciated. This is the most recent release of DP. Swampy in Super8:
https://qbism.com/download/file.php?id=91 New test build with better color and transparency rendition: https://qbism.com/download/file.php?id=88 Intense saturated colored lighting: forever blocky. For anyone who doesn't already have super8 installed, this link includes the the test build above (v267) plus missing dlls for music playing:
https://qbism.com/download/file.php?id=94 I already had some DLLs installed, but the music sounds a little unusual. I thought you were using a statically-linked library.
By the way, the color in this version has really improved a lot. Haven't tried it with colored lighting yet. The MDLs looks shiny. Pie is good, too.
Shiny mdls: Change r_light_style cvar to 0 for conventional flat lighting. I guess the default is 1. A matter of time and form, but no super8 goal for now except a stable windows release for qexpo. I'm on Mint as much as possible lately. Linux is on the list if development continues.
Trying to help a new modder with their soundpack for Quake. He has the ambent fire for the torches giving an error in Proquake that its not a loop type audio file. I believe other engines such as DP and Fitz probably automaticly loop these, but does anyone know how to change it so its a looping type? We looked in Audacity and could not find a setting. I thought I remember readint there was more or less a bit you change in the
I never found a reliable explanation of how to loop sounds, even though i have done it myself multiple times. Part of the problem is the terminology is inconsistent across audio tools.
I think you basically have to open the wav in a program like cool edit 96, soundforge, etc, and add a "tag" or "marker" or something at the point in the file where you want the loop to re-start. If you want the whole thing to loop, place it at the beginning. If you want there to be an intro and then a loop, place it at the end of the intro. Even when i did this, sometimes it didn't work for me. I might have tried multiple programs to make it work. Because of this frustration and hassle, one of my wish list quake tools is a dead-simple "make a sound loop" utility program where you run it on a wav and it adds the data that is appropriate. Perhaps other people had better experiences, though! And there under tools (I think) add marker.
It didn't matter where or what it was called, Quake would then treat it as looping. Ahk, Win 7 or later for Goldwave so I cant check it, but will fwd to the modder the link to this thread. Thanks all.
Older versions for XP/etc here: http://www.goldwave.com/release.php
Getting DarkPlaces to look correct is only partially achievable. I have a particle font I got from somewhere that allows particles to be square and pixelly. gl_texturemode gl_nearest is good. Water will not twist unfortunately. I have not found a way to re-enable the twist effect and is the only reason Darkplaces is not a fully supported and true Quake engine, for all its interesting options.
You're better off just using a different engine for the true software look. Darkplaces' whole shtick is about looking fancy. Why use it at all if you wont use its features?
Really it's true strength is for use in total conversions where you want to use cool stuff like the Q3 bsp format and md3 models.
For playing Quake? Ehhhhh... not so good. With Darkplaces you have a prvm command so you can check globals and look at entity specific fields etc, using the command prompt.
Is this something just in Darkplaces? I thought all the legacy engines have it, but apparently no? fte has 'poke_MODULE' commands that you can use to get/set various qc terms (ents can be read by number).
every engine supports saved games (with the possible exception of dedicated servers). saved games are always text, and should allow some sort of inspection, although figuring out entity numbers may be awkward. Interesting - yea, Darkplaces has a crash.dmp option you can set, and turns out its merely doing a save game (.sav) just before crashing.
It does comment each bracketed field past the worldspawn with "entity" [x] so you can find them, however I imagine the save game would be numbering all the edicts past worldspawn as entity 1, and incrementing, which I guess can be a pain sifting through. I had thought the legacy engines from way back like Winquake etc, all had the prvm command , but maybe it was the "edicts" command. I remember doing that and it would just spit everything out to the console. Cant recall if I used it to actually set things during the game and test them though. code dump:
Cmd_AddCommand ("edict", ED_PrintEdict_f); Cmd_AddCommand ("edicts", ED_PrintEdicts); Cmd_AddCommand ("edictcount", ED_Count); Cmd_AddCommand ("profile", PR_Profile_f); you mean those? I'd kinda forgotten about them tbh, sorry. iirc, edicts is basically unusable because it fills the console buffer too easily. either way in vanilla there's no way to peek at globals without saved games. fteqw+fteqccgui has a watch list thing that's updated with each single-step, or you can just mouse-over stuff too, of course. That looks like them.
DP also lets you use the prvm to filter things , ie: prvm_edicts server model Prints all the edicts on the current server to the console and shows their current model string. You are right, edicts command crashes the engine. DP removed it but some other engines like Direct Q are still using it. Fitzquake 0.85 does not crash tho.. Saw this a long time ago, I guess its a Proquake feature, thought I once saw it being able to detect Darkplaces clients connecting as well but not sure. As it stands when I use the "Manquake" version of Proquake, it always seems to detect Proquake, just different veersions. Are the engines using a standard ID and a tag of some sorts to ID the engines, or is this all now just a passing fancy?
string () PQ_Version = { local float i, ch, sum; local string format = " with proquake version 0.00"; local string x; i = self.netconnection[QS_MOD] / %1; if (!i) return " with a non-proquake client"; else if (i == 1) return " with an unknown proquake client"; else if (i == 2) return " as a qsmack client"; ch = floor (i / 4096); i = i - ch * 4096; sum = hex_ctof (hex[ch * %2]) * 16; ch = floor (i / 256); i = i - ch * 256; sum = sum + hex_ctof (hex[ch * %2]); ch = floor (sum / 10); x = ftos (ch); i = %23; strcpy (format[i], x); i = i + %1; strcpy (format[i], "."); i = i + %1; sum = sum - (ch * 10); x = ftos (sum); strcpy (format[i], x); i = i + %1; strcpy (format[i], "0"); return format; }; proquake added som extra byte or two at the end of its connection requests. this is meant to contain some [engine]mod id, and the version of it. proquake also added 16bit client->server coords only for proquake clients, and nothing else that's particuarly special.
this resulted in pretty much every NQ client suddenly pretending to be proquake because it was the only way to get 16bit angles at the time. so really, all that code can actually detect is whether the developers of said client actually gave a fuck about multiplayer or not. it also depends upon qccx hacks that will break with any engine that even attempts to provide sandboxing, with offsets that are highly specific to the server in question. adding hacks with assumptions about memory layouts is evil, but if the engine doesn't actually provide any extensions then really the only choice is to hack said engines. What Spike said, I had to fake qrack to telling proquake server's it is pq3.50 compatible so that it will allow players to use the 16-bit angles. once the handshaking is established pq will send angles as such and qrack will read them. Other engines like Qspasm connecting to a PQ server will only use 8-bit angles and thus be at a disadvantage. :( btw pq server/clients in this fashion also break demos played on other non proquake clients...
Do the 16 bit angles allow fullpitch?
So I guess older engines and even Darkplaces still only has 8 bit angles, and therefore if a non pq clients is on a pq server, their angles are not as precise, is that how it works? angle cheats are separate from angle precision.
darkplaces pretends to be a proquake client too. its own network protocol always uses 16bit angles, for both client->server AND server->client. because proquake's angle thing is strictly client->server, it doesn't break demos because it doesn't even appear in demos (so r00k is wrong in that regard, unless there's some other difference that I'm overlooking, like proquake's svc_print encodings, but those should just look glitchy). the fitzquake protocol also uses 16bit client->server angles. however, proquake doesn't support that, so quakespasm is indeed limited to 8bit angles on public deathmatch servers, but not when playing singleplayer. btw pq server/clients in this fashion also break demos played on other non proquake clients...
It is well known that ProQuake demos play even in the original Quake/WinQuake/GLQuake. And by extension JoeQuake --- which uses ProQuake network code -- this is why speed runners use JoeQuake to record their demos [amongst other reasons]. Why could not each engine have its own cvar that more or less corresponds to its clienttype and version?
IE: cvar FitzQuake = "Fitzquake 0.85" Then feed this field into something decided upon to be 'universal' in the engine community in case they 'give a shit' about mp...heh. As it stands now the code I posted is I guess cute, it can announce what client a player is using when connected...if it were to work accurately that is. At least if the structure did pass a unique string to read to the layman qc modder, they could perhaps customize some mods to take into account the many differences in all the engines and give the user a better experience, ideally... 1: cvars are not normally server-visible. making them server-visible also implies making all cvars server-visible, like ones that contain rcon passwords or other things that shouldn't be scraped.
2: string parsing is not possible/feasable without server extensions, limiting the servers that can actually benefit from it to those that either don't support anything but their own by default(dp), or that already have their own auto-detection(fte). 3: http://xkcd.com/927/ 4: really, it would need a whole list of 'compatible with' much like user-agent strings in http. string parsing is annoying, did I mention that yet? 5: encouraging people to use client-specific features also encourages people to depend upon incompatibilities. the end result is probably not very good in the long term. don't get me wrong, it'd be nice to know what each client supports, but doing it on a per-feature basis rather than a per-client basis helps to encourage people to actually adopt the standard properly rather than getting modders to add a hundred different hacks for each client. 6: quakeworld clients can be distinguished fairly easy by reading that client's userinfo string. of course, this still requires knowing everything about every client. I admit that I've used it for blacklisting clients that don't appear to implement standards properly, and I know mvdsv uses it for both blacklists and more annoyingly whitelists. whitelists suck by the way. you end up straight back with trying to pretend to be some other client. and then all the complaints about cheats start. whitelists suck. so yeah, it'd be nice for servers to be able to tell what they're actually talking to, but at this point I seriously doubt anything is going to change, and even if it did, it probably isn't going to be TOWARDS compatibility, at least in the long run. what i meant as "break" was that all demos play back with 8bit angles. So, in slow motion watching a demo from first person pov, the aim isnt as smooth as the player saw when recording.
this is in cl_input.c [code] if (!cls.demoplayback && cls.netcon->mod == MOD_PROQUAKE) // JPG - precise aim for ProQuake! { for (i=0 ; i<3 ; i++) MSG_WriteAngle16(buf, cl.viewangles[i]); } else { for (i=0 ; i<3 ; i++) MSG_WriteAngle(buf, cl.viewangles[i]); } [/code] btw Qrack breaks demos because the number of lightmaps increased for halflife map support, which i could easily scrap but then i have 1000s of demos that were recorded with that fact. :|
the viewangles displayed by an nq demo are exactly as precise as was displayed when it was being recorded, on acount of each demo packet containing 3 floats for angles, no truncation at all, not even to 16bit.
those writes are irrelevant when playing back a demo. that buffer isn't sent anywhere on playback, even if its still made. If you recam a demo or have qc generating some sort of chasecam with forceangles/svc_setviewangle then yeah, you're probably going to end up with 8bit data getting expanded to floats, purely because the result is based upon the server->client precision (which is unmodified by proquake). regarding lightstyles, you'll find this nice line memset (cl_lightstyle, 0, sizeof(cl_lightstyle)); inside CL_ClearState. Or, in other words, you can omit any lightstyles following an svc_serverinfo that are empty (whether recording a demo or serving to clients), and your halflife support etc still works, without any needless incompatibilities. Obviously if a map/mod does use one of those lightstyles then that's the map/mod's problem rather than yours. Really, support for 255 lightstyles should be a standard feature by now. Chatted with Zop last night, and he says that command ' q_version ' was I guess a Manquake type of mod where participating engines could code in their response string, and it would be initiated using the 'say' command. Doing it alone on a server would not yield a response, however more than 1 player on a server would trigger each client to respond with their engine version. According to Zop, the admins voted that out of the RQ games so I guess its either commented out in the eng source or deleted, but I guess this is one way of doing it.
in CL_ParseString i call this...
void Q_Version(char *s) { extern cvar_t cl_echo_qversion; static float qv_time = 0; static float qi_time = 0; char *t; int l = 0, n = 0; if (cl_echo_qversion.value == 0) return; t = s; while (*t != ':')//skip name t++; l = strlen(t); while (n < l) { if (!strncmp(t, "q_version", 9)) { if ((qv_time > 0) && (qv_time > realtime)) { return; } if (cl_mm2) Cbuf_AddText (va("say_team Qrack version %s\n", VersionString())); else Cbuf_AddText (va("say Qrack version %s\n", VersionString())); Cbuf_Execute (); qv_time = realtime + 20; break; // Baker: only do once per string } if (!strncmp(t, "q_sysinfo", 9)) { if ((qi_time > 0) && (qi_time > realtime)) { return; } GetMem(); GetMHz(); if (cl_mm2) { Cbuf_AddText(va("say_team %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer)); Cbuf_AddText(va("say_team Video mode %s \n", VID_GetModeDescription (vid_modenum))); #ifdef WINVER Cbuf_AddText(va("say_team Windows Version %x \n", WINVER)); #endif } else { Cbuf_AddText(va("say %iMHz %iMB %s\n\n", MHz, (int)(Mem/1024), gl_renderer)); Cbuf_AddText(va("say Video mode %s \n", VID_GetModeDescription (vid_modenum))); #ifdef WINVER Cbuf_AddText(va("say Windows Version %x \n", WINVER)); #endif } qi_time = realtime + 20; Cbuf_Execute (); break; // Baker: only do once per string } n++; t++; } } all client-side... Qrack goes one step further than ProQuake in that, if the player who initiated the q_version in mm2 mode then Qrack will respond in mm2.
1: requires annother player on the server.
2: can potentially be exploited to get other kicked/muted from the server due to spamming. 3: working around the previous issue makes it unreliable. 4: the reply is indistinguishable from many other possible responses. 5: the reply is totally not standardized. 6: you can't tell what the client is until a not-insignificant time after the player is already running around. its fine for players to know what other players are using, for those that are curious about it, but its useless for mods. quakeworld standardized upon f_version triggering the main response, after fuhquake, but also works for fte and fodquake too, but I guess ezquake has an off-by-one error... I thought all the engines since day 1 supported colored text using the ' ^ ' character?
Turns out if I push a string in QC and use one of the extended colors with that character, Darkplaces will print it with bprint or sprint with the new color, but I noticed PQ does not seem to support this? Have not tried Fitzquake or other engines yet. I thought all the engines since day 1 supported colored text using the ' ^ ' character?
Engines that support it are actually a minority. It was one of those niche features that appeared in one or two engines way back at the dawn of time - i.e very soon after the GPL code release, and IIRC on the ancient (and long-dead) QER site - but was never really documented nor standardised, and never really picked up by any others. ^ is pretty much just DP+FTE (and q3 onwards, obviously, but that's quake3 and not quake).
if you just want 'red' text, you can use \b (iirc) within a string to toggle it in fteqcc or frikqcc. so maybe that's why you think it works in more engines. I appreciate your comments about q_version, though yes 1 doesnt work unless two online, is kinda moot since you know your own client version. :|
I can make it so it's only mm2 and/or only before a match is going; and limited to once per minute response. That said there is also a command to just disable it called cl_echo_q_version... as for ^ color chars I'd rather see full ANSI support with blinking characters and the full set of extended characters too! ;)
but then Quake was kinda unique with it's own custom character set... q_version was never anything but a social feature to create awareness of modern clients.
And get people to upgrade. If you were using glquake or ProQuake 3.50 and someone typed q_version, 2 things might happen: 1) You see may everyone else on the server was using ProQuake4, Qrack (later DirectQ supported it, but wasn't around at the time). 2) Another player might ask you what you are using and why and someone might even suggest you are using a cheater client. The social pressure thing worked wonders and I can recall connecting and doing a q_version check and within weeks it was close to 100% modern clients. At the time, it was important to get people to upgrade so automatic map download had a near 100% rate and people could play custom maps, ctf, coop servers, rocket arena automatically. Any Quake 1-2 Ports With Monster Footsteps? [EDIT]
Posted by crystallize [94.180.115.39] on 2016/04/22 15:01:24 Hello. It would be intresting to see a port where monster sounds are synched to animation, unlike Q2 with gibbed monsters screaming or making falling sounds. A fiend or a spawn or a dog or a shambler making footstep sounds would be odd.
Maybe someone could make a model with those monsters wearing boots. I believe AD has footstep sounds for every enemy type. The shambler footstep is the biggest and heaviest but also kind of muted/muffled.
Thought port meant engine?
It does, but engines wouldn't handle that sort of gamecode - it's something you'd have to do in a QC mod - so the chap asking is barking up the wrong tree. AD does footsteps, obvs. Wasnt sure to post this here or in coding help. Im trying to alter the field "world.message" so it is strcat'd to be something more than just the description. Basicly I made some cute does that appends the Original authors name(s) to the ID maps. However, when the map loads, the message seems to always be either nulled / empty or its something the engine dont want to show. Basicly the line where it use to show in the console is now empty.
I have tried moving it outside of Worldspawn and seems to be no help. Basicly I am doing a strcat in worldspawn to the message field so is this safe? There is no strzone function in older PQ otherwise Id try using that. If you want to change the map name in the signon message, then hacking it in the QC strings or the entities text is totally the wrong way to go.
Just change the message sent as part of svc_serverinfo instead. Or change the Con_Printf in CL_ParseServerInfo. And be ready to have a fallback for the case where the mapper has already included their name here. I disagree about using engine code for what's merely an asset design thing. Unless it's implemented as an extra feature, using a new field instead of hacking world.message.
If this is implemented as an engine hack, it'll need CRC checks to ensure that it won't change the description of all the other start.bsp maps out there, for example (including the ones recompiled for transparent water). It overcomplicates things and creates yet more code to maintain. Using an external Thanks Mankrip and MH for your points made. Didnt know PQ supports
Src mod Im working with for the message field is Runequake...and its got a file called strman.qc (string management I guess) so I thought maybe you could do just about anything with strings there, but apparently theres more to it in PQ. I can code changes to any world Yes,
[i]That is soooo not an engine thing.[/i]
moderator moved me here :P Thanks for the hint about Arcane Dimensions. Also I want to show you Tenebrae 1.02 (2002) that can't be found in the web today... except may be as source code. It's difference with currently available 1.04 is lack of annoying colored fog and different lights placement. All these old fancy screenshots that Tenebrae was always advertised with, were most likely taken from this version. http://rutracker.org/forum/viewtopic.php?t=4966700 Noticed in legacy PQ if you rcon to a non std port other than 26000, initially you appear to be connected ok, however any further rcon commands except "status" are diverted to port 26000 somehow. So far the only client that correctly routes to the initial port and stays there seems to be Qrack.
Decided to try this tool which seems to be mostly designed for Q3 era games [ http://www.ruckman.net/downloads-1 ] and after modifying a line of code, seems to be able to rcon ok into Darkplaces servers, but still cant seem to get it to rcon to a PQ type server. Would anyone have an idea why or what has to be done so it works? LordHavoc was quite inspired by Quake 3 in the early days which is why DarkPlaces and Nexuiz used the Quake 3 model format, the Quake 3
ProQuake's author seemed to just want regular Quake to have some features that Quakeworld had for those who preferred NetQuake physics. It isn't surprising that DarkPlaces rcon is very similar to Quake 3, as Nexuiz in many ways was very Quake 3-like. ProQuake's author probably used a method very similar to what was in the Quakeworld source code (I'm guessing, but its an educated guess). Thanks for that info. I too have noticed the similarities, and I like how it uses the pk3 file system with curl for connecting players to get all the assets to play the mod. It really is a modder friendly engine in that regard.
After reading what you said, I decided to revert the altered code back to the original that came with the above download, and in that form, it wont rcon to my dp server. So the changes we made to rcon_code.php allow DP rcons to happen but so far with PQ, no dice. We changed line 27 or thereabouts as follows: // $query = "xFFxFFxFFxFFx02 rcon "" . $PASSWORD . "" " . $COMMAND; $query = "xFFxFFxFFxFFrcon " . $PASSWORD . " $COMMANDn"; Sorry of this is turning into a coding thread, but I didnt get any response to my other rcon issue in the coding area. Also if anyone is interested in modding said dl so that it covers all the legacy Quake / qw engines with me that would be great. I thought maybe we could have a session manager of sorts with this and add icons up there for all the quake engines so that when you click on one, the "mode" changes so you can rcon into those kinds of servers too. The author was contacted but hes got not much time to help mod it and has ok'd me to modify it to cover other games / engines. Just a side note since Baker refered to QW rcon maybe being used in PQ, when you rcon into a DP server and successfully send a command that prints something to its con, it will lead with : "QW print command from " , which tends to maybe say that DP is using QW type rcon code?
Another tidbit - DP uses rcon_address as opposed to rcon_server. During my tests this seemed to be incompatable when using DP to try and rcon to a PQ type server. However DP does have a "PQRCON" command, which seems to claim it can rcon to a PQ type server, and also does not work. Weather or not its related to the differences in the 2 cvars for the server address, not sure. However, if you want to understand network code you really have to be willing to get your hands dirty. There are no shortcuts.
Search for rcon in the source, it is precious few lines in precious few files. Find out how it sent, received, the packaging. If you end up not being able to figure it out, I wouldn't be too worried. Engine coding is hard, requires very strong determination and it isn't for everyone. For network, this is doubly true. Another way of thinking about this: rcon is sending and receiving a text string telling the server to do something.
And considering how few instances of the word "rcon" there is the source, shouldn't you find out how the client sends it, what code it sends (CCREQ_RCON for ProQuake) and where the server receives it. And I'm not claiming it is "easy". However, this is the kind of challenge where everything is sitting right out in the open and you can say "This sucks, but if I make up my mind I can read it line by line" in the applicable places -- or the other option is not doing it. It is just kind of binary decision. NQ's netchan sucks.
Its the reason that quake can't easily be played through NATs. Yes, there are hacks that mitigate that in a few engines (like proquake), but not all (like quakespasm), and those hacks don't work for the serverside parts. Any reliable data that is sent requires two extra udp packets at a minimum - one for the data, and one as an ack. Its just undesirable in general. Which is why DP switched at least part of its netchan towards the qw/q2/q3 style for connectionless packets (shame about those reliables really). rcon is insecure. passwords are sent as plain text for a start. Most engines have no throttling against bad packets (just spam everything you can). If you have rcon passwords embedded in your config then its just a simple stuffcmd(self,"cmd rcp $rcon_password\n"); away from any server that wants to exploit you. You're probably better off using 'screen' or some equivelent tool to admin your server, although yes, these are slightly more hassle to use (yay! less inclination for admins to interrupt games!). sending an rcon command to a server that you're not connected to should imho be considered bad form. It may be useful if you just want to kick someone, but chances are you'd want more than that anyway, and it'd be a shame if you eg got the IP wrong and didn't notice. The response is unreliable, so you have no idea whether the server actually got your command or nor when the response doesn't arrive, and if the response is too long then you also have issues So yeah, rcon sucks. There are better alternatives, even without modding a server. I personally tend to enjoy writing networking code. It requires you to follow two 'threads' at once, but unlike actual threads they generally have much better defined sync points. Tbh at the end of the day, ALL code is just passing messages around the place. Whether its across a network or between cpu cores or just between two sides of an API, for a LOT of people coding is pretty much all just message passing. Even QC has thinks and touches and other events. Yes, it can take a while to familiarise yourself with the various concepts, but its also very useful if you intend to program anything. Most of the time, the challenge is figuring out where to start. For NQ that would be CCREQ_* for client->server requests, CCREP_* for server->client responses. Those are all the out-of-band things you can send. Actual connections uses more stuff, of course, so I'm going to gloss over all of that and end the rant here. So, there's not a single engine with software rendering that has modern netcode for decent multiplayer? ppl just care about damn gfx :(
I was told by the author of Qtracker, [ https://www.qtracker.com ] the intended Gamespy replacement...that its capable of rcon for other gameservers, but he did not include rcon for Quake. He intends to code it in for the next release, so was glad to hear that. As long as there is something that can rcon based on the server type, Ill be satisfied.
As for engine coding, yea have meant to have a go at it again, but something like a video showing how to do it would clear up alot of things for me. So far after asking on other forums no ones interested in making a video, and another idea would be some kind of site that uses an api of sorts to work with and or experiment compiling the engines based on the material uploaded. Probably asking for alot, but at least that way there is some kind of centralized point where its easier to learn and with some real engine coders like we see here having access, it could lead to some interesting new ideas or improvements. People who make things are determined types that don't get stopped easily.
They don't get stopped by the lack of a video. It isn't like there aren't a million tutorials, books, videos and game dev sites and places like insideqc, gamedev.net, moddb and the other zillon sites. A developer is someone with a strong determination. You aren't going to be making anything and you broadcast the "I'm a helpless snowflake" vibe in every post. If you wanted to get into this stuff --- -- there are so many resources on the internet that you'd already be doing it. Real developers overcome obstacles and every real developer has overcome so many obstacles they don't even keep track. is something I have tried for a long time to get a grasp of and I just don't have the mind for it.
Mapping however is second nature might be the way some people do things, but its not for everyone.
So far the most professional helpful engine developers that have ever inspired me, dont make condescending or patronizing posts such as above ^^^ Thats about all Im gonna say regarding it. I rather see the discussion stay on track about Quake Engines instead of taking snipes at how people decide to tackle certain problems or gain knowledge. If you have a system that works for you , wondeful. Not everyone has the same way of doing things. Maybe something on Philip Buuk's channel would help you out?
Also, I don't think baker is insulting you, rather, giving you some tough love. Listen to baker, you probably are putting out the "helpless snowflake" vibe unknowingly. I'm guilty of it and it's an easy trap to fall into when you're stuck and really don't know where to begin. Ultimately, that's going to 1) cause people to be disinterested in your cause and 2) distract you from what you ought to be doing. Also, don't dismiss advice because you find its content or presentation repugnant. This shit is hard and, more often than not, the truth of the matter is usually what you don't want to hear. might be the way some people do things, but its not for everyone. I can relate, but that way of thinking is ultimately a crutch. There is no shortcut from a to z. You're going to have to put your nose to the grindstone and work your way through. If I had taken this advice some time ago I would be in a much better position now. Maybe my advice isn't applicable to your scenario, maybe it is, who knows. Just my 2 cents. Best of luck! Thanks for your link, started watching it, seems very appropriate. Something like that may "fill in the blanks" for me perhaps. Thats more like proactive posting and providing possible solutions based on the real common goal, which is definitely more constructive.
As for the "helpless snowflake" insinuation, it all depends on how much research you do on me. Check my profile, I have a website though outdated regarding a QC mod. I am an active QC coder and also just recently started a Quake C support Email list fr the casual newcomer if need be. Im active in Quake as best as I can possibly be given its hurting circumstances. I have interacted with Baker before on other sites, but obviously theres only so much cooperation possible there. Aside from Quake, sometimes I get to have a real life, and Im not ashamed to say its been a lousy one lately for lots of reasons I could lay out here, which would most likely make people sick to their stomachs, so I wont do it. Its also off topic as well. There is a tendency on the internet in general these days for forget there is an actual imperfect human being on the other side who may feel "helpless" or "powerless" at times. To me, thats fine and despite me feeling that way lately , Im still able to help people if asked, and also do things for the possible new person trying Quake, so I think Im not as helpless as was implied. Thanks. good, I hope that material will prove useful!
It sounded as though you may have been going down a familiar path. I just wanted to take the opportunity to save you some time and grief if that were actually the case. No insult was intended. No problemo KP, understood.
Already watching the 2nd vid, and it does make me remember part of what may be my "special snowflake mental block" here so to speak. Its regarding Visual Studio. I have 2008 and 2010 installed on my main desktop PC, and when I tried compiling an eng straight from original known good src, (without making a single change) I could never get a good compile without an error. Checking further, I saw LOTS of complaints and remarks about inconsistencies back and fourth from different versions, and its well known I guess in the coder communities about these problems. I guess I could have gone to those sites and waded through tons of material to find my particular issue, but since I have been a sorta active member in some Quake Websites where there are real actual engine coders, made more sense to ask for the help there. But I think this video will def help alot for me. Glad to see some poeple are making vids about modding or coding Quake, could not find any when I looked. The internet is becoming a real vast place packed with so much content, sometimes its pretty easy to get lost...or overwhelemed. Maybe thats also part of it. In case you or anyone else wants to see some of my Quake modding experiments etc, heres my Quake only youtube [ https://www.youtube.com/user/teknoskillz/videos ] Maybe we can 1 day create Quaketube? :o) technically it does... it just doesn't work. :)
even if it did, it still wouldn't run mods properly (being a qw engine) without a huge amount of work. Even getting the official mission packs working properly wouldn't be trivial. Posted by Sgt-PieFace [108.63.148.236] on 2016/06/28 18:16:56
I made a short video show the changes that have been made to Quake via client updates and mods over then 20 years of its existence. https://www.youtube.com/watch?v=ImlgOmSUF4M Kinn you might explain why
Both look bad.
1996 seems to have been made at a lower resolution and/or picmipped down, probably the latter judging by the relative size of the sbar. The original Quake textures may have been low-res but they were also quite crisp. no fullbrights or overbrights either; GLQuake may not have had them, but software Quake did and software Quake came first. 2016 looks even worse. It's the typical DarkPlaces baby setup: a horrible mixture of high-res textures and low-res content. Looks in no way cohesive and the whole setup just seems to be designed to appeal to those who want to look at the pretty normal maps rather than play the game. The Quake high-res mod community still doesn't seem to understand that if you have normal maps then you need flat diffuse maps. Yuck. Next. Well, if you have a Mac with Xcode and the latest version of everything, you could switch the left part of the video with my soft-rendered OSX port. You would get the crispiness of low resolution textures as rendered on a 2880x1800 screen (or whatever resolution you have) - or even in a small window if you prefer. Might make for a fairer comparison.
Kinn you might explain why
It's like mapping a hi-res photograph of a person onto a minecraft character model. I really don't have the energy to step people through why this looks bad. It's not just high-res models, it's map geometry as well. The combination of high-res map textures and low-res map geometry just really really jars. Throw in the occasional spot where no high-res texture exists and it throws you even further.
Hey guys, I've recently picked up Quake modding, and I've been looking at ways to make content that I could distribute without people needing Quake itself. I realize it would entail me making all-new textures/models/code, that's fine. I've been running Quakespasm as my engine of choice due to its relative faithfulness to the source, would it allow for completely custom content without me needing the original Quake paks?
I know only of OpenQuartz as a completely 'bare' moddable engine. I don't know if QuakeSpasm still requires the "proof of purchase" file to run custom content, but Darkplaces doesn't. DP has been used to create some full standalone games, even commercial ones such as Steel-Storm: Burning Retribution.
I don't know if QuakeSpasm still requires the "proof of purchase" file to run custom content
Just checked the most recent code, and yeah, it still does the COM_CheckRegistered check. This is actually still a useful distinction in quake, even outside of the context of running custom content, because it also ensures tat people don't accidentally blunder into the e2, e3 or e4 entrances in the Start map if playing shareware. well you could set "registered" to false without disabling custom content. That cvar is what locks the episode gates.
If I'm experiencing big slowdown and framerate stuttering when there are lots of animated lightmaps on-screen, which command line value or cvar am I forgetting to set? The game runs 100% fine the rest of the time...
I'm guessing you're running Intel GPU + Fitz 0.85 or an old version of Quakespasm?
The GLQuake lightmap upload code could slow to a crawl on some drivers, Intel in particular. MH fixed it a while ago and the fix made it in to QS 0.90.0 (iirc) and MarkV. You should probably also define "lots".
The animated lightstyle code in stock GLQuake and derivatives, even with my fix, just doesn't scale. All that my fix does is batch up some uploads and provide the right hints to the GPU that it doesn't need to do a format conversion, but it's still possible to construct scenes that run in the 20/30/40 milliseconds per frame range. The real fix is to move lightstyle animation entirely to the GPU. This is actually quite simple (you can do it in GL 1.1 even) and you end up trading off texture uploads (and pipeline stalls) versus extra blend passes and draw calls (and increasing the video RAM requirements for lightmaps). The devil is in the dynamic lights, but you can do these with more blend passes and attenuation maps (if you don't have shaders), at the expense (I think) of not being able to take the surface normal into account. The whole thing becomes significantly simpler (not to mention much faster) if you're prepared to say "screw GL 1.1" and require shaders. End result either way is that the frame rate is levelled: scenes with lots of animated lightstyles run at much the same speed as scenes with none, and lightstyle interpolation becomes possible. Dynamic lights run roughly the same as the old code, but with much higher quality, and proper dynamic lighting of large MDLs and BSP models becomes possible. dynamic lights then need to become (shadowless) realtime lights, otherwise you're stuck with just flashblends/coronas.
still, if you're willing to ditch dynamic lights and non-glsl to optimise light styles, you can create a non-lit pathway through your code for almost no cost at all. throw in texture arrays and remove the whole view-frustum-recalculation-every-frame thing, and your bsp rendering drops to almost the cost of just a pointcontents and a glMultiDrawIndirect call. this is what I did with my 'onedraw' engine, its performance humiliates FTE on most/nearly all maps, but is also far more limited (being from-scratch doesn't help), with no dlights, no lits, no skyboxes, etc. alternatively, you can move the lightmap updates onto a different thread - fte's 'r_dynamic -1' setting does this. Unfortunately GL still basically requires the GL api to all be done on a single thread(as does d3d9), though presumably this could be accelerated a little with pbos. Shadowless real time is what I mean, yes.
As for lightstyles, when you break down the R_BuildLightmap code it clearly just becomes: texture * lightmap0 * style0 + texture * lightmap1 * style1 + texture * lightmap2 * style2 + texture * lightmap3 * style3. That's trivially easy to express in GLSL with or without additive blend passes, and not much more difficult to express in fixed pipeline GL. End result is animated lightstyles without new texture uploads. I'm going to rabbit on about this for a while cos it's something that I've done a lot of research on, and the end results were a little counter-intuitive. It's also useful to provide the background and reasoning for what I'm advocating; it demonstrates that I have done the research and that I have the figures to prove it.
So, I'd always been aware that lightmap updates were a bottleneck in GLQuake, and it really hit bad on some RMQ (and other) maps. There are basically two steps to a lightmap update: R_BuildLightmap and glTexSubImage2D. Contrary to what I expected, when I benchmarked I found that R_BuildLightmap was actually not the bottleneck. You can comment out the calls to R_BuildLightmap so that it still does the glTexSubImage upload, and you get the same bad performance. You can comment out the calls to glTexSubImage but leave R_BuildLightmap in and it runs fast. With glTexSubImage there are 3 factors that influence performance: size of data being uploaded, whether or not the driver needs to do a format conversion, and whether or not the driver needs to stall the pipeline. For typical Quake lightmap usage, data size is hugely unimportant. Unless you consider extreme cases (e.g update nothing versus update everything) data size just doesn't matter.
Format conversions can kill performance, and the stock FitzQuake code will always need to do a format conversion. Stock FitzQuake requests lightmaps in GL_RGB format on the GPU, but (unless you're using very weird hardware) there's no such thing as a 24-bit GPU texture format. It's powers of 2 all the way: 8-bit, 16-bit, 32-bit, etc. GL_RGB is also an unsized format, so the driver is free to give you 5/6/5, 10/10/10/2, 10/11/11, 8/8/8/8 or whatever. What you most likely will get is 32-bit, 8/8/8/8 with the last 8 unused, but you're not actually 100% guaranteed that unless you ask for it (i.e GL_RGB8). At this point some people will kick and scream about "wasting memory". I loathe that term; it's not "wasting" it, it's using it. There may be nothing stored in the memory, it may never be read from or written to, but the extra byte per texel is being used to increase performance. This is the very same principle as cache-aligning data, aligning allocations on page boundaries, aligning (or padding) to 16-bytes for SIMD, etc etc etc on the CPU. Why are people so fucking surprised that similar principles apply on GPUs? Get over it. So stock FitzQuake code has (most likely) a 32-bit texture on the GPU, but supplies 24-bit data on the CPU. That's a format conversion, right there, and you're totally at the mercy of the driver for how efficient (or not) it is.
NVIDIA always seemed to take the fastest path for the type of conversion needed, so a simple conversion might take 1ms but the most complex take 40ms. AMD/ATI always seemed to take a similar path irrespective, so conversion times might bob around 10ms to 20ms. Intel was batshit insane. I can't remember the times but they were off the chart. The only explanation I could think of was that the driver downloaded the entire texture from GPU to CPU, did the conversion, then re-uploaded the entire texture back to the GPU. I don't know if that's actually true or not. Stock FitzQuake also did a glTexSubImage upload per-surface rather than per-lightmap. With a typical ID1-sized map, that could be several hundred uploads instead of maybe a maximum of 10. And each one of those uploads is a pipeline stall, so it totally breaks CPU/GPU asynchronous operation. Instead of the CPU handing a bunch of work off to the GPU and being able to continue itself, it instead handed a small bit of work off, waited for it to finish, handed another small bit off, waited, etc, several hundred times per frame.
That's the same codepath that stock GLQuake with R_DrawSequentialPoly took, and the same performance characteristics are observable there. But stock GLQuake didn't have GL_RGB lightmaps, so it didn't do any format conversions; stock FitzQuake just got the worst of every possible world. This wasn't such a huge problem in the old 3DFX days because the graphics pipeline (or at least the part of it that was implemented by the GPU) wasn't as deep back then. Only per-fragment and framebuffer ops happened on the GPU, so the effects of a stall were significantly reduced. On modern hardware it's catastrophic. It's the equivalent of putting a glFinish call after drawing each msurface_t. Stock GLQuake with multitexture disabled batches up glTexSubImage calls so that they only occur once per lightmap rather than once per surface. It also doesn't do any format conversions.
Stock FitzQuake with multitexture disabled also batches up glTexSubImage calls so that they only occur once per lightmap rather than once per surface. It still does format conversions, but the impact is reduced. It's still horrible on Intel though. That's why "disable multitexture" was the standard advice when using stock FitzQuake on maps with lots of lightstyle animations. It wasn't that the single-texture path was any faster in the general sense, it was that lightmap uploads were implemented in a more performant manner. But it's possible to write a multitexture path that also batch-uploads all lightmaps before drawing anything, and in that case disabling multitexure will just make everything slower. So, current QuakeSpasm fixes all of this with the exception that it uses GL_RGBA/GL_UNSIGNED_BYTE on the CPU. That will still trigger a format conversion on (?some?) Intel drivers. On those drivers, the only combination that doesn't trigger a format conversion is GL_BGRA/GL_UNSIGNED_INT_8_8_8_8_REV. I believe that on D3D10+ class hardware it's not a problem, however.
None of this scales. It runs fine on ID1 maps, it runs fine on medium-sized maps, it runs fine on small maps with many light updates, it runs fine on large maps with few light updates. It will still excessively slow down on large maps with many light updates. Again, the number of lightmaps grows, the number of glTexSubImage calls increases, factor in brush models and add lots of them, and you're back to hundreds of uploads per frame and all the herkie-jerkies that come from that. Brute-forcing it on the CPU isn't the answer. With that kind of surface count you'll probably get something worthwhile by threading R_BuildLightmap (which will be called so many times as to make this worthwhile) but you'll still hit a single-thread ceiling with your glTexSubImage calls. You need to solve it more creatively, and moving the updates entirely to the GPU is the answer. You never need to check if a lightstyle is modified, you never need to run R_BuildLightmap, you never need to call glTexSubImage2D. And here's something else where parts of the Quake community need to pull a collective stick out of their collective arse. The best-case will run a little slower with this kind of set up. So instead of getting 4000 FPS in DM3 you might get 2500. That doesn't matter a bollocks. You don't optimize the best case, you optimize the worst. Sacrificing a tiny piece of performance (0.15ms) in the best case in exchange for a huge performance increase in the worst (to the extent that there can potentially be no difference between them) is the right thing. At this point some people will kick and scream about "wasting memory". I loathe that term; it's not "wasting" it, it's using it. There may be nothing stored in the memory, it may never be read from or written to, but the extra byte per texel is being used to increase performance. This is the very same principle as cache-aligning data, aligning allocations on page boundaries, aligning (or padding) to 16-bytes for SIMD, etc etc etc on the CPU.
[...] The best-case will run a little slower with this kind of set up. So instead of getting 4000 FPS in DM3 you might get 2500. That doesn't matter a bollocks. You don't optimize the best case, you optimize the worst. Sacrificing a tiny piece of performance (0.15ms) in the best case in exchange for a huge performance increase in the worst (to the extent that there can potentially be no difference between them) is the right thing. I wholeheartedly agree. _o_ Here's a hug. Also, I'd love to see any hardware, ever, where you can run at 2500 FPS. Optimizing is good; obsessing over it is not.
Nice writeup, it all seems to make sense even though I don't have much to do with rendering stuff. For reference, it was fitzquake085 on the last map of The Five Rivers Land. Big wide arena mostly covered with torchlight and often a half-dozen dynamic-lit projectiles crossing it. Stuttering went away just by facing outwards, so I thought it must be a rendering thing. Quakespasm copes with it without the adverse reaction.
Sometimes some newbie shows up and asks why "the Quake community" doesn't do X, Y, or Z like [insert other game, for example "like the Doom community" or "Quake 3"].
But there is no such thing as "the Quake community". Just different individuals of different interests doing stuff they want to do for free. Its not like someone is demanding Barnak do this or that some Steam user must do this. No --- because no one makes demands of free loaders and newbies and insists they must do things. Ah, I clicked submit instead of preview.
What I was trying to say that even a well-intentioned highly skilled engine coder diatribe about how things should work is still basically saying that someone else has to spend their time a certain way for free. That point of view has merit. And it is Tragedy of the Commons because such demands are only directed at the "top producers". No one makes demands of noobs. In a commercial project that would be sold and generates sales, you'd be absolutely right.
In a free project that is a pastime, I don't know if you are right. And one of the most important rules for a pastime is knowing it is a pastime. And The Tradegy of the Common very much applies, you made an exit back in 2013 for this reason and I was already making an exit and once I saw you declare your exit, I left too. It was too much of an out-of-control zoo. 18 months later I'd come back -- sort of --- with firm boundaries in my head and communicate clearly the limitation of what I was willing to (not) do and when I was willing to (not) do it. I'm pretty sure that's true, no doubt about it.
Do we have, however, some kind of display who can actually show those 5K FPS? That was really kind of my point. :) Here is a partial list of "blockbuster" map releases in the last few years:
a) A Roman Wilderness of Pain [aka ARWOP] b) The Alter of Storms [aka ne_ruins] c) Rubicon Rumble d) Remake Quake that will grind down to single digit frames per second in a traditional GLQuake style engines. But a DirectQ or FTEQW can instead of getting 12 fps will get 150 fps or 300 fps. And these kind of mega-maps have been "the norm" in the last 5-6 years. There are plenty more where those came from. a) requires enhanced network protocol (FitzQuake 666 or similar)
b) requires enhanced network protocol (FitzQuake 666 or similar) c) requires BSP2 support, enhanced network protocol (FitzQuake 666 or similar) and should have alpha masked texture support. d) requires the Remake Quake engine bundled in the download (BSP2, alpha masked texture support, Remake Quake's protocol 999, hurt blurs, other 2D effects) What kind of hardware is actually limited to low FPS in those maps? Laptops with Intel GPUs? No system I've played them on with Nvidia GPUs has had issues.
With what engine? Quakespasm since late 2014 or thereabout has used vertex arrays so the performance is about triple the norm on maps with tons and tons of monsters.
try them. fix stuff that doesn't work. job done.
its not like engines that support this stuff are closed source, so it shouldn't be that hard considering the stuff you've previously managed. Sample source code implementing protocol 666 download source
Every single protocol 666 change is marked with: #ifdef FITZQUAKE_PROTOCOL Yeah, every last change is marked. Do we have, however, some kind of display who can actually show those 5K FPS?
That's kinda not the part that's important; it's a bit of a strawman, in fact. As some of us have hinted, running DM3 at 5k FPS is actually not an interesting problem. Take 200 FPS: say someone has a 144Hz display and bump the target framerate to 200 to allow headroom for transient peaks. Running DM3 at 200 FPS isn't an interesting problem either. I'm pretty sure that even a low-end phone can do that nowadays. Running a big, complex map with big, complex scenes at 200 FPS - now that's an interesting problem. You can solve anything if you throw enough brute force at it; but solving it on lower-end hardware too: even more interesting. Historically the Quake engine was viewed as "can't do big scenes" or "unsuitable for open areas" but it turned out that none of that was actually true. It's obviously not the best engine for this kind of thing, but a primary cause of it's historical problems was in the implementation of it's renderer, and it wasn't too difficult to make the necessary changes to solve those problems. So do that and what will happen is that running DM3 at thousands of FPS will also happen, but as a side-effect, not as the primary goal. 1. per-texel lightmap blending?
How does quake's software renderer achieve per-texel blending? example 2. how and where in the rendering pipeline does "palettization" occur? I assume that illegal colors are produced after a lightmap is blended with the diffuse texture? If so, my best guess is that palettizing is the last step before being drawn, though I have a feeling this is 3. a practical way to achieve this look for a modern game? Software render? GL render? GL render + GLSL shaders or some other form of post processing? here is a screenshot palettized in photoshop. I'm currently using these janky mockups to help inform art direction. Obviously, this method is sub-optimal and I suspect this is not close to what an actual game renderer would output. It's a pain in the ass because this rendering style depends on an appropriate art style else it all turns to shit... hence the previous questions. After spending months testing color palettes, I have a whole new level of respect for the id art team. Cramming quake in to essentially 240-ish colors is an art form in itself. I apologize that can't comment on any of your questions but I do have to say that screenshot is extremely fucking killer.
I concur. Love the light design on the door and the left & middle monsters. Would be thrilled to see them in Quake.
unless the project dies, in which case the assets would probably be handed over to the quake community.
You have a ModDB page or something for this project? I'd like to know more and keep myself informed. Perhaps send a PM or post in General Abuse? I don't want to clutter the thread with OT.
for the first and second questions:
1. the lighting is blended with the textures in a "surface cache" which is in texture space so it's always 1 pixel per texel (rather than in screen space where one texel covers many pixels.) That's why you don't see banding that crosses over the middle of texels. 2. the entire renderer is 8-bit so it never has to be "palettized" at run time. 8-bit texture data is combined with light map data in a lookup table called colormap.lmp, where the resulting value is also 8-bit. So i guess it's the creation of this lookup table (shipped with the game) where the palettization takes place. #3 is complicated an other people probably have better answers than me. huh, pretty interesting. that clears a few things up. feels like something that specialized could have some drawbacks. it would be super cool though. devil daggers looks really nice, i wonder how they did it?
@mugwump - no, nothing public currently. I'll make sure you get the word when it's out there :) #2 something like:
diffuseindex = texture[s][t]; lightlevel = lightmap[lm_s][lm_t]; pixelvalue = colourmap[diffuseindex][lightlevel]; so yeah, a simple 2d lookup. the surface cache is just a cache that provides a lower res source lightmap, at an appropriate mipmap level. #3 r_softwarebanding in FTE replicates it with glsl (essentually the same, except the colourmap already has the rgb values expanded to save an extra lookup). taniwha's glsl renderer also does this. this lookup actually happens 3 times over in fte so that lits work as expected. if the lighting is always grey then its identical(ish) to software rendering. there's some fiddly stuff required to get the lightmap sample changes snapped to match the diffuse. and the choice of which mipmap to use follows standard opengl based on pixel distance with an annoying bias based upon the slope of the surface, unlike software rendering picking some midpoint or something and then using a single mip level for the entire surface, so you might want to tweak the d_mipcap cvar to use only the first 3 mip levels or something (yes, FTE uses the proper mipmaps too). this is actually resolution dependant. talking about resolution, r_renderscale 0.25 will scale the rendered res down. negative values in rev 5026 will give you nearest filtering (with a vid_restart annoyingly). I have no idea what you'd need to set up to get DP to replicate this. In theory just paletted textures instead of rgb ones. you can probably just provide greyscale or whatever for the base mip level, but autogeneration of the other mips will just result in noise. if you were to hack some paletization logic into glsl, then my suggestion to you would be to use a 3d texture, but again you'd probably need to hack dp's sourcecode for that. failing that you'd have to express the colour ramps mathematically. 2) See r_surf.c
3) Are you sure you want to do this? The restrictions of 8-bit color software rendering are great for scientific purposes (because they help to expose the needs and the limits of color transformation algorithms), but not for artistic purposes. After studying software rendering for so long, I'm sure that being truly faithful to its limitations isn't worth the effort. It's too painfully restricting. You can get good, painless results by reducing the smoothness of each color channel individually. Let's say, by zeroing the lowest 4 bits of each channel, you'll limit the colors to 16 shades per channel, for a total of 4096 colors. This way, you'll be able to create low-color assets without fighting against palette limitations. A lot of players like/prefer the paletted look. Yes, I'm sure a lot of it is down to nostalgia, but that doesn't make it any less a legitimate reason to pursue the 8-bit look for artistic purposes.
@spike - interesting. I didn't realize fte had these features out of the box. I'll revisit fte this weekend. Honestly, I can't recall why I switched to dp, I think it was an issue with q3 shaders or something. r_softwarebanding and r_renderscale are some tasty morsels. Is there presently a cvar to control the distance at which a mip is used? Are mips generated by the engine? If so, can I create mips manually to be used instead? If i recall correctly, fte supports fbsp?
@mankrip - It's very restrictive, yes. Sometimes that's a good thing. I am very fond of the idea of an 8bit software renderer. It's a romantic idea, I can see why it would be ultimately be dismissed as impractical by many. 4096 is a lot of colors. I'm currently using 16 shade textures... after lightmaps (some of which are colored) you end up with a fairly large range that just doesn't look right. It's neither 8bit or hi-fi graphics... it's sort of a cheap impression, but not genuine. If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be? it's not 8bit, but not high color either (I think). @kinn - I agree entirely. In my case, it's not really nostalgia. Some of my first Doom/Quake experiences where with DP and Doomsday. I later discovered software rendering and immediately preferred the look. There is something magical about it, almost like an animated painting... I can't quite put my finger on it. If so, can I create mips manually to be used instead?
A while back in the mapping help thread, Rick told me about a program called MipDip that supposedly allows you to replace the submips. You can find it on Quake Terminus. I tested it briefly but didn't understand how it works, I'll need to look into it more. @killpixel, sorry, forgot to mention that r_softwarebanding only works with paletted source textures, which means the feature has only really been tested with q1bsp+q2bsp+q1map(with wads). the engine doesn't generate any mips itself in this mode (so watch out for that too).
I could give you some workarounds for q3bsp, but its probably better if I just add palletization logic so that you won't have to tread so carefully... and get wads+wals working properly for paletteized mips. anyway, the basic idea is that you use 'fte_program defaultwall#EIGHTBIT' in your shader (giving you glsl-based nonq3style shaders) with a 'map $colourmap' (which preprocesses the colormap.lmp), then fte pulls in the palette+lightmap+etc textures too. for q1+q2, this already happens by default, but q3 content is much more likely to have shaders overriding things, and fte's explictness means you may want to modify those. If this were magical christmas land, I would have a software renderer with a 512 color palette, or something along those lines. Would that even be?
This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance. A 512 color palette would use 9-bit values for addressing. However, those 9 bits would have to be stored in 16-bit pointers. So, each color index variable would require twice the memory anyway, increasing the amount of cache misses. They would also require bigger color transformation tables and extra bounds checking, which would result in significantly slower performance. I don't remember all the specifics, but when comparing all possibilities, I've realized that the best options would be to either use direct RGB color values (as Unreal does), or keep the renderer in 8-bit indexed color. And then, since a number of operations are faster to perform in 8-bit indexed color, due to dealing with a single index value instead of individual values for 3 color channels, I've decided to stay in 8-bit. @spike
forgot to mention that r_softwarebanding only works with paletted source textures I do use indexed/paletted textures (not quake's palette). though this might not be what you mean? @mankrip This is one of the possibilities I've studied for a long time, and it isn't worth it. The problem isn't just the size of the palette, it's the speed performance. I had a feeling... So, I really have 2(ish) options: 8bit (with all it's limits) or some sort of post-processing shader. I don't understand how it works, but a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display. @mugwump thanks for the link to the glsl shader... I've messed with that and a couple other shaders in DP and never got them to work. They either don't work at all or end up looking all messed up... :/ a glsl shader seems like a brute force method that's not as accurate as a true 8bit renderer. I imagine it functioning like the way I do it in Photoshop: The scene is rendered, then "palettized", then sent to the display.
AFAIK, that's exactly this. The "correct" way would probably be to quantize textures to a global 8-bit color palette, generate 8-bit color transformation tables (lighting, blending, etc.) from the palette, and apply them using a fragment shader. Faithfully replicating Quake's lighting is more complicated, because lightmaps should be upscaled 16x with bilinear filtering, and then quantized to 64 levels. Those 64 levels are then used to index the 64 levels of the color shading map (colormap.lmp). AFAIK, that's exactly this.
That isn't desirable IMO, though it may seem trivial to others. Not only does it seem inefficient, the pre-palettized scene is just an approximation and sometimes won't look the way it's intended once palettized. Designing for software rendering is partially about defining the intended looks, and partially about accepting the resulting looks.
Daemon engine supports Q3 maps and 3D color look up tables which could get you very close I think. In this case you could just take the look up table and apply the palette to it. Otherwise I guess you could do it a la deferred rendering and render lighting and albedo separate and then return the resulting index of lighting + albedo for every pixel, you'd only need 16 bits to store all that. Might be more true to quake's approach but I doubt the average player would notice the difference between the two, especially if you go low-res ("oh this looks like an *old* computer game").
It's probably easier to make a palette whilst doing art, only adding colors to the palette when you really need to, less is more and all. #622 - that seems to be the case.
#623 - I'm familiar with that. I think it's since been assimilated by the latest gzdoom build as "tonemapping". #625 - I think I've come across that engine before, I think it was developed for a particular game? Something natural selection-esque IIRC. I'll have to give it another look. Thanks for the lead. Qbism super8 I think.
quakespasm with all the graphics settings nerfed. https://www.youtube.com/watch?v=RtDBQ333KEo I thought super8 was a software engine? Besides, I tried super8 and it fucked with so many basic things that I never wanted to open it again (weird particles, stupid weapon swaying etc, and it had some pointless palette-bend on by default which screwed up all the colours.
quakespasm with all the graphics settings nerfed.
I'm talking about an emulation of how the software engine takes the texture pixel and the lightmap and then uses a LUT (quake's colormap) to output a colour still in the quake palette. There's something about the final look which is just magical to me, and it's not just nostalgia talking :} I am sure that Mark_V has a winquake style version now? Not tried it a great deal but might be worth checking out
MarkV WinQuake looks great but is a software engine and thus I get single digit framerates on modern maps.
I was just hoping someone may have tried to emulate the software look using a modern graphics API, that's all. Well, I know you don't like DP but Nahuel recently uncovered a GLSL shader for DP that aims to emulate the retro look. I haven't tried it so I don't know how accurate it is, but you might want to give it a try. You can find it here: http://quakeone.com/forums/quake-mod-releases/finished-works/12469-hgszs-retro-quake-glsl-retro-shaders-darkplaces.html
Note that the 2016 DP builds break this shader, so Seven has fixed it (scroll down to post #10 for link). Read baker's last post in the mark v thread. I just shat myself with excitement.
Wait. What. Windows WinQuake through Open GL for KillPixel You mean that? Because if that means what I think it means, then consider my dungarees dung'ed and my breeches browned also! damn just realised a few posts up people are talking about FTE doing this - I'll have to have a look.
fte with r_softwarebanding 1 uses 8bit rendering for the world and models, except for coloured lighting (where each colour channel is performed as a separate lookup) so disable lit support if you want strict 8bit colours.
this applies to world(gl+vk renderers) and models(gl renderer). other things including particles etc are unaffected by this, but at least fte's particles can follow palette-based ramps too. Thanks - just had a look and r_softwarebanding looks lovely and I even like how it looks with fog and coloured lights on top of it too!
There's a lot of stuff I'll need to turn off though to make it look and sound more vanilla - is there a "proper oldskool" config somewhere? m_filter defaults to 0 so reset that if its no longer 0. there isn't any other mouse smoothing.
m_accel 0 maybe? again defaults to off. 'fps_preset vanilla' should disable(and in some cases enable) all the stuff to make fte feel like vanilla's software rendering, including the demo reel, nq sbar, nq player physics, software banding, square particles, disables lerping, etc. complete list of cvars changed with the presets: https://sourceforge.net/p/fteqw/code/HEAD/tree/trunk/engine/client/m_options.c#l818 (each preset is cumulative with the prior ones, so you'll need to consider the settings above the vanilla preset also, if you want the complete list) the problem with lots of settings is figuring out which ones you actually want set. :s quakeforge's glsl renderer should also render much like software rendering (unlike its regular non-glsl gl renderer).
that said, I don't know how easy it is to get quakeforge to actually run, hopefully taniwha has fixed it up a little since I last tried. m_filter "0"
m_accel "0" I have those set but it makes no difference - the mouse just feels weird and laggy compared to quakespasm, like the movement is being interpolated or something. QS feels immediate... I'm sure you've checked, but is vsync enabled, either in the client or forced by your gpu settings?
No I hadn't checked, and that was indeed the culprit. vid_vsync "0" now added to my config. Cheers! Can anyone recommend a tool I can use to profile the cpu / gpu usage of quake engines on my pc? I have noticed that when using Quakespasm, my laptop is silent, but on other engines I've tried (FTE, MarkV), running under the same config I use for QS, my laptop's fan blows like a foghorn for some reason...
This is almost certainly happening because QS is using a Sleep call every iteration of it's main loop, whereas other engines are not.
There are valid arguments to be made that running flat out is actually correct behaviour for a game engine. Might that also be related to how QS's CPU usage rockets when I have it minimised vs when I'm playing it?
I used HWiNFO to log all the stats when running the quakes.
I did a test where I played demo1 twice in QS, and did the same for MarkV using equivalent graphics settings etc. (actually I played demo1 three times in MarkV because the fan was really going crazy after the second time round and I wanted to see if it was getting any hotter) So here is a simple chart of the max CPU temp across all my cores when playing the demo, sampled at 2-second time intervals (there are less samples for QS because I played the demo twice there vs three times for MarkV) https://docs.google.com/spreadsheets/d/1ozielkRSptmYI6PSSrn1QwSBcai8WTHauQ1pW8z__5s/edit#gid=0 With QS my CPU temp always stays just below 50C, but with MarkV it's constantly running over 70C. Now I'm no engine guru but my gut feeling is I'd rather keep my CPU temp at 50C if I have a choice in the matter (considering I'm getting identical framerate in game either way) mh - what are the advantages to "running flat out", as you say? is this win7? you can set your cpu states in power management. depending on your mobo you can do this via the bios. You can also have the client run on 1 core, may help temps. Maybe even give process tamer a try.
70C isn't necessarily bad. I wouldn't want to run 74-80 constantly, though. Not sure I want to go digging around in bioses and tinkering with CPU settings, not really my area :}
Yeah, QS has a 1ms sleep in main_sdl.c. It also sets the Windows timer precision to 1ms (done by sdl) - afaik this raises power use somewhat for the entire system while QS is running, but it should mean that a 1ms sleep is actually 1ms and not 15ms or something.
Just looked at MarkV's source, it looks like you need to set "host_sleep" "1" to enable sleeping. I imagine the temps will be about equal once MarkV is sleeping. On complex non-id1 maps QS may take a lead, owing to its new GL renderer, but not sure if this will show up in temps. Well damn, that did the trick! Just did another profile and the temps in MarkV are down to around 50C, similar to QS.
So, any reason why this isn't the default behaviour? First of all, and to establish context, there at least used to be a perception that Quake is an older game, uses less resources, therefore it should have lower CPU usage than a newer game. However, a simple "while (1) {}" loop is sufficient to peg a CPU core at 100% (you won't see this in modern Windows because the OS will move it from core to core quite frequently). So it's not the amount of work you do that matters.
Both Windows Sleep and Unix/Linux usleep specify that Sleep times are a minimum, not a guaranteed time interval. To quote from the usleep man page: "The sleep may be lengthened slightly by any system activity or by the time spent processing the call or by the granularity of system timers." So when you sleep for 1 millisecond, you will actually be sleeping for more than 1, and the specification allows it to be much more than 1; this can be sufficient to cause you to miss a vsync interval, or disrupt input. 1 millisecond doesn't sound like much, but if you remember that 60fps is 16 milliseconds per frame, then it's a substantial enough fraction of it. At this point a typical reaction might be something like "Quake frame times are so short anyway, surely this is just a theoretical problem". So let's assume that a typical frame time is 1ms. The frame runs then it's followed by a bunch of Sleep(1) calls until it's time to run another. It should be obvious what's going to happen - at some point the last of those Sleep(1) calls is going to fire, and if you sleep for just a little too long you're going to miss the interval and the next frame will run late. Slightly late with vsync disabled, but with vsync enabled you'll drop to 30fps. So the reason why it's preferable to run flat out is because the alternative is potentially worse. That shouldn't be read as meaning that all Sleep calls are bad. If you're running on battery your priority changes and you'll definitely want to sleep. But sleep as a general solution should be avoided; the OS should move your program between cores automatically which will prevent individual cores from ever running at 100% all the time, so nothing should be overheating. Or alternatively, if it's a multithreaded game that's already CPU-bound, then you most definitely don't want to be giving up a resource that you don't have enough of to begin with. None of this is going to convice anyone who's already made up their minds, I know... how does this relate to c-states and os power management? Do sleep calls trigger certain c-states? If a system has c-states and power management disabled does host_sleep override that or does it do nothing?
I don't know about Linux, but on Windows Sleep calls don't define how your program interacts with OS power management. All that the documentation states is that the current thread is suspended for an interval based on the value you specify.
What I infer from that is that if there's other work that the core could be doing, it will do it, so you should have no expectation that calling Sleep will guarantee that you'll go into a power-saving mode. After all - Quake isn't the only program running on your OS. My only objection, for Windows anyway, is the current Sleep docs here seem to state pretty clearly that, if you set the timer resolution to 1ms with timeBeginPeriod, a Sleep(1) will actually sleep somewhere between 0 and 1ms, but not more than 1ms. IIRC, I have measured Sleep(1) sleeping for several milliseconds if you don't call timeBeginPeriod, but if you do it's reliably never more than 1ms. (Of course, this is one random test I did, one PC, probably windows 8.1 or 10, but at least it matched the docs.)
Agree regarding vsync.. it always seemed broken to me, at least in QS (adds so much input lag that it's almost unplayable), maybe most Quake engines (?). If vsync is in use, shouldn't the throttling of the mainloop be left to the blocking "swap buffers" call? If vsync is active then I suggest don't throttle otherwise, either via sleep or Host_FilterTime. IIRC a glFinish immediately after SwapBuffers helps some; causing input to sync up correctly with display, otherwise the CPU may be running a few frames ahead of the GPU.
Last time I checked vsync was a busy-wait on some hardware/drivers, but that was in the D3D 9 era. About 3 weeks, I tried the Mark V WinQuake on a high end gaming laptop I imagine is similar to yours.
The experience was absolutely terrible and was like 10 fps. Keep in mind on my Windows machine which is nothing remarkable, I get an easy 300-400 fps in Mark V WinQuake on resolutions like 640x480. I made some adjustments in the just uploaded Mark V which I think may dramatically improve the WinQuake version with machines like yours. (*I say "I think" because I made some adjustments for the GL version and it was perfect afterwards on that machine. It slipped my mind to do a WinQuake test, so I can't know for sure.) There is a gitlab with bug tracker here, not sure if it's Xonotic specific. However, it doesn't look like a fork; at least commits are synced between that and the icculus site. Still seems to be somewhat active.
https://gitlab.com/xonotic/darkplaces/issues heh, doesn't fix it... The 64 bit glx version forces my monitors into mirrored mode, rather than primary / secondary.
SDL version works fine though. DP Is Not In Active Dev as far as I know...
It is again since April 2016, as evidenced by Icaro's link (don't refer to the outdated Downloads page). It now uses the latest quakespasm base code.
https://dl.dropboxusercontent.com/u/108695968/Quakespasm-IRC-0.3.zip I'm also slowly adding speedrunning features to it. When it gets a proper release with more features I might give it a name change and make a proper news post for it. For now, if you're planning on streaming playthroughs, here ya go. -Snaut Does the
It contains black magic and the souls of the undead. Want to check? Try loading a map that needs one... WITHOUT IT!!!
It holds colour * intensity, so an intensity 0 red light will be 0|0|0.
Everything else needed for lighting is actually stored in the surfaces lump, outside of the lightdata. So: each surface stores an offset into the lightdata where it's lightmaps begin (if that offset is -1 then the surface has no lightmaps and so is fullly dark), as well as the styles used by the surface. Does anyone know why in Darkplaces sometimes the sky will show on the water...instead of the water? Is this fixable or a bug?
|
|
|
|
|
|
|
Post A Reply: |
|
| Website copyright © 2002-2017 John Fitzgibbons. All posts are copyright their respective authors. |