Amiga.org
Operating System Specific Discussions => Amiga OS => Amiga OS -- Development => Topic started by: kas1e on February 11, 2005, 12:34:18 AM
-
Hi 2 all. I have a lame question about syncro in warp3d. I using voodoo3/aos3.9/m68k and want to do some truecolor animation. So:
I draw 640x480x32bit picture on screen (this picture = 6 textures), and try to scroll on this picture some sprite (128x512x32) with transparency. So, if i just move sprite (witchout redrawing some areas (textures) of my backscreen) it work nice with WaitTOF() only. BUT. If i moving sprite, and trying redrawing part of backscreen (two 256x256 textures), (do it animation i mean), i have some bugs on screen. Not big bugs, but some UPpers areas of my screen is 'blinking'. If i drawing in 'low' part of screen, it is work fine.. I don't know what is it, maybe problem with WaitTOF() or need do it somethink else ..
Well, next, i read some docs (graphics/intuition/warp3ddev), and found some worlds about 'double buffering'. It is allow to me rendering all data to 'invisible' scren, and flip with 'main' screen. But i do not understand HOW it can be help me. If WaitTOF() can't do it good synchro, how buffer fliping can give me good synchro ?
So, if i understand correctly, double-buffering can solve my 'some blinking UPpears areas'. (i am right?) And as i reading, here is 2 ways for it :
1. ScreenBuffer (alloc/change/free).
2. ScrollVPort + WaitBOVP.
Well, i just to try this code (only for 'flip' picture from 'invisibli' part, to 'main' part):
// ... create screen/window/warp3d context ...
vp=screen->ViewPort;
// draw to 'invisibli' screen.
W3D_SetDrawRegion(context,bm,480,&s);
vp->RasInfo->RyOffset=0;
ScrollVPort(vp);
WaitBOVP(vp);
W3D_SetScissor(context, &s);
// draw my pict, to 'invisibli' buffer, and do it some wait.
draw_pict(context,1.0f);
Delay(10);
// flip to 'main' screen
W3D_SetDrawRegion(context,bm,0,&s);
vp->RasInfo->RyOffset=0;
ScrollVPort(vp);
WaitBOVP(vp);
W3D_SetScissor(context,&s);
And nothink to happened .. Picture was drawing on 'invisibly' part, and can't flip.
Next, i try to use ScreenBuffers:
// creating 2 ScreenBuffer. 'main' and 'invisible'.
if(!(buf1=AllocScreenBuffer(screen, NULL, SB_SCREEN_BITMAP)))
{ printf ("failed to allocate screenbuffer\n"); goto panic;};
if(!(buf2=AllocScreenBuffer(screen, NULL, SB_SCREEN_BITMAP)))
{ printf ("failed to allocate screenbuffer2\n"); goto panic;};
// BitMap for Warp3d context creating
buf1->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort = NULL;
bm = buf1->sb_BitMap;
context = W3D_CreateContextTags(&CError,
W3D_CC_MODEID, ModeID,
W3D_CC_BITMAP, bm,
W3D_CC_YOFFSET, 0,
W3D_CC_DRIVERTYPE, W3D_DRIVER_BEST,
W3D_CC_FAST, TRUE,
W3D_CC_DOUBLEHEIGHT, TRUE,
TAG_DONE);
// ... skip some setstates/etc ...
for(i=250;i>0; i-=5)
{
ChangeScreenBuffer(screen,buf2); // draw to invisible buffer
Draw_Sprite(context,i);
ChangeScreenBuffer(screen, buf1); // flip ScreenBuffers.
};
And agayn, i have not a good synchro ;(
Well, here is questions:
1. Where best way for work with synchro on warp3d. If anyone have some sources it is will be very good.
2. How do it normal hi-rez animation on warp3d.
Any docs/link/sources/talks/help will be very good.
sorry for poor english, hope anyone can help me with it, thanks.
-
First of all, stick with the ScreenBuffer based buffering. It's much less of a pain in the rear than the scrolling one IMHO.
Secondly use WaitBOVP(&(screen->ViewPort)) to wait for the buffer flip. I have found this works a lot better than WaitTOF().
Thirdly, when you change buffers, remember to update your W3D_Context to use the newly released buffer for rendering using W3D_SetDrawRegion(), otherwise you will be still rendering to the same BitMap that before the buffer flip was the invisible one but now is the visible one.
-
Karlos, thanks for answer.
So, i must use ScreenBuffer, and get to trash all thinks about ScrollVPort ? ok.
What about WaitBOVP(&(screen->ViewPort)) and W3D_SetDrawRegion(), as you can see in my examples, i use it already, but it is not give me good synchro.
btw, maybe you can explain more complete, what i must to do 'step-by-step' ?
I just do not understand, WHY i must use double-buffering ? Where is + ? And how i can use it ? For example:
1. i setup invisibli buffer for render:
W3D_Scissor s = {0,0,640,480};
W3D_SetDrawRegion(context,bm,480,&s),
2. draw data to this buffer.
draw_my_pict();
3. here i want to flip this buffer to main. how ?
ps. and what about YOFFSET in context creating, must i use it or not ?
-
You don't have to use the ScreenBuffer approach, I just find it works better than the tall screen / ScrollVPort method.
Right, about double (or triple) buffering in general. The basic idea is that you always draw to a BitMap that is currently invisible. Once the drawing is done, you swap this BitMap for the one currently on display (waiting for the appropriate synchronization). The BitMap you just drew on is now on screen and the one that was on screen is now available to draw on.
Doing this ensures that you never "see" the rendering happening, which would otherwise produce a very flickery image.
A consequence of this is that the "invisible" and "visible" BitMaps keep swapping over.
Therefore, regarding the W3D_SetDrawRegion() call, you have to do this every time you flip the buffers, not just when you first set up the context. From the looks of what you have written, this is the thing you are neglecting.
So every time you do the ChangeScreenBuffer(), you must also do W3D_SetDrawRegion() to tell the W3D_Context to use the "current" invisible BitMap.
One problem I noticed with your code is that you call the AllocScreenBuffer() both times using the SB_SCREEN_BITMAP argument. This arguement is used to associate the existing screen's BitMap with the ScreenBuffer, not allocate a new one. So in your case you never really had a second buffer anyway, they were both simply pointers to the screens's one. You dont use the SB_SCREEN_BITMAP when you want to actually create an invisible buffer.
Another thing to consider is that the ChangeScreenBuffer() call can fail at the point you call it. An ugly (but working) way around this is to do something like this
Screen* screen;
W3D_Scissor scissor { ... };
ScreenBuffer* buffer[2];
int drawBuffer;
//...
// create the initial visible buffer (this is just the screens bitmap)
buffer[0] = AllocScreenBuffer(screen, NULL, SB_SCREEN_BITMAP); // doesn't allcoate BitMap
// create the initial invisible buffer. Note the second argument is 0
buffer[1] = AllocScreenBuffer(screen, NULL, 0); // does allocate BitMap
// the second buffer is the initial drawing buffer
drawBuffer = 1;
// function to swap the buffers
void mySwapBuffer()
{
// make sure we swap the buffer. This truly is an ugly way, but it works - in any case, the busy loop is almost always never entered. But for the love of god don't do anything like this in a WarpOS ppc version - possible frenzy of context switches - make it a 68K function .
buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=0;
while (!ChangeScreenBuffer(screen, buffer[drawBuffer]))
;
// change the drawBuffer number
drawBuffer ^= 1;
// wait for bottom of viewport sync
WaitBOVP(&(screen)->ViewPort);
// update the context to use the new draw region
W3D_SetDrawRegion(context, buffer[drawBuffer]->sb_BitMap, &scissor);
}
If you use the above function (or similar - this is from memory), you should experience smooth, unflickering graphics.
Forget all about the YOffset thing, just use 0. It's only needed for the ScrollVPort() buffering strategy anyway.
-
Oh, a note about triple buffering...
Double buffering is your primary means of eliminating flicker by ensuring the rendering is done off screen. However, the synchronization step involved in switching the buffers can cause a stall.
Suppose you *just* miss the next monitor frame - you end up waiting for the next one after that before you can proceed to render.
Triple buffering mitigates this by using a queue of three buffers rather than a pair. This way you always have a buffer ready to render into on every monitor frame.
For systems with faster CPUs (ie capable of faster rendering), this can produce a smoother experience.
-
Do i must for ScreenBuffer techniqe use double Height screen/window ? I mean if i use 640x480 screen, can i use SA_Height/WA_Height with 480, or need 960 ? Do i need set W3D_CC_DOUBLEHEIGHT in TRUE for warp3d context ?
So, i just try to use this (with Height 480) code:
//.. open screen/window
buffer[0] = AllocScreenBuffer(screen, NULL, SB_SCREEN_BITMAP);
buffer[1] = AllocScreenBuffer(screen, NULL, 0); drawBuffer = 1;
// bitmap for context creating
buffer[0]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort =NULL;
bm = buffer[0]->sb_BitMap;
// ..create context, set some states
for(i=250;i>0; i-=1)
{
buffer[drawBuffer]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=0;
while (!ChangeScreenBuffer(screen, buffer[drawBuffer]));
drawBuffer ^= 1;
WaitBOVP(&(screen)->ViewPort);
W3D_SetDrawRegion(context, buffer[drawBuffer]->sb_BitMap,0, &s);
W3D_LockHardware(context);
W3D_DrawTriStrip(context,&tris4); // 256x256
W3D_DrawTriStrip(context,&tris); // 256x256
W3D_UnLockHardware(context);
}
// ..close all libs/buffers/etc
And i can wath as flip my buffers ! i mean for(i=250;i>0; i-=1) i can wath some time as 'flip' my buffers .. but as i understand my triangles must be not flicking, as in case if i use WaitBOVP(&(screen)->ViewPort); or WaitTOF(); only. Maybe some more initialization need it for warp3d himself, or for buffer-switching ?
First, i think maybe problem with my 040/33 (too slow), but it work the same for ppc too! i compile it for warp-os/warp3dppc and it work the same :(
ps. if you have some time, can i send to you my code/binary for test ? maybe problem in my hardware ..
-
sorry for the intrusion but:
"Not big bugs, but some UPpers areas of my screen is 'blinking'. If i drawing in 'low' part of screen, it is work fine.. I don't know what is it, maybe problem with WaitTOF() or need do it somethink else .."
i have a similar problem with the W3DDemo "WarpTest", in the W3D archive.
CVPPC at 90 Mhz (but the same at 80) CGX42.7 with a low vertical freq>62Hz.
Thanks
-
to Framiga:
but what about some Demos for example ? i mean ppc/warp3d demos like mawi/encore/universe ? the same problem or work fine ?
ps. warptest work fine for me.
-
@kas1e
just tryed again:
PaybackDemo>W3D= OK
FreespaceDemo>W3D= OK
ony WarpTest gives me those strange problem an GFX corruption on the 3D object.
EDIT- ops forgot . . .not i haven't tryed those demos (mawi/encore/universe)
-
@Framiga
Well, maybe normal project (like games kind of payback,etc) use other techniqe then ScrollVPort (in warptest is it), and i think not only ScreenBuffer .. Maybe 3x-buffering in here ?
-
i'm just downloading this:
ftp://ftp.scene.org/pub/parties/2003/symphony03/amiga/demo/encore_bynight.lha
WOW fantastic :-)
works perfectly here . . . thanks
-
2framiga:
well, it work good with warp3d synchro too. so, i have only one question to all, how exactly it work ?:) where good example ?
ps. if you interesting in warp3d demos like ByNight from Encore, watch this:
Potion:
1. Planet Potion (work only on 15bit screens, can't work for voodoo, but it is the best)
2. Future Vision (the same).
MadWizards demos (work for me nice):
1. CruelKarma Forms (2001/the best)
2. Cull bazaar (2001).
3. another dream away (2002)
4. new dawn fades (2002)
5. heavy traffic (2002/very nice too)
6. third eye conqueror (2002/can't work on my voodoo, but it must work on CV).
7. fate fits karma (2003)
8. till i feel you (2003)
Encore:
1. Sulaco
2. ByNight
3. Kheshkhash (can't work on voodoo)
and some from CreativeMinds and Universe.
And in all GOOD SYNCHRO :)
-
@kas1e
If you want to send me your code/binary I don't mind having a quick look. I'll pmail you my email address.
I use double/triple buffered ScreenBuffers on my BPPC 68040/25 + BVision without any great problems. One of the things is knowing exactly where to put the WaitBOVP() call - it can make all the difference.
You don't need to use a ScreenBuffer for the ScrollVPort() method, it's only for the ChangeScreenBuffer() version.
-
Karlos do you know how to do window double buffering?
-RWO
-
@RWO
Karlos do you know how to do window double buffering?
There is no window buffering.
-
@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
but what about MiniGL sources ? i founding these strings in mglDisplaySwitch:
context->BufNr++;
if (context->BufNr == context->NumBuffers)context->BufNr = 0;
context->Buffers[nowbuf]->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=NULL;
while(!ChangeScreenBuffer(context->w3dScreen,context->Buffers[nowbuf]));
W3D_SetDrawRegion(context->w3dContext,context->Buffers[context->BufNr]->sb_BitMap,0,&(context->scissor));
if (context->DoSync) // if Sync in GL = TRUE, do SYNC.
{
struct ViewPort *vp = &(context->w3dScreen->ViewPort);
WaitBOVP(vp);
};
it's too bad ?
-
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).
-
But in this examples ScreenBuffers combinate with WaitBOVP, but it is a ScreenBuffers anyway. Do you mean just using WaitBlit(), instead WaitBOVP(), maybe ?
-
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.
It does use ScreenBuffers.
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.
It hardly ever fails to swap the screen buffer, anyway.
Also, such WaitBOVP syncing breaks triplebuffering (triplebuffering will appear identical to doublebuffering then)
That's what it's inside an IF statement... you can actually turn it off... so what's the point ?
-
@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.
-
mess :)
2piru: can you write func base on dbi_DispMessage, witchout
WaitTOF/WaitBOVP under Warp3D ?:)
2entzilla: why do not create 'W3D_Sync' for upcoming warp3d (if it will be) releases ?
-
@piru
Well, i try to use your case here:
DBIport[0] = CreateMsgPort();
DBIport[1] = CreateMsgPort();
myScreenbuffer1 = AllocScreenBuffer(screen,NULL, SB_SCREEN_BITMAP);
myScreenbuffer2 = AllocScreenBuffer(screen,NULL, 0);
myScreenbuffer1->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort = DBIport[0];
myScreenbuffer1->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort = DBIport[1];
myScreenbuffer2->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort = DBIport[0];
myScreenbuffer2->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort = DBIport[1];
..create context/open screen...
while(1)
{
// ...do some matrix/etc stuff
while(!ChangeScreenBuffer(screen, myScreenbuffer2));
if (! SafeToWrite)
while(! GetMsg(DBIport[0])) Wait(1l<<(DBIport[0]->mp_SigBit));
SafeToWrite=TRUE;
W3D_LockHardware(context);
W3D_ClearDrawRegion(context,0x00000000); // fill screen with black color
W3D_DrawTriStrip(context,&tris);
W3D_UnLockHardware(context);
if (! SafeToChange)
while(! GetMsg(DBIport[1])) Wait(1l<<(DBIport[1]->mp_SigBit));
SafeToChange=TRUE;
while(!ChangeScreenBuffer(screen, myScreenbuffer1));
SafeToChange=FALSE;
SafeToWrite=FALSE;
}
In this case, after running, system halt, and only reboot can help me. If i adding WaitBOVP() in loop, it working, but problem anyway here - blinking of my object.
I just try this:
ChangeScreenBuffer(screen, myScreenbuffer2);
myScreenbuffer2->sb_DBufInfo->dbi_SafeMessage.mn_ReplyPort=0;
W3D_LockHardware(context);
W3D_ClearDrawRegion(context,0x00000000); // fill screen with black color
W3D_DrawTriStrip(context,&tris);
W3D_UnLockHardware(context);
myScreenbuffer2->sb_DBufInfo->dbi_DispMessage.mn_ReplyPort=0;
ChangeScreenBuffer(screen, myScreenbuffer1);
or just:
ChangeScreenBuffer(screen, myScreenbuffer2);
DBIport[0]=0;
W3D_LockHardware(context);
W3D_ClearDrawRegion(context,0x00000000); // fill screen with black color
W3D_DrawTriStrip(context,&tris);
W3D_UnLockHardware(context);
DBIport[1]=0;
ChangeScreenBuffer(screen, myScreenbuffer1);
Result the same. Just halt. If adding WaitBOVP(&(screen)->ViewPort); it works, but the same problem - blinking.
-
RWO wrote:
Karlos do you know how to do window double buffering?
-RWO
Piru is right in that there is no such thing. However, if you AllocBitmap() a BitMap using the display's BitMap as a friend, you will create an offscreen buffer you can render to.
You then use a call such as ClipBlit() to blit the offscreen buffer to the window. It isn't as fast as fullscreen (the blit actually does take some measurable time on older cards), but you achieve desired effect.
-
EntilZha wrote:
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.
It does use ScreenBuffers.
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.
It hardly ever fails to swap the screen buffer, anyway.
I ran a piece of code for two hours solid when testing something. In that time, the ChangeScreenBuffer() never failed once. I was curious to see if the while(!ChangeScreenBuffer(...)); call busy looped so had it increment a counter. It was still zero after the strain test finished.
I'd say Thomas remark here was understated even.
-
@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 (http://www.amiga.org/forums/showthread.php?t=14095) 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?
-
BTW, the tall screen method/scrolling for double buffering will not work if there's any screen promotion utility that does screen centering active. The user ends up looking at the middle of the drawing area seeing a frame of the bottom part of the screen on top and vice versa... It took me *ages* to figure out what the hell caused that problem! :-)
-
Karlos, does it make a big difference speed wisely to have a friend bitmap? I usually just allocate a bitmap with certain colour format properties and use BlitBitMapRastPort(), letting the OS handle all kind of conversion and saving me the trouble to support various possible colour formats.
-
Mr_Capehill wrote:
Karlos, does it make a big difference speed wisely to have a friend bitmap? I usually just allocate a bitmap with certain colour format properties and use BlitBitMapRastPort(), letting the OS handle all kind of conversion and saving me the trouble to support various possible colour formats.
It does indeed make a difference. Depending on your RTG card/driver, you might find that your graphics are converted by software.
I benchmarked the OS conversion and discovered that all cross-format blits on my CGX/Permedia2 were done in software by the driver software and not particularly quickly either. As a consequence I wrote my own routines and a 2D function LUT to do the job. These were hand optimised asm that did each possible conversion (there are less than 14x14 - most conversions are symmetrical) as fast as possible, taking advantage of 32-bit accesses, rotate instructions etc not available at the C level. They outperformed the OS blit routines by up to 3x on my system depending on the source/destination formats.
Anybody who ever ran my pixeltest tool has inadvertendly seen these routines, pixeltest was actually written purely to benchmark them (unbeknown to the users at large, you can specify the source data format on the command line).
Bottom line is:
Allocate your offscreen BitMap as a friend of the display. This ensures
a) that the BitMap is in Video memory
b) that the BitMap in the same format as the display, meaning that any Blit will be done in HW.
For Warp3D's hardware acceleration to work, (a) is absolutely essential anyway.
The downside is that you will have to care about the supported formats yourself. However, you would be very unlucky to encounter anything other than the following hardware formats
8-bit CLUT
15-bit RGB big endian (A1:R5:G5:B5)
15-bit RGB little endian
16-bit RGB big endian (A0:R5:G6:B5)
16-bit RGB little endian
32-bit ARGB
32-bit BGRA (just 'little endian' ARGB32 ;-) )
which is a lot less than the total possible number of formats supported.
Even 24-bit packed pixel modes are rare on any half modern graphics card.
Only rely on the OS to do the conversion if speed is not essential to your application. Or at least allow the user to choose (I envisage newer drivers that properly do colourspace conversion in hardware will appear)
-
@Karlos: thanks for interesting answer. Could I get your pixeltool utility? I want to try it :)
-
@Mr_Capehill
Sure, but it is obscenely boring to watch :lol:
I'll put a version up in a moment (and edit this post when done).
-edit-
I lied, I posted a new post. Oh wait, no I didn't, this is an edit....
/me crashes in an infinite loop...
-
You can find pixeltest here (http://megaburken.net/~karlos/demos/)
-
wow Karlos
your Warpdemo prog is impressive!!!
Why don't you public it somewhere?
10 minutes job, a screen grabber and voilà . . . GREAT :-)
-
@Framiga
Hehe, glad you like it. It sort of is public, just not on aminet :-)
Note: epending on your 3D driver and wether or not I compiled the gfxlib of the framework to use the warp3d v3 functions for lines, the "show mesh" option might not work at all.
So, let's see your picture then :-D
-
i've done a joke to my nephew (10 years old).
I prefer don't public it . . . but i've intention to build some animations.
I'll post here soon
Thanks :-)
EDIT- about the mesh, should it be a sort of grid?
-
If I weren't so lazy, I'd add the options to save the images and deformations directly.
I sort of had the idea of literally allowing you to save any particular deformation as a keyframe to a file that could then be used to make animations and so on.
However, it was actually written as a sort of fun way to estimate texture fill rates more than anything (I took that code out of it before making it a toy) and so on.
If you look at the source code (which should be included, but you need the framework to build it), you can see it isn't something I really lavished too much effort on ;-)
-
with a little effort, its possible to do incredible things.
btw . . . Warpdemo accepts only 256x256 pics?
I've done only some simple test but others will follow.
About looking inside the source . . . Karlos do you wanna kill me :-)
Its chinese for me :-(
-
Framiga wrote:
EDIT- about the mesh, should it be a sort of grid?
The 'show mesh' option should show a line grid on top of the basic image, which is then dimmed slightly, showing you where the vertices are.
However, I think the current build of the gfxlib part of the framework was compiled using *only* warp3d vertex array methods.
It so happens that for 680x0/OS3.x, only an unreleased (experimental) permedia2 actually supports all the warp3d v4 drawing methods. I know the 4.2 driver and the equivalent voodoo drivers certianly don't do it.
In the gfxlib / Rasterizer class, there is a compiler switch to render points and lines using the V3 methods because of this, but it was switched off here I think.
-
Framiga wrote:
btw . . . Warpdemo accepts only 256x256 pics?
In theory, any power of 2 * any other power of 2. Basically the texture limiations of warp3d itself apply.
If you are stuck on 256x256, I bet you have a voodoo :-D
I got a 512x512 one working on my permedia2 no problem ;-)
-
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 :-)
-
Ok Karlos CVPPC here too and works with 512x512 as well.
Show Mesh, shows only a dimmered copy of the original image.
-
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.
-
like this?
10.AmigaOS:> warp image "Ram Disk:gianca.jpg" -sysdebug
[ Info ] SystemLib created memory pool
[ Info ] SystemLib initialised
[ Info ] Rasterizer:: initialized
[ Info ] Rasterizer:: finalized
[ Info ] SystemLib freed memory pool
[ Info ] SystemLib finalized
I'm not 100% sure, but:
128x128 works
64x64 works
600x400 doesn't works
400x400 doesn't works
OOOPS sorry . . . you said power of 2 (not multiple of 2) :oops:
-
@Karlos:
for some reason I can't get to your page. FireFox Says "www.megaburken.net could not be found".
-
@Mr_Capehill
It's a DNS problem, try http://81.172.167.40/~karlos/demos/
-
@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 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?
-
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.
-
@Piru: kiitos :)
Will test those tools ASAP.
-
@Karlos
WarpDemo works fine under MorphOS btw, playing with some 1024x1024 textures atm. Funky :-)
warpdemo1.jpg (http://www.iki.fi/sintonen/pics/warpdemo1.jpg)
-
@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
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 (http://www.iki.fi/sintonen/pics/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)
-
REPAIRED!!! (http://xoomer.virgilio.it/cieffeeditingvideo/pic/warpdemo2.jpg)
. . . or quite :-D
-
@Framiga
Access forbidden :-(
-
@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
With 1024 x 1024 texture, 100 x 100 mesh is fast still, can't see any difference to lower values.
warpdemo3.jpg (http://www.iki.fi/sintonen/pics/warpdemo3.jpg)
Going up from there adds some visible slowness (I guess it takes over a frame to redraw things then).
-
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 ;-)
-
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.
-
@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 ;-)
-
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.
-
Want to up, this old thread. What about this kinds of double-bufferings over WarpOS ? Will be here some kind of slowdowns in fact of context switching ? If yes, how it possible to avoid them ?
-
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.
-
Hey Karlos, you still alive ?:) I tryed to write you some time ago, but looks like you cnahge email ..
Well, W3D_LockHardware based on Warp3dPPCBase will also have context switching you mean ? (why? i think it will be, if i will use warp3d.library (not ppc ones) from wos application, but with warp3dppc.library, here is must be no context switching, right ?)
Also context swtitching in fact of idcmp, will be have big slowdown or not so ? At this moment, i see really slowndowns if compare it with 68k version - in SwitchBuffer function. I dunno why, in fact of only WaitTOF(); or in fact all of this 68k fuctnions like ChangeScreenBuffer and WaitTOF.
As i understand, i just need to create fucntion like this:
void SwithDisplay_WarpOS(W3D_Context *context, struct Screen *screen)
{
Run68k(here is an old 68k fucntions)
}
?
-
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.
-
@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, question for you ;) If i remember correctly, you know Bvision driver very well ? So, maybe you can give me a hint/point about what i can do with it: i have a w3d request, with 15/16/24 bit modes on bvision. If i choice 15/16 modes - gfx looks ok. If i choice 24bit modes, i have strange corruption.
here is 15-16 bit example: (http://x25zine.org/1.jpg)
here is 24bit example: (http://x25zine.org/2.jpg)
sources are the same, and works fine on a1/peg/winuae/a1200/a4000(voodoo/radeon/cybervision). Only on bvision this kind of corruption.
Modes for texture is: RGB565, ARGB1555.
States: Gouraud only.
Have any idea maybe ?
It's not so matter of course, but i am just in interest what is it and how i can avoid it
-
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, latest public version with latest patchs. I tryed it on 3 different setup. (ppc/040-33/bvision , ppc/040-25/bvision and my ppc/060/bvision). In all case result with 24bits are the same.
-
for me it looks like pixel are swapped. Is it really a 24bit mode and not 32bit ?
If ti 24bit and its handled as a texture I'd say there is a word swap when transfering the texture to graphics memory.
-
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) ?
-
Karlos, it's fullscreen mode, i just open 640x480 screen and open 640x480 window on it. For W3D_RequestModeTags: aslsm_minDepth:15, aslsm_maxdepth:32. For openscreen:
SA_Depth: 32. Why is here 32: becouse if i will setup 16, double-buffering just do not works for voodoo3. (but on voodoo3 only 16bit modes can be choiced, stange a bit).
-
funny to see that I am getting the same kind of corruption on my amigaone with radeon 7500 when launching QW... :crazy:
-
I was test on one machine a 'wipeout' game. And in window, with 24bit of depth, with W3D_Permedia2_PPC.library 4.2, the same corruptions, look at this:
With 16bit depth of screen:
(http://x25zine.org/wip4_wb_in_16-bit.jpg)
With 24bit depth of screen:
(http://x25zine.org/wip3_wb_in_24-bit.jpg)
If change W3D_Permedia2_PPC.ibrary back to the 4.0, all os ok. With 4.2 this kind of corruption. And the same with W3D_Permedia.library.
I think if the same problem can be happened on A1, maybe it's problem with some kind of setup settings ?
ps. also i checked on 2 bvision configs, some ppc demos (from encore) and, if you use 24bit screen, and run these demos in window mode, you can see this kind of corruption while text rendering is happenen! looks like as Karlos pointed, bvision 4.2 driver have buggy handler of textures which depth is lower, then mode which was choice. (expectally problem with 16<->24bit)
-
have someone any idea, how works with warp3d in windowed mode ? i mean for example, how do smooth scrolling or fade effect, if there no double-buffering possible ?
-
Let's up this pretty old thread about warp3d.
Right now i tryed to write somethink warp3d based for AROS, and there is an interesting point: Aros not have ScrollVPort() or ChangeScreenBuffer() (ie. aros not have system friendly double-buffering, at moment only on at all - dunno). But i still in interest to avoid flikiring here and so on.
So, main idea which i talk about was by Alan (wazp3d author), it's make a 'window double-buffer' (about someone asked in this thread before). Ie, you create a window on screen (public, on your own), and after make a new buffer with copy of bitmap. Like this:
InitRastPort( &bufferrastport );
ScreenBits = GetBitMapAttr( window->WScreen->RastPort.BitMap, BMA_DEPTH );
flags = BMF_DISPLAYABLE|BMF_MINPLANES;
bufferrastport.BitMap = AllocBitMap(large,high,ScreenBits, flags, window->RPort->BitMap);
if(bufferrastport.BitMap==NULL)
{printf("No Bitmap\n");goto panic; }
After create a context, which pointed to copy of our bitmap (i.e. our buffer to which we will draw for first).
context = W3D_CreateContextTags(&Error,
W3D_CC_BITMAP,(ULONG)bufferrastport.BitMap,
W3D_CC_YOFFSET,0,
W3D_CC_DRIVERTYPE,W3D_DRIVER_BEST,
W3D_CC_INDIRECT,TRUE,
W3D_CC_DOUBLEHEIGHT,FALSE, //DoubleHeightON,
W3D_CC_FAST,TRUE,
TAG_DONE);
And next just draw somethink by warp3d, and after it's done, you just copy this bitmap-buffer content to the your window, like by this way:
BltBitMapRastPort(bufferrastport.BitMap,0,0,window->RPort,0,0,large,high,0xC0);
So.. it works, but it's not so fast of course if compire it with screen double-buffering.
Maybe someone have any other idea of how can be done double-buffering by fast way ?