22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 V_AddToCmdList_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 VL_Triangle_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 V_AddToCmdList_

22:53:33.990 Massaged Callback (Entry)

22:53:33.990 V_IssueCmdBufferAsync_

Eighth time lucky:
https://1drv.ms/u/s!As-dKk-N73dSlkxBDSHrcGuqVrgx?e=KPBQIK
MD5: d28bb4fe007ed81978c2bc01894f49f7

Source:
https://1drv.ms/u/s!As-dKk-N73dSlk01ISYyj5LRkYxo?e=meoyUv
MD5: df5e1eab199fdd5af3f99e1ccb15092f

I think this particular crash should be fixed. A function (GetVertexSize )which returns the byte size of a given vertex type was missing a type which is present in RReady. Because RReady was crashing while adding F1 support, I added support for the type. v2k.RReady didn't get the update. The function would've returned a vertex size of 0 which probably crashed the verite driver.

seems all the same visually

RaVeN-05 wrote on 2023-10-19, 16:02:

seems all the same visually

Corrects bug /in VL_Triangle_
https://1drv.ms/u/s!As-dKk-N73dSlk432mypEyDqIUcy?e=vmDumX
MD5: 8787541c7633b28887410bfb112dc307

1Source changes:
2__declspec(naked) __declspec(dllexport) vl_error VL_Triangle_()
3{
4	__asm {
5		/*push    ebx;
6		push    ecx;
7		push    esi;
8		push    edi;*/
9		pushad;
10	}
11
12	//v_u32 EBP;
13	__asm {
14		/*mov v_type, edx;
15		mov v1, ebx;
16		mov cmdbuffer, eax;
17
18		mov eax, esp
19		mov ebx, [eax + 20];
20		mov v3, ebx;*/
21		//pop refresh_rate;
22		mov v_type, edx;
23		mov v1, ebx;
24		mov cmdbuffer, eax;
25		mov v2, ecx;
26
27		mov eax, esp;
28		mov ebx, [eax + 36];
29		//mov ebx, [eax + 28];
30		//mov ebx, [eax + 20];
31		mov v3, ebx;
32
33
34
35	}
36
37	//v2 = v1 + (GetVertexSize(v_type)>>2);
38...

Intel vTune profiler runs correctly with Formula 1/RReady now.

v2 now comes from register ecx instead of this: v2 = v1 + (GetVertexSize(v_type)>>2); I misinterpreted the F1 disassembly.

I tested 10-20-001, I didn't test the previous ones since my previous post. It changes resolution but appart from that it seems to be the same as before.

I did several tests just in case. In one test I switched off the computer during the starting grid with the checkered flag, if it helps seeing differences with other logs where I let the game hang on a black screen. Other tests are in 640, in 32 bit mode, and using the cyrix patch.

I'm not really sure it crashes on the black screen. There's no way to alt tab, or ctrl alt del, or press the windows key or anything that would change the focus of the game window, even in the game menu. Maybe it's just a hang and not a crash.

chuky wrote on 2023-10-19, 19:54:

I tested 10-20-001, I didn't test the previous ones since my previous post. It changes resolution but appart from that it seems to be the same as before.

I did several tests just in case. In one test I switched off the computer during the starting grid with the checkered flag, if it helps seeing differences with other logs where I let the game hang on a black screen. Other tests are in 640, in 32 bit mode, and using the cyrix patch.

I'm not really sure it crashes on the black screen. There's no way to alt tab, or ctrl alt del, or press the windows key or anything that would change the focus of the game window, even in the game menu. Maybe it's just a hang and not a crash.

Try a build without any logging to see if it crashes. While adding F1 support to RReady I had quite a few issues with logging:
https://1drv.ms/u/s!As-dKk-N73dSlk8_i-2irqz4mL8Q?e=kAtDgl
MD5: 92dac21644bad70026753fec5a20954a

Source:
https://1drv.ms/u/s!As-dKk-N73dSllCh3cIcj-ZhEpW-?e=ImJdAi
MD5: 989f620dd1764bc43de995456c22cfad

Chuky, your checkered flag log files folder (... 1024 checkered flag) is empty.

The new build 10-20-002 still creates an empty V2k.RReady.Verite.txt log. The game runs faster but it hangs/crashes, it's the same as before.

I did a few other tests with the previous version 10-20-001.
- In the first test I managed to press alt-enter during the checkered flag scene. No idea why it worked because the other times I tried it didn't work. The game minimized in the Windows bar at the bottom, the game wasn't windowed. The game didn't seem to act like I pressed enter, even though you press enter when pressing alt-enter. I kept the logs and then I killed the program with the task manager.
- In the second test I pressed enter in the checkered flag, waited for the black screen and I switched the computer off. I had problems turning it back on, I had to do it 3 times, I don't know what happened. When I came back to Windows I was in 16 colors and 640*480. It wasn't fail safe mode, it was just the wrong mode. The display options in windows still said the name of my graphics card. I rebooted the computer to see if it would stay and then it was again in 16 colors 640*480. I put 1024 16 bits and rebooted the computer and then it was fine. The wierd thing is logs are really small compared to the other logs, while I went to the same point. edit: nevermid, logs are not small actually.
- The last test is just switching off the computer once the game hangs/crashes and is not responsive.

edit: I checked again and the log with the problem are not small. It's wierd, WinME said 6 kb and I could open it with the notepad, while the file is almost 2 Mb.

Another attempt (Fixes serious bug where already issued cmdbuffer may have been added to while already processing in VL_SetFogEnable_):

https://1drv.ms/u/s!As-dKk-N73dSllG7DQqkLcaroVJX?e=BrcDUc
MD5: 78b017c418fb7abfbc1d8ee330309c02

Source: https://1drv.ms/u/s!As-dKk-N73dSllK1BV44WdcbuDhy?e=6Gdq9u
MD5: 1d88f3e76e3f889bcf1c9b37760fc566

RReady's unaffected because it guards against this, but commands may be lost or ignored. This fix has been backported to RReady.

It's still the same with this one.
I wonder, does the microcode uc file have anything to do with the issue ? Maybe using the original microcode from their custom driver could help ? Or would it help if someone with a V1000 tried your wrapper ? I can't help with that unfortunately.

chuky wrote on 2023-10-20, 00:22:

It's still the same with this one.
I wonder, does the microcode uc file have anything to do with the issue ? Maybe using the original microcode from their custom driver could help ? Or would it help if someone with a V1000 tried your wrapper ? I can't help with that unfortunately.

RReady ignores the microcode file and runs just fine by redirecting the calls to the vanilla functions. The microcode file is designed to correct bugs in the driver level firmware. The space for storing microcode on the Verité is also limited and can't be used to reimplement an entire api.

This is crashing because of bugs in my assembly code.

chuky wrote on 2023-10-20, 00:22:

It's still the same with this one.
I wonder, does the microcode uc file have anything to do with the issue ? Maybe using the original microcode from their custom driver could help ? Or would it help if someone with a V1000 tried your wrapper ? I can't help with that unfortunately.

You could very well be right. I just messed around with RReady and it actually has a separate texture select path for RRedline 1.0. I just assumed it would work with an actual Verité board. The improved texture select kicks as soon as you start race. When I have some free time I'll take another look at this.

One more with cmdbuffer id logging (OR it may spectacularly crash):

https://1drv.ms/u/s!As-dKk-N73dSlnnM_HTNjV566uqM?e=lXmP2x
MD5: e598dc78c4a7758c27fa8bc8762437c7

Here's the log, it's big but it doesn't look like it logged any id. Menuing and the prerace screen were extremely slow though.

Thanks chuky. If you look for the text massaged callback, the command buffer ids are there (on entry and exit). Between two massaged callbacks there's a V_IssueCmdBufferAsync, so the buffer ids appear to be ok. The other thing is there's less stuff in the command buffer now. It issues faster.

One weird thing is towards the end there're multiple VL_InstallTextureMap commands with out any rendering commands. It's just selecting textures and not doing anything which seems kind of pointless.

I'm still convinced it's a bug in my wrapper.

From the menu, if you go to options and then credits does it crash?

It doesn't crash when I go to the credits. I waited a bit after it changed texture from the Bizarre Creations logo to the Psygnosis logo and then I went back to the menu and I quit. It looked fine, I guess. When the Bizarre Creations logo faded out, a few times, for 1 frame it looked like 1 tile of the texture didn't have the same lighting or darkness as the rest, but the other frames were fine. I don't know if it's an issue or not.

I've reviewed the code, possibly introduced new bugs (hopefully not). See whether the lockup is still there:

https://1drv.ms/u/s!As-dKk-N73dSlnsMo-Zu9Ad0nTvO
MD5: 3bdb604f2db89c1e472123372db319ed

It still hangs in quick race mode. Credits work, there's the same thing during in the credits the texture change where sometimes some polygons are darker for 1 frame.
Here's the log when it hangs.

https://1drv.ms/u/s!As-dKk-N73dSlnwTLGYZxuntdgPh?e=RPy1zN
MD5: 21a9b6fdf6544a792639184d2dcc152e

I've ported across one paletted texture change from RReady into this. It's not a straight wrapper for VL_SetSrcStride_. RReady used to crash after this as well starting a quick race.

I don't know whether anything will work with this build. It could lead to a horribly corrupted mess.

[EDIT] I don't know whether this is problem, but I'm fairly sure it relates to paletted texture support. Quick Race and Demos use it.[/EDIT]

going to blackscreen and hangs before starting race

It seems to be the same. Credits work.