VOGONS


RReady (Rendition Verite wrapper) Test Build (Alpha 1)

Topic actions

Reply 2961 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t
Makus wrote on 2025-07-07, 07:45:

Hi sharangad,
are you talking about the INT 21 functions of the DOS/4GW extender?
Perhaps chapter 10 of this book can help you: https://openwatcom.org/ftp/archive/11.0c/docs/cprogguide.pdf

That's just what I need! Thank Makus! I would never have found that on my own.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2962 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t
Makus wrote on 2025-07-07, 07:45:

Hi sharangad,
are you talking about the INT 21 functions of the DOS/4GW extender?
Perhaps chapter 10 of this book can help you: https://openwatcom.org/ftp/archive/11.0c/docs/cprogguide.pdf

According to the pdf, Int 31h is the Dos4GW call. Int21h is a dos call which can be overridden by a user supplied 32 bit handler. So this call is probably internal to the app.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2963 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t

ICR2 makes several Rendition specific Int 10h calls as well as Int 1Ah calls to detect and initialise Rendition boards.

Going through the source in Ghidra there's only one int 10h call (function 0x0f: Get current VGA mode.) and not a single int 1A call. Is it safe to assume binary is a compressed dynamic loader? I thought it was but checkpoint10 at icr2.net was able to work out what the data blocks did and control engine and track physics.

If it does anyone know how I can decompress the rest? I tried using IDA (the last version compatible with DOS and it has rendering defects in my Win98 VM). In theory Ghidra should be able to do it.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2964 of 2971, by RaVeN-05

User metadata
Rank Oldbie
Rank
Oldbie

not sure , there is a lot of exe compressors. probably you can use dosbox debugger and dumpmembin 0:0 ffffff (bumps 16 mb ram file) while game runs , this will expand exe if its compressed and show code in uncompressed state.

for other things: i streamed vquake1
and have spot some differences to original HW, its minor and not matters:
r_antialias - works even if AA still early version , for value 4 or 7 which will use rounded particles its have little bug, particles sometimes have transparency problems like we seen earlier in vhexen2
see atachments

r_surfacelookup - ok
d_bilerp - turn off/on models (should off/on texture filtering)
d_sync - dead cvar, no attention here.
d_amip - 0 - makes model looks better, 1 - at distance models will use mipped image and bad side of it models will have blue lines at some connected polygons
d_wfreq - works (better than original HW) at some negative values we could see blue noise on original HW, here its not happening
d_wamp - works (better than original HW) at some negative values we could see blue noise on original HW, here its not happening
d_dither - off/on texture filtering (while it off/on color dithering on original HW to simulate more color depth)

the blue or noisy colors appears at world map geometry in connected surfaces/triangles
see atachments

when noclipping out of map boundaries
in wrapper - hall of mirrors and weapon model view is slowly whitening to solid color
in original HW - everything filled by gray clear color , even weapon is removed to gray too

the highest resolution in game crash game if menu or console invoked.
while underwater resolution can be used safely any resolution.

https://www.youtube.com/user/whitemagicraven
https://go.twitch.tv/whitemagicraventv

Reply 2965 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t

Thanks for the bug report. I was waiting for this a long while!

Raven-05, could you try this to see if the particle problem is fixed? I never noticed it before, but I tried shooting the CRT in slipgate complex and it seems ok now.

[EDIT] The other bug is probably a QSPAN or texturing bug, but most probably QSPAN. How does it run on your system?

[edit2]
Also it seems like vhexen2 is based on the vquake 1 code base.
[/EDIT2]

************************************************************************
RReady Alpha, 07 July 2025
************************************************************************

https://nirvtek.com/downloads/RReady.Alpha.20 … vQuake.Alpha.7z
MD5: 617dcb64b46ee64a2e081ea4e15c29a4
- Possible fix for vQuake particle transparency alpha blending bug.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2967 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t
RaVeN-05 wrote on 2025-07-07, 16:45:

works excellent!

That's a relief. I'll take a look at the other bugs tomorrow.

Is there a cvar to turn model rendering on and off?

Also I think the higher resolution problems with vQuake are pretty much the same as vhexen 2.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2968 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t

This should fix d_dither enabling d_bilerp and d_bilerp hiding models.

https://nirvtek.com/downloads/RReady.Alpha.20 … 8.002.vQuake.7z
MD5: 921c801df8ad5639e035d4b3c61f8f63

The texture seam problem is related to the QSPANs and texture clamping. Still looking at fixing it.

[EDIT] can't fix the qspan bug just yet. Getting my roof fixed over the next couple of days.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2969 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t

Ok, while I have some time. The stay coloured pixels are a scaling artefact. If the Rendition upscaling resolution is set to 1280x960 and vquake's resolution is set to 640x480, the lines disappear. The upscaling resolution needs to be an integer multiple of the game's internal resolution. Turning on "integer scaling" will also help.

I really need to do something about scaling artefacts. ICR2's cockpit dials also have the same problem.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda

Reply 2970 of 2971, by RaVeN-05

User metadata
Rank Oldbie
Rank
Oldbie

d_dither
d_bilerp
all fixed thanks, d_dither is have no valuable now coz everything rendered in 32 bit colors, which is better.
the dynamic lights in quake is painful, slowlyness is probably can be fixed in future by qemu but for now its most lowest priority. )
Thanks)

https://www.youtube.com/user/whitemagicraven
https://go.twitch.tv/whitemagicraventv

Reply 2971 of 2971, by sharangad

User metadata
Rank l33t
Rank
l33t
RaVeN-05 wrote on Yesterday, 10:43:
d_dither d_bilerp all fixed thanks, d_dither is have no valuable now coz everything rendered in 32 bit colors, which is better. […]
Show full quote

d_dither
d_bilerp
all fixed thanks, d_dither is have no valuable now coz everything rendered in 32 bit colors, which is better.
the dynamic lights in quake is painful, slowlyness is probably can be fixed in future by qemu but for now its most lowest priority. )
Thanks)

Thanks for testing all that. The dynamic lights are affected by r_surfacelookup. Try toggling the setting to see if it improves performance. One of those settings is slow with RReady.

QEMU seems to have hit a brick wall. It seems like the older legacy BIOS for QEMU can't be compiled anymore. The latest and greatest version now support EFI I think. I seem to have hit a brick wall there.

Developer of RReady - Rendition Verité Wrapper.
https://www.youtube.com/@sharangadayananda