krabob
Member |
Hello all. I have a problem, and questions will come at the end of this text.
For some reasons (another amiga coder motivating me), I get back to coding effects keeping intuition, with sas c and phxass. I aim some AGA vanilla effects using the blitter, and I'm quite new into coding blitter, even if I have quite an idea of what it can do.
The first thing I did was a converter from gif to amigaOs's "struct BitMap", the function can also extract a mask, and optionaly output "interleaved bitmaps".
Then I played around doing bobs with intuition screens having the SA_Interleaved flag and graphics.library/BltMaskBitMapRastPort().... it was drawing bobs ok, but It seemed to use a slow "blit per line", instead of one single blit for the whole bob as it should be the case with interleaved bitmaps.
So I started coding my own "one blit per bob" routine,( and had to add an optionnal "16 pixel empty column at the right" to my "gif to struct BitMap" function, so it could work.)
1st approach I tried:
OwnBlitter()/WaitBlit()/(asm things ending with move.w d7,bltsize(a6) ) /WaitBlit()/DisOwnBlitter()
It worked, but "sometimes" I had a flicker with the bob not drawn.
Then I tried a second approach:
OwnBlitter()/WaitBlit()/Forbid() (asm things ending with move.w d7,bltsize(a6) ) /WaitBlit()/DisOwnBlitter()/Permit()
... I tested an extra Forbid/permit because I though someting could take over my blits,
it changed absolutely nothing.
Then I searched some forum and read that if the copper was reset during a blit, it stops and trashes the current blit and can change any of its dma pointers. And sometimes yes, my memory got trashed elsewhere.
Then I figured out I was under intuition and that intuition was doing its own copper changes with high priority. The fact I have a lot more "blit flickering" when I move the mouse pointer tends to prove this point. And it explain that Ownblitter() and forbid() couldn't help.
So I searched How the fuck it was safe to do my big hardware blits under intuition...
Then I tried to use graphics.library/QBlit() and QBSBlit() because according to the autodocs, it has prevalence over OwnBlitter() and can be used to synchronize with the beam.
It took me some times to make QBlit() work (absolutely *No* example of using that in official developer archives, nor anywhere), and with some waitTof()/Waitblit() at the right place I have less flickering, but the nasty flickering bug is always there ! And memory can be trashed anywhere at any time.
So How the fuck is it possible to blit under intuition ?
Is QBSBlit() meant to synchronize blits so that they are not affected by copper resets ?
Is there a signal system to just tell intuition to not reset the copper until a blit is finished ?
Do "bltxdat" have to be set for rectangle blits ? I don't set them, maybe I should ?
Any idea of what a simple function like "BltClear()" does, to not be bothered by the intuition copper ?
Ok, I have an archive with 3 nice exe and a sas c makefile:
[url]http://victorien.ferry.free.fr/agifd.zip[/url]
testAGifOS13.c does "testagif13" that reads a 32 color gif and is A500/OS1.3 compatible.
testAGifOS30.c does "testagif30" and does some bobs with BltMaskBitMapRastPort() and gifs in 16 colors. (OS3 only)
testAGifOS30testblit.c has the main() for "testblit" with the more complex interleaved/asm bobing I tried with QBlit() and OwnBlitter(). (set #define USE_QBLIT 1 to use the queue)
Thanks for reading.
|
Blueberry
Member |
Really nasty bug, that one. :(
Presumably, the system disables blitter DMA momentarily while writing to COPJMP if it knows that the blitter is running. Apparently OwnBlitter() is not enough to tell it that this might be the case.
One workaround you could try: The system is likely writing to COPJMP during the graphics.library vblank interrupt server. You could try adding two vblank interrupt servers (using AddIntServer) - one with higher priority than graphics.library (which has priority 10, according to ARTM) and one with lower. The high-priority one would disable blitter DMA, and the low-priority one would enable it again.
As for your other questions:
The BLTxDAT registers are only used when the corresponding blitter DMA channel is disabled. And even in that case you only need to set it if your minterm logic function depends on the value in that particular channel.
You don't need to add the 16 extra pixels on the right. This can be handled using the first/last word masks. As long as you use the A source channel for either your image or your mask, you can just set the width one larger than the image width (as you do now), the source modulo(s) to -2, the first word mask to $ffff and the last word mask to $0000.
Other values for fwm/lwm are used for plucking out source data which is not word aligned (for instance the characters of a font are usually packed tightly in a bitmap).
|
