|
Posted by Baker on 2012/06/29 11:38:17 |
I wasn't planning on doing this mini-project, it started as an effort to address some Fitzquake issues, fix them the right way up to Fitzquake standards (i.e. do it right, once and properly versus continual releases) and donate it back.
FitzQuake Mark V Download:
http://quake-1.com/docs/utils/fitzquake_mark_v.zip
Short version: Eliminated most issues in FitzQuake thread, most issues I can even remember hearing of ever and marked every single one clearly with a very minimal implementation.
It may be the case that only metlslime and Quakespasm and engine coders may find this engine upgrade of interest.
Features: 5 button mouse support, single pass video mode, external mdl textures, alpha textures (like RMQ), record demo at any time, rotation support, video capture (bind "capturevideo toggle"), console to clipboard, screenshot to clipboard, entities to clipboard, tool_texturepointer, tool_inspector (change weapons to see different info), clock fix, contrast support, fov does not affect gun, gun displays onscreen, Quakespasm wrong content protection, external ent support, session-to-session history and .. (see readme). |
|
|
#1046 posted by Baker on 2016/02/05 23:53:08
It was a 2 liner. Here's how it worked:
D_PolysetDrawSpans8
if ((lzi >> 16) >= *lpz)
{
byte bsrc = ((byte *)acolormap)[*lptex + (llight & 0xFF00)];
if (bsrc != 255) { // Baker: masked theory.
*lpdest = bsrc;
*lpz = lzi >> 16;
}
}
I feel like a complete jerk as result.
#1047 posted by mankrip on 2016/02/06 00:10:53
Oh, that's a MDL. I thought it was a BSP.
Baker
#1048 posted by Kinn on 2016/02/06 01:01:36
Awesome!
#1049 posted by necros on 2016/02/06 04:33:02
wow baker, this is great! thanks for taking a chance on the alpha textures on models!
#1050 posted by mh on 2016/02/06 11:12:03
Surely it should be "if (*lptex != 255)" - I don't know if palette index 255 can ever come out of the lighting calculation, but that aside, alpha should come from the base texture anyway.
#1051 posted by Baker on 2016/02/06 11:56:45
You are right. I only spent a few minutes, tried a quick experiment and it worked. I think the above happens to work because 255 is a fullbright.
Feb 7 2016 - Beta Build
#1052 posted by Baker on 2016/02/08 02:43:19
Windows Open GL + WinQuake | Windows Direct X Version
* Alpha masked models support (set .mdl's QME 3.1 0x4000 flag)
* Alpha masked models for WinQuake version too
* No limit static entities
* RCON remote console support (ProQuake compatible) + full NAT fix.
* sv_map_rotation "dm3 dm6 dm4 dm6" --- map rotation via cvar - repeated names fine, it won't get confused.
* May have (all?) obscure mod bug-fixes that NightFright pointed out.
* Install from Quaddicted. Type "install travail" for instance. Type "uninstall travail" to uninstall.
* No dependencies at all. Just single .exe
Source. Maybe next time will update Mac build.
Impressive
#1053 posted by mankrip on 2016/02/08 03:30:56
Baker
#1054 posted by nitin on 2016/02/08 11:53:14
will this play orl's new map set?
#1055 posted by Baker on 2016/02/08 15:00:57
ericw did a very kind thing by making a scrappy custom Quakespasm executable with "protocol 999" support for orl's map so more people might try it.
As I understand it, it isn't true protocol 999 and wouldn't be able to play, for instance, RemakeQuake like the RemakeQuake Engine can screenshot.
So it's not a real protocol -- it's just something kind that ericw did for ORL.
Protocol 999
#1056 posted by mh on 2016/02/08 15:18:15
It's been a while but IIRC protocol 999 was deliberately designed to be modular; if I've got this right, a standard protocol 666 data flow is also a valid protocol 999 data flow with the exception of the protocol version number and an extra int which is used to specify what optional features are used.
Again working from memory, clients and servers then use that extra int to negotiate what set of these optional features they both have in common, and from there features are enabled or disabled.
So in theory even a "scrappy protocol 999" is therefore also a valid protocol 999.
But like I said, this is all from memory. The last released version (which was not supposed to be final) may or may not support all of this, but what I've just described is certainly what the intention was.
MH
#1057 posted by mankrip on 2016/02/08 15:54:55
This interests me. It's one of the goals of my protocol experiments.
Got more detailed info on this?
999
#1058 posted by Spike on 2016/02/08 16:57:13
scrappy = perfectly adequete.
possible host_errors is better than unconditional host_errors, imho.
partial is better than none.
unless baker wishes to propose a different solution for large maps or jerky rotations? :P
@mankrip
#1059 posted by Spike on 2016/02/08 17:24:45
// protocol flags
#define PRFL_SHORTANGLE (1 << 1)
#define PRFL_FLOATANGLE (1 << 2)
#define PRFL_24BITCOORD (1 << 3)
#define PRFL_FLOATCOORD (1 << 4)
#define PRFL_EDICTSCALE (1 << 5)
#define PRFL_ALPHASANITY (1 << 6) // cleanup insanity with alpha
#define PRFL_INT32COORD (1 << 7)
#define PRFL_MOREFLAGS (1 << 31) // to do - support this...
if its protocol 999, then read a 32bit integer interpreted as the above flags. those flags define how it differs from 666.
If there's a bit set that you don't understand, error out or something.
there is no handshake/negotiation in rmqe, the server dictates and clients are expected to fall in line.
rmqe uses PRFL_INT32COORD| PRFL_SHORTANGLE| PRFL_EDICTSCALE
qs-oms3 uses PRFL_INT32COORD| PRFL_SHORTANGLE
fte uses PRFL_FLOATCOORD| PRFL_SHORTANGLE (which matches dpp5+ and fte clients, as well as avoids extra inprecision...).
ericw missed te 255 apparently (but so does fte, so whatever).
He also missed U_SCALE (which might come back to bite him with illegible server messages on rmqe servers).
QS should probably also warn if any protocol flags are set that his client doesn't support, again to avoid any bewildering illegible server messages.
personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place.
#1060 posted by Baker on 2016/02/08 18:26:10
Obviously I want smooth rotation. Would ideas behind this protocol permit the following to evolve in it:
1) Prediction
2) Baseline compression/ack frames.
3) EF_FOLLOW, EF_NODRAW and other flags like DarkPlaces, view weapons
4) Possibly connectionless connections.
5) Team scores in multiplayer?
@mh
#1061 posted by Baker on 2016/02/08 18:29:33
"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means? Is that how .alpha in FitzQuake 0.85 if 0 for a new entity should actually be --- I think 255 is full alpha, but I haven't looked.
#1062 posted by mh on 2016/02/08 19:11:06
It's slightly, and amusingly, ironic that one aspect of Quake that RMQ very successfully recreated was the somewhat fucked-up development.
personally I'd recommend against having the client distinguish between 666 and 999 other than to parse the flags. its simpler to treat them identically except with 666 having flags 0, but that's just my opinion because I hate lots of OR expressions all over the place.
I'd agree with this recommendation; I can't remember what way I did it originally, but like I said - the intention was for 999 to be identical to 666 but for the flags, so this approach would work and be cleanest.
Got more detailed info on this?
There's not really much more to say aside from what Spike and myself have said. Protocol 999 was designed in a rush to meet a very specific requirement (a large map going beyond regular bounds) and was left unfinished. Despite that the intention was for it to be easily adoptable and extensible, so bit of forethought was put into how to achieve that. Hence the fact that you'll see that there's a "moreflags" bit already reserved, which signals to send another int (and IIRC the intention was also that bit 31 of this other int would in turn signify even more flags, and so on, so it should in theory be infinitely extensible).
"alpha insanity" -- that appears several times in the RMQ engine source code. Could you explain what that means?
I think this is in reference to the FitzQuake standard of having an alpha of 0 signifying full opaque. I understand why this was done (so a memset-0 would set a good default) but I remember being annoyed by it at the time. Probably unnecessarily annoyed too, I must add: juggling multiple things, 75% of which aren't even working and all of which are needed now for content does tend to stress one out a little.
@mh
#1063 posted by Baker on 2016/02/08 19:41:19
Kinn managed to get me excited about alpha textures on .mdl --- resulting in a couple of updates. I couldn't resist!
I guess I'll be meditating on the protocol 999 thing. My destination of choice is full, no compromises coop support in a way that would meet Spike's approval.
If protocol 999 is a pitstop on that road or not, I still can't tell although perhaps Spike can tell me.
re: the alpha insanity, I hear you ;-)
(I think I'll use the Pitfall logo for this post, I don't think I ever used that one before ... heh)
#1064 posted by Spike on 2016/02/08 20:06:34
in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.
the problem with extending protocol 999 is a case of who defines the flags.
my own extensions have a chained style, ultimately terminating in the protocol version that they're meant to be extending.
note that fte also has a handshake mechanism (but falls back to stuffcmds for nq).
see also: PEXT2_REPLACEMENTDELTAS|PEXT2_PREDINFO|PEXT2_VOICECHAT, if you're bored.
my personal fear is that everyone defines their own extensions and then I end up feeling like I have to implement 5 different variations of the same extension, each with a different svc or different order of flags etc. each subtly different that I can't share code despite them all fundamentally doing the same damn thing.
unfortunately there is no real authority when it comes to extensions.
#1065 posted by anonymous user on 2016/02/08 20:23:05
in fitzquake, 0 means wateralpha for turb surfaces. other values ignore wateralpha entirely, thus it does make a distinction between 0 and 255.
I was thinking more in terms of entity alpha and FitzQuake's ENTALPHA_* macros, with the memset-0 happening in ED_ClearEdict.
My most ideal thing would be split-screen support with controller support. No idea how that would work but I would be overjoyed with that.
Coop...
#1067 posted by Spike on 2016/02/08 20:48:16
baker, I don't really do approval, ever...
not sure why you're looking at me specifically about coop.
all I can really say is that coop without some easy way to punch holes through NATs is somewhat futile nowadays, from a usability perspective.
my xmpp thing used an XMPP server for ICE stuff, but needing people to create accounts etc is a significant issue, and even using existing acounts like gmail addresses is filled with far too many nightmares.
I keep meaning to use an irc server or something for it, but I can never find the motivation to try.
You could also run your own specialised server for it, but gah, infrastructure.
@spike
#1068 posted by Baker on 2016/02/08 21:20:26
I mean your "school of thought" on the efficiency of a network protocol. No I don't mean your explicit approval, per se.
(And maybe with luck I may have a real block of time later this year. Otherwise it's 2017 -- and such is the way of things in this world ...)
#1069 posted by ericw on 2016/02/08 21:30:47
Thanks for the code review :) Mankrip: here is the diff to QS. I was meaning to test it more, like test connecting between my implementation and FTE/DirectQ/RMQEngine and demo compatibility, but didn't get around to it yet.
I will look at implementing PRFL_EDICTSCALE.
One thing I need to look more closely at is the "roughround" flag in RMQEngine, in MSG_WriteShortAngle:
// -1 and -2 are legal values with special meaning so handle them
// the same way as ID Quake did; other values can use rounding
if ((f == -1 || f == -2) && roughround)
{
// encode to byte, decode back to float to get the same behaviour as ID Quake
sang = (int) (f * 256.0 / 360.0) & 255;
f = (float) sang * (360.0 / 256);
}
I'm not sure what the purpose of that is.
Also, I am tempted to switch QS to use the 24-bit position to save space. I noticed that with 32-bit positions, QS overflows the signon buffer when loading telefragged.bsp (this map requires something like 48KB with protocol 666..)
My thought on the protocol flags: it's useful if a demo recorded with protocol 999 is playable in any engine that supports 999. This implies freezing the set of flags, because otherwise an old 999 client won't be able to play a demo (or connect to a server) running a new 999 version with new flags.
General thoughts: I'm still sort of meditating on this as well, and it's not merged into the main QS repo. Larger than +-4096 map support only really happens for users/mappers if 999 is enabled by default, you can't expect users to know whether a map requires >+-4096 support and set the sv_protocol cvar accordingly. I even forgot to set it myself while testing oms3_2.bsp and had to restart the level, lol.
@fifth
#1070 posted by Baker on 2016/02/08 21:46:30
My to do list --- whenever the time comes and it does not feel soon ---
1) ipv6 + what I have been discussion above + automatic background high-speed LAN/non-LAN propogation of current mod running for coop via TCP.
2) Enhanced graphical integration with Quaddicted.
3) Mirrors + security cameras.
4) Linux software renderer build and polish up unreleased OpenGL version which regretably uses SDL because X Windows is a cluster-mess and seems like it was designed by a basement nerd who never used an operating system with a decent GUI --- and even then SDL doesn't cover all the bases, but hats off the SDL guys because it does cover 90% of the way and SDL 2.0 is exceptionally nice and forward thinking.
5) Inter-map travel with single file saves.
6) Absorb remaining ProQuake features. Absorb 1 or 2 remaining JoeQuake features. Mark V already plays .dz demos on any platform with no dependencies, the Mac build for instance. ProQuake will then become just a different build of Mark V.
7) sv_gameplay_fix_qrally_is_a_crappy_mod_dot_com 1
8) Probably add rotation back in.
9) I think I needed to touch up Nehahra in 2 places.
10) Possibly multiplayer save games.
11) Take another look at WinQuake and what I wanted to do but didn't. It wasn't too much, but I can think of a 2-3 things.
12) Would need to check list, I'm sure something else is on there.
|
|
This thread has been closed by a moderator.
|
Website copyright © 2002-2024 John Fitzgibbons. All posts are copyright their respective authors.
|
|