Odd Rendering behavior with image_rotate{} function

Odd Rendering behavior with image_rotate{} function

I am running AmiBlitz 3.6.1 Beta on an AmigaOS 4.1 FE machine. I tried this also on AmigaOS 3.x in WinUAE and had the same odd behavior.

I modified the example program dbl_simple_10_control.ab3. Towards the end of that code I changed this:

dbl_QBlit {2,x,y} ;draw ball

to this:

image_RotateBlit{2,x,y,0}

I modified it to test the image_rotate function for a project I'm considering porting to AmiBlitz3.

The odd rendering is that when the ball is rendered, (1) the image loses it's transparency and (2) the rendered image flashes every second or two.

Any ideas of how to fix these two odd behaviors with image_rotate{} ?

I ask because I'd like to use this function for a top down view of entities in a game.

Thanks in advance for any suggestions.

[Daedalus]

First things first - the 3.6.1 release has some bugs and quirks, and it might be a good idea to download the latest snapshot to update its components (clicky). Many parts have been fixed or modified since the 3.6.1 release. I'm not sure if that will fix the problem, but it's worth doing anyway - the image include was updated in 2016 for example, whereas 3.6.1 is two years older.

Have you tried turning the fast parameter on or off when calling the function? I'm not sure what it does, but it's possible it affects the rendering in some situations. The flashing could simply be that the function is a little slow to execute compared to the QBlit function, so you end up missing the refresh. Are you doing double-buffering? How are you handling that?

Originally Posted by Daedalus

First things first - the 3.6.1 release has some bugs and quirks, and it might be a good idea to download the latest snapshot to update its components (clicky). Many parts have been fixed or modified since the 3.6.1 release. I'm not sure if that will fix the problem, but it's worth doing anyway - the image include was updated in 2016 for example, whereas 3.6.1 is two years older.

Have you tried turning the fast parameter on or off when calling the function? I'm not sure what it does, but it's possible it affects the rendering in some situations. The flashing could simply be that the function is a little slow to execute compared to the QBlit function, so you end up missing the refresh. Are you doing double-buffering? How are you handling that?

I downloaded the snapshot of AmiBlitz3. I had the same flickering effect with that version. I tried altering the fast parameter but that didn't stop the flickering either. It is double buffering.

I'm still trying to solve the image_rotate flickering but I've run out of possible solutions at the moment.

[Daedalus]

If you're double buffering, there should never be any flicker since the shape is already on the bitmap by the time you display it. Are you sure your double buffering logic is sound? Using standard image blitting routines from image.include bypasses the automatic double buffering offered by the dbl_display include, so you have to implement your own bitmap swapping routine. In that case it's probably best to avoid using the dbl_display include altogether, as I don't know how well it will react to you swapping its bitmaps out from underneath it. It certainly won't be the most efficient method anyway.

Maybe it's not double buffered. Here's the code below. It's from AmiBlitz3/Sourcecodes/Examples/dbl_simple_10_control.ab3.

My added code is towards the end on the line with this comment: ************ Image Rotation Test ***********

START OF CODE:

optimize 7
WBStartup
XINCLUDE "dbl_display.include.ab3"
XINCLUDE "intuition.include.ab3" ; we want intui.include for input

NEWTYPE.ball
x.f:y.f:xv.f:yv.f
End NEWTYPE

Dim List ball.ball(0)
If AddItem(ball()) Then ball()\x= 0,200,1,-2
If AddItem(ball()) Then ball()\x= 0,200,2,-1
If AddItem(ball()) Then ball()\x= 0,200,1.5,-1.5

gfxpath.s = "/Data/"
succ.l = image_Load {2,gfxpath.s+"glass_big",$FF00FF,20} : image_MidHandle {2}
succ.l = image_Load {1,gfxpath.s+"pattern"} : image_MidHandle {1}

succ & dbl_Init {"MyGame",#dbl_scr_BestModeID,640,480,24}
breakme.l = False

If succ
dbl_BGBlitPattern{1,0,0,!dbl_GetWidth,!dbl_GetHeight}

; print some instructions
dbl_BGPrint {"Use arrow keys or mouse to move, ESC to quit !",10,10,1}
x.f = !dbl_GetWidth/2
y.f = !dbl_GetHeight/2
a.s = "nothing pressed"

Repeat
dbl_Flip{}
dbl_Unqueue{}

; Get IDCMP message based input
; Use this for events like pause, exit or mouse etc.
Repeat
idcmp.l = intui_GetEvent{}
Select idcmp
Case #IDCMP_MOUSEBUTTONS
If !event_click ; Mouse clicked ?
Select !event_mb ; Which Mouse button
Case 1
a.s = "Mousebutton 1"
Case 2
a.s = "Mousebutton 2"
Default
a.s = "Cool, you have more than 2 mousebuttons!"
End Select
Else ; no, releaed !
a.s = "nothing pressed"
End If

Case #IDCMP_MOUSEMOVE
; The mouse was moved, get new absolute coos on screen !
x = !event_mx
y = !event_my

Case #IDCMP_RAWKEY
; Someone pressed or released a key
If !event_keydown
a.s = "Rawkey: $"+Right$(Hex$(!event_rawkey),2)+" => Vanillakey: \\22"+Chr$(!event_vanillakey)+"\\22"
Else
a.s = "nothing pressed"
End If

Select !event_vanillakey
Case 27 ; ESC
breakme = True
End Select

End Select
Until idcmp=0

; Here we can ask every raw key at any time for pressed/released
; Use this to control your space ship
If !intui_rawstatus{$4C} Then y-2 ; Up
If !intui_rawstatus{$4D} Then y+2 ; Down
If !intui_rawstatus{$4E} Then x+2 ; Left
If !intui_rawstatus{$4F} Then x-2 ; Right

; the same with mouse buttons
If !intui_joyb{1} Then ; mouse button 1 pressed ?
If !intui_joyb{2} Then ; mouse button 2 pressed ?

image_RotateBlit{2,x,y,0,1,0} ; ************ Image Rotation Test ***********
;dbl_QBlit {2,x,y} ;draw ball ;*** Commented out for rotation test ***
dbl_QPrint{a.s,x,y+20,1,-1,0}

Until breakme
End If
End

END OF CODE

Thanks, Daedalus, for your help on this.

[Daedalus]

Yep, that's double buffered, but it's using the dbl_display.include's internal double buffering method. You're bypassing that by using a non-double-buffering blit from image.include, which means just that shape isn't double-buffered, which is most likely what causes the flickering. You either need to abandon the use of dbl_display.include entirely to use those functions and implement your own double buffering (not as difficult as it might sound), or else blit the rotation to an intermediate bitmap, then use the result as a shape with dbl_QBlit to get it onto your display, which should work fine but might slow things down a little.

Originally Posted by Daedalus

Yep, that's double buffered, but it's using the dbl_display.include's internal double buffering method. You're bypassing that by using a non-double-buffering blit from image.include, which means just that shape isn't double-buffered, which is most likely what causes the flickering. You either need to abandon the use of dbl_display.include entirely to use those functions and implement your own double buffering (not as difficult as it might sound), or else blit the rotation to an intermediate bitmap, then use the result as a shape with dbl_QBlit to get it onto your display, which should work fine but might slow things down a little.

That makes sense. Thanks for the help. It's much appreciated! I may try blitting the rotation to an intermediate bitmap method first.