Different issues with X5000 and modern cards (Radeon_SI and NovaBridge)

[kas1e]

Tested today rewarp/rewarp3dppc from aminet on my x5000, and when run Sulaco or ByNight by Encore they all runs (with sound and stuff), but they runs veeeryy slow. I attach serial cable, and find out that probably slowing things down happens because of massive serial output, which looks like this:

[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040
[vaa_InstFaultHandler] pCur->VMA.Flags = 0x00000040

Then when something on screen starts, it those addresses sometime changes.

If there is time and interest to deal with, i can help with all the tests.

Thanks

[DvdBoon]

I missed this one. @kas1e Do you use a debug kernel or something?

[kas1e]

Hi, need to re-check again. Hope tomorrow.

[kas1e]

Ok rechecked on latest update2 + release kernel (non debug one) on my X5000 with the latest builds of rewarp and rewarp3dppc. Just reboot, Dbl-click on the icon to run Sulaco:

1). At first, I have a lot of black screens. Only fonts can be visible. 2). When some of the first effects show ups (through, not fully visibly) things start to be very slow in rendering.

In the Serial I have a gazillion of:

W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported W3D_SI.library (0): W3DHW_DrawTriangleV unsupported

Do not remember if there were some hack/patch for it?

If we check console output, then:

part1: 30.68 FPS (because almost all were black screen, only fonts visibly) part2: 49.60 FPS (because almost all were black screen, only fonts visibly) part3: 2.18 FPS (yes, just 2 fps. There we have something visibly, while broken, but something, and it runs VERY slow). part4: 6.06 FPS (yeah, also very slow, also something was visible)

And so on. I.e. where black screen we have more or less ok FPS (still not fast enough of course), but where something renders, it then goes to the crawl mode.

I tried also the By_Night demo, and this one brings the same results.

I checked ReWarp3DPPC sources, and find out in the file warp3dppc_68k.c this part:

ULONG stub_DrawTriangleV(W3D_Context * context, W3D_TriangleV * triangle)
{
    ULONG result;
    result = W3D_DrawTriangleV(context, triangle);
    return (result);
}

So, as it seems this W3D_DrawTriangleV() is not implemented on Warp3D SI for RadeonHD cards, maybe we can add a patch there? Just like replace in on W3D_DrawTriFanV/W3D_DrawTriStripV combos, etc? Maybe once that cure, slowdowns will go, and things will render correctly too?

Maybe that output I have shown before was indeed on debug-kernel, but IMHO we firstly need to deal with DrawTriangleV, and then check how speed/rendering will be and can go further from there.

[rkujawa]

Perhaps @ksdhans could provide some input here? It would probably be most reasonable to add the missing function to W3D_SI.library, instead of trying to patch it. However, I don't know if implementation of this function is feasible (I guess it was left out unimplemented for a reason).

From architectural perspective, it would be desireable to keep the ReWarp3DPPC wrapper as thin as possible.

[DvdBoon]

I see. ReWarpPPC was intended for 'old' Warp3D (so up to version 5) and as far as I have tested only works for Avenger, Napalm, R100 and R200 cards. So the "classic" cards.

There is not much that I can do about that. It is just a wrapper to warp3d.library.

[kas1e]

I also tried WipeOut, it also didn't' works as expected. It runs, but bring after intro black screen and all kinds of issues (through nothing about missing functions on serial).

I fear that it not only about supported/non-supported cards. At least, the warp3d si driver for RadeonHD is proving to work with warp3d apps (at least all minigl apps works, few pure warp3d apps works), and that all just warp3d.library, the same one. But all the old prods, such as demos and games like wipeout probably need patching to works on modern cards. And that probably needs to be done in warp3d driver, which, probably, no one will do, as it too low priority now.

I may try later to find out radeon9250 PCI version, and try it in my x5000. So to see, how things will behave. And then if there still will be some bugs, we can back to this then. If any of you want to spend time on it, of course :)

[samo79]

@kas1e

Meanwhile you can doing some test on your Pegasos2, atleast we can test/report eventual Rewarp issues on "proved to work" os4 hardware (old R200 drivers)

[DvdBoon]

I have this movie here from way back (3 years) which shows stuff working on the X5000 with ATI Radeon R9 270X. Sulaco demo is one of them...

https://www.youtube.com/watch?v=AJbcbIPLqIE&ab_channel=DennisBoon

[DvdBoon]

I gave up pn my X5000 after waiting 4 years on a sound card to arrive from AmigaKit.

[kas1e]

We all give up on something because of any reasons :) As for the video:

In your video, the first run of the Encore demo happens with bugs. Half of the effects missing (that probably due to missing w3d call in warp3d_Si as we discussed before). Then you exit from the demo pretty fast, but that was the moment when "slow fest" issues start after. So at least in this regard, you have the same problems with that video.

You run then it a second time with Wazp3D, but that of course absolutely of no use: slow fest (on 2GHZ CPU :) )

As for WipeOUT: indeed it runs, through feels pretty slow too for 2 GHZ? But seems this one also runs through WaZp3D, and not over rewarp3d? (or rewarp3d + wazp3d combo?)

[ksdhans]

Perhaps @ksdhans could provide some input here? It would probably be most reasonable to add the missing function to W3D_SI.library, instead of trying to patch it. However, I don't know if implementation of this function is feasible (I guess it was left out unimplemented for a reason).

It was initially left out because the Radeon and R200 drivers (Radeon 7000-9000 series) didn't. I have implemented the legacy draw functions, but can't remember in which version. IIRC, PatchWarp (or whatever it's called) should be able to work around this.

Another big problem with old Warp3D software is that they frequently rely on bugs in old drivers to work correctly. Even Wipeout 2097 relies on the chromatest operation using colour channels in ABGR order. The Radeon & R200 drivers have a set of environment variables to enable/disable workarounds for these, as does Wazp3D. You'll see some of them here: https://wiki.amigaos.net/wiki/UserDoc:Warp3D

[DvdBoon]

PatchWarp3D counts which and how much times a function is called. I only ever saw 3 if used with the old software. Those 3 are implemented in ReWarp3DPPC (see installation and ENV setting PatchAll with permision of Mr. Thellier)

The Warp3D driver of R200 in itself has more problems. DrawLine is bugged (most notably seen in the WOS FreeSpace version in rendering the pilot font and the HUD representation of a jump point). And Fog does not play well with the old software. Both leading to crashes. And ChromaKey needs to be permanently turned off otherwise no textures are shown in old WOS stuff. I updated the R200 code with the fixes and FORCEVERSION 4 for old software, but the patches were never pushed. It might be still on the git after 3 years though.

[DvdBoon]

As I was too lazy to make a package and it's all niche anyway.

[kas1e]

Btw, Hans says that DrawTriangleV is surely implemented, it just some debug line left in the driver printing that. But the function is in drivers already. So all render issues are not related to missing functions, but to the bugs in drivers/software/etc.

I updated the R200 code with the fixes and FORCEVERSION 4 for old software, but the patches were never pushed. It might be still on the git after 3 years though.

You mean updated R200 drivers on the Hyperion side, just didn't commit them?

I will try to play with all the warp3d environment wars, to see if I can make wipeout and encore demos to work.

But, the real problem is why they so slow on the 2ghz machine. Let aside rendering bugs, but speed shouldn't be much faster? This is a newer RadeonHD card, 2ghz CPU, etc?

[DvdBoon]

I cannot test myself. What is slow? The demos are 50Hz capped. At least on the classic Amigas.

[DvdBoon]

And yes, I meant Hyperion side. I even looked at porting it to OS3, but the state of the various ATI drivers is in legal limbo with parts being in the hands of Hyperion (composite, warp3d) and part AEon (2D) so I just gave up.

[ksdhans]

I've noticed something odd with WipeOut: it never calls any clear function to clear the z-buffer. At least, in windowed mode (it won't let me try full-screen). It's like it expects an implicit depth-buffer clear.

It's definitely not clearing the z-buffer by other means, because the depth test is set to W3D_LESS and the z buffer is never disabled. Any ideas what it's doing?

[kas1e]

@DvdBoon

I cannot test myself. What is slow? The demos are 50Hz capped. At least on the classic Amigas.

On the video, you show (on x5000), both the Encore demo and Wipeout very slow. Encore demo shows only the first 2 (and broken) scenes which kind of "ok" (but far from 50 fps), and after that coming slow-fest scenes of 2-3 fps. Same from Wipeout. Check how objects moving. It's about 15 fps maximum.

Anyway, is there any interest in further tests? I mean, not just discussing it, but if I will test everything deeply and provide a detailed report of what wrong, etc, may it lead to some actions/tests / possible improvements / etc ?:) I can donate as well if things will be improved. I also can test everything on Pegasos2 with Radeon9250.

[DvdBoon]

It will work a lot better with the Radeon 92xx. However, as the changes were never published, the errors in W3D_R200 are still there. Are you an official beta tester?

[kas1e]

It will work a lot better with the Radeon 92xx. However, as the changes were never published, the errors in W3D_R200 are still there.

I will try tomorrow on my peg2 with radeon9250 firstly, to see speed / render bugs, etc, and then will compare with x5000 / RadeonHD.

Are you an official beta tester?

Yes.

[DvdBoon]

I'll see if I can get the files from the X5040.

[kas1e]

Yeah, cool! I may also try after asking someone to incorporate them in if it will worth of and if you still will worry about :)

[kas1e]

Ok, doing some tests firstly on my pegasos2 Radeon9200:

Firstly I trying on all the components from FE update2 (so old original warp3dppc and powerpc libs). Demos as Sulaco and ByNight runs fine (Speed ok, visuals ok). The wipeout game also runs fine (despite just only little glitches under the ship as black texture, but in others all ok and playable).

Now, switching to ReWarp and ReWarp3DPP : in window mode, sound/music stops working in the WipeOUT. To be sure I switch back to the original powerpc.library, reboot, and sound are back. And when music miss, I see often that process "wo2097_mixer" is "parent process has tried to exit before all children have". So that definitely an issue of just powerpc.library, not of warp3dppc.library.

Demos as Sulaco and ByNight give no visual glitches at all. And the speed of every scene is 50 FPS!

So far, from the pegasos2 side, I can say that it all fine, but the only bug that Sound disappears completely in window mode is a wipeout.

Now, I tried things on X5000 with RadeonHD.

There does not matter if I use "setenv Warp3DPPC/PatchAll 1" or not (well with very little exception, not of a big deal for those 2 demos and WipeOut), but we have there some really major issues:

1). In both Sulaco and ByNight demos, almost every effect is "Black screen" with only a little part of the effect visibly. There almost no scene which renders properly, always half of the things or even whole effects missing.

2). Speed-wise, Sulaco and ByNight give 50 FPS on every scene on my Pegasos2 1GHZ/RadeonR9250 with rewarp libs , but on x5000 with warp3d_si some scenes in the Sulaco just unbelievable slow (and half visibly because most of the effect are black screen). There are details about every scene

Sulaco :

1st scene: just a black screen. missing "medusa", only "Encore" words visibly    : 30.75 FPS
2st scene: just a black screen, missing "ship", only "sulaco" words visibly.     : 49.98 FPS
3st scene: SLOW LIKE HELL. 2 fps, mostly black screen                            : 2.19 FPS
4st scene: SLOW LIKE HELL, 6 fps, mostly black screen                            : 6.12 FPS
5st scene: half effect visibly                                                   : 50.00 FPS
6st scene:  SLOW. 18fps, missing parts                                           : 18.85 FPS
7st scene: that one seems mostly ok in rendering, but "Wave of lines" miss       : 31.19 FPS

By Night:

1st scene: ok                                                    : 49.81 FPS
2st scene: rendering broken (half of the scene invisibly).       : 40.69 FPS 
3st scene:  the same, half of rendering missing.                 : 50.00 FPS
4st scene:  the same, half of rendering missing.                 : 50.00 FPS
5st scene:  the same, half of rendering missing.                 : 50.00 FPS
6st scene:  the same, half of rendering missing.                 : 26.16 FPS
7st scene: black screen                                          : 50.00 FPS
8st scene: half of rendering missing.                            : 15.25 FPS

As can be seen, By Night is mostly ok, but some scenes still too slow for x5000. Everything should be 50 FPS of course, just as on pegasos2.

3). WipeOUT has major issues:

Issue #1: can't choose graphics mode when choice Screen. I.e. I press on "Select" but not the ASL window spawns. I assume that Warp3D_SI issue and wipeout probably use some older method of querying modes? Hans maybe has an idea about it.

issue #2: didn't render text "press start" on the first screen. Everything after the first title picture just a black screen. That includes the menu and everything else.

And that not very much related if I use or didn't PatchALL. Just with PatchALL in one scene of one demo things renders a bit better, but that all. Mostly everything black.

@ksdhans Is w3d_SI driver have some sort of environment variables too, so I may play with them to see wtf happens with WipeOut, and why in all the demos half of the effects just didn't' renders, and 2 scenes are slow like hell? (while on pegasos2 with rewarp libs and radeon9250 they fine by speed).

I see there 3 issues on our side:

1). too much black screen everywhere (and in demos, and in wipeout completely all black). Can just need some additional clear/setup in warp3d_si? (or via envs?) 2). in wipeout we can't select screen mode (while, on pegasos2 we can, meaning it warp3d_si.library issue) 3). the speed. speed in demos awful taking into account that this is x5000. I remember that I find out that on x5000 with warp3d_Si TORCS and SpeedDreams games which works very fast on pegasos2, also slow like hell and give just 4-5 fps. That can be related pretty well.

I can help with everything and all tests if there wish to improve warp3d_si a bit.

[kas1e]

@ksdhans @DvdBoon

I also tested 6 MadWizard demos on Pegasos2/Radeon9250 with rewarp/rewarp3dppc: with PatchAll they all render correctly (despite random hanging issues). But then, when I test them on X5000 with RadeonHD (so Warp3D_SI), they the same as in other demos from Encore and as WipeOut bring issues of "missing effects, broken effects", etc. It's like often some things not where they should be (like X/Y/Z things messed around, values of textures too, etc).

I.e. every ppc/warp3dppc prod seems to share those issues on x5000/warp3d_si about "too much black screen" and "missing effects". Like some default warp3d state values differ much or so. Maybe that can be somehow debugged / workaround in warp3dppc? I can donate surely if there can be some work done on that front.

Because generally speaking, on pegasos2, with rewarp / rewarp3dppc things is pretty fine. Some bugs to find/fix, but in general, is ok. And to add, Encore demos, Madwizard demos, WipeOut surely works before not on Radeon9xxx drivers, but on Voodoo3 and Bvisions/Cvisions , so code more or less "general", and issue to find is what the difference on x5000/warp3d_si.

@DvdBoon Maybe you have some interest to spend on bug-hunting / finding issues about ?:) I can donate for your time surely as well.

[ksdhans]

@ksdhans Is w3d_SI driver have some sort of environment variables too, so I may play with them to see wtf happens with WipeOut, and why in all the demos half of the effects just didn't' renders, and 2 scenes are slow like hell? (while on pegasos2 with rewarp libs and radeon9250 they fine by speed). No ENV vars, sorry. To create them I would have had to know what effects are broken. IIRC, ReWarp didn't exist back when I wrote W3D_SI, and the old WarpOS compatibility library didn't work on new machines. Hence, old software was never tested. I think people had lost interest by the time ReWarp was released, because I don't remember getting any bug reports.

I see there 3 issues on our side:

1). too much black screen everywhere (and in demos, and in wipeout completely all black). Can just need some additional clear/setup in warp3d_si? (or via envs?) The WipeOut blackness is depth-buffer related. Hopefully those demos make the same mistake. Where can I download those demos?

2). in wipeout we can't select screen mode (while, on pegasos2 we can, meaning it warp3d_si.library issue) I'm not sure what's going wrong there. I'd have to look at how WipeOut and the Warp3D.library figure out what modes are available...

3). the speed. speed in demos awful taking into account that this is x5000. I remember that I find out that on x5000 with warp3d_Si TORCS and SpeedDreams games which works very fast on pegasos2, also slow like hell and give just 4-5 fps. That can be related pretty well. Most likely, they render graphics in a manner that forces many tiny render ops. For example, if they thrash the Warp3D state a lot, then they can trigger pipeline flushes. Modern graphics cards don't work well when you send them lots of tiny render operations one by one. The driver does its best to assemble small operations into larger ones (i.e., larger vertex buffers), but there are plenty of situations where this isn't possible. I never did figure out how to get TORCS and SpeedDreams to work faster.

[kas1e]

@ksdhans

No ENV vars, sorry. To create them I would have had to know what effects are broken. IIRC, ReWarp didn't exist back when I wrote W3D_SI, and the old WarpOS compatibility library didn't work on new machines. Hence, old software was never tested. I think people had lost interest by the time ReWarp was released because I don't remember getting any bug reports.

And it also mostly because that as you can see people, not often report bugs in a normal way :)

The WipeOut blackness is depth-buffer related. Hopefully, those demos make the same mistake. Where can I download those demos?

Very lucky it's the same issue. Just looks so close. Demos can be downloaded here (remember to set "setenv Warp3DPPC/PatchAll 1", before running them):

http://kas1e.mikendezign.com/warpos_demos/Encore-Sulaco.lha http://kas1e.mikendezign.com/warpos_demos/Encore_Bynight.lha http://kas1e.mikendezign.com/warpos_demos/MadWizzards_HeavyTraffic.lha http://kas1e.mikendezign.com/warpos_demos/MadWizzards_Till_I_Feel_You.zip

Madwizzard ones may hang randomly (there another bug report to warp3dppc), but overall they run and broken rendering/missing effects can be seen the same as in the Encore demo. On pegasos2/radeon9250 with the same rewarp libs and "Warp3DPPC/PatchAll 1" set, they all render correctly (as well as I remember right on Voodoo3 and C/Bvisions too).

I'm not sure what's going wrong there. I'd have to look at how WipeOut and the Warp3D.library figure out what modes are available...

From the pegasos2/Radeon9250 tests, I can see it throw a lot of mode to choice, up to 1920x1080. But need to recheck if they PC or not, etc.

I ready for any tests, just say/send anything :)

[kas1e]

@ksdhans

There is an image of screen modes when I run WipeOut over rewarp libs on pegasos2/radeon9250 (so they no PC ones, but usual ones)

http://kas1e.mikendezign.com/aos4/rewarp/wipeout_screenmodes.jpg

Btw, do you think in WipeOUT missing text on the first intro-image "press start" also because of depth-buffer related? See what I mean:

http://kas1e.mikendezign.com/aos4/rewarp/wipeout_missing_press_start.jpg

On x5000/radeonHD we didn't have that "press start" text.

[ksdhans]

Thanks for the download links. If you use the driver version with the profiler enabled, then you may be able to see what's triggering pipeline flushes.

@ksdhans

There is an image of screen modes when I run WipeOut over rewarp libs on pegasos2/radeon9250 (so they no PC ones, but usual ones)

http://kas1e.mikendezign.com/aos4/rewarp/wipeout_screenmodes.jpg Ugh! It looks like WipeOut only wants to run on big-endian 16-bit screens. Southern Islands (and newer) GPUs don't support those modes, but do have their little-endian counter-parts. There's nothing I can do about that on the driver side.

Btw, do you think in WipeOUT missing text on the first intro-image "press start" also because of depth-buffer related? See what I mean:

http://kas1e.mikendezign.com/aos4/rewarp/wipeout_missing_press_start.jpg

On x5000/radeonHD we didn't have that "press start" text. Yes, that's also due to the depth-buffer problem.

[ksdhans]

This bug ticket can probably be closed, because the problems aren't ReWarp related...

[kas1e]

@ksdhans Yeah, I can create separate tickets for warp3d SI on aeon's bug tracker instead (so they will not forget)

[DvdBoon]

The suspense! ;-)

[kas1e]

@all Just for not spam the issues list, I reopen this one as it looks like our general discussion topic :) And the more people in discussion, the more ideas we will have. I also renamed the issue's topic so all will be clear.

So... So far Hans already fixed improved NovaBridge to the level when all the issues we discuss there gone, speed is fine too (in all Encore demos, for example, I had stable 50 fps for each scene in each demo). Still, some issues are here (most of which I report to the a-eon bug-tracker already so Hans is already aware) such as:

1. in all Mawi demos, we didn't have proper "cinema" effect where at the top and at the bottom we have small black areas. Instead, it all looks like both areas just draw at the bottom together. There is a bug report with all the info:

http://www.amiga.org/developer/bugreports/view.php?id=850

I think it can be a clipping issue (but of course not sure) because I remember having something of this sort back in times when coding "the vague" warp3d diskmag. It even can be some warp3d bugs to which Mawi relies back upon in times, so probably some sort of inbuild patch can be needed (and fixing this probably will make NovaBridge closer to original warp3d with its bugs and co).

2. the Second issue, is the missing textures in some Mawi demos and in Heretic2 on the whole. That one is probably also because some different textures formats or simple usage of them are wrong/some-special-warp3d4-way. There is a ticket for:

http://www.amiga.org/developer/bugreports/view.php?id=849

If anyone has anything to add, that probably can help as well.

And the third issue which I didn't report at the moment to a-eon's bug tracker as not very well understood from where an issue can come and which can be for example configuration issue. Or, it can be a side effect of an issue with those black areas being at the bottom, dunno. But. Problem is:

When we run any MAWI demo in fullscreen mode (i.e. it, without "-win" parameter), then in fullscreen they "blink" like madmen. It looks like something with VSYNC, but from another side, all other demos/apps for warp3dppc/wapros correctly work in FullScreen. So it something coming from MAWI's code probably (or that side effect of those black lines being merged at the bottom). In window mode no such issues, so it definitely something with opened 640x480 screens and maybe parameters attached to the screen (maybe some auto vsync or how it is called in tag list when you open a new screen).

Video: https://youtu.be/ze6xR1MGOVQ

So if anyone has any ideas or something to say about it, plz share your opinions. Will be cool to find out from where the roots of the issue come, so it all can be fixed.

[kas1e]

Related to issue 3, interesting that if i "alt+m" so to be on the main workbench screen, and scroll down workbench so can see this 640x480 screen, the "blinking" effect is still there, but looks a bit different. Maybe it will bring some idea as well, there is:

https://youtu.be/Ae8i6Z1W-NQ

Imho it does look like vsync or something of that sort. And as it didn't happen in window mode, my assumption is that they create a screen with some tags or so, which NovaBridge didn't do maybe? I checked via Ranger what kind of screen is it, and this is:

Type: Custom Depth: 16 Box: Left: 0 Top: 0 Widht: 640 Height: 960 PixelFormat: R5G6B5PC Flags: HiRes Compositing: Disabled Drop Shadows: Disabled User Data: 0x00000000

I do compare with Encore demos, which didn't have such a "blinking effect", and their settings for the screen are:

Type: Custom Depth: 16 Box: Left: 0 , Top: 0, Width: 640, Height: 480 PixelFormat: R5G6B5PC Flags: HiRes Compositing: Disabled Drop Shadows: Disabled User Data: 0x00000000

The only difference I see here is in the Box params, where Height in MAWI demos is 960 (probably for Triple buffering?) Maybe that causes such a difference? And maybe indeed we had a "Clipping black lines at bottom" issue because of that as well?

[ksdhans]

Please use A-EON's bug tracker for NovaBridge issues, which are irrelevant here (this is ReWarp's bug tracker). Forget about W3D_SI.

[ksdhans]

Seeing as we're here, the third issue looks like double-buffering may be done without properly waiting for the dbi_SafeMessage and dbi_DispMessage. That would have been safe to do with slow hardware, but with a fast GPU you can easily end up drawing/clearing a buffer while it's still being displayed. I have to enable vsync in games such as OpenArena, or I get such flickering there too (at least on the menu screen).

Double-buffering is poorly documented. There's a thread on os4coding, where I asked others how to do it correctly: https://www.os4coding.net/forum/anyone-have-or-know-complete-changescreenbuffer-example

If I'm right, then I don't know what workaround could be added to force old demos/games to wait for the double-buffering messages without hurting apps/games that use it properly.

[kas1e]

@all Hans fixed everything in novabridge, so close this one one more time :)