WinUAE 2.3.3 beta series

[Toni Wilen]

Originally Posted by Steve

EDIT: Right, the first bug seems to have gone?? All I did was change to full-windowed mode and back again and the problem hasn't come back. What the hell?

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)

[gimbal]

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...

[Steve]

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.

[Toni Wilen]

Originally Posted by gimbal

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...

"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?

[Steve]

Originally Posted by Toni Wilen

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.

[Toni Wilen]

Originally Posted by Steve

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.

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)

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

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

[gimbal]

Originally Posted by Toni Wilen

I need a huge brown paper bag now.

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

[oRBIT]

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").

[Toni Wilen]

Originally Posted by oRBIT

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.

[oRBIT]

Originally Posted by Toni Wilen

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?

[Toni Wilen]

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)

[freddy]

I can not tick the box

[Toni Wilen]

Originally Posted by freddy

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..)

[Dr.Venom]

Originally Posted by Toni Wilen

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).

[MazinKaesar]

There is any 64bit version of WinUAE 2.3.3 beta?

[Toni Wilen]

Originally Posted by MazinKaesar

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..)

[Toni Wilen]

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

[Dr.Venom]

Originally Posted by Toni Wilen

Beta 2:
- ignore new displaydata vsync stuff if RTG mode is currently in use

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.

displaydata=49.917971,t=LOF,pal,nlace,lof,gfx_width_fullscreen=742,gfx_height_fullscreen=287,gfx_display=2 <-- When native mode is opened switch to monitor 2
displaydata_pal=50.000000,pal,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_display=1 <-- When RTG screen is opened switch to monitor 1
displaydata_ntsc=60.000000,ntsc,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_display=1 <-- When RTG screen is opened switch to monitor 1

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

[rare_j]

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.

[Toni Wilen]

Originally Posted by Dr.Venom

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.

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.