Ah, last time :) ADI wrote: > There is a solution. Have you read what Rudolf said about allegro > game > library? AFAIRemember, it requires a frame buffer double the size of > screen. The driver gives it, but it only uses the first half to > display > on screen. Then there are 2 choices: 1) you draw in the 2nd part and > instruct the card to start retracing from it (swap buffers), then > draw > in the 1st part and swap again, and so on; 2) you could just use the > first part, prepare things in the 2nd, then blit using 2D HW with of > without transparency. > I'm not sure about this: but I think you can even request a frame > buffer 3 times the screen size. My drivers support any size you want, as long as the hardware supports it. Even when only partial support exist: you will get it. With this I mean: the acceleration engine has smaller constraints than the CRTC hardware. If your buffer gets too large the acceleration hooks nolonger get exported if you request them. Although I implemented this, it's quite complex to be precise, and there's no means for you to know beforehand if you'll get acceleration. Therefore I am thinking I should remove non-accelerated support at some point. Note also: I do not advice to use allegro's trick. The large screen is meant to be used for a _virtual workspace_. If you alternatively use it to trick a double-buffer-whatever solution, you nolonger have the virtual workspace thing available (cleanly). Or things like the pageflipper demo. -------- Once more about overlay. Axel's right: video overlays are not visibly transparant. Showing is determined by a specific color on the background. So you loose the background. modern cursor overlay's however _are_ (AFAIK). the RGB32 cursor is of course RGB24 with 8-bit alpha. RGB16 should be 1-bit alpha. Old cursors are still transparant: you preset one of the four colors to be transparant. Of course, this still means you only see the cursor image OR the background: no mix. Unlike RGB16/32 cursors. AFAIK. Bye! Rudolf.