English Amiga Board


Go Back   English Amiga Board > Coders > Coders. Asm / Hardware

 
 
Thread Tools
Old 10 September 2014, 19:34   #1
krabob
 
Posts: n/a
Hard Blits under intuition & Gif To "struct BitMap" converter

Hello, I already posted this in another forum... no panic.

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 I could do my big hardware blits under intuition safely...

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

http://victorien.ferry.free.fr/agifd.zip

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.
 
Old 15 September 2014, 17:38   #2
phx
Natteravn

phx's Avatar
 
Join Date: Nov 2009
Location: Herford / Germany
Posts: 1,566
Quote:
Originally Posted by krabob View Post
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.
Not suprising. You didn't synchronize your Blits to the VBLANK and the multitasking system can also slow you down at any time. Also graphics/intuition might "own" the Blitter themselves, for a longer period.


Quote:
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.
Also not surprising. Your function might still be delayed for a variable amount of time, until OwnBlitter() is successful.


Quote:
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.
Hmm... are you sure the OS is writing COPJMP every frame? I cannot remember at the moment. Or maybe only when using interlace?


Quote:
So How is it possible to blit under intuition ?
I never did that. As I either use the graphics.library or take over the whole system. Otherwise, exactly as you did: either OwnBlitter/DisownBlitter. Or using the QBlit() functions.

Quote:
Is QBSBlit() meant to synchronize blits so that they are not affected by copper resets ?
I would guess so. Use bn_beamsync in the blitter node to choose the VPOS to sync with.

Quote:
Is there a signal system to just tell intuition to not reset the copper until a blit is finished ?
Don't think so.


Quote:
Do "bltxdat" have to be set for rectangle blits ? I don't set them, maybe I should ?
No. It can be used as a static preset for a channel, when you don't enable DMA for it.


Quote:
Any idea of what a simple function like "BltClear()" does, to not be bothered by the intuition copper ?
BltClear() does OwnBlitter(), WaitBlit(), blitter-clear, DisownBlitter(). Nothing special there.

Are you sure about these memory corruptions? Otherwise I would guess that you just need to synchronize your Blits properly...
phx is offline  
Old 15 September 2014, 18:25   #3
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 3,168
Quote:
Originally Posted by krabob View Post
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.
Were you writing to the Screen's BitMap (as opposed to a window's)?

Quote:
Originally Posted by krabob View Post
1st approach I tried:
OwnBlitter()/WaitBlit()/(asm things ending with move.w d7,bltsize(a6) ) /WaitBlit()/DisOwnBlitter()
You don't need to WaitBlit() before DisownBlitter().

Quote:
Originally Posted by krabob View Post
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.
Are you sure Intuition was writing to COPJMP? Because if your bits weren't beam-synchronised, the extra CPU usage caused by moving the mouse would change the relative positions of blits and the raster beam.

Quote:
Originally Posted by krabob View Post
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.

Is QBSBlit() meant to synchronize blits so that they are not affected by copper resets ?
Don't know, but that hardware bug is probably not related to the flickering you're seeing.

With QBlit() and QBSBlit(), you don't need to call WaitBlit() in between blits. WaitBlit() just busy-waits until the current blit is finished, which wastes CPU time. Workbench uses QBSBlit() when you drag icons around.

With QBSBlit() you can have your blits start when the raster is just below the data being blitted, hence there should be no flicker. And you make better use of raster time than calling WaitTOF() then doing all your blits. QBlit() isn't beam-synchronised so you would get flicker using that.

Not sure how relevant it is, but see this posting and view the two AVI files. There's a noticeable difference between beam-synced blitting and not-synced.
mark_k is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
"Reminder "Lincs Amiga User Group aka "LAG" Meet Sat 5th of January 2013" rockape News 4 30 January 2013 01:06
CD32 Image-Name-Bug: "...(bla)[!].zip" -> "...(bla)[" / "...[test].zip" -> "...[tes" cfTrio support.WinUAE 8 18 December 2012 17:31
"Hard drive" access causes sound & video stuttering Gameboi project.WHDLoad 3 15 January 2009 18:59
"Photon cell animator" & "Anim Workshop" amiga request.Apps 5 05 April 2008 17:22
Scanned reviews of "Drop It" & "Project Ikarus" Tim Janssen HOL contributions 1 15 May 2003 10:55

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:49.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2020, vBulletin Solutions Inc.
Page generated in 0.06162 seconds with 12 queries