RaVeN-05 wrote on 2024-09-03, 20:40:

Its very cool to have them, those guide videos !

Thanks. Are the cutscenes correct in the Quake 2 expansions? Somehow I don't think so.
[EDIT2] I keep forgetting I have a Rendition board. I should probably test this [/EDIT2].

[EDIT3]Cutscenes with RReady: https://youtu.be/dM413HOxVP0
Even on my V2100 they do look like that, so it might be ok. I still get the feeling the left edge is cut off with "The Reckoning."
[/EDIT3]

[EDIT]
One other thing I noticed was that even on real hardware Team Apache screen updates freeze (such as when quitting a mission and hitting 'Y'), until there's mouse movement. So there's some weirdness in the screen updates.

vQuake 2: The Reckoning - Chroma keying improvements

The shader based filtered chroma keying is now the same as for vHexen II:

https://youtu.be/nncSZ_e3Vks

Now I can get back to Dosbox minimum framerate improvements. Making the DOS wrapper open source allows me to embed it directly into Dosbox. vQuake 1 shows improvement with vanilla Dosbox, which is what I've fixed so far. Minimum framerates hovering above 40 fps (up from 20 in some places) at 768x576. It looks very smooth.

ICR2 crashes at the moment. If I can get it working, maybe high poly carsets and replays *might* run faster.

vQuake 1 appears to be the only game showing signs of improvement. Everything else is either slower or the same.

vQuake's average minima appears to be higher. Games like Tomb Raider and and (especially) Rebel Moon run slower. The slowdown in RM is catastrophically bad.

[EDIT] It will be interesting to see how staging performs with these changes.

Here's yet endless split screen video of dosbox-rendition before and after embedding and ICR2 appears to be working (no change in performance):
vQuake sees significant performance improvements.

https://youtu.be/AYTnfiOlKPk

[EDIT] For staging there's a much smaller performance delta, but the embedded version ends up leading the piped version. Minimum framerates are higher, but then staging already had higher minima. I won't post a video of it.

one thing i noticed when testing rm and cr on real computers was that:
- the faster pc the more fps i got in rebel moon
- the faster pc the less fps i got in cart racing and nascar racing

So if you optimised rready for cart racing, this means rready is slowing down faster pcs so that cart racing is not slowing down. As a side effect rebel moon is slowing down on faster pcs with rready.

That's a good point. There's some kind of bottleneck somewhere. I'm seeing weird loading issues if I have visual studio 2022 running in the background. Some internal process uses up a lot of CPU sometimes and kills my framerates.

Need to profile this a bit more. I think I don't have visibility of what's going on in terms of CPU loading. RReady isn't GPU constrained. I think there's a user on icr2.net who gets 30 fps with a GT740 with ICR2 with an Intel i7 6700. I'm using the Intel profiler at the mo, which presents the data in an odd way. Visual studio's internal one stopped working, about a year ago and all the fixes I tried wouldn't get it working again, after an update. It errors out with a "Failed to collect data" error.

I've also interspersed Sleep(0) (yield) in some timing critical loops as they improve performance on slower machines. The sleeps kick in only if there's no data to process. Removing them pushes up cpu load without a tangible benefit. I really need to get the VS profiler going.

robertmo3 wrote on 2024-09-06, 06:14:

- the faster pc the more fps i got in rebel moon
- the faster pc the less fps i got in cart racing and nascar racing

Is this with threadsafe=true?

this is on real computers with real v1000

robertmo3 wrote on 2024-09-06, 06:27:

this is on real computers with real v1000

Ah, the plot thickens.

Also there's a weird thread safety issue with ICR2 and the Nascar games. The other games don't suffer from it, well apart from EF2000+.

The other games handle register accesses/writes from another thread without any problems, but ICR2 and Nascar go nuts. I've actually had to slow down RReady with a busy loop for the Nascars., otherwise they crash or freeze. ICR2 is pretty stable these days though even without threadsafe=true.

************************************************
RReady Alpha September 08, 2024 (Untested Alpha release)
************************************************

https://nirvtek.com/downloads/RReady.Alpha.20240908.001.zip
MD5: dc331c189d6148300d934679c8cdb18f

- Fixes r_surfacelookup "1" not working. The earlier betas should render, but r_surfacelookup "1" and earlier betas are not officially supported, yet. There may be bugs. Note enabling surfacelookup ("1") is slower than disabling it ("0"). This is true for vQuake 2 and vHexen II as well with RReady.
- vQuake 2 chroma keying and texture filtering is now shader based. This should fix pixelated textures in expansion pack "The Reckoning."
- RLauncher remembers the last tab and selected app in each and every tab between restarts.

This will be tested and released to the Store once it's validated.

The embedded code path has been abandoned. Only vQuake saw any improvement and with staging the improvements were minimal. Others regressed or ran the same.

************************************************
RReady Alpha September 09, 2024 (cusorily tested Alpha release)
************************************************
https://nirvtek.com/downloads/RReady.Alpha.20240909.003.zip
MD5: 0b5930f7f08569653b385136a498744f

https://nirvtek.com/downloads/RReady.Alpha.20240909.001.zip
MD5: 5afb44c22325fff2dfbdb61d7df75016

- Fixes random texture corruption with r_surfacelookup 1 (vQuake 1). On weaker CPUs (in modern terms) r_surfacelookup 1 will be faster, just like in Rendition's heyday.