FX functions BUG(s)...or maybe not? only AmigaOPS4.x related

[Tuxedo]

Hi Andreas!

I think to have discovered some weird and really annoing things regarding fx functions...

First and minor:

WaterRippleBrush() function accept zero as Wave lenght parameter but that locks the entire system and you have to reset...

The below issue happens only on AmigaOS4.1Upd4 since I tryed it also on MOS 2.7 and dont happens(i.e. it works as expected)...
But was weird the same imho...

Major issues:

All the fuinctions that locks the system here on AmigaOS4.x have a really strange behaviour...

Try the code below:

Code: Select all

@DISPLAY 1, {Width = 800, Height = 600}

LoadBrush(1, "ram:test.png")

TextOut(#CENTER, #CENTER, "Please Wait, processing image...")

EmbossBrush(1, 8)

DisplayBrush(1, #CENTER, #CENTER)

WaitLeftMouse()

Well...
The TextOut() function will display him text only a moment after the EmbossBrush() function have finished the elaboration and than the image was displayed...
If you comment the DisplayBrush() line than you get the TextOut() message displayed after elaboration finished but only after...really weird no? Since Hollywood wasnt multithreaded that dont have any sense right?
In theory before starts EmbossBrush() function Hollywood have to process the TextOut() function and complete its task than (and onoly than) continuing processing images...no?
Also if AmigaOS4.x have the bug you tell us regarding the locking of the system while using such functions why The TextOut() wasnt processed before EmbossBrsh() by Hollywood interpreter? Wasnt odd?

Thank you!

[airsoftsoftwair]

WaterRippleBrush() function accept zero as Wave lenght parameter but that locks the entire system and you have to reset...

True. I'll fix this.

Major issues:
All the fuinctions that locks the system here on AmigaOS4.x have a really strange behaviour...

This seems like an issue with OS4 pointer locking. I suppose that the screen refresh is disabled while the system is locked, so the TextOut() result doesn't get visible. Try to insert a VWait() after TextOut() call. Then it should work but of course it's not a nice solution. However, it's up to the OS4 team to change this behaviour.

[Tuxedo]

mmm....

I solved putting a Wait(1) putting VWait() or Wait(1, #MILLISECONDS) dont help....

But, sorry, I can know why if Hollywood was syncronous and not multithreading the TextOut() function was affected by that issue...

However for the moment I'll put that Wait(1) on that locking commands...

Hope that AmigaOS4.1.5 have that fixed(I will try to contact some X1000 user to test..)

[airsoftsoftwair]

Drawing is usually an asynchronous operation (results are deferred until the next vertical refresh). That's why you get this behaviour. Normally, you won't notice this, though. This just becomes visible on OS4 because OS4 locks the entire system.

[Tuxedo]

For the "zero" behaviour also Pixelate and Contrast returns error if you pass "0" to them...

For the OS4.x bug I can update the situation on X1000:

A guy kindly tested the script:

Code: Select all

@DISPLAY 1, {Width = 800, Height = 600}

LoadBrush(1, "ram:prova.png")

TextOut(#CENTER, #CENTER, "Please Wait, processing image...")

EmbossBrush(1, 12)

DisplayBrush(1, #CENTER, #CENTER)

WaitLeftMouse()

SetFillStyle(#FILLCOLOR)

Box(0,0,800,600, #BLACk)

TextOut(#CENTER, #CENTER, "Please Wait, processing image...")

Wait(1)

OilPaintBrush(1, 12)

DisplayBrush(1, #CENTER, #CENTER)

WaitLeftMouse()

that here on AmigaOS4.1.4 works only if the "Wait(1)" was present.
On X1000 the "Please Wait, processing image..." phrase appear in first and also in second step but the mouse was locked as here, so something seems solved from OS4.1.4...

[airsoftsoftwair]

Might also be just accidental luck. If the vertical refresh occurs at the right moment then I'm sure the Wait(1) isn't necessary on your setup either. It's just a matter of timing. The deeper problem is that OS4 locks the entire system when locking bitmaps. I've informed the OS4 devs once again about this issue but still no reaction :/