Blitz Basic 2 basics

[Daedalus]

Hmmm, that's interesting. I'm sure I've poked colour registers before to change them (and regularly still do for the background colour for examining timings). Is it possible that you're poking too early in the frame? Or do you have any other palette commands in the loop that might override the poked value?

[Nightshft]

Originally Posted by Daedalus

Is it possible that you're poking too early in the frame?

Yes, probably. How do I change it NOT too early - is there a proven way?

[Daedalus]

Are you using VWait in your program? There's an alternative command in one of the support libraries called VWaitPos (I think) that can replace VWait and has the ability to be triggered at any given line on the display. At least for experimenting, it might be worth trying it half way down the screen, and if the colour change takes effect there, working upwards to see if/when it stops working.

[Nightshft]

Originally Posted by Daedalus

Are you using VWait in your program?

Yes.

... VWaitPos (I think) that can replace VWait and has the ability to be triggered at any given line on the display... it might be worth trying it half way down the screen, and if the colour change takes effect there, working upwards to see if/when it stops working.

Yes, vWaitPos(Line) works fine. Vertical Line number has to be >= 41 (so it doesnt get reset by this copperlist. I initialized this coplist with y=44.). It's not a very elegant approach for a simple colorchange, so I guess I'd stick with the palette change. But that's always good to know.

I also wasn't able to check timing per background color poke/move before because of this. I don't understand why it works for some people nevertheless, but however vWaitPos now makes that possible too.
As always, many thanks Deadalus!

[Daedalus]

No bother Yeah, the display wouldn't normally start to be drawn until around line 44, so I guess the copperlist is only initialising certain things like the palette just before that.

[Nightshft]

For anybody running into the same problem in Blitzbasic 2.1:
Opening the IDE I encountered "unable to open screen".

The solution was to rename/delete sys: prefs/env-archive/ted.prefs
(Probably better after restart and before trying to start the IDE because some prefs are copied to ENV: then)

[Nightshft]

The compiler directive "optimize" has the following parameters, which can be combined:
1..integer and code, 2..fpu, 4..new language syntax

So far so good, but what does "new language syntax" mean?

[Daedalus]

Originally Posted by Nightshft

So far so good, but what does "new language syntax" mean?

It enables a additional ways of interpreting certain items in the source. For example, with New Syntax enables, you can mark a parameter to a statement or function as optional by putting @ in front of it. For example:

Function test.l{data1.w, data2.w, @data3.w}

There are other new things you can do, like casting strings to integers (value.w = @"AB") and inserting ASCII escape sequences into strings (test$ = "\\22Hello World!\\22").

All useful things in certain situations.

[Nightshft]

It surprises me that this is an option of "optimize" and not of "syntax" but the main point is that it's a useful addition. Thanks for the info.

[Daedalus]

Yeah, it would make sense to belong to the Syntax command I guess. I think the reasoning could be that the Syntax command deals exclusively with variable handling, while the Optimize command turns on and off various different compiler settings. To be honest, both commands could probably be renamed, or split out into their discrete functions like pragmas. For example:

Optimize Off|Int|FPU
NewSyntax Off|On
ForceDeclarations Off|Inline|On
CheckCasts Off|On

[Nightshft]

Is it possible to read cpu registers? I know of getReg and putReg which can read the standard adress- and data registers and write to the data-registers. But can I read the other registers too? Especially I'd like to read VBR which is only accessible in supervisor mode.
(I guess it could be possible with inline asm and variable pointers?)

[Nightshft]

Just found out that I can set the initial path for a file requester with

path$=drive:somepath/
a$=FileRequest$("Title",path$,file$)

which is nice.

Is there a way to set it to a specific subdirectory (from where the .exe is located)?
Unlike some other languages it's not possible to use par$(0) to get the executable path.

[emiespo]

Hi all, I have a very noob question, as I'm trying to learn BlitzBasic for the first time.

My attempt to open a HAM screen doesn't seem to be working... according to the manual this should do it:

Screen 0,0,0,320,200,6,$200,"My Screen",0,1

But instead it does nothing (also how would I detect an error?). If I remove the VMode part ($200), I can see a new screen being created.

Thanks in advance...

[Daedalus]

Originally Posted by Nightshft

Is there a way to set it to a specific subdirectory (from where the .exe is located)?

There are a couple of commands in a 3rd party library that do what you're lookingfor. It's the RIMiscLib, and is generally standard with all but the most basic of BB2 installations. The functions are ProgDir$ and ProgPath$, which return the parent directory of the exe and the full path of the exe respectively.

Originally Posted by emiespo

My attempt to open a HAM screen doesn't seem to be working... according to the manual this should do it:

Screen 0,0,0,320,200,6,$200,"My Screen",0,1

But instead it does nothing (also how would I detect an error?).

Hmmm... I haven't checked in code myself, but the AmiBlitz documentation lists $800 as the HAM flag, not $200. So it's possible that's an error in the original documentation. As for how to detect an error, well it's tricky. Sometimes the debugger will tell you, but in many cases the values you enter like this are simply OS tags that pass straight through Blitz to the OS itself. If that fails, many Blitz commands can't offer feedback and simply fail silently (or badly). It's possible to check for a screen being opened by seeing if the object's address is null:

Screen 0, [...]
If peek.l(ADDR Screen 0) = 0
  NPrint "Unable to open screen!"
  End
End If

If I remove the VMode part ($200), I can see a new screen being created.

Yep, that will open a default format screen, which is a standard low res screen.

[emiespo]

Originally Posted by Daedalus

Hmmm... I haven't checked in code myself, but the AmiBlitz documentation lists $800 as the HAM flag, not $200. So it's possible that's an error in the original documentation. As for how to detect an error, well it's tricky. Sometimes the debugger will tell you, but in many cases the values you enter like this are simply OS tags that pass straight through Blitz to the OS itself. If that fails, many Blitz commands can't offer feedback and simply fail silently (or badly). It's possible to check for a screen being opened by seeing if the object's address is null:

Screen 0, [...]
If peek.l(ADDR Screen 0) = 0
  NPrint "Unable to open screen!"
  End
End If

Thanks a lot! I took that value from an online version of the manual (first page on Google...).

So far it's my understanding that Blitz Basic is a very low level collection of wrappers around OS functions (and in general Amiga custom chip access). Thus very hard to use without proper documentation and examples, and also pretty easy to crash the machine with . Now for instance, how would I access that screen's bitmap?

My goal is to have a quick way to wrap some assembler code I have already done with all those "boring" parts to open a screen, show some titles, high-scores, etc.

Is there any decent example collection?

[Daedalus]

Originally Posted by emiespo

Thanks a lot! I took that value from an online version of the manual (first page on Google...).

So $800 is the correct value then? Good to know... I did check my original paper manual, and that also lists $200, but it's known for having many mistakes, even beyond the 6 pages of corrections it came with.

So far it's my understanding that Blitz Basic is a very low level collection of wrappers around OS functions (and in general Amiga custom chip access). Thus very hard to use without proper documentation and examples, and also pretty easy to crash the machine with .

Yep, that's pretty much it alright. There are some very high level elements and some very low level elements, but in general the OS doesn't check parameters (and hardware doesn't either of course) so any incorrect values can just get applied without question. It's the same for most languages - checking all those parameters would just be too slow, so it's up to the coder to get right, or to check where things might not be correct.

Now for instance, how would I access that screen's bitmap?

You can either create an appropriate bitmap before you open the screen and attach that, or you can simply open the screen without a bitmap parameter and one will be created automatically with the same dimensions as the screen. To then access that, use the ScreensBitmap command, which will assign a Blitz bitmap object number to this default bitmap.

My goal is to have a quick way to wrap some assembler code I have already done with all those "boring" parts to open a screen, show some titles, high-scores, etc.

Nice

Is there any decent example collection?

Blitz itself comes with quite a few examples included (check the documentation drawer), and if you have one of the larger Blitz installations (e.g. from the Ultimate Blitz Basic CD), it should include issues of the Blitz User Magazine (BUM). This often included interesting code, as well as updated command libraries.

[emiespo]

Originally Posted by Daedalus

So $800 is the correct value then? Good to know...

Yes, thanks to your advice, I tested $800 with a HAM picture I found on Aminet and it appeared correctly :-) YAY!

You can either create an appropriate bitmap before you open the screen and attach that, or you can simply open the screen without a bitmap parameter and one will be created automatically with the same dimensions as the screen. To then access that, use the ScreensBitmap command, which will assign a Blitz bitmap object number to this default bitmap.

This is the issue I was talking about: the amigaguide manual of AmiBlitz is also quite bad. I looked into the "screenslib" and that command is not there, I looked into the "bitmaplib" and it's not there either. How am I supposed to understand how a screen works without reading *the whole* manual first? I then searched for your suggestion on the original manual, and after spotting an example that loads a picture I was able to load a IFF file with 3 lines of code.

Blitz itself comes with quite a few examples included (check the documentation drawer), and if you have one of the larger Blitz installations (e.g. from the Ultimate Blitz Basic CD), it should include issues of the Blitz User Magazine (BUM). This often included interesting code, as well as updated command libraries.

Yeah I got that, but it seems only very specific examples, and not many of them are OS-friendly ones. Maybe I was looking in the wrong spot... I'll try again.

Thanks again, I made some progress at least... ;-)

[E-Penguin]

Anybody ever had any success with "rotate" on a shape? I set the handle to the middle (with midhandle) but it never seems to rotate around the centre of the shape. Is there something I'm missing?

MidHandle 0
Rotate 0,0.1
Handle 0,0,0

[Daedalus]

I've only ever used it for 90 degree rotations on square shapes, so it works without distortions, but it rotates around the centre then. Are you sure you're not getting it clipped because it's wider than it used to be with the rotation? Perhaps your shape object needs to be bigger with an empty margin surrounding the actual image, so it has room to rotate into?

[E-Penguin]

You're right, 90 deg works fine.

It's a 32x32 shape - I'd have though it would have deal with the size internally. I guess I'll have to create a bunch of rotated shapes in a drawing program and load them in. Shame though!