Wblit or Getashape - one of them makes me nervous

[peceha]

Hi,
today I started playing with something I gave up more than a month ago (because I couldn't get my graphics display correctly).

Look at that code:

WbToScreen 0
ShowScreen 0
WBStartup

BitMap 0,800,600,2
LoadBitMap 0,"ram:whitePicture.iff"

cnt.w=0
For x.w=0 To 9
  GetaShape cnt,x*16,0,16,16
  cnt+1
Next x

wFlags.l=$2|$4|$8|$400
Window 0,0,16,190,190,wFlags,"test",0,0

cnt.w=0
For y.w=0 To 7
  For x.w=0 To 9
    WBlit cnt,8+x*16,8+y*16
    cnt+1
    If cnt>9 Then cnt=0
  Next x
Next y

Repeat
  ev.l=WaitEvent
  If ev=$200
    Free Window 0
    End
  EndIf
Forever

The picture it points to is just a blank IFF filled with white color.
Every time I run that code I get different results (and no matter what color is set to background in picture's palette)

Below you can see just 3 different results (my WB is running in 4 colors, the whitePicture.IFF is saved in 4 colors with WB palette):
Everytime something else - all it should be is just one solid white square (10*16)x(8*16) pixels big
.

What am I doing wrong?
Thanks.

[Daedalus]

Both WBlit and GetaShape work fine for me in general, though it's important that the parts of the puzzle are all the same depth. Are you sure the WhitePicture.iff file is only 2 bitplanes deep? That sort of corruption looks like there are excess bitplanes somewhere in the process, but if everything is definitely 2 bitplanes deep I don't know what is happening. You can try do a SaveBitmap to save it under a different filename after it's loaded to see if it's being loaded correctly. You could also blit to a bitmap and then transfer that bitmap to the window afterwards (BitmaptoWindow command), which allows more versatile blitting operations using the standard Blit commands, though it is slower if you were looking for doing some sort of animation in the window.

As an aside, do you need the cnt variable when you're using a For...Next loop? cnt will always just be x+1...

[peceha]

Ahh!!, No, I do not need it - it is a leftover from a bigger version of the script - I just haven't noticed it

I'll check step by step everything you wrote and come back soon.
For now I can say that IFF is for sure 2 bitplanes deep.

[peceha]

For now I only checked SaveBitmap and already can see something strange is going on:

- my original picture is all white with the palette order: gary(set as background), black, white, blue.
- I can open that picture in multiview/ vissage/dPaint/pPaint/adPro and I see white everywhere

- now I use SaveBitmap 0,"ram.test.iff"
- I open that new picture in multiview and .. there is no white color at all - everything is gray (same in adPro)
- I open it in vissage/dPaint/pPaint - all is fine - white color everywhere

Just resaved the main pic in pPaint (before I used dPaint for painting) - but it didn't help - same problem...

So for now I need to solve that problem with vanishing white color ...


---------------------------
something is messing up the colors (on the left original picture, on the right after SaveBitmap, both displayed in Multiview):
- GRAY: BLACK
- BLACK: BLUE
- WHITE: GRAY
- BLUE: WHITE

[clenched]

Try adding an extra ,0 after the loadbitmap line and wherever savebitmap is used. This ensures a correct palette instead of pot luck. The program worked for me even before doing anything else.

[peceha]

I used BitmaptoWindow+Blit - no luck, same as before.

@clenched
,0 at the end of LoadBitmap/SaveBitmap solved the problem with wrong palette after SaveBitmap - now the saved image has the same color - Thanks !!

But I still do not know what is going on here, why the display in the window is corrupted at my side ...
... my WB is a clean install from floppies + Opus5 + almost nothing else...

-------------------
The last thing I could do was to resave my original image - I used this time artPro: just loaded the old one (800x600x4col) and scaled to 320x256 (also changed display ID to LoRES) and saved it.
Didn't help - for the first start of the program there was one big white square in the window so I almost jumped out of chair but next and next and next time it was all broken like before.

[peceha]

I used WinUae and the script is... working fine - no glitches.

Does it mean that my Amiga could be damaged?

[Daedalus]

Is it the exact same setup on the real machine and in WinUAE? Perhaps there's some patch that's interfering with the blitting operations. It's very strange that BitmaptoWindow and Blit aren't working - it makes is sound more likely that it's just not loading the initial image file correctly, though it appears to be saving it ok again.

what happens if you load a smaller bitmap? Perhaps there's a bug in the loading command with that sized bitmap.

[peceha]

I belive it is - I installed WinUAE maybe 2 months ago and then I just took all the files from amiga's HD. I do not recall changing anything important on real Amiga since then.

I set the Bitmap to 320x256 (Bitmap 0,320,256,2) but it didn't help.
I commented out all addons (fblit, ftext, blaze..) from my startup-sequence and switched off Opus5.
I put back iPrefs instead of fastIPrefs
Then I run through user startup and also cleaned up what I could.
After restart I get the same glitches.

------
I have made an executable from this code and one person on polish forum just tested it on another real Amiga - the same result: glitches


------

WbToScreen 0
ShowScreen 0
WBStartup

BitMap 0,320,256,2
LoadBitMap 0,"ram:test.iff",0

wFlags.l=$2|$4|$8|$400
Window 0,0,16,190,50,wFlags,"test window",0,0

GetaShape 0,0,0,16,16
WBlit 0,0,0

Repeat
  ev.l=WaitEvent
  If ev=$200 Then End
Forever

Now that code just takes one tile from file and blits it.
Same result - few times in a row everything is ok, then next few times it is not.

[peceha]

Thank you all for help.

Problem solved!! all the glitches are gone

In the early startup menu I had to tick "disable processor cache"


But now the question...
Does it have to be always off when I want the program to work correctly?

[Daedalus]

Very odd - I still think it's due to a bug of some sort and disabling the caches is just hiding it. I can't remember off hand but I'm sure there are alternative bitmap loading commands you could try instead to see if you can get around the issue that way. I know I've been able to load bitmaps and blit shapes on my various machines without disabling caches, so there must be something funky going on somewhere...

[peceha]

I will look for alternatives to LoadBitmap in that case. Even for me it's hard to believe that it is normal "behavior".

But first (since now I can finally see my graphics on the screen ) I need to fix small issue in the code (some "room tiles" have wrong IDs thus are showing in wrong places).

Well... I'm quite excited anyway, hehe.
Thanks!!!

[clenched]

Hmm. Same on my A500 & GVP A530. Off works. On does not.

[peceha]

On the Polish forum one guy just wrote a short reply:
"WBlit was used before blitter"
"before" was capitalized.
I dont know what it means -will have to ask him to explain.

[Daedalus]

Hmmm, I haven't come across that issue before, but he may be onto something. Try adding a VWait at the top of the loop to sync your drawing with the display.

[peceha]

VWait didn't help.
I think that guy from other forum was confused a little bit - he saw WBlit command in the script and assumed it had something to do with waiting...

I'm 100% sure it cannot be a bug - it is just impossible
Almost every program written in blitz is using blitting and there are no problems at all.
And the script from my 1st post is just blitz's basics

EDIT
I loaded that code into AmiBlitz as well - same result.

[idrougge]

If the cache is destroying things, try to call CacheClearU_ at the appropriate moment.

[Toni Wilen]

Sounds like you have weird/bad MMU setup that makes chip ram cacheable.
EDIT: Does anything change if you install this: http://aminet.net/util/libs/MMULib.lha

[peceha]

Originally Posted by idrougge

If the cache is destroying things, try to call CacheClearU_ at the appropriate moment.

I tried in many places - at the very beginning, just before GETASHAPE and just before WBLIT - no improvement, hmmm...

Sounds like you have weird/bad MMU setup that makes chip ram cacheable.

But this happens on other amigas as well.
- #9 you can see a picture from another real amiga
- clenched in post #13 attached 2 screenshots proving the same (now the attachment is gone)

Just saw your edit - will check it right away

[peceha]

Originally Posted by Toni Wilen

Sounds like you have weird/bad MMU setup that makes chip ram cacheable.
EDIT: Does anything change if you install this: http://aminet.net/util/libs/MMULib.lha

Thanks!!!
That package did the trick
The glitches are gone.