Warp3d synchro/double-triply bufferging

[Piru]

@RWO

Karlos do you know how to do window double buffering?

There is no window buffering.

[Piru]

@Karlos

One of the things is knowing exactly where to put the WaitBOVP() call - it can make all the difference.

You should not put it anywhere, ever. WaitBOVP() busyloops (or at least it busyloops with certain system configurations). It's a very bad idea to use this call.

You should use the syncronization service provided by ScreenBuffers (or rather graphics.library/DBufInfo that is used by intuition ScreenBuffers). See graphics.doc/DBufInfo for example of syncronized doublebuffering.

[Piru]

it's too bad ?

Yes it is. It should use the buffering provided by the ScreenBuffers. With ScreenBuffer it would be perfectly synched to the display beam, and it would never busyloop.

Also, the code does some nasty manual busylooping if the ScreenBuffer cannot be swapped instead of just refusing the swap (ok, there might be some implementation specific reasons why it MUST always succeed to swap). Such while loops can create nasty lockup. If construct like this MUST be used, the code should sleep a bit after each failure.

Also, such WaitBOVP syncing breaks triplebuffering (triplebuffering will appear identical to doublebuffering then).

[Piru]

@EntilZha

It does use ScreenBuffers.

Indeed, ScreenBuffers themselves do sync to VBL by default. However, this is not enough to get "nice" syncronisation, as the WaitBOVP sync code points out.

ScreenBuffers (or graphics DBuf actually) have the ability to do the "nice" syncronisation (making sure the frame has been seen at least once), by using dbi_DispMessage. There is no need to use WaitBOVP.

That's what it's inside an IF statement... you can actually turn it off... so what's the point ?

DoSync is enabled by default, thus if triplebuffering is enabled (mglChooseNumberOfBuffers), one has to manually disable sync (MGLEnableSync) or you actually get doublebuffering with more memory usage. But I suppose that's obvious to everyone.

PS. It could be that graphics.library original ChangeVPBitMap does indeed busywait aswell, but this shouldn't be used as an excuse to force the same on systems where ScreenBuffers does multitasking friendly syncing, while WaitBOVP doesn't.

I'm sure you knew all this already.

[Piru]

@kas1e

Of course it flickers, as you don't tell W3D where to render to. Now it only renders to the first buffer, and you toggle between the rendered frame and empty frame.

Like Karlos already pointed out you need to tell W3D where to render by using W3D_SetDrawRegion().

About the code in general: You've misunderstood something there. You must not call ChangeScreenBuffer for both ScreenBuffers in the loop, but instead you must have single call to ChangeScreenBuffer, and toggle between myScreenbuffer1 and myScreenbuffer2. When looking at the graphics/ChangeVPBitMap example, replace the ChangeVPBitMap call with ChangeScreenBuffer call.

Further checking to do:
1) Did you set both SafeToChange and SafeToWrite to TRUE initially?
2) Did you implement cleaning up the possibly pending messages after the loop?

[Piru]

@Mr_Capehill

It's a DNS problem, try http://81.172.167.40/~karlos/demos/

[Piru]

@Karlos

WarpDemo works fine under MorphOS btw, playing with some 1024x1024 textures atm. Funky :-)

warpdemo1.jpg

[Piru]

@Karlos

I think you should play with the "mesh" parameter on the CLI. Try using a mesh of 32 or more to get a much finer level of control.

Of course the recalculation time is O(n*n) with respect to the mesh value, so don't go nuts with it...

Oh, thanks. I'll check it out.

-edit-

mesh 64, looks much smoother now:
warpdemo2.jpg

A slight bug exists in that I clamped the window size to a max of 1024x768, so your image was probably a bit distorted anyway

Yeah noticed this.

So what GPU is that you are using?

R200 (It's a Radeon 8500LE)

[Piru]

@Karlos

With 1024 x 1024 texture, 100 x 100 mesh is fast still, can't see any difference to lower values.

warpdemo3.jpg

Going up from there adds some visible slowness (I guess it takes over a frame to redraw things then).

[Piru]

On the voodoo it seems anything larger than 256x256 is not allowed

Not with current Warp3D voodoo drivers at least. VSA-100 (Voodoo 4 & 5) does upto 2048x2048.

Have you tried any rectangular images?

Not really. For some reason I assumed it needed to be 1:1 :-) Will try later...

Also, if you didn't read the "manual" (if I even included one), there is a "scale" option (which is floating point) for smaller images.

Yeah, used with that at first, then looked for some larger images to play with.

[Piru]

As Karlos already pointed out you must group as many m68k calls as possible to single m68k code section which you then  Run68k. The reason is that each single m68k call from WOS context results in full cache flush for both m68k and PPC CPUs. All OS calls generate such a context switch.

In my code I had input processing, screenbuffer switching, optional palette changing and AHI audio I/O in single m68k function. This was PUP code though, but the principle was the same.