@robertmo3 what's the popup dialog message you get when you start tomb raider?

nascar racing 2 works even on 2 cores
cart racing 2 needs 3 cores now (used to be 2 cores only before)

keyboard is ok now

robertmo3 wrote on 2024-04-29, 06:49:

also tomb raider makes some error popups but works, but if you don't close the popups it works slowly - this is a new feature of latest build

actually you don't have to close them - game works fine

robertmo3 wrote on 2024-04-30, 14:03:

nascar racing 2 works even on 2 cores
cart racing 2 needs 3 cores now (used to be 2 cores only before)

keyboard is ok now

Are the frame rates better with cart racing?

robertmo3 wrote on 2024-04-30, 14:03:

nascar racing 2 works even on 2 cores
cart racing 2 needs 3 cores now (used to be 2 cores only before)

keyboard is ok now

Keyboard problems were a bug.

during the game when i stand in a row of cars not pressing anything it has increased from 17 fps (2024.04.28) to 21 fps (2024.04.30)

robertmo3 wrote on 2024-04-30, 20:32:

during the game when i stand in a row of cars not pressing anything it has increased from 17 fps (2024.04.28) to 21 fps (2024.04.30)

I need to tweak this more. My target is 30 fps for ICR2 with a discrete GPU and a quad core.

sometimes any game starts with slower fps, but pressing alt-tab fixes that

robertmo3 wrote on 2024-05-01, 08:36:

sometimes any game starts with slower fps, but pressing alt-tab fixes that

That's a focus issue. Not entirely sure why that happens. The full screen window should automatically steal focus.

Mem writes are a big problem, they're written one at a time, but need to be processed in chunks for efficiency, but doing it right is a bit of a problem. There's a lot of overhead involved in sending byte mem writes. The address which is 4 bytes has to be sent across, 4 bytes + the actual byte so 5 bytes have to transferred for every byte. Secondly when mem writes stop pending writes have to be written out. A reliable method of detecting when writes have stopped is needed.

This has to work using minimal cpu and very quickly.

The black screen delays are because of mem writes.

so if you developed it normally without those freaky pipes all these problems would magically be gone?

A lot of them. The instability and cpu load would go down . The mem write problem would still be there though. Opengl isn't designed for textures/framebuffers to be updated one byte at a time.

sharangad wrote on 2024-05-03, 05:52:

Opengl isn't designed for textures/framebuffers to be updated one byte at a time.

what about direct3d?

sharangad wrote on 2024-05-03, 05:52:

A lot of them. The instability and cpu load would go down .

you know what, just make it normally. In any case you can always bring pipes back.

robertmo3 wrote on 2024-05-03, 06:14:

sharangad wrote on 2024-05-03, 05:52:

Opengl isn't designed for textures/framebuffers to be updated one byte at a time.

what about direct3d?

It's the same.

The problem is that the this isn't real video memory.

For instance if a single byte's written to the screen, the mem write has to be turned into a texture (or a pixel draw) and drawn to the screen. On an actual Verité the write automatically updates the screen. because you're modifying what's on screen This needs one or more OpenGL commands each of which takes up CPU. It's better to group a bunch of adjacent pixels and draw them together to lower CPU overhead. These commands aren't lightweight in OpenGL and Direct3D. The problem is the frame buffer isn't directly accessible in any modern rendering API, even Vulkan. If you want to draw something to the screen, you can't POKE (1-4 bytes) into VRAM. You have to select the screen as your output destination and draw a pixel (very slow and inefficient) or render a 1x1 texture onto the screen. Neither of these are optimal for 1,2 or 4 byte writes.

RRedline doesn't have this problem. The API recommends calling V_LockBuffer to gain access to video RAM. This waits for queued commands to be completed and returns a memory block to write to. Once writing's done, V_UnlockBuffer's called to turn the Verité on. RReady uses updates the screen at this time before resuming rendering. With RRedline direct memory writes are also possible (if you query the VRAM address), but nobody does that.

Pretty much all the Speedy3D apps I've seen so far use direct mem writes/POKEs to render splash screen's and menus use V_FIFO_MEM_WRITE_SPRITE (another ridiculously slow call). VL_MemWriteSprite is available with RRedline as well, but nothing uses it.

robertmo3 wrote on 2024-05-03, 06:26:

sharangad wrote on 2024-05-03, 05:52:

A lot of them. The instability and cpu load would go down .

you know what, just make it normally. In any case you can always bring pipes back.

I can't legally distribute it if I do that.

I think I've fixed your Tomb Raider "This program has performed an illegal operation" dialog. This is what was keeping it from running on my 2 of my Intel based systems (Sandy Bridge and 8th gen). It already ran in slow mo on my Haswell based HD4000 machine.

Don't know why Sandy/8th gen doesn't render anything with integrated graphics. Need to look at that now.

my integrated graphics works but jerky

robertmo3 wrote on 2024-05-03, 07:02:

my integrated graphics works but jerky

It works on HD4000 but not HD2000 nor the UHD620 (laptop) for me.

I also always get an error on HD2000 much like what I get randomly with my GTX1060/Ryzen 7. I need to sort this error out, the random instability is related to it.

my is HD2500