/vr/ - Retro Games

>>6925587

>>6912895
he said it needed to be "cleaned up", but judging from what I've seen in the leaks I have... that's not going to be easy (jesus fucking christ).

he also said that there was middleware involved, but the only thing I could find is the galaxy audio driver, and it could just be swapped out for something else like the case of dmx with the doom source release.

>>6908524
I playtest my mods so extensively I'm unable to appreciate them anymore. I need other people to do that for me.

... and if that don't work, use more gun.

>>6884835
>Something about Unreal I dunno
>https://www.youtube.com/watch?v=abwxJGUsJ0
The fuck is this supposed to be? video is unavailable.

>>6871737
nothing, just dies

>>6871725
... or reload a save

>>6871667
overheal fades out like in quake (relatively fast, much faster if above 500), refreshers are +100 instead of +200, only autoactivate on lethal damage. the other health items can't prevent death anymore (so stacking yourself with full cubes/tetras won't work as an extra life).

>>6871332
Anyway because the superhealth items were too OP I ended up rebalancing everything again.

>>6869861
You die, and then you can press fire to come back, and then you die twice.

>>6869551
Because that's how things have always been structured. Changing it now would break everything.

>>6869526
Many engines have dedicated, optimized lightweight classes for non-interacting visual effects, they also don't have world geometry that can unpredictably change at any moment. And most importantly, they don't have hundreds of enemies active at all times.

In the Doom engine, every actor can have AI, behave like a projectile, particle, decorative, etc. Each actor has code for handling all of that, which adds up quickly in CPU overhead. Meanwhile in others like Unreal Engine there's dedicated classes for effects, pawns, projectiles, decorations, etc.

If a slaughtermap runs smoothly in prboom+ vs gzdoom, it's merely because the mobj tick function is 11x larger (or even more since a lot of extra work is offloaded to other massive functions).

I've sort of been working around this by rolling out my own lightweight Tick() functions with unneeded features removed, but not everyone has that level of skill in zscript (or uses zscript at all).

>>6869072
You can't magically multithread it and expect everything to still work the same but faster. In fact, this would only make things more complicated because now you'd need all sorts of syncing code for everything and on top of that determinism is thrown out the window (this would instantly kill p2p multiplayer).

There is a reason why the vast majority of game engines still do game logic in a single thread. It's simpler, easier, and more cost-effective.

>>6866410
that's good. at least you know it's not for you.

>>6865531
CHOO CHOO!

>>6848379
that's precisely what I wrote CheckReplacement for

>>6837512
bitch, this isn't even as fancy as I want it to be, I'm scaling it FORWARD

>>6836708
succ

>>6818540
sounds more like those guys say "YOU WILL DIE A SMOL SMOL DEATH"

>>6808759
it's impossible because tim sweeney never coded in font scaling

>>6800371
good boy

>>6754686
>reshade ssao and dof drawing over sprites and even the hud
how do these people live with themselves?

>>6734665
but anon, "hell" doesn't exist in btsx lore

>>6727940
the oldunreal people are a bunch of pathetic knobheads. they're already known to have broken their nda a couple times by backporting features from later versions of the engine, so I wouldn't be surprised that was their fault too.