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[EDIT: With vanilla Dosbox].

************************************************
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 ([EDIT]Fully 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.

One final Quake engine video, this is the last one:

https://youtu.be/lQxZ1_tkFF8

The effects of v1k_surfacelookup/r_surfacelookup.

i also recommend to try to check those cvars
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)

and
d_amip 0 is better graphic quality for models
d_mipscale 0 - disables mipmap (may decrease fps) floating point values is acceptable here

the embedded render into dosbox is good for vQuake , maybe let it be for only for quake, anyway vQuake most hungry game for PC

and maybe now is possible to find out what d_sync means?

RaVeN-05 wrote on 2024-09-11, 11:24:

i also recommend to try to check those cvars Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1) Re: RReady (Rendition […]
Show full quote

i also recommend to try to check those cvars
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)
Re: RReady (Rendition Verite wrapper) Test Build (Alpha 1)

and
d_amip 0 is better graphic quality for models
d_mipscale 0 - disables mipmap (may decrease fps) floating point values is acceptable here

the embedded render into dosbox is good for vQuake , maybe let it be for only for quake, anyway vQuake most hungry game for PC

and maybe now is possible to find out what d_sync means?

I tested d_mipscale 0 early on and vquake chugged with vanilla dosbox.

The embedded path doesn't improves staging very much. Vanilla dosbox speeds up to staging levels but the static is still there, but it's a lot less.

If staging is the preferred dosbox for vquake, is there any reason to support the embedded mode? Nothing else is faster, in fact rebel moon is a lot slower, less than 33% of piped speed and it increases my testing burden.

I can add it to dosbox and leave it disabled. if anyone wants the source.

I have other games to get going.

[EDIT] I'll see if I can find out what d_sync does.

I think d_wamp and d_wfreq control the amplitude and frequency of the underwater sine warp.

I think this was mentioned somewhere, possibly by you in this very thread.

From Vogons wiki, most of these are there:

https://www.vogonswiki.com/index.php/VQuake

D_sync isn't. Will test it tomorrow.

Don't bother with vQuake too much.
It's great it already running.)
I think

I really want to focus on Eurofighter now, get that working properly.

Vquake beta 1.06 used to work but no longer does. I think know why. Vquake 1.08 makes the bios calls in protected mode, and 1.06 in real mode, or at least some of them. I changed some pointers from physical ones to real ones, which might be why this is happening. But this isn't a priority at the moment. Other than vq 1.08 everything else handles physptr sjust fine. Vq 1.08 needs realptr and everything else handles that just fine as well.

d_sync isn't vsync,. If it is, it's not like r_nopageflip/v1k_nopageflip. Not entirely sure what it does.

No doubt we'll figure it out in the end.

There is a FIFO synchronisation call V_FIFO_FRAME_MARKER and V_FIFO_SYNC_AND_RESPOND (this is listed in the F1 leak and was ignored by RReady generally). Some Speedy3D apps do use it.

It writes to the FIFO output queue once <something> happens. The app can wait for it to appear (i.e for the Verité to reach a synchronisation point) before doing anything else. RReady does implement it in two different ways for some games, but I don't know if it's right. But the games do run. Whiplash is one of them and that runs at a solid 60 fps.

So dma_sync maybe?

I'll test for this in a bit.

[EDIT] Nope. V_FIFO_FRAME_MARKERS are there pretty much every frame and are ignored and there're only a couple of V_FIFO_SYNC_AND_RESPONDs after a mode switch. d_sync doesn't seem to affect either of these.