Add com_gameHz to play with higher HZ/FPS #297

Stradex · 2020-06-11T07:24:17Z

This basically allows the player to set the amount of HZ/FPS they want the game to run. Making it a bit like BFG Edition in that aspect.

The cvar to use is com_gameHz. by default it is 60 (original), but you can change the values, but after you change the value you actually need to close and open the game again in order to see it working.

BTW this requires a new custom pak that should be put at base folder in order to play it. Because it requires to update the GAME_FPS and GAME_FRAMETIME from the scripts def in order to match the com_gameHz values dinamically.

I can upload the binaries for Windows 32 bits if someone actually wants to test it. (idk if github allows me to drag zips with .dll and .exe files)

pak009.zip

Stradex · 2020-06-11T17:30:04Z

Also, if someone have a mod with custom game logic for dhewm3 and it is worried that after this pull request that mod is not going to work anymore. This is the necessary code I used to update librecoop to make it work with this pull request. (Also keeping compatibility with original dhewm3 usign a preprocessor directive by now)

For base:
Stradex/librecoop@7f87c0b

Forr d3xp:

Stradex/librecoop@0d435a9

DanielGibson · 2020-06-11T17:42:47Z

Thanks for the PR, it will most probably take a while till I merge it because, as you said, it might break existing mods.
What seems especially problematic in that regard is that it needs changes to the scripts - so far I could avoid shipping any game data, all the dhewm3 changes have been done in code. That wouldn't necessarily be a deal breaker for the main game and RoE, but for mod-compatibility it's more difficult :-/

Also I'll have to review (and ideally test) this thoroughly, and I'm not sure when I have enough time for that.. (unfortunately, I can't even test it properly because all my current screens are 60Hz)

Don't get me wrong, this looks great on first glance and it's a often-requested feature, but as it's a quite invasive change I want to make sure we get it right and minimize breakage :)

BTW: Attaching zips containing .exe and .dll to github comments should be no problem, I do that all the time.

Stradex · 2020-06-11T21:07:54Z

Hello!

No problem!, I understand that this can be a huge change and can break compatibility with older mods. And that is a problem yes, I will try to find a way to do some kind of "hack" in order to avoid needing to modify the scripts and add a new .pk4 file. I suppose that if I achieve that then we can smooth a bit the merge of this feature :).

Also, if you use r_swapInterval 0 then you can test even with a screen limited to only 60hz, you are going to notice the difference no matter what.

Edit: I share to everyone here the compiled files for Windows 32 bits (including the pak009.pk4) , so anyone who wants to help with testing can do it.

For people with screens that doesn't support more than 60hz, use r_swapInterval 0 (need to close and open the game again after doing it)

dhewm3_unlockedfps.zip

Arl90 · 2020-06-11T23:44:16Z

This seems great, hope we can have it in dhewm 3.

DanielGibson · 2020-06-11T23:45:40Z

For people with screens that doesn't support more than 60hz, use r_swapInterval 0 (need to close and open the game again after doing it)

entering vid_restart in the console might suffice :)

I just remembered that there already was some discussion about >60fps at #230 and also #15 (comment) - revelator says he has a timing-related fix from DarkMod, so it might be worth checking out what they did (unfortunately, his modified dhewm3 doesn't seem to be on Github).

In the discussions there was something about Doom3 not properly running at 60fps, but 62.5, and it seemed that this was due to time being measured in integer(!) milliseconds.

const int USERCMD_HZ			= 60;			// 60 frames per second
const int USERCMD_MSEC			= 1000 / USERCMD_HZ; // 16

A frame should be 16.666.. ms, but the code uses 16 everywhere - and 1000/16 = 62.5 (instead of the desired 60) - that (combined with vsync) might lead to micro stuttering, I guess?
And millisecond resolution might cause even more problems at higher framerates (=> lower frametimes, just 4,166.. ms at 240fps).

I wonder if your changes here are affected by these problems?
Might be worth checking out what darkmod and D3BFG do?

I'm not sure if that makes sense or is even possible in Doom3, but do you think we could continue to run the game logic at 60Hz, so scripts and (most of?) the code in the game DLL don't have to be changed, but render at a different rate (and probably update at least the camera so looking around feels smooth)? It sounds like it should work at multiples of 60Hz (like 120Hz), but what if someone tries running the game at 90Hz or 144Hz or 165Hz - will stuttering get even worse then?
If running the game code that way (async), we might be able to modify the rest of the engine to either use microsecond for time, or maybe keep milliseconds but put them in a float or double for additional precision?
I haven't investigated this topic in Doom3, so this is just ideas :)

… order to avoid having to use custom pak content

Stradex · 2020-06-12T00:34:12Z

I have good news, I added a new commit that lets us use this feature without having to add a new pak file.

Build for windows 32bits (This one does not require the extra pak009.pk4 anymore)

Dhewm3 1_5_1 com_gamehz 32bits.zip

…p yet)

Stradex · 2020-06-12T08:31:12Z

In the discussions there was something about Doom3 not properly running at 60fps, but 62.5, and it seemed that this was due to time being measured in integer(!) milliseconds.
const int USERCMD_HZ			= 60;			// 60 frames per second
const int USERCMD_MSEC			= 1000 / USERCMD_HZ; // 16
A frame should be 16.666.. ms, but the code uses 16 everywhere - and 1000/16 = 62.5 (instead of the desired 60) - that (combined with vsync) might

I did a new commit based on that problem, I believe with the new framerate being float instead of int the improvement should be important. In my end I notice some improvement but I would prefer more people to test it before coming to conlusions too fast.

Stradex · 2020-06-15T00:05:07Z

This is the last build of this pull request. (Win32 binaries), This is for anyone who wants to test the feature.

dhewm3 unlocked fps v3.zip

DanielGibson · 2020-06-15T03:30:54Z

I looked at TheDarkMod very briefly and while it seems like they did some timing changes (using microseconds instead of milliseconds in a few places, apparently to get real 60fps instead of 62.5), it seems like it's still limited to 60Hz so it's not super helpful for >60Hz support.

I'll also look at D3BFG and I'll also try to understand how exactly a frame in Doom3 works, esp. what part of it happens in the game DLL.
I still hope that we can somehow run the gamecode (incl. physics) at 60Hz, but render at 120Hz (or 240 or whatever).. but for that to work, camera and movement code and ideally also animations should run at 120Hz (or whatever) - otherwise we'd just render the exact same frame twice (or four times), which would be pointless of course and wouldn't look or feel any "smoother".

(If all else fails we could just run at 60Hz and display 120 in the framecounter :-D)

For testing your current solution it might make sense check if the stuff that was broken with com_fixedtic -1 or the experimental builds that just hardcoded USERCMD_HZ = 120; works with it.
See:

com_fixedtic -1 causes Imp fireball and Lost Soul trail effect to render incorrectly #261 (with com_fixedTic -1) "Imp fireball smoke effect and Lost Soul smoke trail when it flys toward you renders incorrectly"
- issues with Dentonmod; resolving them will likely also allow me to submit my mod for official mod support #248 mentions similar problems (flickering particles) with com_fixedTic -1
Smooth movement on refresh rates above 60Hz? #230 (comment) "When closing the crane in Alpha Labs Sector 3, the game crashes to console"
- the same thread mentions a few more crashes, might be related though

It probably also makes sense to grep the whole engine and gamecode for "60" and "16", in case hardcoded values (instead of USERCMD_HZ and USERCMD_MSEC) are used somewhere (of course not every "60" or "16" in the code should really be one of those constants, we'd have to check every occurrence)

DanielGibson · 2020-06-15T03:59:25Z

Ok, looks like TDM supports 120Hz after all, you gotta search for "uncapped framerate" or "uncapped fps" apparently.
Looks like they also ran into lots of bugs, like
https://bugs.thedarkmod.com/view.php?id=4514
https://bugs.thedarkmod.com/view.php?id=4696
https://bugs.thedarkmod.com/view.php?id=4924
https://bugs.thedarkmod.com/view_all_bug_page.php?filter=5ee6ef1defb1f

I created a git mirror of their SVN repo in case anyone is interested in looking at single commits mentioned in the bugreports: https://github.com/DanielGibson/thedarkmod-mirror
(each git commit message has a line like git-svn-id: https://svn.thedarkmod.com/publicsvn/darkmod_src/trunk@8769 49c82d7f-2e2a-0410-a16f-ae8f201b507f - in this case the SVN revision they'd mention in their bugtracker is 8769)
NOTE: It's big, >400MB! Most probably because they (used to?) check in large static ffmpeg libs for win32 and win64..

nbohr1more · 2020-06-15T06:07:55Z

Thank you for the mirror!

If you wanna see the bleeding edge TDM stuff, go here:

https://github.com/fholger/thedarkmod

We're (TDM) mostly out of the woods with regard to high-FPS bugs but we probably could have saved ourselves a lot of hassle by simply modifying the core HZ attributes as our new developer Cabalistic did in his branch prior to joining (same dev who maintains the above repo).

Duzenko ( the developer who began uncapped FPS work ) was impatient to start because he was trying to solve a different timing issue for low FPS scenes and capped FPS was impeding that work. (Eg. That initial implementation had lots of problems.) We have been fortunate that a few outside (and very skilled) contributors mysteriously arrive to fix some of the physics and game bugs (then return to the shadows).

…ysics with player not working correctly

Stradex · 2020-06-15T20:43:43Z

Thank you all for the talk and info, and also thanks to someone who was testing the build and giving me feedback I added a new commit that should fix a problem related to game physics running a bit more faster than the original game. Also this build is supposed to remove the original mircostutter problem present in vanilla doom 3.

DanielGibson · 2020-06-20T23:57:26Z

neo/d3xp/Game_local.cpp

@@ -604,6 +605,8 @@ void idGameLocal::SaveGame( idFile *f ) {
 	savegame.WriteBool( isMultiplayer );
 	savegame.WriteInt( gameType );

+	savegame.WriteFloat(preciseTime);


this breaks savegame compatibility :-(

Thanks for letting me know this. I will try to find a way to avoid that, in fact I was looking at the BFG Edition code like a lot, and there are many things that I don't like about this pull request after looking at that. So I will try to find a way to improve this or actually try this again but most similar to the BFG Edition approach.

I think the best way to do this is to bump BUILD_NUMBER and in idGameLocal::InitFromSaveGame() you can check savegame.GetBuildNumber() and only if it's the new number you read preciseTime, otherwise you set preciseTime to some sane default value.

DanielGibson · 2020-06-21T00:00:04Z

neo/d3xp/Game_local.cpp

@@ -334,6 +334,7 @@ void idGameLocal::Init( void ) {
 	//Update MSEC and gameFps
 	gameFps = cvarSystem->GetCVarInteger("com_gameHz");
 	msec = 1000.0f / cvarSystem->GetCVarFloat("com_gameHz");
+	msec *= 0.96f*0.96f; //HACK to emulate OG D3 msec error, in order to have exactly the same game logic speed


why 0.96f*0.96f ?
I get that 16 / 16.666 == 0.96, but why square it?

That was a mistake from me. I thought that I needed to do that twice because common frame was already working at 16.666 hz, but multiplying by 0.96f twice was a mistake.

In fact that product for 0.96f is something I don't like at all. It is some kind of "duct-tape" ugly code. I will look at this feature in some days or weeks in order to see if with a fresh mind I can actually figure out something better.

DanielGibson · 2020-06-21T15:59:03Z

neo/d3xp/Game_local.cpp

@@ -309,6 +310,10 @@ void idGameLocal::Init( void ) {
 	const idDict *dict;
 	idAAS *aas;

+	msec = 16.0; //60fps


please put a space after "//", e.g. // 60fps (yes, always, not just here), like it's done in the existing code

(it also just looks better)

Stradex · 2020-06-23T08:24:38Z

Thanks for reviewing the code, but tbh with you there are some physics and game logic strange bugs that still I need to fix and I believe that is mainly because my approach probably is not the best at all. Sadly I must admit when what I am doing is not quite right and this is one of these times.

Hopefully maybe this failed attempt will encourage others to actually try this. I am no saying to close this but I am saying that this is not quite right, not even close, to consider a pull request. There is stuff to fix and probably when I have more free time I will try to look for another approach.

DanielGibson · 2020-06-24T00:42:42Z

Hey, sorry to hear it doesn't work as well as we hoped!

Can you write down what bugs you ran into? I think that'd be super-useful to know in case someone else would like to try to fix your approach, or to make sure that other approaches don't have the same issues - or just for yourself when you get back to this later and maybe forgot about the specific bugs :)
(At least I tend to forget such things after a few months)

I turned this pull request into a draft so it's clear that it's not done yet, but I'd otherwise leave it open as I think this contains good information - even if it turns out that indeed a different approach is needed I imagine that some of your changes are still useful - and if it's just to see what things in the code need to be changed for this.

I'm sure we'll come up with a working solution eventually, when we have some more time! :-)
(I have little freetime at the moment)

Sol1vaN · 2021-04-11T01:19:23Z

When closing the crane in Alpha Labs Sector 3, the game crashes to console"

the same thread mentions a few more crashes, might be related though

Seems that I've founded a way to solve this crash (temporal fix).
I'm don't know if this have relation with this problem, but it works for me.

The idtech4 (dhewm3) engine have a lot of instability when you play in 144Hz/144FPS mode (or another Hz/FPS different to 60Hz/FPS).
So, you need to change the afinity of CPU to the 0 core only.
May be the render engine works better in this way when you play at hi Hz/FPS.

Until now, I've played a lot in 120Hz/120FPS mode and right now I'm in the Alpha Labs Sector 4 with no issues.

I hope this help to contribute a little more to find a better way to reach the unlocked FPS feature.

turol · 2021-04-11T07:15:49Z

If CPU affinity helps it then it could be related to #169.

mirh · 2022-12-31T02:38:04Z

I'm just a random passerby but I'm completely missing on the sense of this PR.
Monitor frequency should only be a concern for the resolution selection code.
Everything else in the game should just care for framerate.

If you want v-sync then (putting aside all the fancy nuances that has today), that should be a completely separate matter until the user decides they want it.

Yamagi · 2022-12-31T14:59:46Z

The point is that Doom 3 (and thus also dhewm3) assumes a max framerate of 60hz throughout the code and within the scripts. Rendering more frames breaks things badly. There are several approaches to solve that problem, however none of them is easy to implement. This PR is one of them.

Being able to render more frames would be nice, because these days 60hz is the lower end of the spectrum. Even if we can reach only 120hz, it would be a big improvement. VR probably needs 240hz or even more...

Zhnigo · 2023-06-12T09:02:59Z

This is the last build of this pull request. (Win32 binaries), This is for anyone who wants to test the feature.

dhewm3 unlocked fps v3.zip

Hello and thanks for your work! Is there a way to implement this functionality in dhewm 1.5.2? 1.5.1 has severe visual bugs when playing with D3HDP

simonedibilio · 2023-11-29T22:43:49Z

I second Zhnigo's comment, I too was trying to get your patch working on 1.5.2 cause of D3HDPv2 (best graphical overhaul out there imo), but - alas - to no avail..

com_fixedTic -1 doesn't really do much for smoothness like "unlockedFPS" does, unfortunately :')

markanini · 2023-11-29T23:30:03Z

com_fixedTic -1 doesn't really do much for smoothness like "unlockedFPS" does, unfortunately :')

What's the perceivable difference?

simonedibilio · 2023-11-30T11:12:30Z

com_fixedTic -1 doesn't really do much for smoothness like "unlockedFPS" does, unfortunately :')

What's the perceivable difference?

I think it's a frame pacing issue, 'cause fixedTic -1 feels like 60hz (or worse!), no matter what: I tried with the game running unlocked at a thousand FPS, or with it limited at various FPS stages (90, 120, 144, 175, 240 - depending on the set monitor's refresh rate) through nvidia's control panel, or nvidia's inspector (which should be the same..), or RTSS (again, should be the same as the control panel).

.. whereas with Stradex's patch, it feels exactly like BFG's 120hz mode: perfectly sync'd, smooth and responsive, like in a competitive FPS.

I recently replayed through the whole game on 1.5.1 with this patch and - apart from the memory leak (?) issue that requires you to restart the game every now and then to avoid it getting locked at 25 FPS and the oxygen getting depleted faster on a couple of outside segments of the game (not even all of them) - it was amazing.

simonedibilio · 2023-12-01T19:49:04Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .

To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2

Peace ✌️

markanini · 2023-12-04T00:25:14Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .

To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2

Peace ✌️

Thanks. After comparing it's clear how Stradex's patches are much smoother than com_fixedTic -1. And you made RoE work too!

simonedibilio · 2023-12-04T08:59:37Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .
To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2
Peace ✌️

Thanks. After comparing it's clear how Stradex's patches are much smoother than com_fixedTic -1. And you made RoE work too!

And - as of saturday - The Lost Mission too! :)

Stradex · 2023-12-04T13:12:29Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .
To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2
Peace ✌️

Thanks. After comparing it's clear how Stradex's patches are much smoother than com_fixedTic -1. And you made RoE work too!

And - as of saturday - The Lost Mission too! :)

Hi! Thanks a lot for doing it. I've been really busy lately sadly and I am not finding time to work with Doom 3 stuff anymore :(

But it makes me happy to see that some of the stuff I did still serve some purpose, I am sorry for not porting it to Dhewm3-1.5.2 myself but I am glad you did.

quake1982 · 2023-12-05T09:28:21Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .

To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2

Peace ✌️

Sir, you are doing God's work, much appreciated for this contribution. However, there are two major bugs:

switching mods (e.g. from based DOOM3 to ROE) causes "black screen" in a short term (from 5 to 25 seconds), which means the game menu can not be shown immediately (still the console can be shown in the screen).
The gravity gun in ROE or Lost Mission can not work immediately (probably in 10-30 seconds)if you first grab it or after cut-scenes.
I think those bugs must be triggered by the uncapped fps.
Cheers!

simonedibilio · 2023-12-05T18:12:43Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .
To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2
Peace ✌️

Sir, you are doing God's work, much appreciated for this contribution. However, there are two major bugs:
1. switching mods (e.g. from based DOOM3 to ROE) causes "black screen" in a short term (from 5 to 25 seconds), which means the game menu can not be shown immediately (still the console can be shown in the screen).

2. The gravity gun in ROE or Lost Mission can not work immediately (probably in 10-30 seconds)if you first grab it or after cut-scenes.
   I think those bugs must be triggered by the uncapped fps.
   Cheers!

hey! thank you for taking the time to report these issues; I'd ask - if you don't mind - to move the discussion to the "issues" section on my repo, so that we can keep track of these problems there :)

quake1982 · 2023-12-05T22:11:29Z

I decided to take matters into my own hands and ported Stradex's source into dhewm3 1.5.2 .
To anyone landing here from pcgamingwiki or wherever, just check out my repo: https://github.com/simonedibilio/dhewm3/tree/unlocked-fps-rw-dhewm3-1.5.2
Peace ✌️

Sir, you are doing God's work, much appreciated for this contribution. However, there are two major bugs:
1. switching mods (e.g. from based DOOM3 to ROE) causes "black screen" in a short term (from 5 to 25 seconds), which means the game menu can not be shown immediately (still the console can be shown in the screen).

2. The gravity gun in ROE or Lost Mission can not work immediately (probably in 10-30 seconds)if you first grab it or after cut-scenes.
   I think those bugs must be triggered by the uncapped fps.
   Cheers!
hey! thank you for taking the time to report these issues; I'd ask - if you don't mind - to move the discussion to the "issues" section on my repo, so that we can keep track of these problems there :)

No problem!
By the way, I'm gonna do further test. As a matter of fact, the first bug doesn't affect the game too much, you just have to wait a few seconds. But the second one, sometimes, is very annoying. For instance, in the first Boss of ROE (blink skill), when you enter the boss fight arena, there will be a cut scene, and then the fight will begin. In this case, the gravity gun can not be used to grab those green plasma projectiles immediately, you have to roll with him for a moment, then wait until the gravity gun works.
I'm not familiar with C/C++ programming, so I couldn't provide program-level details. But, I think those bugs are triggered by the high framerate because the inner clock-tics was locked at 60 fps originally, including all the physics and animations. If I switched back to 60 fps, everything is back to normal.
Cheers!

Muleke · 2024-03-20T15:12:38Z

I am really glad to see that there is still interest in making DOOM 3 run with a high refresh rate, just like in BFG Edition!

Running TDM with a high refresh rate and FPS is a dream come true, so I'm looking forward to having that implemented in dhewm3!

Terepin · 2024-04-01T08:23:03Z

Since 1.5.3 is out, can this be ported to the newest version as well?

glKarin · 2024-05-10T08:47:30Z

glKarin/com.n0n3m4.diii4a@1f62e47 - glKarin/com.n0n3m4.diii4a@33787d9
ONLY TESTING FOR ME
I am using some TheDarkMod's source about FPS in DOOM3, it seems look like well, although maybe has some bugs.
Current, if enable com_fixedTic, firstperson model animation will be faster. I do not also test any more.
And I think using cvars as engine -> game instead of changing idGame::RunFrame function for keeping SDK/mod's compation.
So I want to your suggestions.
UPDATE:
some triggers not be triggered.
More and more errors. AI, collision, sound, projectile...

Stradex added 2 commits June 11, 2020 04:19

added com_gameHz to play with higher FPS

65d12cb

fix: change _malloca to _alloca

6d9f3d3

hack: inject GAME_FPS, GAME_FRAMETIME and CHAINGUN_FIRE_SKIPFRAMES in…

9ab12b7

… order to avoid having to use custom pak content

Stradex added 2 commits June 12, 2020 02:21

remove setscriptfps not used anymore

8738450

improved framerate precision using float instead of integer. (not d3x…

695d050

…p yet)

Stradex added 2 commits June 13, 2020 03:03

update: support for d3xp

15f4e5e

fix: multiplayer fix and more

d6c7304

Stradex force-pushed the unlockedFPS branch from c96658f to d6c7304 Compare June 14, 2020 06:16

fix: desync between client and server

bb0dd7d

Fix: game now running original game logic speed and solve bug with ph…

168b027

…ysics with player not working correctly

DanielGibson reviewed Jun 20, 2020

View reviewed changes

DanielGibson reviewed Jun 21, 2020

View reviewed changes

DanielGibson marked this pull request as draft June 24, 2020 00:34

DanielGibson mentioned this pull request May 19, 2024

Concept of dhewm3 running at 144Hz refresh #250

Open

Add com_gameHz to play with higher HZ/FPS #297

Are you sure you want to change the base?

Add com_gameHz to play with higher HZ/FPS #297

Conversation

Stradex commented Jun 11, 2020 • edited

Stradex commented Jun 11, 2020 • edited

DanielGibson commented Jun 11, 2020 • edited

Stradex commented Jun 11, 2020 • edited

Arl90 commented Jun 11, 2020

DanielGibson commented Jun 11, 2020

Stradex commented Jun 12, 2020 • edited

Stradex commented Jun 12, 2020

Stradex commented Jun 15, 2020

DanielGibson commented Jun 15, 2020 • edited

DanielGibson commented Jun 15, 2020 • edited

nbohr1more commented Jun 15, 2020

Stradex commented Jun 15, 2020 • edited

DanielGibson Jun 20, 2020

Choose a reason for hiding this comment

Stradex Jun 23, 2020

Choose a reason for hiding this comment

DanielGibson Jun 24, 2020

Choose a reason for hiding this comment

DanielGibson Jun 21, 2020

Choose a reason for hiding this comment

Stradex Jun 23, 2020

Choose a reason for hiding this comment

DanielGibson Jun 21, 2020 • edited

Choose a reason for hiding this comment

Stradex commented Jun 23, 2020

DanielGibson commented Jun 24, 2020 • edited

Sol1vaN commented Apr 11, 2021 • edited

turol commented Apr 11, 2021

mirh commented Dec 31, 2022

Yamagi commented Dec 31, 2022

Zhnigo commented Jun 12, 2023

simonedibilio commented Nov 29, 2023

markanini commented Nov 29, 2023

simonedibilio commented Nov 30, 2023

simonedibilio commented Dec 1, 2023

markanini commented Dec 4, 2023

simonedibilio commented Dec 4, 2023

Stradex commented Dec 4, 2023

quake1982 commented Dec 5, 2023

simonedibilio commented Dec 5, 2023

quake1982 commented Dec 5, 2023

Muleke commented Mar 20, 2024

Terepin commented Apr 1, 2024

glKarin commented May 10, 2024 • edited

Stradex commented Jun 11, 2020 •

edited

Stradex commented Jun 11, 2020 •

edited

DanielGibson commented Jun 11, 2020 •

edited

Stradex commented Jun 11, 2020 •

edited

Stradex commented Jun 12, 2020 •

edited

DanielGibson commented Jun 15, 2020 •

edited

DanielGibson commented Jun 15, 2020 •

edited

Stradex commented Jun 15, 2020 •

edited

DanielGibson Jun 21, 2020 •

edited

DanielGibson commented Jun 24, 2020 •

edited

Sol1vaN commented Apr 11, 2021 •

edited

glKarin commented May 10, 2024 •

edited