|
Post by ketmar on Oct 14, 2022 2:15:16 GMT -5
tdrr, VOXELDEF is not supported, and prolly will never be, sorry. you have to create the usual Vavoom model definition XMLs for voxels, in ZDoom, voxels replaces sprite lumps, globally, for any use of that lump. but in k8vavoom, voxel model is simply another kind of 3d model, and should be created as such.
|
|
|
Post by camper on Oct 14, 2022 8:35:18 GMT -5
I don't think polygonal monsters are bad per se, but usually the models are atrociously bad. Yes, I absolutely agree that the attempt to recreate polygonal monsters from doom1,2 was a failure. These monsters are truly disgusting. Need to take a set of monsters whose design takes into account low polygonality. Their design does not have to completely repeat the original doom, but only the functionality like as freedoom. Such monsters look pretty good and fit in organically.
|
|
tdrr
Doomer
Posts: 66
|
Post by tdrr on Oct 14, 2022 14:45:13 GMT -5
tdrr , VOXELDEF is not supported, and prolly will never be, sorry. you have to create the usual Vavoom model definition XMLs for voxels, in ZDoom, voxels replaces sprite lumps, globally, for any use of that lump. but in k8vavoom, voxel model is simply another kind of 3d model, and should be created as such. Aw, unfortunate. I guess I'll get to it at some point, still interested on checking how K8Vavoom fares with the mod. Thanks for the heads up. Such monsters look pretty good and fit in organically. Ah yeah, that I can agree with. Would certainly be nice-to-have.
|
|
|
Post by ketmar on Oct 15, 2022 6:59:25 GMT -5
the main problem with any 3d monsters is animation: don't interpolate it, and it will look ugly. interpolate it, and everything will look like it's swimming. and you don't have enough flexibility with Doom 35 FPS state machine to use mid-state animation frames. it is not a problem with pickups and decorations, though, and i'm playing with 3d models for almost everything except the monsters for years. but i still have to see a good-looking animated 3d model for Doom monster (being it from the original roster, or some new design).
in k8v, it is possible to use "mid-state animation frames", but you need interpolation turned on for that, and you'll almost inevitably get that "floaty" feel to animation/movement.
maybe it is possible to design a new monster set with this limitation in mind, but hey, it won't be Doom anymore! ;-)
|
|
|
Post by ketmar on Oct 15, 2022 7:08:14 GMT -5
Aw, unfortunate. I guess I'll get to it at some point, still interested on checking how K8Vavoom fares with the mod. Thanks for the heads up. it heavily depends of your GPU. basically, it is a GPU performance test, because models are fully uploaded to the GPU, and rendered with a single OpenGL call (ok, several calls, constant number anyway). voxel optimiser will hardly matter here, because it needs a lot of big flat surfaces to do its work, and organic models don't have many of those. p.s.: i am quite interested too, but too lazy to perform the conversion. let's wait then… ;-)
|
|
|
Post by 3t0 on Oct 16, 2022 20:04:31 GMT -5
yes, it is possible to "detach" objects from the server and receive only notifications about some "interesting" events (like projectile collisions), or "detach and discard", leaving client in full control (useful for blood splats and other decorative things), and such. the foundation is there, it's simply not polished well enough. Very interesting! And pure clientside entities like in modern quakes, besides paticles, are thus not completely possible, or? Or better said there must be detach phase. it basically calls network I/O code on each frame. the very same code is used to record and play demos too (and that's why you can't have a stable demo format here: there is simply no such thing as "network protocol" here beyond the bare minimum, everything else is just sending script states and doing RPCs; any script change may reorder the fields and RPCs, and everything will break). How do you prevent blocking on network read fd ? Or because it's UDP it never blocks? It's some time since I played with beej's hello world UDP examples. Would you benefit from some kind of packed unified hash? I heard mumble uses googs protocol buffers, so those are certainly mainstream enough and at the same time performant enough for real-time application (would perhaps fix field ordering problem?). Or that brings nothing advantageous to the table. you can't do it that way, because each object in Doom could access and modify state of any other object. that's why we can't have multicore playsim, and that's what "server" part is. the "client" part is mostly about various VFX like particles and such. also, local client can directly access server state, so it does. but yes, you still can see "spawning a server" and "disconnecting" messages in SP game, because that's what "server" code prints. Aah I never relized this might be a problem in Doom silly me. Now I see my foolishness. In Quake, because of "realer" separation between client and server, it's harder to peek and poke server memory, but in Doom it's a necessity. So how did Zandronum abstract this? Also, I presume, this means bugs, because MP playsim is quite different (server memory missing on pure clients, so no server peekig?) compared to SP, right? yes, i'd like to see more coop wads, where coop is really required. i mean, where you need your friends to actually cooperate to finish the map by doing different things in different map parts, coordinated and such, not just a simple "the same as SP, but with more firepower". My thoughts exactly, but I believe due to, obviously, combinatorics explosion, this becomes quickly beyond even more advanced mapper's capabilities it seems. As "a programmer" I see myself coming up with some gadgets and hacks to help myself, and mappers are pretty crafty, but given difficulties are still hard to add for many, this is probably beyond "normal" mapper's reach. If any of you played Painkiller that's how you do massive SP/COOP bosses, I believe. That is why I was so excited by elementalism. Boses there were basically gimmick bosses like Quake's Chthon, but still very original (especially Earth boss is great "protomix" of model and sprite) and a blast to see at least. I didn't like their phases, they felt very unoriginal but these bosses were still miles better than some "other boses" which are essentially just multi projectile "bigCaco" (like in Order of odonata or Hedon). That's another reason why I asked you about attachments: model/voxel + attached sprite is indeed very interesting combination. I understand in elementalism it's all faked: Earth boss body model being just decoration and real boss being the heads that convert later to "BigCaco" (LOL). It's basically some weird icon of sin. Painkiller bosses feel much more epic and massive, because they can move: (Oh I almost forgot the swamp boss and his fart bubbles) We don't get games like these anymore (besides modern doom of course). Hmm I wonder what would be needed to make something so big play nice with the game - probably having no playsim collisions with player is a must, so that we can move under it(?) (or being physically just bigCaco "locked" to specific height - so that feet do not block the player movement?). All faked so it still registers hits form player weapons. Also at that resolution, 3D model seems like a must, although I saw this done with sprites in some coop wave mods. How to do multiple damage zones without attachments is not clear to me either (to bring some r-type variability to fight). Probably it would also benefit from some specific navigation logic where boss can move near/over you but no completely on your position, or rather say: if he is a box 256x256 a logic so you can get 160x160 to its center, essentially under it, so that is' body can be "over" you, before it starts to move away from you, like in pankiller, so you get that "omfg he almost stomped me" feel? Probably a pipe dream . in Heretic, the player could be morphed into a chicken. ZDoom generalized it to a common "player morphing", so the player (pawn) could be "morphed" into some other player class. that's how some mods are doing vehicles, for example — by "morphing" the player into "vehicle". while Vavoom supports chickens, the whole morphing thing is very different from how it is done in ZDoom, and isn't as flexible as ZDoom one. I always wondered how they do those vehicles - so that means no vehicle mods for k8v ? Bummer . yes, i know. but the problem is much deeper than that, actually: for example, my video drivers sometimes makes the whole network system to starve, even on 127.0.0.1. but somehow it mostly manifests itself when i run a "combined" client-server, not for a dedicated one (with dedicated, clients are working ok). i still don't know if it is some fault in my code, or i am triggering some OS/driver bug ... that's why i really need separate physical boxes to properly test things. I see. This thing of mine is old as well, but at least for shit like that it's relative powerhouse. Yes, I see you really need your own cluster: some boxes and network hardware. still 4.14, and see no reasons to upgrade. ;-) I see you are a LTS guy like me - this epoch it's pretty fancy, how many LTSes there are. there are some ongoing missile attacks here, leading to power outages. so expect my server to be inaccessible quite often for now. sorry. It seems it's becoming second Palestina slowly, stay strong! I like to indulge myself with the illusion that if you translate all the content of the "assaultcube" to the k8 engine, then this would attract attention. Many resources from the "assaultcube" are not exclusive only to him and I think that from a moral point of view this is acceptable. I understand you - been there done that. But I don't believe that is the way - though I might be wrong. You would be just diluting assault cube's membership and your thing is basically just and asset flip. I have a little story about this, so if you wish to read it, ask for it. In addition, k8 is already an advanced single player engine. Ketmar disagrees with me, but I think "chasm: the rift" style polygonal monsters are very good for doom. Especially when I saw the chasm project on the gzdoom engine. I know that project - it's amazing that they managed to rip the models. What sucks is that they failed to rip the textures, so the maps do not look too good. Or rather IMHO Doom graphics color palette does not blend well with Chasm color paletted monsters. Same situation is with Quake models: they look pretty good in Doom like games. Palette is different though. They should rip the textures and get something really Chasmy going on, but as far as I know the project is dead. Second thing: I think ketmar objects mainly to actual Doom monsters being 3D models not 3D models per se. I don't think polygonal monsters are bad per se, but usually the models are atrociously bad. The ones in Risen3D or those that supposedly came bundled with Vavoom for some time were downright horrible. I believe the same. Doesn't help they usually don't change animation framerate so they look really janky and unrealistic with their motion. As far as I understand k8v state engine doesn't allow you to simply change animation frame counts on existing entities, thus naive 3D model replacements must have same number of model frames as sprite equivalent. Maybe I am talking out of my ass here, but I believe that is the case. But if I am not mistaken k8v has model vertex animation interpolation (not 100% sure though) so it should somewhat blend. Unfortunately, for "morphing" models (lol) as all MD? model formats are (besides MD5 which is weird) this will always lead to "bubbling" of the entities (watch kingpin retro videos on youtube to get what I mean). MD3 sidesteps this slightly by having bigger resolution for vertex positions, but model animations are still ye olde morphs (so they bubble a bit - it's just "almost" invisible). So you could fix it by making your version of "smooth doom" (if you know the mod), but in 3D. Ie design replacement entities that implement same monsters, but that have more frames for limbs movement than original sprites. I believe this is the only way to add more frames to the states, so that when combined with proper model format, like MD3 for example, model animation would finally stop bubbling and start to look good. This is roughly same amount of work as voxel sprites - and you need to write defs too. And special defs for k8v to be exact (xml) - if I understand it right. Only other thing to get rid of this is ... interpolate it, and everything will look like it's swimming. and you don't have enough flexibility with Doom 35 FPS state machine to use mid-state animation frames. ... skeletal animation. I know you hate the idea, ketmar. But I believe with IQM this would work. The main requirement which would complicate stuff would be that model animation engine (at least part handling skeletal models) would need to be slightly decoupled from other model formats and their animation logic. Nobody said that single state cannot last (instead of tics) as long as the given animation plays (at predetermined framerate). I don't understand how k8v works here, so I am not sure this would easily doable, but as far as it is only framerate unlocked engine I know of, it is only one that is also capable of doing such a feat, at least potentially. That is what I think. Maybe I don't understand it properly at all, so then disregard, but I am pretty confident in my "guessalisys". This would probably require changes to state tracker (I believe it still counts in tics - or not? no idea how unlocked FPS black magic joins back with ticking monsters) and model animation sub engine. Also suddenly the model draws are not as "simple" anymore either - there is this skinning shit going on, with vertex buffers and vertex shaders, and all the related, black magic, mumbo jumbo, probably too hard. Finally, unless person implementing the models is not meticulous with their animation timing, original monsters redone this way, would not exactly match the original doom ones tickwise anymore and would "break" the gameplay in all sorts of subtle and weird shit ways. However, it would be great thing for model heavy "games" (because mods like these are no longer simple doom mods) where there are longer and detailed animations for characters, that are smooth and precise. Now who would do models for this and write proper state definitions? Modders are pretty ignorant sometimes and k8v is lesser engine, despite being most advanced and interesting. Given my four decades of observing humanity I don't see it flying, really. Pros are that IQM has working Blender tools, it is supported in Cube2, Tesseract, multitudes of Quakes, so there are several implementations to look at and steal from. At least that part is covered. It's not much, but it's not that bad either - but integrating it all back into k8v though - quite a lot of work for too little (and only potential) benefit. Only future would show how successful it would eventually be and it's quite a big leap, with too much work, for "initially" too little gain. Finally, by having working skeletals, at one point or another, I believe, somebody would want to do attachments, the thing that ketmar is not a very big proponent of either. Anyway, so while achievable, it is pretty expensive stuff, with great potential but not so clear usage certainty in the future. I waste of time and resources? Would be very interesting to indies though , you bet. EDIT: Oh, and the voxel monsters. They're good, but... hot dang, my framerate! Too expensive in terms of performance. I am not observing any perf. degradation with gzdoom (it microstutters the same) and am too lazy to dust off my xml skills to try them in in k8v (but will eventually have to ). But if the state maps really match, as I believe they do (one kvx model to classic doom sprite), how hard would it be to add distance based auto toggle (between voxel and sprite) ketmar? Would you be willing to do that? Or does that already exist in engine perhaps (that would be so cool!)? Cheello's voxels are soo good, that they look identical to sprites form cardinal angles (intentionally), so at proper distance (I don't know, perhaps 512 units) even on high resolutions, you would be almost unable to tell that they suddenly became sprites - that would be such awesome feature to have and would ease load on many weaker machines I bet.
|
|
|
Post by ketmar on Oct 16, 2022 22:45:53 GMT -5
And pure clientside entities like in modern quakes, besides paticles, are thus not completely possible, or? yeah. client can spawn its own entities, and operate them as it wants — server will never send anything for them (as it doesn't know about them), so the client can do anything it want. How do you prevent blocking on network read fd ? Or because it's UDP it never blocks? you can do non-blocking with TCP too, but in k8v it's UDP, yeah. the network layer is responsible for assembling "real" packets from UDP parts. it's actually more complicated than that (it has several independent channels and such), though. basically, you can take a look at ENet, its design is very similar. Would you benefit from some kind of packed unified hash? I heard mumble uses googs protocol buffers, so those are certainly mainstream enough and at the same time performant enough for real-time application (would perhaps fix field ordering problem?). Or that brings nothing advantageous to the table. there's nothing i cannot do better and faster, and with less code. ;-) the problem with field ordering and such is not in the protocol, but in the amount of data to transfer. k8v network protocol doesn't even operate on bytes — it is often using less than a byte for some small values, trying to pack as much data as it can into one UDP frame. adding field tags will blow up the packets. i did that for savegames, though — the size is not a concern there, and that's why you very rarely have unreadable older saves in k8v, despite massive internal changes. the engine may complain about some missing fields in save, but it will use default values for them, and most of the time it works (because i'm trying to choose reasonable defaults ;-). So how did Zandronum abstract this? they didn't. ;-) otherwise they'd have a multicore playsim already. they basically did what Vavoom is doing, just with a different code. but the idea is the same. that's why i know i can beat Zandro in MP (because Vavoom has much better foundation for it), i just don't want to spend my time on that now. Also, I presume, this means bugs, because MP playsim is quite different (server memory missing on pure clients, so no server peekig?) compared to SP, right? actually, no. clients aren't doing playsim at all, everything orchestrated by the server. client only needs current actor state, position and direction to render it, that's all. just a dumb terminal. of course, to make it more… fluid, there is a need to perform at least some physics on the client… and that's where everything starts to break horribly. mostly because monster movement is not physics-based at all, the engine just force-teleports them instead of using proper directions and velocities. so i can easily detach projectiles (they are mostly physics-based), but not monsters. Hmm I wonder what would be needed to make something so big play nice with the game a little bit of VavoomC magic. remember, you can do everything with VavoomC, because it is the language that is used to write the whole playsim (including monster AI, of course). so you can create compound objects, change their sizes, and do other things impossible with DECORATE. How to do multiple damage zones without attachments is not clear to me either actually, we already have that in the engine — that's what "headshots" are. ;-) it's not hard to find where hitscan hits AABB. k8v headshots aren't fake — the engine actually calculates the proper hitpoint, and checks if it hits the area assigned for "head". you also have a much better chance to land a critical headshot if you're shooting closer to the vertical center of the object. I always wondered how they do those vehicles - so that means no vehicle mods for k8v ? at least not how it was done in ZDoom. of course, you can do that (with VavoomC), because that's how chicken morph is done. it's just not done the way ZDoom did it. there are some ongoing missile attacks here, leading to power outages. so expect my server to be inaccessible quite often for now. sorry. It seems it's becoming second Palestina slowly, stay strong! lol. thank you! i'm as strong as ever, though, but i cannot say the same about the city infrastructure. ;-) As far as I understand k8v state engine doesn't allow you to simply change animation frame counts on existing entities, thus naive 3D model replacements must have same number of model frames as sprite equivalent. you can do that, but it's not pleasant job at all. model frames can be assigned to states by their numbers, so they don't have to replace any sprite lump. and you can specify "intertick time" for model frames. so it is possible to assign several model frames to one state, with different "intertick timing", and interpolator will do the rest. barrel model, for example, does that for better liquid animation. actually, original Vavoom had no way to attach model frames to sprite names, and i had to add that feature to support MODELDEF from GZDoom (because this is the only way to assign create model animation there). But if I am not mistaken k8v has model vertex animation interpolation you're absolutely right. skeletal animation. I know you hate the idea, ketmar. But I believe with IQM this would work. i simply see no reason to do that. The main requirement which would complicate stuff would be that model animation engine (at least part handling skeletal models) would need to be slightly decoupled from other model formats and their animation logic. …and that's why. ;-) you need a whole new animation framework to support that, and actor code should know about it. basically, it means ditching DECORATE (as it is totally unfit), and creating the new, incompatible way to write mods. a lot of work for zero chances to get any traction. old mods won't magically work with the new system, so i'll have to write and maintain two separate subsystems for something hardly anybody will use. This would probably require changes to state tracker (I believe it still counts in tics - or not? no idea how unlocked FPS black magic joins back with ticking monsters) nope, everything in seconds internally. that's why Boom conveyors never worked right, for example — they're closely tied to 35 FPS, and to the physics based on 35 FPS lockstep. for some reason Boom authors choose to make conveyors completely physics-based: converyor belt simply changes the object velocity. it's a smart thing, but it heavily depends, for example, on friction values changing at a fixed rate. in k8v the impulse sometimes is too small to overcome the friction, and other times too big for friction to compensate it properly. and conveyors expect the exact values, because they're simply adding more velocity on each step, knowing that friction will reduce it by the fixed amount… which is absolutely not the case with Vavoom. so it works for some simple setups, but completely breaks for others. However, it would be great thing for model heavy "games" (because mods like these are no longer simple doom mods) where there are longer and detailed animations for characters, that are smooth and precise. yep. but i never intended k8v to be The Universal Game Engine. this is Doom Engine. ok, Doom, Strife, Heretic and Hexen engine. ;-) there is little reason to stick to the original idTech1 for a completely new game. i mean, it's ok to keep UDMF, for example, and some lower-level data formats, but there is no reason to stick to broken idTech1 physics, to its limited state machine, and so on. we can keep the rendering, but it would be way better to rewrite physics and playsim from the scratch. Pros are that IQM has working Blender tools, it is supported in Cube2, Tesseract, multitudes of Quakes, so there are several implementations to look at and steal from. At least that part is covered. there are no problems implementing model loading and rendering: internally, k8v model code is WAY more powerful than of any other idTech1 offspring. it already supports submodels, relative submodel placement (attachment, if you prefer), separate submodel animation, matrix-based animation interpolation, and many other buzzwords. ;-) it basically already has all the required pieces. Finally, by having working skeletals, at one point or another, I believe, somebody would want to do attachments, the thing that ketmar is not a very big proponent of either. DECORATE simply cannot do that properly. VavoomC can, though. Anyway, so while achievable, it is pretty expensive stuff, with great potential but not so clear usage certainty in the future. I waste of time and resources? yeah. it's kind of "nice to have" thing that could be done when somebody have infinite time and resources at their disposal. ;-) Would be very interesting to indies though , you bet. sure, i'm always open to hiring proposals. ;-) but i definitely won't do it for free. yet nobody approached me so far to hire me to create a custom 2.5D engine for their New K00l Retro Shooter (or RPG, or something else). ;-) But if the state maps really match, as I believe they do (one kvx model to classic doom sprite), how hard would it be to add distance based auto toggle (between voxel and sprite) ketmar? there is really a little reason to do that. of course, something like ancient Intel GPU emulator may struggle with 3d models, but even 10 y.o. GPU will spend almost none resources rasterizing someting as big as several pixels by several pixels. ;-) all models are uploaded to GPU, so i render them simply by telling the GPU that i want model number X at position Y, regardless of model complexity. and GPUs are smart enough to throw away most of the invisible pixels on their own. ;-) sure, it's easily doable (just one more check), but i'm not convinced that it worth the efforts yet. ;-) Cheello's voxels are soo good, that they look identical to sprites form cardinal angles (intentionally), so at proper distance (I don't know, perhaps 512 units) even on high resolutions, you would be almost unable to tell that they suddenly became sprites - that would be such awesome feature to have and would ease load on many weaker machines I bet. even with sprites, slaughtermaps will crawl. otherwise, there should be no problem maintaining 50-100 monsters visible, i believe, and this is usually way more than needed. ;-)
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 26, 2022 7:32:03 GMT -5
First post here.. Hey all!
|
|
|
Post by ketmar on Oct 26, 2022 10:54:37 GMT -5
Mr.Rocket, yay, hi! also, while i am here, i want to add some final words on networking: the HUGE reason why i'm not really motivated to work on it is DECORATE. to create a proper MP, i need to have a good client-side prediction, and for that, i need a set of simulated states. i.e. the separate state machine that does some client-side-only logic. trying to emulate it by using the "normal" logic and dummied out actions is a huge PITA, and not even always possible. this is a lot of work (really A LOT) to workaround something that could be easily solved by introducing several new states. but of course, even if i'll introduce such states (and the corresponding actions; and i partially did it already), the existing mods will not magically fix themselves. so there is no way to avoid coding that complicated mess. it is boring, it is tedious, and it will never work as good as i want it to be. when i realised that, i lost all motivation, and mostly stopped working on network code.
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 26, 2022 22:00:52 GMT -5
woah.. let me take a deep breath here and try not to get discouraged heh. Network stuff?: Wondering if it's best to test without any 3rd party scripts, decorate etc. first? no effects no nothing, not even -bdw, as well as disabling all shadows, everything, ~ even though I hate to say it (maybe even disable 3dfloors?) just base game in the network stream, making it solid... Then see about adding small addons afterwards? like dumping a model in.? I guess what I'm saying is, any way to make it clear where problems may arise first. ~ sorry i haven't overviewed the current state of things.. i just jumped in here.
|
|
|
Post by ketmar on Oct 26, 2022 22:58:07 GMT -5
sadly, it doesn't work this way, it's "all or nothing" case. you can't add "half of the playsim", it won't work. but even if it would… i already know where the problem is. and it is insolvable. that is, the only "solution" is to throw away all Doom playsim, and writing everything from the scratch, in completely incompatible way.
there is no such thing as "base game", the Doom game itself is just a built-in DECORATE mod, actually. ;-) it doesn't matter how much DECORATE is there on top of it.
what we really need is two versions for each actor in the game: one is running on the server, and one is simulated on the client. each version should run different code.
also, monsters in Doom aren't really "moving" at all, the AI simply teleports them to their destinations. this doesn't play good with simulation, so the whole AI should be rewritten to use physics to move monsters instead (i.e. only set direction and velocity, not teleporting things around).
and doing even one of those things will break any mod out there. so look at this from my PoV: i will loose the ability to run mods to get a good-working game mode i'm not really even interested in… not a good deal, i'd say. ;-)
guys at Zandro spent years trying to make it work, and they still don't have anything good at their hands. i mean, Zandro is "better than others", but it is still very far from being what i consider "good". it's not their fault, tho, they pulled almost every trick they could to make it work, but idTech1 is the worst enemy here.
k8v core tech can do it right, but the playsim as it is can't. maybe one day i'll invent some magic trick to make it work, but for now i simply don't know how to do it.
sure, i can throw away most of the game, and strip everything to the barebones deathmatch (only player pawns and basic weapons), but there are a lot of much better DM MP games out there already (and i'm not interested in playing deathmatches, i want Doom SP/Coop! ;-).
sorry for being so pessimistic about it, but alas… i see little reason to invest time and efforts into the MP part with the current playsim. i may eventually fix some (hard to catch) bugs i know about in network code, but that's all. at least until i got that "aha moment".
|
|
40oz
diRTbAg
Posts: 5,534
|
Post by 40oz on Oct 27, 2022 12:54:06 GMT -5
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 28, 2022 18:38:49 GMT -5
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 28, 2022 19:28:39 GMT -5
ketmar, yeah it seems that the net code with most apps of any kind is always the hardest, not that I'm a real software dev like yourself but from what I've noticed over the years, it seems it's always the main issue. I'll never know how Carnevil achieved it back when Skulltag was introduced with client prediction, if it was the first or rather csdoom? either way it's pretty amazing how you guys can pull it off. ~ was it Huffman or based on Quake inheritances, just guessing cause I wouldn't know. Would be cool if there were some network code plug-in, or dll, where one could simply drop it in the working directory and it would just work heh.
|
|
|
Post by ketmar on Oct 28, 2022 19:47:17 GMT -5
I'll never know how Carnevil achieved it back when Skulltag was introduced with client prediction, if it was the first or rather csdoom? it can be done (k8v has some unfinished code for client-side prediction for player pawns; i didn't finished it, but it is definitely doable). the problem is that it cannot be done consistently — it will always be a pile of hacks. this is because player pawns and projectiles are physics-driven. k8v, for example, can "detach" a projectile — i.e. tell the client: "simulate the projectile on your own, just don't perform any actions", and the server sends only the final collision info, leaving physics simulation to the client. but this works only for simpliest projectiles without any logic in them; even a Revenant seeker is already off-limits for such simulations. Would be cool if there were some network code plug-in, or dll, where one could simply drop it in the working directory and it would just work heh. if only it could be that easy… ;-) it is actually possible to write a new deathmatch-only game using VavoomC and Doom assets (ok, almost possible, you need to finish some C++ parts for that). only it won't be Doom anymore, and won't support any mods, even the simpliest ones.
|
|
|
Post by 3t0 on Oct 29, 2022 17:53:52 GMT -5
you can do non-blocking with TCP too, but in k8v it's UDP, yeah. the network layer is responsible for assembling "real" packets from UDP parts. it's actually more complicated than that (it has several independent channels and such), though. basically, you can take a look at ENet, its design is very similar. As this is area of my (somewhat) limited expertise, I wanted to know, but I don't remember UDP details anymore: but then for TCP you need non blocking IO on TCP socket set (ie set fd to unblock and check for EWOULDBLOCK/EAGAIN) right? As I said, it is some time I was messing with this, I was just curious how do you prevent k8v process from locking up in mainloop waiting for network IO. But yeah ENet is incredible (I know it form my cube/sauer/tesseract spelunking), Lee and others did amazing job. And it actually exposes fds for integration into the poll() core. More astonishing is janis probably envisioned something similar just for vavoom this guy is mad chad. there's nothing i cannot do better and faster, and with less code. ;-) the problem with field ordering and such is not in the protocol, but in the amount of data to transfer. k8v network protocol doesn't even operate on bytes — it is often using less than a byte for some small values, trying to pack as much data as it can into one UDP frame. adding field tags will blow up the packets. This is some serious packing power - I am getting more and more surprised by k8v the more I know about it. I was similarly surprised when I found chacha20 tables, presumably for RNG, or when I thought fixed point is still used for map structs - which it is not: float wink wink. Also I was always too lazy to loiter in gzdoom . i did that for savegames, though — the size is not a concern there, and that's why you very rarely have unreadable older saves in k8v, despite massive internal changes. the engine may complain about some missing fields in save, but it will use default values for them, and most of the time it works (because i'm trying to choose reasonable defaults ;-). Ah fuck me sideways, so k8v is that one and only fucking idtech descendand that does not blow up with savegames? Because you know all my gzds saves are fucked. Quakespasm, I think, is the same way and it enrages me incredibly. they basically did what Vavoom is doing, just with a different code. but the idea is the same. that's why i know i can beat Zandro in MP (because Vavoom has much better foundation for it), i just don't want to spend my time on that now. ... actually, no. clients aren't doing playsim at all, everything orchestrated by the server. client only needs current actor state, position and direction to render it, that's all. just a dumb terminal. Lower below more about that... a little bit of VavoomC magic. remember, you can do everything with VavoomC, because it is the language that is used to write the whole playsim (including monster AI, of course). so you can create compound objects, change their sizes, and do other things impossible with DECORATE. Yeah it's on my todo list, I just don't have time for it right now. Most attractive feature to me still is UFCS and I havent had time to try it in D even. actually, we already have that in the engine — that's what "headshots" are. ;-) it's not hard to find where hitscan hits AABB. k8v headshots aren't fake — the engine actually calculates the proper hitpoint, and checks if it hits the area assigned for "head". you also have a much better chance to land a critical headshot if you're shooting closer to the vertical center of the object. I noticed all that (vertical distance) and I "knew" thanks to VC this won't be some Brutal Doom level hack - I guess this means it would "auto work" with voxels, right? Also, what about tracking animated hand, I then need to have some sub-AABB for hand tracked for each state sprite? Let's say if one would like to do Burtal Doom/Chasm-like shootable limbs in k8v. I guess it must be VC coded then too, or? at least not how it was done in ZDoom. of course, you can do that (with VavoomC), because that's how chicken morph is done. it's just not done the way ZDoom did it. Phew good to know we can still have vehicles eventually . lol. thank you! i'm as strong as ever, though, but i cannot say the same about the city infrastructure. ;-) I assume you live on periphery so hopefully less chance of damage by rockets? you can do that, but it's not pleasant job at all. model frames can be assigned to states by their numbers, so they don't have to replace any sprite lump. and you can specify "intertick time" for model frames. so it is possible to assign several model frames to one state, with different "intertick timing", and interpolator will do the rest. barrel model, for example, does that for better liquid animation. actually, original Vavoom had no way to attach model frames to sprite names, and i had to add that feature to support MODELDEF from GZDoom (because this is the only way to assign create model animation there). Oooh this is nifty - pretty rad - only thing needed would be skeleton . …and that's why. ;-) you need a whole new animation framework to support that, and actor code should know about it. basically, it means ditching DECORATE (as it is totally unfit), and creating the new, incompatible way to write mods. a lot of work for zero chances to get any traction. old mods won't magically work with the new system, so i'll have to write and maintain two separate subsystems for something hardly anybody will use. Yep I know your thinking by now... however for indie dev hmmmmmmmm . nope, everything in seconds internally. that's why Boom conveyors never worked right, for example — they're closely tied to 35 FPS, and to the physics based on 35 FPS lockstep. for some reason Boom authors choose to make conveyors completely physics-based: converyor belt simply changes the object velocity. it's a smart thing, but it heavily depends, for example, on friction values changing at a fixed rate. in k8v the impulse sometimes is too small to overcome the friction, and other times too big for friction to compensate it properly. and conveyors expect the exact values, because they're simply adding more velocity on each step, knowing that friction will reduce it by the fixed amount… which is absolutely not the case with Vavoom. so it works for some simple setups, but completely breaks for others. So you are telling me, that k8v actually holds 1 tick state for "exactly" 0.0285 sec as is, no integer tick shenanigans? It actually watches frame delta and tries to line them, state changes, up so that they happen on intervals of 0.0285 for map actors? there are no problems implementing model loading and rendering: internally, k8v model code is WAY more powerful than of any other idTech1 offspring. it already supports submodels, relative submodel placement (attachment, if you prefer), separate submodel animation, matrix-based animation interpolation, and many other buzzwords. ;-) it basically already has all the required pieces. Yet it cannot do bones right? Thought other items in that list are really neat, that is some serious capability right there. yeah. it's kind of "nice to have" thing that could be done when somebody have infinite time and resources at their disposal. ;-) I know, and then nobody would make use of it because modders are "stupid" - sorry real modders no offense meant. there is little reason to stick to the original idTech1 for a completely new game. i mean, it's ok to keep UDMF, for example, and some lower-level data formats, but there is no reason to stick to broken idTech1 physics, to its limited state machine, and so on. we can keep the rendering, but it would be way better to rewrite physics and playsim from the scratch. ... sure, i'm always open to hiring proposals. ;-) but i definitely won't do it for free. yet nobody approached me so far to hire me to create a custom 2.5D engine for their New K00l Retro Shooter (or RPG, or something else). ;-) Wow, now I was not aware this was the possibility, now I only need to win a lottery to pay for my feature wishlist to be backported into the k8v XD! Why another engine when I could have done as submodule of this project . Not enough money a the moment though . there is really a little reason to do that. of course, something like ancient Intel GPU emulator may struggle with 3d models, but even 10 y.o. GPU will spend almost none resources rasterizing someting as big as several pixels by several pixels. ;-) all models are uploaded to GPU, so i render them simply by telling the GPU that i want model number X at position Y, regardless of model complexity. and GPUs are smart enough to throw away most of the invisible pixels on their own. ;-) sure, it's easily doable (just one more check), but i'm not convinced that it worth the efforts yet. ;-) I myself have not observed any perf. issues with GZ (ofc besides regular GZ issues I gave up on). Man somebody really needs to do Cheelo's mod conversion. Any volunteers? even with sprites, slaughtermaps will crawl. otherwise, there should be no problem maintaining 50-100 monsters visible, i believe, and this is usually way more than needed. ;-) Sounds good to me. First post here.. Hey all! Yo long time no see! Network stuff?: Wondering if it's best to test without any 3rd party scripts, decorate etc. first? no effects no nothing, not even -bdw, as well as disabling all shadows, everything, ~ even though I hate to say it (maybe even disable 3dfloors?) just base game in the network stream, making it solid... Then see about adding small addons afterwards? like dumping a model in.? I guess what I'm saying is, any way to make it clear where problems may arise first. Well the problem is partly this: in all modern doom source ports, all supported classic games are mods of themselves, I guess you get what I mean. Ie doom game is doom mod using doom assets, hexen is hexen mod using hexen assets. Thus each sourceport plays slightly differently. That is reason for existence of ports like choco and others. These dont' have advanced mechanics modified too much, so they play closest to the holy grail of original Doom. there is no such thing as "base game", the Doom game itself is just a built-in DECORATE mod, actually. ;-) it doesn't matter how much DECORATE is there on top of it. And this means that subset of decorate used must be working over network - at least everything needed for implementing DOOM needs to work. Which probably is most of the decorate stack . what we really need is two versions for each actor in the game: one is running on the server, and one is simulated on the client. each version should run different code. This is actually how original counter-stike and I think half-life deathmatch does it. Even CSS. That's why sven-coop is such a golden nugget. Last time checked SP half-life sdk, it didn't bother with clientside prediction (ofc why would you?) at all. Thus sven-coop guys probably went and reimplemented all the half-life monsters (probably on to op half-life death match base (which concentrated only on death match player prediction)) for MP. Crazy task if you think about it. At least if they have client side monster prediction. But... guys at Zandro spent years trying to make it work, and they still don't have anything good at their hands. i mean, Zandro is "better than others", but it is still very far from being what i consider "good". it's not their fault, tho, they pulled almost every trick they could to make it work, but idTech1 is the worst enemy here. ... sure, i can throw away most of the game, and strip everything to the barebones deathmatch (only player pawns and basic weapons), but there are a lot of much better DM MP games out there already (and i'm not interested in playing deathmatches, i want Doom SP/Coop! ;-). ... sorry for being so pessimistic about it, but alas… i see little reason to invest time and efforts into the MP part with the current playsim. i may eventually fix some (hard to catch) bugs i know about in network code, but that's all. at least until i got that "aha moment". ... it can be done (k8v has some unfinished code for client-side prediction for player pawns; i didn't finished it, but it is definitely doable). the problem is that it cannot be done consistently — it will always be a pile of hacks. this is because player pawns and projectiles are physics-driven. k8v, for example, can "detach" a projectile — i.e. tell the client: "simulate the projectile on your own, just don't perform any actions", and the server sends only the final collision info, leaving physics simulation to the client. but this works only for simpliest projectiles without any logic in them; even a Revenant seeker is already off-limits for such simulations. Yes but why not give up the idea for client-side predictions of monsters entirely - you above said that client already is a dumb terminal. Why not just predict players and simple projectiles like you already can like Counter Strike family of mods/games does and use "hard" "frame step" updates from server, for everything else - even if it stutters. Then each mapobj/actor just needs to be a single "frozen frame" impersonated on the client, single state and position, and perhaps hitscan lines (for client puffs), everything else is sent only one way form server to client and you only update the frozen frames when new data is recieved. Each server frame sent is full overwrite anyway. This way only few thigs would be "fps fuild": players, hitscans and simple projectiles as you said. Woudl it be a such a big problem to have jumpily strolling imps, cacos and revenants seekers? At least in localnets (where packet delivery takes sub-ms times) this should not be such a big issue or am I missing something? Would that be too hacky? Or is that what is being done already?
|
|
|
Post by ketmar on Oct 29, 2022 22:59:32 GMT -5
but then for TCP you need non blocking IO on TCP socket set (ie set fd to unblock and check for EWOULDBLOCK/EAGAIN) right? yes, this is the easiest way. there are others, though (for example, doing `select()` to check if there is something in the socket, and then use os-dependent call to check how much data is buffered, and therefore safe to read). non-blocking mode has its own bag of gotchas (especially with poll/epoll/etc.). so it mostly depends of how your code was architected. But yeah ENet is incredible (I know it form my cube/sauer/tesseract spelunking), Lee and others did amazing job. And it actually exposes fds for integration into the poll() core. More astonishing is janis probably envisioned something similar just for vavoom this guy is mad chad. Janis is The Great Man, but here we should be honest here: it's just Unreal. earlier Vavoom used QW-like netchan, but then Janis replaced it with what Unreal is using. i mean, it is literally Unreal network architecture, clean-room reimplementation. you prolly may even trace some class names back to UDK (only with `V` prefix instead of `U`). Epic described their tech good enoigh to pull such trick. ;-) that's why, btw, i'm often saying that Vavoom is more Unreal than Quake: the engine definitely started as a hybrid of Doom and Quake, but Janis kept pushing it into Unreal territory. i thing Vavoom (and k8v) are actually Doom/Quake/Unreal hybrids now. ;-) I was similarly surprised when I found chacha20 tables, presumably for RNG corelib is used in several other my projects, so it contains more code than is used in k8v. as for ChaCha, it is actually used, but not for PRNG (i'm using Bob Jenkins' one, and PCG). ChaCha is used to encrypt UDP packets. it is just to prevent various 3rd parties from tampering with the data mid-way, not a Real Security (initial key exchange is done in plain text anyway). Ah fuck me sideways, so k8v is that one and only fucking idtech descendand that does not blow up with savegames? Because you know all my gzds saves are fucked. Quakespasm, I think, is the same way and it enrages me incredibly. i believe that current GZDoom is doing something like this too (it saves games as JSON files). but it was a huge ZDoom/GZDoom problem several years ago, yeah. and the original Vavoom was just as bad. i had to rewrite that part, so i can both develop the engine, and keep playing wads without loosing my saves. ;-) sometimes i'm breaking saves even in k8v, though, but it's quite rare (less than 5 times since i introduced the new savegame format several years ago, i believe). and the new code is already full of hacks to load older saves, because i'm not such smart as i used to think about myself, and didn't designed the format to be extensible enough. ;-) but i'm trying hard to keep everything working, yeah. there were several changes in base class names and layout, for example; heavily improved physics with new important fields, etc. but nobody noticed, because i added that translation code to the loader. because i HAET when upgrading the engine means "ok, you just lost all your progress, suck it, loser!" ;-) I noticed all that (vertical distance) and I "knew" thanks to VC this won't be some Brutal Doom level hack - I guess this means it would "auto work" with voxels, right? yeah, it automagically works with any monster from any mod. of course, it has to guess where the "head" is (just a simple math, taking into account monster height and some other heuristics), yet it works Good Enough in majority of cases. also, headshot system knows about primary and secondary hitscans (i.e. for SSG, which fires many hitscans at once, second and other hitscan attacks will have a very low chance to deliver a headshot; it also works for weapon mods — heuristics again ;-); it can also handle "hitscan projectiles", and even normal projectiles (but this is currently not used). Also, what about tracking animated hand, I then need to have some sub-AABB for hand tracked for each state sprite? Let's say if one would like to do Burtal Doom/Chasm-like shootable limbs in k8v. I guess it must be VC coded then too, or? it depends of the way you're creating your objects. but yeah, headshot calculation method is overrideable, so your mod can layer any required checks on top of the standard system. it means, for example, that Chasm the Rift can be properly recreated in k8vavoom. Chasm used one hitbox per monster, and calculated the damage and dismembering according to hitbox hitpoints. and k8v already has all low-level machinery for that. of course, it is possible with ZScript too, but with k8v it is slightly easier. ;-) I assume you live on periphery so hopefully less chance of damage by rockets? oh, no, i'm living almost in the center of the city. ;-) So you are telling me, that k8v actually holds 1 tick state for "exactly" 0.0285 sec as is, no integer tick shenanigans? It actually watches frame delta and tries to line them, state changes, up so that they happen on intervals of 0.0285 for map actors? yes, exactly that. all state times are converted to seconds, and the only reason the state duration cannot be smaller that 1/35 of second (or not exact multiply of 1/35) is because DECORATE cannot specify it. ;-) there was a fun bug with that: if the state "leftover time" was lesser than the current frame delta, extra unspent time wasn't subtracted from the next state duration. it took me quite a while to find out why the game at 40FPS is actually slower than at 60FPS (due to bigger "forgotten extra time"). also, as k8v now has "hitscans as projectiles" mode, it is actually possible to implement proper bullet time too. ;-) Yet it cannot do bones right? Thought other items in that list are really neat, that is some serious capability right there. technically, it almost can. bones are just "attached submodels", and k8v supports that. i mean, submodel is rotating/moving with the parent model, and has its own transformation matrix too, applied on top of that. all building parts for skeletal animations are there, fully implemented and working. I know, and then nobody would make use of it because modders are "stupid" - sorry real modders no offense meant. from modders PoV, it would be stupid to stick to one obscure engine, with very small userbase. ;-) so i'm not blamind modders here. this is a kind of "chicken-and-egg" problem. i'd certainly like to have more resources (not only money, all kinds of them) to simply add a lot of features to k8v, and wait for people to come, but… but working on something nobody will use is a luxury i mostly cannot afford yet. still, i'm always open to modders' requests. Remilia, for example, asked for ACS API to check dynamic lighting at the given point, and i implemented it (which means that it is now more-or-less possible to implement stealth in k8v, lol). Wow, now I was not aware this was the possibility, now I only need to win a lottery to pay for my feature wishlist to be backported into the k8v XD! sure, why not? ;-) one can either take k8v code and do it on their own (viva GPL!), or hire me to do it for them. i mean, it's not about money per se, i may do it for free if i'm really excited by the idea, but if one want me to do something i myself don't need… well, i expect at least some kind of compensation for my time. ;-) if only i had unlimited time, i won't be asking for anything, but alas… Man somebody really needs to do Cheelo's mod conversion. Any volunteers? i don't believe that somebody except me can do it in reasonable time. it's not that hard, just tedious, and there is not enough documentation (alas). And this means that subset of decorate used must be working over network - at least everything needed for implementing DOOM needs to work. Which probably is most of the decorate stack . 100% of it. ;-) Yes but why not give up the idea for client-side predictions of monsters entirely mostly because it's not only about movement; animation (state transition) is heavily depends of game logic too. when i'm writing about "client-side prediction", i mean everything — movement, animation, sound, etc. Why not just predict players and simple projectiles like you already can like Counter Strike family of mods/games does and use "hard" "frame step" updates from server, for everything else - even if it stutters. … This way only few thigs would be "fps fuild": players, hitscans and simple projectiles as you said. … Would that be too hacky? Or is that what is being done already? that's mostly what the engine does right now (except that player pawn prediction code is not working properly yet ;-). and i absolutely HAET how it looks and feels. remember that i want Coop games to work smoothly in the first place, otherwise there is no reason (for me) to bother. ;-) also, weapon firing still sux: as there is no proper client-side simulation of weapons, firing is heavily lagged. i.e. you won't see weapon firing animation until the server responds with "ok, it's now figing". as switching to firing state is controlled by weapon action code, we need separate code to properly predict it on the client, because the client should know what kind of ammo the weapon is using, does the weapon need some other inventory items to work, how it expends the ammo and items, and so on (and keep the local copy of all that info). it can be guessed for simple cases, but mods with complex weapon system are hard to handle this way. people are doing all kinds of weird things with weapon mods, and the DECORATE-specified ammo can be not the one the weapon is using, there can be some weird logic, and so on. i've seen it not only once or twice. ;-) in the end of the day, it sux, and Zandro currently does much better job at it.
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 30, 2022 8:28:24 GMT -5
Yoooo! Well the problem is partly this: in all modern doom source ports, all supported classic games are mods of themselves, I guess you get what I mean. Ie doom game is doom mod using doom assets, hexen is hexen mod using hexen assets. Thus each sourceport plays slightly differently. That is reason for existence of ports like choco and others. These dont' have advanced mechanics modified too much, so they play closest to the holy grail of original Doom. Yeah I totally get how the games and its resources work ect. I just have trouble wrapping my head around the network play mechanics side of things internally. But from my understanding the server must know how to handle all the decorate resources even in an errors case and then re-interrupt what it had to do to fix things and send it back to the client without something breaking on the fly?
|
|
|
Post by ketmar on Oct 30, 2022 9:04:28 GMT -5
But from my understanding the server must know how to handle all the decorate resources even in an errors case and then re-interrupt what it had to do to fix things and send it back to the client without something breaking on the fly? the server IS the place where the game works. clients simply send user input to the server, and process server reply; that reply basically is: "show this sprite at that coords". nothing at the client side can directly influence the playsim at the server (except user input, of course). i.e. clients are just "remote keyboards/mices". that's basically how any client/server game works. now, the problem with this approach is the latency: as client only renders sprites at the given coords, and does NO playsim at all, it only can update the view when the new data from the server arrives. and that latency can be quite big for internet games (100-300-500 msecs). to make it somewhat bearable, client tries to "predict" what the server will do. the server is still the authority, the client only tries to guess what will happen (because the client doesn't have the full world state). i.e. the client mostly have only coordinates of visible objects, but not other info, and cannot do playsim on its own. so it have to guess. why don't keep the copy of the game on each client? because syncing the state of the whole game world will require a lot of bandwidth. it will also make the life easier for cheaters, but this is usually the secondary concern.
|
|
|
Post by 3t0 on Oct 30, 2022 15:44:40 GMT -5
But from my understanding... As ketmar said, it is atrocious. This is how original Quake worked, I still remember it: everything was server validated (even viewangles). Now think Mr.Rocket, even when you are on a pretty good connection, let's say 20 msec ping distance, and you press "shoot", it's 20msec to notify the server. Server then calcs the shooting result and it's again 20 msecs to notify client back (if everything is fine and dandy), so now you can draw shot puffs/blood on a client. So at minimum, at 20 msec ping, you have 40msecs to register a shot - and anything above 15 msec is easily perceivable by humans, especially instant actions like hitscan shooting or view rotation is especially latency sensitive. In old netquake, I remeber turning my view with mlook to the left, only for it to suddenly jump somewhere in between where it should be, and where it was 40 msecs before (hello: packet arrival from server ressetting it to "correct" value) - this fucks up your head almost immediately. If I remember correctly this was first issue "fixed". So I still remember view jitter in original Quake (at first server did not allow client to even look elsewhere than it wanted to have it looking and even view rotation was validated). If you were on real inet back then, you usually got 500msec pings on POTS "delayup" line (like from europe to murrica) easily. That means a whole second between you pressing "shoot" on a mouse and your shot actually registering and being drawn and realized in-game. So later Carmack introduced QuakeWorld and "client-side prediction". It was separate client executable, from normal game, and it was originally intended for deathmatch only. In QW your client can move in a map freely, and can look around freely (thank god) and shots are rendered using local data immediately. However your position and orientation and shoot presses are sent to the server as usual. Of course when proper server frame arrives back, you movement (but not view angles) is immediately reset to "correct" position (if you somehow wandered to far where you should be). This allow you to feel your 500 fps screen refresh, and to server to see what it needs to see. On your client, the other players remain in movement, depending on the last state recieved from server, ie if somebody was moving diagonally at a speed 200units/s they are moving that way on your client as if they were local player. If they collide during such movement with something, your client will do the normal collision calculation, itself, as if it was local player colliding. This technique is called client side prediction. Client basically "hallucinates" current gamestate based on last data it recived treating them as if everything was local. Naturally, client has no clue whether what it's imagining is true or false. But as long as it has some data, it can use it to simulate movements and "dream" forward how a game state could look like. Of course, eventually, like 40 msecs later into the future, actual server packet(s) finally arrive, and now client has real positions of everything (of course reflecting real situation on server 20 msecs in the past). If any locally simulated avatar of other player or other entity wandered too far from their actual position, they are immediately "teleported" to a new proper location, specified in server packet and their movement vectors and angular velocties are corrected to actual server state. On bad connections - you sometimes can see other players "snap back in time" into positions when this is done. So this is not perfect, however... It turns out this is most bearable way for player to actually feel playing (even if there is a lag to the server). As client rotation angle and rate is not limited by server, client rotates view immediately and draws hitscan shots immediately, so you feel like game reactions to your inputs are instantaneous - but this is in practice just a deception - of course. Server will actually see and validate your shots only much much later, in completely different environment as you were in when you fired. Of course it will take angles and everything into account, but by that time, yout and other players positions are already slightly off on the server too. Damage will be registered only if server registers it - that is why it is sometimes possibile to "miss" hitting the other player in netgames, even if you, in fact, hit them in your client's "dream" (and on your clients screen). Because server and client share movement code, with short enough lag, the prediction, will often predict proper avatar positions so close (to the state on the server), that correctional entity teleport executed on your client when new packet arrives, will be almost unnoticeable. It was discovered by carmack that for ping in range from 5mscec to 500msecs this works reasonably well to fool the players and allow for good deathmatch play. Now where is the problem with Doom here, can't we do the same? The problem is that in Quake everything is done following this design form the get go. Entities know that they cannot peek into server memory structures (because it might be half a world away), and only thing they can work with on a client is either last valid state from server or new state predicted by client from it. Nothing less and nothing else. But when Doom came into being, all these tricks and designs were not yet understood, and that is what ketmar is bickering about. So in Doom monsters are not separated into server part and client part, they think of themseleves as being always local and they tap directly into data structures of other monsters willy nilly, any time they want, during game simulation. But during netplay, these changes happening in other monsters, they can be happening half a world away, and it is simply impossible to tap into that for current monster then, and there is simply no such data (of the other monster) present on a client. So I proposed that besides players avatars, letting everything else as is: left frozen in last state received from server, and move it all only when new server data arrives, ketmar immediately points out that even then, weapons break almost immediately that way, because they rely on this "state sharing". So then the only other way (until somebody invents something else) is to simulate full game locally completely as if single player, and occasionally resync "local server state" with "remote server state", which seems what skulltag and zandronum are doing - and which is as a technique quite doable - but insanely tedious and very error prone.
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 30, 2022 17:09:43 GMT -5
Alright, thanks guys for the long explanation. I have a better understanding now on the roadblocks you're having to deal with when it comes to the Doom engine in general, or at least that tech, and of course not wanting to re-invent the wheel. Btw, I actually still have QW Client on one of my other drives.. an older version of Doom Connector actually supported it too heh. ~ though I don't recall if I worked on the game dll for it or not. ~ ah, no, I made one for Darkplaces.. ~ man I remember back in the day checking Bluesnews to see if "id" put out any new famous point releases etc.
|
|
|
Post by 3t0 on Oct 30, 2022 18:03:11 GMT -5
you're having to deal with when it comes to the Doom Nah I am just amateur software archeologist. ketmar , janis and others are the sorcerers here. I actually still have QW Client on one of my other drives If I am not mistaken most modern Quake sourceports like Quakespasm support both QuakeWorld and NetQuake protos in same executables.
|
|
Mr.Rocket
Doomer
Say hello to my BOOMSTICK!
Posts: 15
|
Post by Mr.Rocket on Oct 30, 2022 18:45:40 GMT -5
Nice, I've heard of Quakespasm but never got around to down grabbin it. I'll have to check it out and get into some Quake DM for old time sake. Back on topic, k8vavoom! I need to update that little launcher I made for it awhile back. I remember I still need to wrap quotes around everything so the file paths can make it past 5 deep. That and I only set it up to play local network games, but from the sound of it, it's probably better that way with the current state of things.
|
|
|
Post by ketmar on Nov 4, 2022 3:30:59 GMT -5
as nobody took the adventure of doing it… quick-and-dirty test:
|
|
|
Post by 3t0 on Nov 4, 2022 4:43:42 GMT -5
Amazing ketmar! I was so much waiting for this. Interesting we seem to think similar enough. So you actually looked into it a same timeframe . I am glad I did not spent enough time on this, since you probably knows bestest . I started several times, last time before yesterday, but gave up due to not getting enough time and getting lost in vavoom docs. And was too lazy to find where I put vavoom's md2 pack. Anyway while we have your attention on this, may you please explain following part of the docs; do I understand right it then as following decorate collapses into next snippet...: Spawn: ETTN A 10 A_Look Loop See: ETTN ABCD 5 A_Chase Loop Pain: ETTN A 7 A_Pain Goto See Melee: ETTN EF 6 A_FaceTarget ETTN G 8 A_CustomMeleeAttack(random(1, 8) * 2) Goto See Death: ETTN IJ 4 ETTN K 4 A_Scream ETTN L 4 A_NoBlocking ETTN M 4 A_QueueCorpse ETTN NOP 4 ETTN Q -1 Stop ----8<-------------->8------------------ Spawn: state 0 See: state 1 state 2 state 3 state 4 Pain: state 5 Melee: state 6 state 7 state 8 Death: state 9 state 10 state 11 state 12 state 13 state 14 state 15 state 16 state 17
Each of the small "state integer" above is the 'index=' attribute number in model binding's '<state>'element: <class name="KRPGMana1"> <state index="XX" model="bluemana" frame_index="0" angle_start="0.0" angle_end="360.0" /> </class>
Do I got that right? Whats confusing me is algorithm with which I get from textual decorate into the raw "state numbers": - each sprite name + each rotation letter is one "state number"?
|
|