Warp3d synchro/double-triply bufferging

[Karlos]

Framiga wrote:

About looking inside the source . .  . Karlos do you wanna kill me :-)

Nope. Why, is it that bad? A few things you probably noticed

1) there is no main() function.
2) the program is a C++ class
3) there isn't a single line of AmigaOS specific code anywhere ;-)

Its chinese for me :-(

Try a tab space of 2 - that's what I use. It will make it look a lot tidier at least :-)

[Karlos]

BTW, anything written with my framework supports a "-sysdebug" option on the CLI which can be handy when stuff doesnt work that maybe isn't the application's fault.

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

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

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

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

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

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

[Karlos]

There's always a slowdown with context switching.

The best way to minimise this is to handle them yourself. Identify all the system calls you need to make at least once per frame and put them into a single 68K function which you call manually using Run68K().

For example, you'll want to flip the buffer. You'll also possibly want to read the messages from your window's IDCMP port. I used to use PPC native callbacks for input under WOS. To do this, each frame I captured all (well up to a limit) the IDCMP messages on the 68K with a typical while loop and decoded them into an array that formed part of my display "context".

When control passes back to the PPC, the array of data was then traversed and the PPC native handlers called for each event.

Towards the end, I had at least three jobs that were 68K native - flipping the buffers, capturing the IDCMP message content (which included mapping raw printable keycodes to characters etc) and updating an AHI buffer for the sound.

Everything else was PPC native - handling the callbacks, mixing the sound and so on. This led to about 2 full context switches per frame including the one caused by W3D_LockHardware() and the manual one I did. It's only a pity they couldn't have been merged somehow.

[Karlos]

@kas1e

Yeah still alive, but so busy I probably forgot to reply.

You do get a context switch with the PPC native W3D_LockHardware() call because it in turn has to call some 68K functions when it locks the various resources. That's pretty unaviodable. What you don't want is to make things worse by adding a dozen more of your own, hence the solution of gathering the OS calls together.

[Karlos]

Hmm. Exactly which version of the bvision driver is that? I don't recall getting that kind of problem with 16-bit textures on screens with greater depth than the textures.

[Karlos]

It's been quite a while, but I don't recall that the Permedia2 supports hardware 3D acceleration in 24-bit packed pixel mode - I'm guessing it's really 32-bit :-?

@Mastatabs

Yeah. Notice that the colours of the rotated pixels aren't affected; that suggests it isn't the 16-bit texels getting swapped, whatever the corruption is, it's happening in the framebuffer itself.

If I get a chance, I'll have to look to see if I can reproduce the effect.

@kas1e

Is this fullscreen or windowed (guessing fullscreen) ?