Dr. Sean
-
Content count
30 -
Joined
-
Last visited
Posts posted by Dr. Sean
-
-
-
Sending changes in an entity's state is indeed a far better scheme than periodically sending an entity's full state. It allows for superior decoupling of the game simulation from the network serialization as entity states are simply serialized at the end of the game loop.
I employ a similar scheme in a new branch I am developing based on the TRIBES engine architecture. In my approach, the game play simulation sets a flag whenever it changes the state of an entity. For example, if P_ZMovement() changes an entity's Z position, P_ZMovement calls a function to set a flag that the Z position was changed this during gametic. Under the hood, each entity has a circular buffer of bitfields, with a different bitfield for each of the last N gametics. And each bit of the bitfield represents whether a specific field of an entity's state was modified in that gametic (eg, Z position). Thus when sending a client the delta state of an entity gametics 50 and 55, that entity's bitfields for gametics 50 through 55 are bitwise AND'D together to get all list of all fields that were modified and need to be serialized.
This paper describes the architecture of the TRIBES engine and subsequent TNL library.
http://www.pingz.com/wordpress/wp-content/uploads/2009/11/tribes_networking_model.pdf
Video and slides for similar information: http://coderhump.com/austin08/
This paper describes Doom 3's architecture, which is an advancement over Quake 3 Arena.
http://mrelusive.com/publications/papers/The-DOOM-III-Network-Architecture.pdf
This video describes Halo's architecture, which is based heavily on the TRIBES architecture.
http://www.gdcvault.com/play/1014345/I-Shot-You-First-Networking -
Patrol1985 said:DAMN IT! :P
Who confirmed it and when?
Sponge from id Software has confirmed it several times on IRC. He's also one of the organizers of QuakeCon and was great to work with regarding the 20th Anniversary tourney at last year's QuakeCon. -
Doomkid92 said:Certainly not, DOS autoaim works a charm. Perhaps the lag I experience (usually around 300ms) effects my playing worse on Zandronum because of the different netcode used. (Odamex uses a CSDoom base, where as Zandro doesn't, if I'm recalling correctly that is.)
I would say the issue is not auto-aim but rather the fact that Zandronum uses your round-trip ping time (calculated once a second) for the unlagged system. This is problematic when your connection has jitter (packets don't always have the same round-trip delivery time), which is usually pretty noticeable when you're playing over-seas. It means that when you press fire, the packet containing your input may not reach the server in the same amount of time as the last ping value and thus your accuracy will suffer. -
bradharding said:Increasing each 64 to 1024 appears to resolve the issue, which I've done so DOOM RETRO.
Doing so may possibly lead to integer overflows when the scale value returned by the function is used, and in particular, rendering when the player walks underneath 2s midtextures. In my experience, 256 was a better value than 1024. Eventually this issue was the catalyst prompting me to rewrite Odamex's renderer to eliminate angle-based scale calculations entirely. -
Quasar said:I don't think id is actually even aware that they're still using the Vicarious Visions version of Doom 2. The version of Ultimate Doom included on Xbox 360 and in BFG Edition after all is based on the original IWAD, *not* VV's version containing E1M10.
id is definitely aware of the differences. I (and others) have spoken to Sponge regarding the Steam version of Doom 2 and the topic of BFG Edition came up as an example. Whether or not id chooses to introduce new IWAD changes in future releases is up to them but at least the topic of maintaining compatibility is on their radar as well as a few options for making changes without breaking IWAD compatibility (hard-coding the executable to load PWADs containing changed maps instead of changing the IWAD). -
Uncapped framerates do not cause additional input latency. However, most ports that have uncapped framerates also use interpolation to approximate the player's view angle and position between 35Hz gametics. This does add a sense of input latency because there is now additional latency in the result of the player's input being displayed to the screen.
Interpolation requires two known data points and for a Doom renderer that is trying to interpolate the player's viewing position, those two data points would be the player's position in the current gametic and the player's position in the previous gametic. If it has been 14ms (approximately 50% of the time of a gametic) since the last time the game performed its input handling and physics, interpolation will find the position that is halfway between the previous position and the current position and then render from that interpolated position.
So the interpolated position is always somewhere between the current position and the previous position. This creates a varying latency that can range from 0ms to 28.6ms (1/35Hz). -
Odamex decouples the rendering frame-rate from the gameplay frame-rate so that they can be completely independent. The net result is that renderer frame-rates can be capped at arbitrary rates, such as 60.0fps or anything that the user wants. When Odamex is rendered at 35fps, there is no game-world interpolation, but with any other frame-rate, interpolation is used determine the position and angle of all actors, lifts, etc.
Odamex's code is very much built on the info in this article: http://gafferongames.com/game-physics/fix-your-timestep/ -
exp(x) said:I imagine main memory speed and latency is also a factor.
This is very important with the Doom software renderer's method of drawing wall columns, which makes extremely poor use of the CPU's cache and causes the CPU to fetch and cache a line of the destination frame buffer from RAM for each pixel of the column the renderer draws. Fortunately there are some tricks to making better usage of the cache such as drawing four interleaved columns at a time to temporary buffer or by drawing in 64x64 blocks but the speed it takes to fetch from RAM is still a bottleneck. -
This was really great exposure for the Doom community and I think the tournament showed FPS players that Doom can be an incredibly exciting game when played competitively. I know Odamex and Doom in general have gained several new players as a result of the stream and the wonderful job Jehar did explaining some of the subtle nuances and quirks of the game as the matches unfolded. I felt fortunate to work with Sponge of id Software to ensure things went smoothly and I think we're all grateful to see Doom take center stage for its 20th anniversary.
-
NerdKoopa said:So, when I tried to run Epic CTF in Zandronum and Odamex, the flags refused to appear in both source ports. In Odamex, only the pedestals appeared, but not the flags.
In Odamex, the flags are only spawned on the map when you're connected to a server running the CTF game mode (sv_gametype 3). In single player mode, you'll only see the flag pedestals. -
Ladna said:Hmm, I still think they're pretty different. I didn't bother to fully understand it, but (in MBF and Heretic) PTR_AimTraverse does:
slope = FixedDiv (opentop - shootz , dist);
while ZDoom 1.23 does:
pitch = -(int)R_PointToAngle2 (0, shootz, dist, opentop);
It seems to me like this difference would account for the different vertical spreads, but I could be wrong.
When I made a patch that implemented ZDoom 1.23b33 weapons as an option, the vertical spread for the ZDoom 1.23b33 SSG was noticably reduced, with ranges from around 18% to 28% less than that of vanilla Doom's SSG vertical spread. The code you quoted above was what appeared to cause that diversion. -
Holering said:Noticed enemy heads seem clipped off (most notably imps) at a distance and appear melon-like. Is this a scaling issue in the renderer or a linux bug (using linux)?
I haven't seen this issue before. Could you provide a screen-shot and hopefully a link to a pastebin of your odamex.cfg file so I can determine which combination of settings you're using?
Holering said:Also, double horizontal and double vertical with 640x400 resolution and stretch doesn't appear like vanilla doom or chocolate-doom; looks un-evenly distorted.
The Detail option in the Video Modes menu is misleading now that I look at it again. "Double Horiz & Double Vert" does not actually increase the level of detail - it instead halves it. Not withstanding that, based on what you wrote, it looks like you're using the option to try to emulate the look of 320x200. I think Odamex would be better served by removing the Detail option and implementing a scaling mode to mimic 320x200 in a proper manner.
Holering said:Can't get mouse setup like chocolate-vanilla doom either. Feels like Quake 3 (seems perfect for multiplayer). When I walk forward with keyboard I can force doomguy to walk backgrounds almost instantly with only the slightest vertical mouse movement down. Can't change this behavior and it kinda sucks. Any help to get this more like chocolate-vanilla Doom would be great!
It should definitely be possible to have the same mouse feel as Chocolate Doom in Odamex. Although Odamex's mouse is very similar to Chocolate Doom's with Odamex's default configuration, it appears Chocolate Doom enables its mouse acceleration code by default. To do this in Odamex, type set mouse_acceleration 2.0 and set mouse_threshold 10.0 into the console. -
XCOPY said:tl;dr: What does Zandronum have that modifies the game's experience in oldschool doom gameplay?
Although there are numerous differences in the client/server code and how latency compensation, interpolation, and other bits of smoke & mirrors that ports use to try to hide the effects of latency, your post does specifically mention "oldschool" so I'll focus on that aspect alone.
IMO, a true oldschool experience would be one capable of exact fidelity with vanilla Doom. To that extent, an oldschool-flavored port should be able to play the vast majority of vanilla LMP demos perfectly to emulate the little quirks, bugs, and nuances of vanilla Doom.
The three major client/sever (c/s) ports are all based on different versions of ZDoom, which has notably diverged from vanilla Doom compatibility in favor of a perhaps a more modern game feel. Zandronum is based on the 2.x versions of ZDoom where as ZDaemon is based on ZDoom 1.23b33 and Odamex is based on ZDoom 1.22 with 1.23b33 physics. All three ports make some attempt to offer some degree of (toggleable) vanilla feel beyond what they inherited from ZDoom, with Odamex being the closest (it can play vanilla LMP demos), ZDaemon being second, and Zandronum being a distant third.
Some key differences you'll find between Zandronum and vanilla Doom are the physics and the weapon damage.
Zandronum has a different vertical spread for the SSG and a different method of calculating the damage per pellet. Some competitive players complain that this SSG feels too weak, but that is hardly conclusive. ZDaemon does not have the same spread or damage that vanilla Doom does, nor does it appear to be the same as ZDoom 1.23b33, however it is closed source and no further information can be determined. Odamex's spread and damage match that of vanilla Doom.
While I'm not that well versed on Zandronum or ZDoom 2.x's physics code, I probably qualify as an expert on the ZDoom 1.23b33 code as I added the ZDoom physics code on top of Odamex's vanilla physics code. Some of the general changes all versions of ZDoom have when compared to vanilla is wallrunning in both north and south directions, aircontrol, proper three-dimensional explosion damage/thrust, altered gravity, smoothing of the player's view when going over bumpy terrain, and non-projectile actors moving over/under each other.
Typically when you hear competitive players complaining about Zandronum physics, keep in mind that they are typically complaining about the differences between Zandronum/Zdoom 2.x physics and the ZDoom 1.23b33 physics that they prefer, rather than comparing it to vanilla. There appear to be some real differences that do change the feel of the game but I'm sure someone more versed in ZDoom 2.x would be able to offer a better comparison in that direction. -
Ladna said:Isn't Windows MIDI what SDL mixer uses? I just fired up PrBoom+ and PortMidi sounds just like SDL mixer.
PortMidi can use any Windows or ALSA MIDI device you choose so it doesn't have to go through the Microsoft GM Synth if the user has a better alternative available. There is really nothing special about PortMidi itself - it's a much lower-level library for MIDI playback than SDL_Mixer. You have to parse MIDI files yourself and feed PortMidi the appropriate MIDI events in real-time.
The advantage that PortMidi offers over SDL_Mixer is that you can feed volume events to the MIDI device to adjust the overall volume of playback instead of SDL_Mixer's approach of calling midiOutSetVolume(), which unfortunatley causes digital audio volume to change as well. -
dew said:the former part of capo's post is correct (ladna's not going to host the site anymore), the latter is speculative. (edit: actually, it's also true.)
So you're saying capo was 100% correct? -
The most significant SDL_Mixer issue we're familiar with in Odamex is that when you ask SDL_Mixer to set the volume of MIDI playback, the volume for all sound in the game is set to that value under Vista/7.
When switching from playing a MIDI song to a non-MIDI song like OGG, SDL_Mixer will fade-out the MIDI song. This causes the volume of all sound in the game to be 0 until the next time the MIDI volume is adjusted (usually the next time a MIDI song is played).
The underlying cause of these issues is that Microsoft changed their paradigm for sound mixing in Vista/7 and have a separate mixer channel volume control for each application. Unfortunately, that means that both the MIDI music and sound effects share the same volume control and can not be controlled separately via the method SDL_Mixer uses to set MIDI volume (midiOutSetVolume).
In Odamex, we worked around these issues by writing a MIDI file player that sends MIDI events to a playback library (PortMidi) in realtime, allowing us to generate MIDI volume control events as needed. -
Quasar said:IF EE can record perfect vanilla demos that play back in the original and in Choco Doom, it just lets me know I haven't broken anything :>
Like EE, vanilla demo compatibility is an important feature in Odamex, but not the overriding goal of the port. However, testing demo play back sure is a great sanity check to make sure code changes don't alter Doom behavior! -
40oz said:Is that a new feature with this version of Odamex? Monsters can have their health doubled?
Yup, new for 0.6.2! Server admins can also change how much damage monster attacks do as well. -
Ladna said:Regarding support stuff, just don't support it. Do you think Odamex supports IDE or Doomseeker (well OK, they pretty much help everybody out because they're cool, but they don't have to)?
When I get time to implement new netcode in the near future, I most certainly plan on helping Blzut3 out with implementing it in Doomseeker (or quite possibly taking the burden off him and writing it myself) and the same with IDE. Let's face it: even though I think our own launcher is great, other users have their preferences and it's in our best interest to make sure they can still use Odamex from their launcher of choice.
(Edit: typo) -
Gez said:IIRC, Odamex has a nice mouse system where it can read your settings from ZDaemon/Skulltag/ZDoom config files and figure out how to translate it into something that'll respond the same way in Odamex.
I'd love it if the conversion code was somehow detailed and generalized so that one could convert mouse settings from one port to another. It could be a nice little stand-alone utility.
A little late to the thread, but ask and you shall receive (at least part of your wish):
http://odamex.net/boards/index.php/topic,1549.0.html
I can certainly break things down more than that if you're interested... -
In Doom, hit detection considers players and monsters to be a square, not a circle. This leads to a very interesting property:
A player's hit-box is 32x32 when looking at the map. This means that if you attack a player while facing north, south, east, or west (as hallways are typically aligned), you have a hittable area that is 32 units wide, as seen by the red part of the hit-box in this first pic:
However, if you attack a player while facing north-east, north-west, south-east, or south-west (as one might when using SR-50 in a hallway), you have a target that is 45 units wide. This is because two sides of the player's hit-box are exposed. This forms a right triangle with 32 unit sides and a hypotenuse that is 32*sqrt(2) = 45 units, as seen in this second pic:
My gut feeling is that when players feel swing-shots are more effective than normal shots, it is because they tend to fire while facing their target at a 45 degree angle during their swing. This makes the hittable target 40% wider and a lot more effective. -
entryway said:
I used a bit of that code as the basis for the PortMidi player in Odamex. Unfortunately switching back and forth between SDL_Mixer and PortMidi still requires a little bit of hackery but it seems to be a working solution for us. ...at least until I can get around to submitting patches to SDL_Mixer and hoping for the best. -
Bastet Furry said:BTW, this reminds me of a little picture...
http://i.imgur.com/W94IJ.jpg
That whole thread was pretty damn hilarious!
Network Messages vs. Deltas
in Source Ports
Posted
I'm writing something from scratch but using the TRIBES white-paper as a basis for the message reliability system. There are some things I want to do that just looked too difficult to shoehorn into the TNL libraries.
I am looking to have the network message format described in a data-definition language in such a way that the client and server can compose message writing and parsing objects from the format definition. When a client connects to a server, the server sends its message format definition to the client and the client then builds objects to parse each type of message. This would allow the client to connect to a server that uses a different message protocol version. More importantly, it would allow clients to play network demos recorded with older versions automatically.
TNL achieves world consistency by always sending the changes in entity state since the last acknowledged state - the same as Q3A.
PVS does become an issue with cooperative play, where you have 300 monsters and an assload of projectiles flying everywhere. I plan on using PVS even for DM or CTF in the interest of reducing network latency by transmitting smaller packets.
What I've read while researching the topic is that routers do not subject small, fixed-size packets transmitted at regular intervals to as much buffering (read: additional latency) as irregularly sized packets when the router comes under load. So my goal is to send 35 packets per second at 64kbps with a fixed packet-length of 228 bytes (and pad if it's smaller). When the connection between the client and server appears to become congested, the packet-length and the packet frequency is temporarily reduced to avoid those unseemly 2-3 second latency spikes that occur when the router's incoming packet buffer gets filled.
Agreed. It looks like you're sending delta states for the entire game world to keep things conceptually simple and I'm sending them on a per-entity basis for finer-grained control. Both methods will get you there. The only important thing is to move away from manually sending network messages for entities like it's 1997.