Warp3d synchro/double-triply bufferging

[Piru]

@Mr_Capehill

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

[Karlos]

@Framiga

It would be possible to make the thing correctly support arbitarty image sizes and a whole load of other stuff. However it's primarily a toy that I have probably spent no more than 4 hours on in total :-)

[bloodline]

Karlos wrote:
@Framiga

It would be possible to make the thing correctly support arbitarty image sizes and a whole load of other stuff. However it's primarily a toy that I have probably spent no more than 4 hours on in total :-)

so where's the windies binaries?

[Karlos]

bloodline wrote:

so where's the windies binaries?

Awaiting a total overhaul of the framework core ;-)

The win32 version(s) were originally maintained by a friend, a man who has forgotten more about windows and directx than I will ever know, but he has no time to work on them presently :-(

That said, the warpdemo did work with the last version under win2k/dx7.

Snags were things like the ImageLoader interface, which is a doddle on amigaos thanks to v43 datatypes, but tricky on most other platforms. The Win32 gfxlib had hard coded support for jpeg, png, bmp and ppm, that was it.

[Mr_Capehill]

@Piru: kiitos

Will test those tools ASAP.

[Piru]

@Karlos

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

warpdemo1.jpg

[Karlos]

@Piru

:lol: Thermal damage warped that card but good.

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

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

-edit-

So what GPU is that you are using?

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

[Framiga]

REPAIRED!!!

. . . or quite :-D

[Karlos]

@Framiga

Access forbidden :-(

[Karlos]

@Piru

So what is the speed like there with these larger mesh / image sizes? (also bear in mind its a 680x0 application)

The actual warpdemo "application" isn't what I would call well optimised, but I wanted to keep it understandable as I figured the program would make a reasonable tutorial for any documentation I would make for the framework. Not that there is any documentation. I suck too bad at that ;-)

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

[Karlos]

I figured as much. On my 040/25 + BVision it works acceptably with a mesh of upto 32 and texture sizes of 512x512.

The P2 would be helped a lot if I subdivided large textures into smaller ones that tile together since the chip doesn't like reading long spans of texels that cross memory pages (it actually has a special texture arrangement called "subpatch" it can use that re-arranges large textures into smaller blocks - no longer linear spans of texels - that achieves the same end, but this is not supported in the 680x0 warp3d driver).

On the voodoo it seems anything larger than 256x256 is not allowed, so the above subdivision idea might be needed for this one anyway.

-edit-

Have you tried any rectangular images? 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. So loading a 256x256 image can be made to fill a larger area, eg

warp image my256x256pic.jpg scale 3 mesh 32

would make the window 768x768...

Of course I should totally rewrite the display bit so its a sensible size and the loaded mesh is automatically scaled to fit properly. Theres nothing stopping me apart from lethargy ;-)

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

[Karlos]

@kas1e

Getting back to the original topic, I sent you a working fullscreen / double buffered / synchronized demo :-)

I would post it someplace but Piru will kick my ass for using WaitBOVP() ;-)

Oops, that let the cat out of the bag...

-edit-

@Piru

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

I meant the Voodoo3000 and below. Havent yet got an image larger than 256x256 to work on the Voodoo3000 system here :-/

Incidentally, the P2 will cope with 2048*2048 textures. Having said that, with 8MB of VRAM you'd be very lucky to fit one in ;-)

[Karlos]

Getting back to the WaitBVOP() issue...

I ran some simple tests (via executive/top) using the code I sent to kas1e and I think Piru is right about the busy waiting - the task uses a lot of CPU when just switching the screenbuffers and waiting for synch with WaitBVOP().

I have never experienced problems as a result of this, but then any single threaded application likely spends only a part of its time waiting for the synch.

I'll try the proper way and see what that does for it.