Here's mine if you need it. Dunno how much varies between the two models.

Thanks. Neither yours nor Raven-05's boards can query native modes (mode numbers below 0x100). Most games use mode 0x7f, which appears to be 640x480 3D.

https://web.archive.org/web/20240330065214/ht … 191/config.html
https://web.archive.org/web/20200229213234/ht … /Fortress/6191/
https://web.archive.org/web/20000815235453/ht … om/console.html
https://web.archive.org/web/20061031104841/ht … ke/console.html

Thanks @robertmo! As soon as I get vquake running, which won't be anytime soon, I'll check it out.

There's some strange behaviour with the DMA registers with vquake. It exits with a "microcode returned an error."

quake allows using console parameters in a config file so that the game may start with lots of things turned off.
this may help make quake running before you make it running with all the things turned on

also maybe other games are easier to run
quake may be a heavily optimized game using lots of direct hardware access hacks hence the hardest verite game to make running.

i think you haven't tried all games yet, maybe one of them gives some hints.
i think it may be worth to check them all before quake

I don't have all the games at the moment, just cart racing/icr2, quake, splanet, nascar and tr1. Tr1, the last time I tried it killed dosbox in rendition mode. Haven't tried in a while. With ICR2 I can either get the sky textures working or the cars/tracks. There's some problem with the texture addresses.

I'll try again. Out of time for today.

And in rr. Exe, the rendition ready logo app, I have no way of getting the app to slowdown. It ends before all the frames have been rendered, unless vsync is turned off.

Vquake has issues with reading and writing a bunch of registers. This isn't my biggest priority at the moment. icr2 and rr are.

Vquake has an undocumented api call that's not used in the second game. Even if everything else worked properly it could take me a while to figure out v_fifo_qlight., possibly months. So I'd rather not deal with it right now. The other games are less strenuous, so probably easier to deal with at this stage. Two other quake calls v_fifo_qspan and v_fifizqzaazedge work for vquake 2. The entry point for qlight exists, but is completely unknown at the mo.

and found for hexen2 it works coz setting value to 0 decreases performance for few fps by timedemo.

https://fte.triptohell.info/wiki/index.php/D_subdiv16

d_subdiv16 "0" - best graphic option, less fps
d_subdiv16 "1" - default value , more fps

visually can't spot difference .

v_idlescale 1 - makes player simulate breathing.

_vid_wait_override and vid_wait is vertical sync settings - doesnot work with RReady, since its forces /unforces vsync by their own method.

Excellent! More Raven-05 tweaks!

More progress with ICR2/Speedy3D, nearly all textures render correctly:

https://youtu.be/BUEF3r0RoQQ

The helmet textures have a wrong linebytes value and the performance seems to have suffered.

To get DMA mode working properly I'll need to knock up a test for an actual board. Will attempt it in a bit.

the white 1, 2, 3 signs textures i think have same problem as helmets

this one should be nuber 3

it looks to be rendered as a 2d element, so may have something to do with wrong aspect ratio (320x200 instead of 320x240)

Maybe. But it could also be because of the pixel format. Different formats need different byteswap/endian treatment.

Not all textures are rgb 565. Some are rgba5551, others could be 8 (4 bits per pel) bit paletted format. The main thing is the pixel size.

It's most probably the stride, the number of bytes per row in the texture. This can be greater than the pixel size times the horizontal resolution. If this is wrong, the rows end up being displaced.

sharangad wrote on 2024-03-30, 20:02:

the performance seems to have suffered.

It looks performance is worse only cause of rendering in 4k.
at the end of your video, when we see the game in the small window, it looks same fast as before.

What's your GPU and CPU?

Gtx1060, ryzen 7, 2700x.

The poor performance is because of edge aa. It captures a copy of the screen multiple times. Draw poly's, edge aa, draw some more, edge as,.....

That's the problem. It has to recapture the screen multiple times because the previous capture's out of date.

Quake 2/vhexen 2 captures the screen only once per frame, as a post processing step.

What I can do is capture the edge aa coords during the run and render them as a post process effect.z obscured polys will be aa though, but it will be a lot faster. Alternatively I can capture a subset of the image, which should be a lot faster.

There will be a performance optimisation pass later on.

I tried making it hit 60 fps, which it does. Less than a second later I get a V_FIFO_SYNC_AND_RESPOND command from the app followed by a bunch of garbage.

V_FIFO_SYNC_AND_RESPOND is defined in the redline fifo header. What I'm supposed to do with it is a bit of a mystery. It may be possible to simulate initial slowdown by blocking the DMA transfers for a while and then hitting full speed. It does work for toggling full screen. Starting up at full res with a slow rate and then toggling to full screen produces a full speed windowed mode near 60 fps. But starting up in full screen with a full frame rate is a no no as is starting up windowed full speed. Starting up full screen at a low rate and then toggling seems to work. Or I get a the dreaded sync command.

[EDIT] Nope. Even with the delayed windowed toggle, it locks up after a little while. Either Dosbox-Rendition+RReady OR the app can't handle the framerate.

Fixed the helmet and number signs. It was as you said resolution related, but not the actual resolution, but the stride, bytes per line. it was being halved twice instead of just once.

The splash screen has issue. Actually I'm having issues syncing mem writes and isolating buffer writes. ICR 2 is the first game I've seen write to all 3 display buffers and the z-buffer with a single mem write. RRead was designed to handle a single buffer at a go. Will try a few more games later today.

RReady doesn't directly handle triple buffering, leaving that to OpenGL. I don't even know if this app triple buffers, it was just a guess based on the rendering output (V_FIFO_DISPLAY being set to 3 different buffers).

I've also managed to coalesce the individual mem writes into a block transfers which makes the game start up a lot faster. But this mean I have to deal mem writes straddling buffers.

Also stabilised the frame rate at between 21-24 fps. Really need to figure out how to handle V_FIFO_SYNC. Not enough hours in the day unfortunately.

I can post a video, if anyone's interested. I'm sure everyone's tired of seeing the same ICR2 footage.

Wonder what kind of framerate ICR2 get with physical hardware.