RaVeN-05 wrote on 2025-07-31, 06:30:

almost perfectly Rabel Moon rendered.
Some very little noticeable minor graphical glitches left.

Thanks @Raven-05, will fix them.

RaVeN-05 wrote on 2025-07-31, 06:30:

almost perfectly Rabel Moon rendered.
Some very little noticeable minor graphical glitches left.

Bugs 003 happens on original hardware and it looks to be an z-buffering bug or lack of. I would post a video, but my capture dongle doesn't go any lower than 640x480 .

And the final one. Sorry about these being JPEGs. I attached them to the post instead of linking against my server.

The other two will be fixed.

Rebel Moon Fixes (hopefully final):

https://nirvtek.com/downloads/RReady.Alpha.20 … 01.RebelMoon.7z
MD5: 2632214aa3080804262a57d459aa4997

- This *should* correct all outstanding Rebel Moon chroma keying bugs and perhaps not introduce new ones.
- There is a problem with the keyboard input sometimes not responding in the dosbox window after existing a Speedy3D game. Pressing [ALT] fixes this. This will be fixed .

[EDIT]Attaching PNG images to the forums produces cel-shaded low bitrate attachments. So here are links instead. So here are JPGs/[/EDIT]
[EDIT]At some point I should put up a video on how this was fixed[/EDIT]

And the last two:

Great news! Ghidra 10.2.2 can open .CGL file as OMF. The 3DBlaster PCI drivers (VRITB170) appear to use FIFO mode direct port output.

A brief overview of how the Rebel Moon bugs were fixed using screen space derivatives is available here:
https://www.patreon.com/posts/overview-of-moo … ntent=join_link
and
https://youtu.be/vH-zlu9VKT0

ICR2: I've increased the base memory used by the game to its limit of 64 MB. The texture heap is a separate 256 MB. I think there's still some sort of internal partitioning going on, which stops the extra memory from being used.

By restricting Dosbox's RAM to 16 MB I got this:

1V:\CR>cart
2DOS/32A -- Protected Mode Run-time Version 7.35
3Copyright (C) Supernar Systems, Ltd. 1996-2005
4Sierra On-Line, Inc.
5Version 1.0.2-RN1 Build #61
6DMA Memory fragmentation:
7Pointer buf :
8Command buf :
9Digital Sound
10Port 220 IRQ 7 DMA 1
11Conf irmed with SB16 8 ST
12Memory Check: 584000 LO 13602800 HI 14186800 ALL
13Insufficient memory. Free up 69013168 bytes, and try again
14
15V:\CR>mem
16
17632 Kb free conventional memory
1863 Kb free upper memory in 1 blocks (largest UMB 63 Kb)
1914912 Kb free extended memory
2014912 Kb free expanded memory

This is with a 256 MB texture heap. It's complaining about the *other* memory (other than the texture heap).
69013168 = 69 MB. This version of the game needs 256 MB alone for the heap, so this has to mean it's complaining about everything else. Usually the entire game needs just 16 MB, with 6 MB for the texture heap and 10 MB for the rest. I *think* if I can unpartition the thing to use mroe RAM, textures would just work.

https://nirvtek.com/downloads/ICR2.64MB.OtherMemory.001.7z
MD5: 4ed3bc2eb1973c8809031bf9c3e7aae8
(This link is fairly useless, since the game behaves exactly the same, but I need it preserved in case of catastrophic hard drive and backup failures).

Australia Tracks are Rendition Ready
https://youtu.be/-RTtGFGoxFE

tested Rebel Moon, its perfect now! =)

RaVeN-05 wrote on 2025-08-02, 16:15:

tested Rebel Moon, its perfect now! =)

Thank you kindly! RReady Rebel Moon has passed the Raven-05 test!

RaVeN-05 wrote on 2025-08-02, 16:15:

tested Rebel Moon, its perfect now! =)

Thanks a lot for all the testing!

I have another build:
https://nirvtek.com/downloads/RReady.Alpha.20250802.004.7z
MD5: c32b89f0ac8c80bad0708b90b031ef6b

which should allow vquake to run on your laptop (dual core).

You'll need to set
threadsafe=false
highperformance=true
picdma=true
override2core=false

ICR2 should be full speed again. I don't know if the games will be stable without major lockups. I've been spending some each day trying to reduce the cpu load of the whole process. Custom carsets in ICR2 probably won't be possible. This will force a bunch of settings if you the CPU has fewer than 3 cores. Enforced thread prioritization has been disabled. So the possibility of hiccups and slowdowns even on quad or better systems is higher, even when dual core settings aren't enforced.

[EDIT] On some systems (Haswell Pentium 3 GHz Intel HD graphics) threadsafe=true, picdma=false, highperformance=-true and override2core=true works really well for ICR2, but not vquake. On my Ryzen 2700X in dual core mode the Haswell settings are terrible. It works much better with the first bunch of settings under the download link.

This is looking like the next release candidate:
https://nirvtek.com/downloads/RReady.Alpha.20250802.004.7z
MD5: c32b89f0ac8c80bad0708b90b031ef6b
- vQuake cvars d_dither and d_bilerp should work correctly
- Rebel Moon all chroma keying bugs should be fixed.
- ICR2 [ALT+B] (autobrake) should function correctly.
- Formula 1 RRedline performance boost (including for everything using paletted textures).
- Improved dual core performance in a default config. (Needs more testing). The minimum required GPU (Intel HD4000) should perform better on the minimum CPU dual core 3 GHz (Haswell).

I think it's better to do incremental updates instead of massive ones with lots of fixes. It's a lot easier to test and isolate problems.

[EDIT]
Or with the same optimization extended to quad cores and beyond:
https://nirvtek.com/downloads/RReady.Alpha.20250803.001.7z
MD5: 031f0bd95305993dc4cd34cd97218f09

I really need to rebuild my Sandy Bridge HD2000 based machine. Motherboards are available, but i don't know whether the CPU still works. The i7 2600 still sells for quite a bit.
[/EDIT]

[EDIT2]
Detroit Belle Isle (2004-1995, 2/4 of these are regurgitated), Detroit Downtown HQ (new) and Houston:
https://youtu.be/yOmgm3wNZXk
[/EDIT2]

My day job is figuring out ICR2, but I spend an hour each night working on CGL:

This appears to be the entry point for cglInitScreen in the source:

1*************************************************************
2*                           FUNCTION                         
3*************************************************************
4undefined  FUN_000160f5 (undefined  param_1 ,  undefined  pa
5undefined         AL:1           <RETURN>
6undefined         AL:1           param_1
7undefined         DL:1           param_2
8undefined         CL:1           param_3
9undefined4        Stack[0x4]:4   param_4                                 XREF[1]:     000160f9 (R)   
10                             FUN_000160f5
11        000160f5 53              PUSH       EBX
12        000160f6 56              PUSH       ESI
13        000160f7 57              PUSH       EDI
14        000160f8 55              PUSH       EBP
15        000160f9 8b  74  24       MOV        ESI ,dword ptr [ESP  + param_4 ]
16                 14
17        000160fd 31  db           XOR        EBX ,EBX
18        000160ff 66  89  f3       MOV        BX ,SI
19        00016102 89  d8           MOV        param_1 ,EBX
20        00016104 e8  6c  fb       CALL       FUN_00015c75                                     undefined FUN_00015c75()
21                 ff  ff
22        00016109 66  85  c0       TEST       param_1 ,param_1
23        0001610c 0f  85  bd       JNZ        LAB_000161cf
24                 00  00  00
25        00016112 e8  7e  1e       CALL       FUN_00017f95                                     undefined FUN_00017f95()
26                 00  00
27        00016117 a3  44  5f       MOV        [DAT_00025f44 ],param_1
28                 02  00
29        0001611c 85  c0           TEST       param_1 ,param_1
30        0001611e 75  0a           JNZ        LAB_0001612a
31        00016120 b8  03  80       MOV        param_1 => DAT_00008003 ,DAT_00008003              = 14h
32                 00  00
33        00016125 5d              POP        EBP
34        00016126 5f              POP        EDI
35        00016127 5e              POP        ESI
36        00016128 5b              POP        EBX
37        00016129 c3              RET

This is my hacked version which output a constant to a port. It doesn't work. It return 0x8003 and skips the RETurn instruction completely. Assembler gurus, what gives? Is it entering the function with an offset and not at the entry point?

1*************************************************************
2                             *                           FUNCTION                         
3*************************************************************
4                             undefined  FUN_000160f5 (undefined  param_1 ,  undefined  pa
5             undefined         AL:1           <RETURN>
6             undefined         AL:1           param_1
7             undefined         DL:1           param_2
8             undefined         CL:1           param_3
9             undefined4        Stack[0x4]:4   param_4
10                             FUN_000160f5
11        000160f5 50              PUSH       param_1
12        000160f6 b8  12  16       MOV        param_1 ,0x1612
13                 00  00
14        000160fb 67  52           PUSH       param_2
15        000160fd ba  00  c8       MOV        param_2 ,0xc800
16                 00  00
17        00016102 ef              OUT        param_2 ,param_1
18        00016103 5a              POP        param_2
19        00016104 58              POP        param_1
20        00016105 c3              RET
21        00016106 fb              ??         FBh
22        00016107 ff              ??         FFh
23        00016108 ff              ??         FFh
24        00016109 66  85  c0       TEST       param_1 ,param_1
25        0001610c 0f  85  bd       JNZ        LAB_000161cf
26                 00  00  00
27        00016112 e8  7e  1e       CALL       FUN_00017f95                                     undefined FUN_00017f95()
28                 00  00
29        00016117 a3  44  5f       MOV        [DAT_00025f44 ],param_1
30                 02  00
31        0001611c 85  c0           TEST       param_1 ,param_1
32        0001611e 75  0a           JNZ        LAB_0001612a
33        00016120 b8  03  80       MOV        param_1 => DAT_00008003 ,0x8003                    = 14h
34                 00  00
35        00016125 5d              POP        EBP
36        00016126 5f              POP        EDI
37        00016127 5e              POP        ESI
38        00016128 5b              POP        EBX
39        00016129 c3              RET

With Furan's 3DBInfo tool:

1V:\DOS\3DBINFO>dos4gw 3dbinfo
2DOS/4GW Protected Mode Run-time Version 1.97
3Copyright (c) Rational Systems, Inc. 1990-1994
43D Blaster Info 0.1 by Ian Hanschen
5Attempting driver load (fixed)
6cg 1QueryScreen
7Error: -32765 (FFFF8003)

[EDIT] Oh, I see the problem. It's not returning 0x8003. It's returning DAT_8003.

Tested Indy Car Racing II.
The ALT+W (Change weather) seems works slowly not all the times, like ALT+B before fix. Feels need to be fixed.

The only font buggy when activating ALT+R (show FPS) and ALT+X (test mode) look screenshot

A test video of polygon transparency in ICR2 is here: https://youtu.be/5w6vc8wVuu8

This is experimental, but *could* be used for future carsets and tracks.

RaVeN-05 wrote on 2025-08-06, 12:13:

Tested Indy Car Racing II.
The ALT+W (Change weather) seems works slowly not all the times, like ALT+B before fix. Feels need to be fixed.

This is the case even on original hardware. The readme file actually mentions that [ALT+W] might respond slowly.

RaVeN-05 wrote on 2025-08-06, 12:13:

The only font buggy when activating ALT+R (show FPS) and ALT+X (test mode) look screenshot

This is a bug and will be fixed. It's a bit of a low priority bug. The text and black background is missing in some frames.

Also could you test ICR2 and vQuake on your dual core laptop? vquake should actually run now. ICR2 should be stable as well.

The latest Alpha:
https://nirvtek.com/downloads/RReady.Alpha.20 … R2Chroma.001.7z
MD5: 36de8eb91b96452d7379c36be0f69a6c
- This release should allow software rendered DOS ICR2 to run in dosboxes-rendition and staging-rendition.
- Keyboard performance tweaks
- preliminary support for polygon texture transparency. To enable it for supported track (currently there is none) add the following to rendition.cfg:
noicr2transparency=0

RaVeN-05 wrote on 2025-08-06, 12:13:

The only font buggy when activating ALT+R (show FPS) and ALT+X (test mode) look screenshot

The byte ordering is wrong here. I think this is a direct mem write to the framebuffer. Also I think it doesn't target the third framebuffer. This game and the Nascar 99 use forced triple buffer which is simulated by RReady since it doesn't directly translate to OpenGL's triple buffering. There're reads from the third buffer in sequence. Will look at it later tonight.

ok will test, thanks