OK the stride is in words.

Formula 1 resize paletted textures and the stride doesn't match.

At one point in the logs a 128x256 byte surface is loaded with a 256x256 texture. This should be illegal since the buffer is too small. The dma transfer probably goes wrong.

My fix in VL_Installtexture won't do anything.

I think this is the problem.

Need to think about this.

Need to figure out how to deal with this.

Regular RReady handles the switch. I can try disassembling the F1 dlls.

https://1drv.ms/u/s!As-dKk-N73dSl2IMo-Zu9Ad0nTvO
MD5: 946cc44874eef3d1201f585bc019cca7

This should shrink the number of bytes passed to VL_LoadBuffer. If this runs there'll be funk textures in the fully 3D sections.

Failing everything I could disable paletted textures altogether to see if it runs.

[EDIT] And there's more logging now.

done. Visually nothing changed, feels slower, yes

Last one for today:

https://1drv.ms/u/s!As-dKk-N73dSl2QMo-Zu9Ad0nTvO
MD5: 485f7ff12cd3e6a2f0d9b43a2d9ed957

If you leave it running does the log file get bigger and bigger?

I'll also need the time it froze., so I can check the logs.

when it froze its immediately stop writing to logs.
Details? How i can count time? Sorry for silly being here)

No, local time when it froze. If your machine's clock's set right I can correlate.

8:09 game started
8:32 starts to fade out to load demo
8:36 loading screen
8:36 a little bit later hangs , no respond , no message writtings to log

Thanks!

https://1drv.ms/u/s!As-dKk-N73dSl2UMo-Zu9Ad0nTvO
MD5: ebea8ab167797d04234ceefaca134ac6

Bit more logging and some changes. V_ResetCmdBuffer isn't called in the callback. It's entirely possible this will crash even sooner.

Also found a bug in my logging code. A thread safe lock in verite.dll was being entered twice and exited once. This shouldn't have any effect, except that the lock keeps a count and it could very well overflow causing issues. I don't know whether it does.

The log file you posted here:
02:45:41.120 Massaged Callback (Entry)
02:45:41.120 MassagedCallback buffer entry cmdbuffer id 4
02:45:41.120 V_IssueCmdBufferAsync_
02:45:41.120 VL_IssueCmdBufferAync_ buffer id 4
02:45:41.120 V_ResetCmdBuffer
02:45:41.120 MassagedCallback on exit cmdbuffer id 5
02:45:41.180 Massaged Callback (Entry)
02:45:41.180 MassagedCallback buffer entry cmdbuffer id 5
02:45:41.180 V_IssueCmdBufferAsync_
02:45:41.180 VL_IssueCmdBufferAync_ buffer id 5
02:45:41.180 V_ResetCmdBuffer
02:45:41.180 MassagedCallback on exit cmdbuffer id 6
02:45:41.180 Massaged Callback (Entry)
02:45:41.180 MassagedCallback buffer entry cmdbuffer id 6
02:45:41.180 V_IssueCmdBufferAsync_
02:45:41.180 VL_IssueCmdBufferAync_ buffer id 6

is very strange. When commands are added through V_AddToCmdList there's a user supplied spill over function for issuing the buffer and getting a fresh one.

In the logs the spillover's called multiple times without any intermediate function call. The game's main thread calls V_AddToCmdList and if the buffer's full, spiller which get a fresh buffer and V_AddToCmdList continues with the new buffer. So this is pretty weird and suggests I've messed up a variable name somewhere.

starting game leads to black screen instantly. the mouse cursor on top movable but cant use task manager

https://1drv.ms/u/s!As-dKk-N73dSl2YMo-Zu9Ad0nTvO
MD5: 698fa9a3662e1ba3255cf39e87366538

I think with this this wrapper can take a break, for a while.

all going same way

Ok this should get you to the menu (mis-balanced stack pop):

https://1drv.ms/u/s!As-dKk-N73dSl2cMo-Zu9Ad0nTvO
MD5: db2a65af1c0b6e3f74b6872293ace219

Logs please.

done

And the last one for today. I disabled logging for V_QueryCmdBuffer while getting the menus to go. Now that they appear to be working:

https://1drv.ms/u/s!As-dKk-N73dSl2gMo-Zu9Ad0nTvO
MD5: e2ea5eb9bd3ddf9ce9cec0aef482224a

Now we should be able to see if it's stuck in an infinite loop querying the command buffer due to a stall.

done.
Other note: music that starts during race do not loops, plays once. but race and sounds not occur , black screen.
this loops:
"17:55:10.590 V_QueryCmdBuffer_ id 0 returned 503"

503 means the buffer is free. (V_CMDBUFFER_AVAIL).

So why it isn't sending more commands is the question.

Need to check the disassembley for V_QueryCndBuffer. It should be in the callback function. This is a job for tomorrow.

The logging in the previous version was borked (previous versions were fine). All command buffer ids were being returned as 0. This should fix the problem.
503 is V_CMDBUFFER_INUSE

https://1drv.ms/u/s!As-dKk-N73dSl2kMo-Zu9Ad0nTvO
MD5: 0a64e242ee523b13993d3bd2aec07182

1#define V_CMDBUFFER_INUSE               503
2#define V_CMDBUFFER_AVAIL               504

So in the previous log one of the command buffers wasn't terminating.

If I can isolate the command buffer that never finishes, I should be able work out which command is causing the lock up.

done