Blitz Basic Questions

[Ze Emulatron]

This is the kind of code I was talking about. It works fine on a write enabled disk but when the disk is write protected it seems to stop at the first line of red code (If OpenFile(0,"high.score") = -1), and doesn't execute anymore, If you change QAMIGA to AMIGA I believe that it would work and open up the popup window that says the disk is write protected, but I don't want to leave BLITZ and QAMIGA modes.

WBStartup

BLITZ
BlitzKeys On

; Setup Variables
#bitmapw = 672  ; Width of the bitmap, level width in pixels, extra column each side to setup bits to scroll to
#bitmaph = 480  ; Height of the bitmap, level height in pixels, extra row each side to setup bits to scroll to

#screenw = 224   ; With of the bitmap to display
#screenh = 160   ; Height of the bitmap to display, 160px so fit on NTSC display

#screenm = 4     ; Screen mode max of 3, 8 colours for 512+512 config, number of bitplanes

BitMap 0,#bitmapw,#bitmaph,#screenm    ; Create main game bitmap
BitMap 1,320,60,#screenm    ; Create Score panel

If DispHeight = 200
  InitCopList 0,34,#screenh,$00014,8,2^#screenm,0
  InitCopList 1,34+3+#screenh,60,$00014,8,2^#screenm,0
Else
  InitCopList 0,44+25,#screenh,$00014,8,2^#screenm,0
  InitCopList 1,44+28+#screenh,60,$00014,8,2^#screenm,0
End If

DisplayAdjust 0,0,0,0,48,-48
CreateDisplay 0,1

DisplayBitMap 0,0,-49,0
Use BitMap 0

DisplayBitMap 1,1,-1,0
Use BitMap 1

Cls 1

Use BitMap 0

Cls 2
VWait 50
QAMIGA

If OpenFile(0,"high.score") = -1
  Cls 1
Else
  Use BitMap 1
  Cls 2
End If

VWait 50
For i = 0 To 5
  VWait 10
  Cls i
Next

CloseFile 0

VWait 250
Cls 0
BLITZ

; set palette

VWait 50
Cls 1

End

I had a different thought about checking the write protect status of a disk is it possible to access the trackdisk device and check TD_PROTSTATUS in Blitz ?

[Graham Humphrey]

Hmm, I am sure I have used OpenFile successfully in the past.

Maybe try it so it returns a value in a variable. eg:

dummy=OpenFile(0,"high.score")

If dummy=-1
...

And so on. Don't know if that makes a difference. I will go through some of my old code if I get time.

[Cobe]

Resurrecting..
I went through all these myself and still haven't found solution.
What I found out. The code stops at OpenFile because "Disk Write-Protected" window is "displayed" but not visible cause we're still in QAmiga mode. If you press Amiga-B it will continue execution.
I tested CatchDosErrs too and it works only in Amiga mode.
Then in second manual I found a poke to remove requester.

poke.l peek.l(peek.l(4)+276)+184,-1

the only thing I know is that peek.l(4) is execbase.

And.. it kinda works. It works but it seems that it remembers write-protected status so next time when you try to save and if you removed write protection meanwhile it will say again that its write-protected. I guess that changing the write protect status should be done while you are in QAmiga mode and that then it will register pulling the disk out and putting it back... I didn't test it... But it would be nice if it could be done some other way...

[Cobe]

I was poking in a dark, I mean in QAmiga mode and got semi-successful results even corrupted disk. So I decided to try it in Amiga mode and it seems that everything's fine.

.savesomething ;without pop up window/qamiga friendly

Poke.l Peek.l(Peek.l(4)+276)+184,-1 ;disable pop up window

dummy=WriteFile(0,"hs")

 If dummy=-1
  Print"Type something to save:"
  a$=Edit$(22)
  FileOutput 0
  Print a$
  CloseFile 0
  DefaultOutput
  NPrint"Saved"
 Else
  NPrint"Disk Write-Protected!"
  NPrint"Eject Disk & Write Enable!"
  Repeat
  dummy=Exists ("hs")
   If dummy=0
    Repeat
     dummy=Exists ("hs")
     If dummy>0  Goto savesomething
     NPrint "Insert Disk!"
     VWait 50
    Forever
   EndIf
  Until Joyb(1)=1 ;safety exit
 EndIf
End

So now I have to rewrite it and confirm that it works in QAmiga mode with all the going back and forth to Blitz mode(VWaiting 250...not pleasant) in order to display prints on screen.

[gazj82]

Does anyone know how incorporate speech syntheses into Blitz basic programs, preferably in BLITZ mode?

[Shatterhand]

I have 2 questions:

1) When I have newtypes with fields on them, I can't access its fields on Procedures or Functions, even when I declare its variables (or their arrays) as Global. This is something that I just can't figure out and would have made my life SO MUCH easier when developing Quasarius.

2) Why I need to tell a "limit" for how many sprites, shapes, copperlists etc I'll use on my game? Does Blitz reserve memory for this? For example, if I limit my game to 300 shapes, but then only use 200 - or even better, let's say I want to reserve my shapes 0-99 to tiles for the background 100-199 to tiles for the foreground and 200-299 to enemies. Then my current background actually only uses 60 shapes, leaving shapes 60 to 99 unused, but still using shapes 100-299... does this "hole" between 60 to 99 consumes memory?

Thank you in advance for answering it

[Graham Humphrey]

Originally Posted by Shatterhand

1) When I have newtypes with fields on them, I can't access its fields on Procedures or Functions, even when I declare its variables (or their arrays) as Global. This is something that I just can't figure out and would have made my life SO MUCH easier when developing Quasarius.

I'm pretty sure you can do this but I couldn't tell you off the top of my head...

2) Why I need to tell a "limit" for how many sprites, shapes, copperlists etc I'll use on my game? Does Blitz reserve memory for this? For example, if I limit my game to 300 shapes, but then only use 200 - or even better, let's say I want to reserve my shapes 0-99 to tiles for the background 100-199 to tiles for the foreground and 200-299 to enemies. Then my current background actually only uses 60 shapes, leaving shapes 60 to 99 unused, but still using shapes 100-299... does this "hole" between 60 to 99 consumes memory?

No, not to my knowledge - it's just numbering and as those slots aren't allocated to anything, they're simply not there. So number them how you like. Certainly I work like this with seemingly no ill-effects.

[Daedalus]

Originally Posted by gazj82

Does anyone know how incorporate speech syntheses into Blitz basic programs, preferably in BLITZ mode?

There are built-in commands that can be used for speech directly from Blitz. I don't think they work from Blitz mode however since they use the narrator.device. The command is simply:

Speak "Hello World"

Parameters can be changed with the SetVoice command. See the sound section of the Blitz manual for details, also available online here.

Originally Posted by Shatterhand

1) When I have newtypes with fields on them, I can't access its fields on Procedures or Functions, even when I declare its variables (or their arrays) as Global. This is something that I just can't figure out and would have made my life SO MUCH easier when developing Quasarius.

Yes, this is perfectly possible - I'm not sure why it wouldn't work for you. Declaring the root of the newtype as shared at the start of the procedure lets you access it throughout the procedure:

DEFTYPE .MyNewType MyVariable

Statement TestInput(test$)
Shared MyVariable
If test$ = MyVariable\answer Then NPrint "Found!"
End Statement

That should work just fine. I think the only possible issue is when you use AmiBlitz 3's new FAST keyword, which prevents the use of newtypes in procedures, but standard procedures aren't a problem.

2) Why I need to tell a "limit" for how many sprites, shapes, copperlists etc I'll use on my game? Does Blitz reserve memory for this? For example, if I limit my game to 300 shapes, but then only use 200 - or even better, let's say I want to reserve my shapes 0-99 to tiles for the background 100-199 to tiles for the foreground and 200-299 to enemies. Then my current background actually only uses 60 shapes, leaving shapes 60 to 99 unused, but still using shapes 100-299... does this "hole" between 60 to 99 consumes memory?

It uses a very small amount of memory, but nothing you should really need to work about unless you're doing some extremely tight coding, in which case you'll probably have problems with things like external floppy drives and hard drives connected as well. It consists of a few bytes per number, so if you skip 100 numbers, you might end up wasting 1 or 2KB. Of more concern is that early versions of the compiler don't let you go above 255 objects, so don't use the old Ted versions of Blitz 2.1.

[gazj82]

Originally Posted by Daedalus

There are built-in commands that can be used for speech directly from Blitz. I don't think they work from Blitz mode however since they use the narrator.device. The command is simply:

Speak "Hello World"

Parameters can be changed with the SetVoice command. See the sound section of the Blitz manual for details, also available online here.

Thanks for the help Daedalus, It's unfortunate it doesn't work in BLITZ mode. I might have to see if I can sample it on workbench somehow.

First I have to get say working as it doesn't seem to work on my 3.9 installation. As far as I can tell I need to install some accents. Unfortunately Aminet is down at the moment.

[Daedalus]

Have you copied over the required files? You need translator.library, narrator.device, and (I think) Speak-handler from a Workbench 2 installation. Probably due to Commodore muppetry over licences, the files weren't included with Workbench 3.0 or above.

[gazj82]

Yes I have the files you mention. From the error I get I need to install some accent files in LOCALE:Accents. The accent can then be selected in the "Translator" tool found in prefs. I still need to do this. Will report back soon.

[gazj82]

Totally separate issue. My current game runs fine on an A1200 but not on a A500. I sometimes possibly have 18 things being blitted in one frame.

The A1200 seems to manage this quite easily. Even if I reduce the blits to every other frame. i.e half in one frame and half in the next the A500 still can't seem to manage this.

Is this my poor coding or am I hitting some sort of Blitz/A500 limit?

I might be able to offload some to sprites. Although I find them quite limiting compared to blitting. Firstly I can't find any obvious way to animate them. You can't specify a shape to use when you move a sprite like you can a blit. Calling "GetASprite" all the time doesn't seem like the right thing to do either. Secondly when I tried them before I seem to remember have awful black borders around my sprites. I must have been doing something wrong here as even C64 sprites don't do this.

[Cobe]

Well you should use getAsprite only once for every frame of the sprite and after that use displaysprite x,y similar as you use blits. X is sprite channel(0-7), Y is sprite number that u can change to create animation.

[Daedalus]

Hmmm... I don't remember having a translator prefs tool or accents - are you sure you're not using some replacement voice synthesis library that needs extra stuff?

As for the blitting, it could be your code, it could be the size or complexity of the blits, or it could simply be the bandwidth of the A1200 leaving more time free for the blitter each frame. First thing to check though: are you running it from the editor with the debugger on? This eats up a lot of CPU time, and turning it off lets the code run at full speed.

Blitting shouldn't really be that slow, and 18 blits isn't a lot if they're moderately sized. If they're large blits however (in pixel count or depth), they take more time.

And sprites can indeed be animated, and you're right that GetaSprite shouldn't be used in this way, it's very slow. What you need to remember is that you have sprite objects (the graphical information) and sprite channels (the hardware used to display the sprites). You only have 8 hardware sprite channels, but you can have as many sprite objects as you want created in advance. You animate by creating a separate sprite object for each frame, then when you want to show a different frame, simply use the desired sprite object corresponding to the new frame in the same sprite object, and it will instantly replace the old frame. This is pretty similar to blitting different shapes as needed to create animation. having black borders around the sprite is possibly as simple as using the incorrect palette registers - sprites use particular colour registers and you need to take that into account when creating them. Colour 0 is always transparent though, so if colour 0 areas are showing up as black, there's something else going on.

Here's a little demo of using sprites in Blitz that I made for the upcoming Blitz tutorial in Amiga Future, to give you an idea of their capabilities:
[ Show youtube player ]
It's AGA, but the principles are the same other than limiting the size and palette.

[gazj82]

Morning thanks for your replies.

Well I have managed to get sprites working which is good news. Well for the most part, for some reason I can only get 7 sprites working on screen not 8.

This leaves 10 qblit's for the A500 to do. Even alternating these so I do 5 in one frame and 5 in the next is still leaving me with slowdown! Although it is much improved.

The difference is amazing between an A1200 and an A500.

Just to clarify. The display is 4 bitplanes and single layer playfield. The objects being blitted are maximum 16x16 although most are much smaller than that even and usually only consist of one colour from the 16 available. (EDIT, sorry one, the player is 32 wide and 16 high)

I do have one colour in my pallete that changes every couple of frames. Turning this off seems to have little effect.

The only other thing that updates per frame is updating the score using the print statement. Would this be causing any problems?

About debugging. I do all coding on my accelerated A1200 and test here using the standard method. But for standard A1200 and A500 testing I use the compiler to create an executable and save this on floppy disk. I then use an image of this ADF on FS-UAE using the appropriate settings.
So I guess the debugger is not on when used this way?

[Daedalus]

Ah, good stuff. Yep, you can lose sprite channel 7 when you don't have enough DMA slots to fetch all the bitplane data the display needs - bitplanes have DMA priority over sprites. There are ways around it, like narrowing the display, but ultimately you're up against the hardware limitations of the Amiga there.

Yep, there's quite a difference between the 500 and 1200 really - a lot of people complain that the AGA chipset wasn't enough of an improvement and is no better than ECS. While there's a certain truth to that, there are actually some quite large improvements that tend to get ignored because most games are written for OCS/ECS.

It seems strange, you should easily be able to blit that many shapes per frame. I take it nothing else is running at the time - perhaps some sort of patches that install interrupts or anything? Are you using the Display Library (DisplaySprite, DisplayBitmap etc.), or Slices (ShowBitmap, ShowSprite etc.)?

You should still turn off the debugger when compiling an executable, otherwise it includes some debugging code that you don't need. I don't think that's the cause of your slowdown, but it will make the executable larger than it needs to be.

[idrougge]

Originally Posted by gazj82

Just to clarify. The display is 4 bitplanes and single layer playfield. The objects being blitted are maximum 16x16 although most are much smaller than that even and usually only consist of one colour from the 16 available. (EDIT, sorry one, the player is 32 wide and 16 high)

It doesn't matter how many colours your bobs use unless you do some tricks such as partitioning their colour use to a single bitplane and use corresponding commands. The blitter will still have to blit and mask the transparent planes.

Originally Posted by gazj82

The only other thing that updates per frame is updating the score using the print statement. Would this be causing any problems?

Printing really chews up blitter time, you can regard it as one blit per character.

One way to speed things up is to create a "clean" background to be used for restoring QBlits. You add it as an extra argument to your QBlit/Unqueue commands.

[Shatterhand]

Print command eats a lot of blitting time, I was really surprised by that to be honest. It looks like creating a bitmap font and using the block command to write text may be faster than using the print command. I just found about this while doing my current game, I was printing a lot of debug info on screen and I was surprised the game was struggling to run on one frame, since it's such a simple game. As soon as I turned off all print commands, the game was flying.

In my game, Quasarius, I remember with all the game logic running I still could QBlit about 20 16x16 shapes in one frame, and my logic was really badly optimized (if I ever make a 1.2 version of it there's so much I've learned, I really could make the game run without ever slowing down nowadays ) - And I was *still* using print to print the score and multiplier info on the hud (in a 1 bitplane bitmap, maybe this helped).

[Master484]

I did a small test with QBlit with one of my programs.

On a 32 color 320*224 screen, with QBlit I could draw about 20 16*16 objects per frame.

And when display update speed was halved to 25 FPS, I could draw about 38 objects.

These results are from WINUAE, using A600 2 MB chip + 8 MB fast, with "cycle exact" ON.

Usually Fast RAM improves the result by some 25 %, so I think that without fast RAM it would be 15 objects at 50 FPS and maybe 30 objects at 25 FPS.

So I think that in your program something is taking lots of extra time.

Most likely the text drawing is the cause of most slowdown; the blitz text drawing command is very slow, especially if you're writing multiple lines every frame.

In my own programs I usually use the texts only for debugging, and always put an ON-OFF button for them, or make it so that the texts are updated only every 10th frame or something.

You can use the text drawing to update things like score displays, but make it so that it only updates the texts when the score itself changes.

---

About low color objects, here is a speed trick that can be used if you have 2 color objects in a 16 color game.

In your 16 color palette, put the 2 colors (transparent + 1 color) to the beginning of the palette (transparent first, then the other color).

Save your 2 color objects to a separate IFF image that contains only these 2 colors. The IFF file itself can be saved as an 8 color IFF (I use XnView on PC and in it 8 colors is the lowest color amount for an IFF file).

Then, when loading these objects to your program, first create a temporary 1 bitplane bitmap, and load them to it from the IFF file, and then GetAShape them from this 1 bitplane bitmap. This should result in the shapes being only 1 bitplane deep, and now they are much faster to draw.

The only downside is that if you draw these 1 bitplane objects over any other graphics, the colors will show up wrong. But if you just have a black background, or use a dual playfield, then the background graphics won't cause broblems.

This method is great for bullets and explosions and stuff like that. And it also works for 4 color (2 bitplanes) and 8 color (3 bitplanes) objects.

There also is a Blitz command to achieve the same thing, I think it was BitPlanesBitmap or something like that, but it's hard command, and I don't have much experience in it's use, so I have just used the above method.

[gazj82]

Well Well Well,

I made sure I had debugging off and turned off the score updates and it now runs at full speed on a A500 without sprites and blitting all 18 images on every frame. I just need to try turning the score back on now, but only updating it when there is a score change. It should have been obvious to only update it when the score changes really. Extremely bad on my part to just let it update every frame from the start.

Extremely pleased. I really didn't want to leave it A1200 only and now I don't have to put up with the 7 sprite limitation (or narrowing the play area).

Thank you for all your help guys. Hopefully have something to show for Christmas, although I hope to not make the same mistake as last time and rush it out with a load of problems, and a couple of days later having to make a point release.