Probably related to old unexplained d3d blank screen issue, switching modes usually fixes it.. ("Effect" in your screen shot happens because 3d objects are usually made from triangles and for some reason second triangle is missing)

Hur, triangles that just disappear under random circumstances?

Its always something silly you don't think of, so could it in any way be related to the vertex winding order perhaps? I know I've made a triangle or two disappear that way when I was playing around with 3D stuff...

It changed when I resized the window which makes me wonder if its related to the depth buffer when you first setup the 3D viewport. I have had issues with polygons vanishing due to z buffer.

"Unfortunately" nearly everything is static, including vertex buffer and there is only one "3d plane", this can't explain why it happens randomly, unless there is some hidden corruption..

Does http://www.winuae.net/files/b/winuae.zip change anything in D3D problem?

I have only been testing it a little but so far its looking good. There are no display problems to report and it seems to be working ok. :)

EDIT: Forgot to test DirectDraw mode! Display now looks better in WB although the mouse pointer is still missing.

I need a huge brown paper bag now.

Vertex buffer's Z-coordinates were left uninitialized (should have been zeroed).

Apparently allocated vertex buffer contains usually zeros but not always (I'd have expected D3D debug mode to fill it with random values to prevent these kinds of hidden uninitialized variable bugs)

DD mode does not support RTG hardware mouse cursor = mouse disappears if you switch on the fly from D3D to DD.

I wouldn't punch yourself. In my opinion forgetting to clear a buffer is an easier to make and harder to debug 'mistake' than bad pointer handling; its a piece of legacy that programmers using native languages will always have to carry around as a burden.

It may seem silly, but this is a true bastard. No brown paper bag for you mister ;)

The latest WinUAE beta 2.3.3 beta 1 seems to run in 60fps no matter how I change my settings (changing different vsync methods or selecting "PAL").

No, it does not.

My RTG WB seems to run in 60fps and when I try a demo it runs at 60fps aswell (too fast). When downgrading to the latest stable version (2.3.2) the demo runs in 50fps as it should. Perhaps there's a setting in the latest beta I've missed?

It was a hint that "it does not work" is not a bug report and you missed to include something important :)

(logs and config file)

I can not tick the box

Confirmed, it is totally broken if there is no custom vsync config entries added (and partially broken if there is custom entries..)

Just to add to this. It would be nice if custom refresh rates entered in the config file could be edited, applied and saved through the GUI as well when the 'lock' button is ticked. Not necessary, but would help in the "user friendliness" department (I found myself a few times trying to edit, apply and save the custom value, only to find out that doesn't work).

I further noticed that when a custom refresh entry in combination with vsync(new) is used, it doesn't seem to bring the start of display in line with the vertical blank (which the automated does). This means that the user can end up with a horizontal steady tear in (for example) the middle of the screen, when he's using a custom refresh in combination with vsync(new), even if the custom refresh is close to the real refresh (for example when 'locking' an automated refresh value).

There is any 64bit version of WinUAE 2.3.3 beta?

Why? It is still totally useless. (Unless you really need ~1.5G of Z3 RAM..)

Beta 2:

http://www.winuae.net/files/b/winuae_2330b2.zip

- experimental joystick raw input support, enable using -rawhid command line parameter.
- D3D blank screen problem should be really fixed now
- empty winuae.ini now does exact same as -portable command line parameter
- harddrive paths relative to win32.hardfile_path didn't work
- config file full paths are converted to relative if path matches win32.xxx_path entries
- ignore new displaydata vsync stuff if RTG mode is currently in use
- Display panel new vsync refresh rate GUI really works now
- uaescsi.device cd image on the fly switching was unreliable
- uaescsi.device crash when switching images (I could only duplicate it with AROS CDFS)
- AROS ROM updated

Unfortunately this seems to break the displaydata config/"trick"(?) that made it possible in Beta1 to automatically switch between monitors depending on whether native mode (monitor 2 / CRT) or RTG Workbench (monitor 1 / LED 1920x1080) is activated.

Maybe you're thinking of a different implementation for the switching between RTG and native modes for dual monitor setups, but if not then I hope you'll re-enable this above (great!) feature from Beta1.

As a suggestion, possibly you could add a "displaydata_pal_RTG" and a "displaydata_ntsc_RTG", for when matched only a selected set of gfx configs can be used as parameters?

EDIT: apart from the above, the beta seems to work well. I like the option to enable RawInput :)

The new v-sync method seems to be working for me, if I select no v-sync I see lots of screen tearing, but if I select v-sync (new) I see no screen tearing.
I used 'no buffering' and A500 quickstart.
Graphics chip is "Mobile Intel(R) 915GM/GMS,910GML Express Chipset Family" which claims to be running in 50hz mode.
I thought it might be interesting to see results for such an old chipset.

Problem is that switching code does not know if switch is from chipset to RTG or from RTG to chipset (or if it is chipset to chipset = PAL/NTSC mode changed)

This needs some re-design.. (This was also in private version)

EDIT: In other words, it only worked accidentally.