Blitz Basic 2 basics

[Retro1234]

Thanks ill check out REDShapez

[idrougge]

RedShapeZ is quite useful. You can use it to grab sprites automatically if you've laid out your shapes in a (visible) grid.

[activist]

New to Blizbasic, and playing about with some of the code on the ultimateblitzbasiccd e.g. triplanes.bb2 in Examples/tedsdemos folder

However, when compile and run, they run fine but when I exit the relevant demo, it always results in "program failed (error #87000004) Wait for disk activity to finish. Suspend or Reboot.

Tried some of the other examples same result. Also Tried 'compile and run' and 'create executable...'

Using winuae 4.2.1, BB2.1 + A1200 configuration + blizzard 030, os 3.1 running in a window.

Maybe has to be an absolute vanilla A1200 to run correctly perhaps ?

[MickGyver]

Originally Posted by activist

New to Blizbasic, and playing about with some of the code on the ultimateblitzbasiccd e.g. triplanes.bb2 in Examples/tedsdemos folder

However, when compile and run, they run fine but when I exit the relevant demo, it always results in "program failed (error #87000004) Wait for disk activity to finish. Suspend or Reboot.

Tried some of the other examples same result. Also Tried 'compile and run' and 'create executable...'

Using winuae 4.2.1, BB2.1 + A1200 configuration + blizzard 030, os 3.1 running in a window.

Maybe has to be an absolute vanilla A1200 to run correctly perhaps ?

Hmm, works for me with a similar configuration, maybe something is wrong with your BB2.1 install. How did you install Blitz Basic 2? Have you tried installing from my newly modified version of the blitz 2 CD? This one: http://eab.abime.net/showthread.php?t=98664

[activist]

Originally Posted by MickGyver

How did you install Blitz Basic 2?

Thanks, copied the installer from:
http://aminet.net/package/dev/basic/ubbinstall
to the ultimate bb cd and ran that. 2 assigns - blitzlibs and blitz2. No errors or issue running compiling or installing. But will try a re-install using that other link just in case.

edit: am pretty sure it's due to something on my uae config unfortunately as I get the same result when try to run any of the 'pre compiled' BB executables on the ultimate cd e.g. blitz2_pddisk2\worm\

Thanks

[activist]

another noob question with winuae with rtg enabled.
When run a blitz game demo from workbench sometimes the native screen the blitz game runs on is hidden. I can hear game sounds, but no video. stays on the workbench screen but is frozen until the blitz demo in the background or native screen ends.
Have set both native and rtg as 'windowed' in winuae display options.
Is there a way of switching from rtg to native if doesn't happen automatically. Or do I have to configure something in picasso96 prefs in workbench for this. Doesnt happen for every blitz game/demo. Just some. thank you.

[Nightshft]

In AB2 when printing output to cli (not opening any windows or screens) - I just get a cli in full width, but only with 4 lines. Anyway to create a bigger cli window for standard output?

[Nightshft]

I have a problem with ReadFile and Inkey$ when the Debugger is running. It normally works fine, but with active debugger it says "No currently used object!"

if readFile(0,"filename")
  fileInput 0
  y=asc(inkey$)  <- error
  or
  bla=cvq(inkey$(4))  <- same
  closeFile 0

Seems like inkey$ sees no active fileInput although its defined one line before. Only when the debugger is running. Am I missing something, or is there a workaround?
(Blitzbasic 2.42. Without debugger this never happens. With debugger always.)

[Daedalus]

Originally Posted by activist

When run a blitz game demo from workbench sometimes the native screen the blitz game runs on is hidden. I can hear game sounds, but no video. stays on the workbench screen but is frozen until the blitz demo in the background or native screen ends.
Have set both native and rtg as 'windowed' in winuae display options.
Is there a way of switching from rtg to native if doesn't happen automatically. Or do I have to configure something in picasso96 prefs in workbench for this. Doesnt happen for every blitz game/demo. Just some. thank you.

This is a strange one indeed, and it's not one I've ever seen... Any time I open a native screen WinUAE will automatically switch to that in a window. Which demos in particular are causing this? Does it happen 100% of the time with those particular demos? Are you using the latest WinUAE?

Originally Posted by Nightshft

In AB2 when printing output to cli (not opening any windows or screens) - I just get a cli in full width, but only with 4 lines. Anyway to create a bigger cli window for standard output?

Not that I know of. AB3 has an option in the IDE preferences window for defining the console output device. This is normally CON: but can be modified to also include size parameters. AB2 and BB2 don't appear to have this option however.

Originally Posted by Nightshft

I have a problem with ReadFile and Inkey$ when the Debugger is running. It normally works fine, but with active debugger it says "No currently used object!"

Seems like inkey$ sees no active fileInput although its defined one line before. Only when the debugger is running. Am I missing something, or is there a workaround?
(Blitzbasic 2.42. Without debugger this never happens. With debugger always.)

And it works perfectly without the debugger? That sounds like a debugger bug - there are a couple of them unfortunately. It's not ideal, but you can disable the debugger for certain commands by using the RunErrsOff command before it, and then re-enable it afterwards with RunErrsOn.

[idrougge]

Originally Posted by Nightshft

I have a problem with ReadFile and Inkey$ when the Debugger is running. It normally works fine, but with active debugger it says "No currently used object!"

if readFile(0,"filename")
  fileInput 0
  y=asc(inkey$)  <- error
  or
  bla=cvq(inkey$(4))  <- same
  closeFile 0

Seems like inkey$ sees no active fileInput although its defined one line before. Only when the debugger is running. Am I missing something, or is there a workaround?
(Blitzbasic 2.42. Without debugger this never happens. With debugger always.)

I wouldn't use Inkey$ for reading a file, but in case the debugger is bothering you, you can turn it off and on for specific blocks of source code. The commands are Runerrsoff/Runerrson.

[Nightshft]

Originally Posted by Daedalus

And it works perfectly without the debugger? That sounds like a debugger bug ...

Yes it does. Guess it's a debugger bug then (AB2 2.42). I just was wondering if I'm doing something wrong or how to get around this. RunErrsOff/On seems like a fine workaround (it's not my own sourcecode so I'm not changing the inkey$ method against something else). Thanks!

Another question: when drawing 2d on a bitmap with line, boxF and all that I don't have to care about clipping, right? I deliberately drew out of the bitmaps bounds and it didn't crash, but maybe that doesn't prove anything if there's enough free ram around the bitmap

[Daedalus]

Hmmm, normally the drawing commands *aren't* clipped, and will trigger the debugger when they draw out of bounds. They will silently overwrite neighbouring memory without the debugger, which could also be another area of the same bitmap causing graphical glitches, or damaging code or data. So I would make sure that there's no way your code can draw outside the bitmap.

[Nightshft]

First I was surprised that you have to take care about clipping, but then again.. not lol.

Thx for all your help daedalus! Is it ok if I ask more? I'm in the process of learning Blitz, but lack of namespace and complete documentation and all those language additions make it a little jungle to wrestle through

Is there a function to return the filename of a path+name or do I have to build one from "Instr" and co?

Is scroll and blockscroll the same? The reference mentions scroll in the chapter about 2d drawing. Code examples seem to use blockscroll more often. I didn't find info about it.

And is there a way to get an overview about the language additions and/or libraries that came later?

[Daedalus]

Originally Posted by Nightshft

First I was surprised that you have to take care about clipping, but then again.. not lol.

Yeah, the drawing commands are pretty close to the hardware, so using them responsibly and safely is up to you - the hardware will blit your data wherever you want it, be it a bitmap, a window, or your program stack

There is a clipped blit command you can use, but it's much slower than normal blits because every blit needs to be checked to make sure it's not beyond the boundaries of the bitmap. It's much quicker to just ensure your code can never produce a blitting location outside the bitmap.

Is there a function to return the filename of a path+name or do I have to build one from "Instr" and co?

Building one from Instr() is probably quite a quick way of doing it. Blitz 2.1 doesn't have a function for extracting a filename from a path, but AB3 does include functions in its Includes that do. However, Amiga's dos.library itself has that and similar functions that you can use, e.g. Filepart_(). You just need to be careful to use pointers to strings instead of the actual strings. This is what the AB3 include does - it should work perfectly in BB" as well:

Function.s dos_FilePart {filename.s}
fptr.l = FilePart_(&filename.s)
If fptr
  filepart.s = Peek.s(fptr)
Else
  filepath.s = ""
End If
Function Return filepart.s
End Function

That function essentially acts as a Blitz-friendly wrapper for the raw dos.library call.

Is scroll and blockscroll the same? The reference mentions scroll in the chapter about 2d drawing. Code examples seem to use blockscroll more often. I didn't find info about it.

They're very similar, but not the same. Blockscroll is basically a much faster version of the Scroll command that can only be used on 16-bit aligned chunks. In effect, this means it can only be used for blocks of bitmap that are multiples of 16 pixels wide, and are located multiples of 16 pixels across the bitmap. If you can ensure these rules, Blockscroll is much faster, but if you can't use the normal scroll.

As an aside, the Block command is the equivalent fast-with-alignment-restrictions counterpart of the Blit command.

And is there a way to get an overview about the language additions and/or libraries that came later?

The BUM issues included in the Ultimate Blitz CD and AB3 include the various updates and their documentation. There's also a good overall AmigaGuide document included with AB3, and possibly on previous versions of Blitz that includes the original guide and all the additional libraries. I vaguely remember there was a guide in the older releases - maybe userlibs.guide?

[Shatterhand]

Originally Posted by Nightshft

I have a problem with ReadFile and Inkey$ when the Debugger is running. It normally works fine, but with active debugger it says "No currently used object!"

if readFile(0,"filename")
  fileInput 0
  y=asc(inkey$)  <- error
  or
  bla=cvq(inkey$(4))  <- same
  closeFile 0

Seems like inkey$ sees no active fileInput although its defined one line before. Only when the debugger is running. Am I missing something, or is there a workaround?
(Blitzbasic 2.42. Without debugger this never happens. With debugger always.)

GODDAMN IT I was fighting with this for a long time until I gave up and just changed the way my code reads data on file.

It's really funny having to code around the bugs of the compiler/debugger of the IDE you are using.....

[BippyM]

I used banks, and processed the data directly using peek, peek$ and poke etc..

Originally Posted by Nightshft

I have a problem with ReadFile and Inkey$ when the Debugger is running. It normally works fine, but with active debugger it says "No currently used object!"

if readFile(0,"filename")
  fileInput 0
  y=asc(inkey$)  <- error
  or
  bla=cvq(inkey$(4))  <- same
  closeFile 0

Seems like inkey$ sees no active fileInput although its defined one line before. Only when the debugger is running. Am I missing something, or is there a workaround?
(Blitzbasic 2.42. Without debugger this never happens. With debugger always.)

[Nightshft]

Thanks Bippy.

When I use a coplist display instead of a slice I can't seem to change the current used colors with the "RGB c, r,g,b" command. Is this correct? Would I have to change a palette object and use DisplayPalette coplist,palette to make it active (copy it to the display palette)?

Is there a way to directly change sprite colors with some other command?

Thanks in advance for your help guys!

[Daedalus]

There's no command to set the colours on a Coplist display directly as such, no. Modifying a palette object and then applying that to the display is one way to do it, or you can poke the values required directly into the colour registers for maximum efficiency.

[slademania]

Hi to all

I have read in the Blitz programmer guide the possibility of using most of the commands directly for assembler using TokeJsr and passing the various parameters in the CPU registers. I have done various tests and the results are OK.

But this system don't work with the DisplayLibrary's commands. I followed the basic guideline ( first parameter->D0, second->D1, or A0.. if a address, etc..) with no result.

Is there any way to use these commands from assembly or some document that talks about how to do it ?

I hope there is some way to do this

Thank you very much in advance...

[Nightshft]

Originally Posted by Daedalus

There's no command to set the colours on a Coplist display directly as such, no. Modifying a palette object and then applying that to the display is one way to do it, or you can poke the values required directly into the colour registers for maximum efficiency.

- copying the palette, changing one color and applying it with displayPalette worked. Its a little overhead just to change one single color, but it works fine. Strange that slices got RGB ... for immediate change and coplist displays don't, but ok, shouldn't be a problem.

- move #color, $register (like $dff180), did not work. it just blinks at the top of the screen, but looks like its overwritten immediately (by the copperlist I guess).

Just feedback, thx for the help.