English Amiga Board

English Amiga Board (http://eab.abime.net/index.php)
-   Coders. Blitz Basic (http://eab.abime.net/forumdisplay.php?f=126)
-   -   Wblit or Getashape - one of them makes me nervous (http://eab.abime.net/showthread.php?t=91558)

peceha 28 March 2018 15:36

WBlit or GetaShape - one of them makes me nervous
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

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

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

Window 0,0,16,190,190,wFlags,"test",0,0

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

  If ev=$200
    Free Window 0

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?

Daedalus 28 March 2018 15:57

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 28 March 2018 16:07

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 28 March 2018 16:29

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

clenched 28 March 2018 19:17

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 28 March 2018 19:30

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

,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 ...:nuts
... 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 29 March 2018 08:11

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

Does it mean that my Amiga could be damaged?

Daedalus 29 March 2018 10:57

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 29 March 2018 11:20

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

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

Window 0,0,16,190,50,wFlags,"test window",0,0

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

  If ev=$200 Then End

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 29 March 2018 15:17

Thank you all for help.

Problem solved!! :spin 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 29 March 2018 15:46

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 29 March 2018 16:44

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.

clenched 29 March 2018 18:15

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

peceha 29 March 2018 18:30

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 29 March 2018 23:12

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 30 March 2018 00:42

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

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

idrougge 30 March 2018 04:00

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

Toni Wilen 30 March 2018 10:17

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 30 March 2018 10:45


Originally Posted by idrougge (Post 1231059)
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 30 March 2018 11:10


Originally Posted by Toni Wilen (Post 1231083)
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

That package did the trick :)
The glitches are gone.

All times are GMT +2. The time now is 00:06.

Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.

Page generated in 0.04319 seconds with 11 queries