|
Notes |
|
|
(0002661)
|
|
TIHan
|
2012-02-21 03:03
(edited on: 2012-02-22 01:05) |
|
|
|
|
|
|
This won't significantly increase CPU load or bandwidth usage, will it? |
|
|
|
(0002674)
|
|
TIHan
|
2012-02-22 21:28
(edited on: 2012-02-23 01:23) |
|
Bandwidth usage, none. Everything done here is entirely server-side. There may be some increased memory. Memory usage will increase for each actor by roughly 436 bytes in theory according to the added properties of the AActor class. So, a good worst case scenario of 20000 actors in game, memory usage will increase roughly 8mb :). (As for CPU, it should have no issues dealing with it, completely unnoticeable.) <- I was ignorant here.
Please correct me if I'm totally missing a concept that I don't know.
|
|
|
|
|
> Please correct me if I'm totally missing a concept that I don't know.
If there is something to worry about I'd say it's TThinkerIterator<AActor>. I don't know how well this iterator scales for large amounts of monsters /actors. Try a wad with several thousands of monsters and you should get an impression. |
|
|
|
(0002677)
|
|
TIHan
|
|
2012-02-23 01:21
|
|
I tested Sunder.wad map08 with about 2600 monsters. CPU with unlagged on, disconnected me from the game as it was using my entire CPU core. This was using the super shotgun with sv_fastweapons set to 2.
Yea this is a big issue. Not exactly sure what I would do. Spleen mentioned back in the day we needed to use some sort of binary tree. |
|
|
|
(0002678)
|
|
TIHan
|
|
2012-02-23 03:11
|
|
|
I attempted to use std::set and stored each unlagged actor in it when they spawned. I still get the same issue :(. |
|
|
|
(0002679)
|
|
TIHan
|
2012-02-23 04:09
(edited on: 2012-02-23 05:10) |
|
Ok! I fixed the CPU issues. See changeset'https://bitbucket.org/TIHan/tst/changeset/d5a6cd023be2 [^]'
To explain, every single call to P_AimLineAttack and P_LineAttack caused the whole cycle of unlagged to take place. The TThinkerIterator was just getting slammed in such a short amount of time. So if I fired my super shotgun that had 25 puffs of spread - UNLAGGED_Reconcile is going to try to run 25 times in a tic causing all that CPU load.
-- To fix this problem, use UNLAGGED_Reconcile before all the P_LineAttacks get called on a weapon (essentially making UNLAGGED_Reconcile only fire once), then do UNLAGGED_Restore, viola! The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others. But, in this case, performance takes precedence over maintenance.
In sunder map08 analysis (with fastweapons 2 - super shotgun):
-Without unlagged, cpu usage was around 7%-9%.
-With unlagged, cpu usage maxed out at 25% (100% for one core, which halted everything).
-With unlagged optimizations, cpu usage stayed at 11%. =D
|
|
|
|
|
> The only downside to this is that I will have to do this manually for pretty much all the heretic/hexen/strife weapons, and maybe others.
This kind of approach can only be a last ditch effort. Before you do this, we should make sure that there really is no other way to do this and decide whether the maintenance nightmare is really worth the benefit. |
|
|
|
(0002681)
|
|
TIHan
|
|
2012-02-23 17:40
|
|
|
I'll look into an alternative way. It will have the meet this single criteria: UNLAGGED_Reconcile and UNLAGGED_Restore can only be ran once in a tic. |
|
|
|
|
|
One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using. |
|
|
|
(0002683)
|
|
TIHan
|
2012-02-24 03:21
(edited on: 2012-02-25 08:32) |
|
> One thing one could investigate is whether it's feasible to handle the unlagged stuff in server_ClientMove before / after thinking and or ticking the player, independently of which weapon the player is using.
I'm not sure what you mean here. Can you explain this some more? I don't feel warm and fuzzy by trying to leave the weapon attacks. The best practice for lag compensation seems to center on weapon firing.'https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' which is very similar to what we are doing now.
I don't think modifying all the weapon attack functions is a maintenance nightmare, but it could be better if we had precise events of weapon firing before and after.
|
|
|
|
(0002685)
|
|
Torr Samaho
|
2012-02-26 00:41
(edited on: 2012-02-26 00:42) |
|
> The best practice for lag compensation seems to center on weapon'firing.https://developer.valvesoftware.com/wiki/Lag_compensation#Invocation [^]' [^] which is very similar to what we are doing now.
Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite.
In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added.
|
|
|
|
(0002691)
|
|
TIHan
|
|
2012-02-26 20:29
|
|
> Under this premise you may want to go where the action functions of the weapons are called, i.e. "if (state->CallAction(player->mo, player->ReadyWeapon)" in P_SetPsprite.
This works! :D Thank you. I'll have to iterate through a list so the ActionFunction gets checked against all possible ActionFunctions. |
|
|
|
(0002704)
|
|
TIHan
|
|
2012-02-27 01:44
|
|
|
|
|
(0002822)
|
|
TIHan
|
|
2012-03-17 20:37
|
|
I've updated the unlagged_monsters_new branch to the latest codebase.
Is there anything that doesn't make you warm and fuzzy with the changes to unlagged? I've been testing this with someone for the past few weeks, we haven't experienced anything out of the ordinary. |
|
|
|
(0003234)
|
|
TIHan
|
2012-04-13 06:14
(edited on: 2012-04-13 07:16) |
|
'https://bitbucket.org/TIHan/tst/changeset/b366b6912446 [^]'
Managed to decrease a little more CPU usage, not a whole lot, but noticeable.
Edit:
Did probably the most intense test you could do to ST, besides nuts.wad ( that wad will never work online ;) ).
Sunder map11 has 5000+ 'active'/'non-dormant' monsters. To test this, I combined monster lag compensation and monster bandwidth mitigation to see how it all performed.
I never disconnected. This is with fastweapons 2, infiniteammo, and any of the hitscan weapons being fired. While my CPU was maxing itself out, it was able to hold its own and not disconnect me :)
|
|
|
|
|
|
This may be a bit outdated of a post, but I always wondered if you could use the GLPVS (or even the reject table) to determine if the monster can be seen from the sector the actor is in. While going around corners with high ping will cause some possible problems, at least it'd send a whole lot less data in more closed maps. |
|
|
|
|
|
0000757 is a better place to discuss how to reduce bandwidth usage. This ticket is about unlagged support for monsters, 0000757 is about monster bandwidth reduction. |
|
|
|
|
|
Do you know if there's any Tihan links left around? All his are dead and it'd be nice to not have to start this from scratch... though I may not have a choice. |
|
|
|
(0010401)
|
|
TIHan
|
|
2014-10-09 01:04
|
|
Hey Watermelon,
Unfortunately, I do not have the repository anymore. :(
Though, getting this to work wasn't that bad.
The idea was to only compensate between when the player shot, rather than for each bullet. ex: super shotgun |
|
|
|
(0010405)
|
|
ZzZombo
|
2014-10-09 03:20
(edited on: 2014-10-09 03:21) |
|
Quote
In case we need to restrict the unlagged stuff to certain code pointers, you can check there if state->ActionFunc is one of those that need unlagged treatment, e.g. A_FireBullets, and call the unlagged code accordingly. This at least centralizes the changes and just needs the list of code pointers to be updated if new ones are added. Wouldn't the better place to do such things be A_FireBulletsHelper() in thingdef_codeptr.cpp? Since ultimately all weapon firing functions call it there will be no need in a list of codepointers.
There is also A_CustomFireBullets().
|
|
|
|
|
Hi Tihan, I don't know if you're still around -- if you get a free chance and could pop on IRC I'd be glad to talk to you if you remember where you left off ;)
If you're not busy that is. If so, no worries |
|
|
|
|
|
I think I still have a clone of TIHan's repository. Will check and report back. |
|
|
|
|
I actually had two old repositories of TIHan. I created a "salvage yard" repository and shoved all of TIHan's code changes in there. I also added AlexMax's gametic unlagged code, since it seems to be gone from his repository. This is the repo.
|
|
|
|
(0010415)
|
|
TIHan
|
|
2014-10-09 08:56
|
|
Watermelon,
I'm not around at all and haven't been in ages; but I'd thought I would pop in just for a bit here. I doubt I'll have time to help. :(
Torr seems to have found most of the code; that should help.
Best wishes to you guys. |
|
|
|
|
Cool code dumps. Time to read.
It's ok Tihan, good luck with your RL endeavors! |
|
|
|
|
Torr (or anyone):
Is there any reason we unlag once for each bullet? It sounds like an insane waste of CPU time. I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished.
There's no way this ticket can proceed until that is done.
Though first I need to know if there's a reason why it was done this way... any known reasons? |
|
|
|
|
Quote from Watermelon
I thought we'd just unlag before firing, and then undo the unlag after the firing function is finished. If you manage to do this in a centralized manner, please go ahead. The way ZDoom handles the firing, I don't see any feasible way to do this in a centralized manner though. The advantage of the current implementation is that it is properly centralized.
Keep in mind, the actors are only supposed to be unlagged for the purpose of hitscan attacks. For any other game logic aspect, the actors need to be at their true position, not at the unlagged one. |
|
|
|
|
|
|
|
|
|
This looks pretty much like the solution I suggested you to use (and is also what I already proposed two years ago 0000531:0002685, that's just so long ago I forget we actually already had a prototype for this). So it should be a good staring point. Whether it is good enough to be included has still to be thoroughly tested though. |
|
|
|
(0010828)
|
|
TIHan
|
|
2014-11-04 18:21
|
|
Watermelon,
To note on that implementation, there was no reason to use a "set". I would either use a "vector" or a fixed array to iterate through the actors. |
|