@Raven can you also test vquake2 lava death on an actual Verité board? This doesn't look to be a crash in RReady, but it could be that RReady's passing ref_v1k duff data or corrupting memory.

For instance on map mintro (Mine entrance) a lava death doesn't crash the game. Neither does mine1. So I'm not entirely sure what's going on with the multiplayer map.

you are magic) hexen2 fixed, not all time render stuck in lava, other maps than meso2 seems don't have this. By some reason meso2 death camera on lava don't stuck on real hw. Could be vh2 problem like not fully compatible to newer windowses.
In RReady you still can unlock camera underlava in death state by pressing 'esc' to see main menu, while in main menu animation and mouse movement will respond.

Checked Quake2 on real hw it happens all the same. So its not wrapper fault here.

Checked SODA Offroad , by watching intro demos couple times, about 20 min, and game closes CTD without any error, doesn't happen on real hw. Software rendered SODA crashes too . Game seems do not crash by manual playing (by myself)

I have a request for vquake 2 on original hardware:

1)Run vquake 2
2) Let the demos demo1 and demo2 run normally
3) Start a new game on easy
4) Blow up the crates and shoot the enemy who shows up through the door.
5) Jump through the window and climb down the ladder and make your way underwater.
6) While underwater swim around and bring up the console and type disconnect
7) Type timedemo 1
😎 demomap demo1.dm2
9) demomap demo2.dm2
10) demomap crusher.dm2

Once the crusher demo (which you may have to copy across) runs, do demos1 and 2 run without issue? Or does vquake 2 crash?

RReady sometimes crashes after this. After running crusher, ref_v1k reloads and horrible things (sometimes happen). I've never been able to debug this.

So if you could give this a go, it would be educational.

[EDIT] I've literally wasted hours trying to fix this earlier this year.

Also I noticed I have more water particles than Verité in the RR1 demo.

This suggests something very wrong.

Tested Quake2 , yes demo1 and demo2 plays ok.

ref_v1k reloads before demo1.dm2 after crusher.dm2

Will check hexen2 , maybe more powerful cpu/gpu can generate more particles?

RaVeN-05 wrote on 2023-10-30, 12:23:

Will check hexen2 , maybe more powerful cpu/gpu can generate more particles?

I doubt it.

ok tested seems it doesn't change amount of particles.
Visually very low fps makes it looks like it low amount of particles.
High FPS makes visuals like we have more particles.

Filtered (AA ) particles looks like less amount.
It visually also depends on how far or close to fountain, if you located far from fountain it visually looks like too much particles here. Even more when they unfiltered.

We can't know amount of spawned particles , unless hexen2 have some kind of CVAR that can show statistic. By other way to figure it oust hexen2 source code exist, unfortunatelly no rendition renderer here.

About Quake2 its not necessary to do all those steps.
just
1.timedemo 1
2.demomap crusher.dm2.
3.~ (press tilde) (invoke console) quake 2 will reload v1k and sometimes rready crash here. sometimes it can continue to work, after recompiling their shaders etc.

Could it be we have different copies of VH2.exe? It's extremely unlikely.
MD5: 417ddceda82e8fd20928fed4b74bc988
SHA1: b1eabde4265f6901fef94b97100bc5d500c434f2

Dated 15 November 1997?

And original hardware is rock solid with crusher right?

vh2.exe exactly as yours, and yes amount of particles seems to be depending of performance of renderer.
i am not sure what you will see in this demo, or not, but i clearly see it changes, sky is decreasing performance for now, and it makes less amount of particles, when sky is not on visible area it produces more particles.
So my video from real hardware is have less amount of particles due to slow PC , CPU/GPU .

vquake2 crusher is very slow and i spot no glitches in graphics/visuals.

I'm not at my machine right now. Does adding maxfps=12 to rendition.cfg allow rendering the green gola?

Shader replacement won't work because rready passes RRedline format vertex and texture data to the gpu. It's faster getting the gpu to decode it.

If not a duplicate vertex structure has to be created with coordinates divided by 65536 or 16777214. The gui works because square/rectangle rendering turns off 16.16 fixed point (or 0.24 fixed point) data processing because it uses a display list (as fast as vertex buffer objects on modern gpus). Different vertex types use differing combinations and types of vertex data. If you look for strings in rready you should be able to find the shader source.

Rectangle rendering rredline style passes a single coordinate so decoding doesn't take up much time.

no, with latest rready it distort golem =0

If you up the framerate to something higher like 24 fps?

Oh and there's more than one shader.

still no, but texture not corrupted, hexen2 designed to operate in 72fps as quake
also demo for tests. There is another type of golem in egypt which is uses red crystals , share same problem.
will check demo on real hw, to confirm. and will upload.

Testing demos

I'll check it out tomorrow.

Enough for today.

Just for kicks here's my golem demo.

It has more beam firing.

Alt-tabbing out and then back in produces the green golems (while firing beam).