Closed Ozymandias81 closed 3 years ago
About those targets indicators, could it be related to the scale crosshair issue we had couple days earlier @AFADoomer ?
It's not that, it is probably what Talon said. --Ozy81
IIRC the target indicators shouldn't show up on skill 3 (HMP/Ordinary) or higher.
If that's the case, then I found it as a very stupid decision, have to say sorry. The case I told here is a clue. --Ozy81
@Ozymandias81 It was my decision https://github.com/Realm667/WolfenDoom/commit/feb6eb903cc428e8799dc765591a9aba4dc78476, maybe it was stupid, but nobody commented on my stupidity neither when I posted it on the issue nor when committed the change. Fixed right now.
Sprinting was always supposed to be disabled while in disguise, but the check broke as the disguises evolved. I can get rid of that check.
Does idmypos actually cover anything when you have items? It should float to the left of the key block and inventory area. I do need to adjust the position downward when fps is shown.
Yes it covers keys and such over that zone, and it is also covered itself by vid_fps variable too. --Ozy81
The skybox might be misbehaving after I made a change to fixe the C3M6 finale swirl skybox. I will take a look.
@Ozymandias81 - But it doesn't cover the keys or the inventory area... Look at your later screenshot. The red key is off to the right of the lock icon.
I see, still fighting with github here sorry so didn't check properly. In that case I think it should place down right after radio messages banners, so in case we can grab shots properly during cutscenes too. My bad in this case. --Ozy81
It already accounts for incoming messages... I just need to add an offset if vid_fps is toggled.
Works good now... On the other side, this model has some tearing that can't be noticed under any model editor, only on GZDoom... Why? It's re_windows.md3, and no it isn't the middle tx in case you ask
Is this in C3M0_A's Resident Evil easter egg? If yes, @AFADoomer made these models, maybe he can help.
The original model that I converted from was a mess. This is residual from that, I think.
It's possible that 2 models are overlapping in this case, though. I'll take a look.
Yes I was aware that AFA did them, I thought it was the midtex, then models clipping together... But no, it comes from the model itself. Didn't test if setting scaling to 1.0 on modeldef helps though (which is 1.333 xyz atm)
EDIT: It's not the scaling neither, probably normals with faces in clip outside somehow for GZDoom.
The skybox might be misbehaving after I made a change to fixe the C3M6 finale swirl skybox. I will take a look.
After investigating, I am pretty sure that's the reason. It worked before that commit but the relative position seems to be broken now.
Yes. And if I revert my change, this one is right again, and the finale one is broken.
Then now what's left is the window model and the optimization... Surely when there are around actor spawners and zombies things get worse than expected. I'll see if I can do more tests while checking issue #384
I've been experimenting with short-circuiting enemy logic/Tick calls if they are outside of a certain range from the player... with some good initial success. I have to track down @Talon1024's issue with the new culling code and do some more testing and tweaking, but this gave me huge improvement.
I'm also working on adding fog/fade handling so that enemies that shouldn't be able to see you through fog from a distance won't shoot at you, also with great success (because fast projectile bullet tracers are expensive due to ridiculous portal check overhead) . C3M2 plays very differently with this change.
Will work to commit these tonight (so like 8 hrs from now).
Added new issue that I noticed while playing C3M2, MGTurretSoldiers and enemies which shoot tracers with Bullet damagetype turns out that they damage tanks... Not sure if it is a smart move to add a different damagetype for EnemyTracers inheriting BulletTracer
Added new issue that I noticed while playing C3M2...
If you transfered it here (sort of) as another issue, does it mean this #465 can be closed?
No your issue is different since it seems related to something else. --Ozy81
Sadly it seems that recent improvements to cull and actors code made things worse, noticed it in a triple run (vulkan-opengl-vulkan) of C3M1_A from UDBuilder and I always get crazy spikes until I reach a zone without many actors... and when I return to the prisoner's courtyard after the first load, things gets a bit better, but indeed worse than how it felt previously @AFADoomer Gonna playtest again to be 100% sure, now from ipk3.
What about if you lower the boa_cullrange value?
Let me check again --Ozy81
It seems that if I change cullrange, things slowdown for a while, let's say 30 secs, then gets better... but then if I leave a zone that I have already visited, let's say surrounded with trees, if I leave it far enough then get back there again, slowdown happens again and it takes 30-35 secs to get acceptable framerate again. Mind you, this is under ipk3, vulkan and rendering distance for everything at 2048, while playing with cullrange between 8192 and 2048, no PPShaders enabled (I even did a run with them but wasn't bearable for me). Some shots with also some profilethinkers, I also forgot to show you a screenshot where I got 29.0 for ColorGrade under Titlemap (and it got some spikes there too, until I removed PPShaders).
Now with properly updated drivers runs better, even with PPShaders on, but I noticed an issue between rendering distance and cull values: if I start the game with cullrange at 2048 and have rendering distance at 2048, it seem to work faulty with conelights, until I increase cullrange to something more than 2048 (tested with 8192). So I bet that if one starts with cullrange at 8192 can't notice this problem. Seems to run fine, always 4.6 r195 ipk3.
Good framerates :)
Indeed, but sadly it happens rarely... now I get spikes on C3M6_A quite everywhere, and with my usual settings --Ozy81
I have found the source of my issues with slowdowns, going to confirm and drop a line in a while... it doesn't belong to GZDoom or BoA btw, but something between my version of Github or DFX.
EDIT: It is my version of github, which seem to pull continuosly and access on my hdd as soon as I do the very first "synch" request, that's also why it takes ages for me recently. My bad and sorry for the incovenience.
That's ok. This drove a lot of optimization that otherwise probably wouldn't have been in the release.
Thanks for tracking it down!
You are welcome! btw I noticed something: heat and sandstorm effects doesn't get deactivated from menues, I am redo cloning of several repositories so it will take a long time... Reminder for me: never use anymore old 3.3.6.1 because of just the presence of "synch" button, we can live without it!
Are all issues here fixed so far?
Yes, only this new one regarding heat/sandstorm not being deactivated --Ozy81
Effect givers should be good after 3bc70d6b510f8977aa8de4c466d42391048d25c1.
[x] There are some problems with recent changes: we can't run anymore while in disguise, this means also that we aren't able anymore to reach some secrets, such this one on C3M1_A.
[x] Also the new coordinates for idmypos takes top-right corner with my setting, makes nearly impossible to see which keys and stuff I have with me.
[X] There is also an issue with targets indicators, they doesn't seem to work anymore on certain occasions, such this one which is fundamental.
[x] In the end, it also seems that special skyboxes doesn't work as intended anymore, or something has been moved on the map (if maps have been edit using external editors beside UDBuilder this could be related maybe).
[x] MGTurretSoldiers and enemies which shoot tracers with Bullet damagetypes damage tanks.
[x] In any case, I have to say that I get terrible slowdowns spikes with Vulkan (more frequent) and OpenGL, while performance is initially better under Vulkan. This also happens under GZDoom 4.5.0 stable via IPK3 and lots of details off.
Running under gzdoom4.6 r195 64bit, while testing from UDBuilder 3751 64bit.