Blitz Basic 2 basics

[E-Penguin]

Originally Posted by Daedalus

In the original Blitz 2.1, you still need to specify a maximum size, so

Dim List Things.l(200)

allocates enough memory for containing your list with 200 items in it, even though it contains 0 objects. They're still "dynamic" in that they only show the number of items you put in, but you'll get crashes if you go above the maximum.

Could create your own linked list implementation though, with a NewTypes containing the thing you want and pointers to the previous/next (or some START/END placeholder)?

NewType .thing
    name.s
End NewType

NewType .thingListItem
    myThing.thing
    *some_pointer_thing_here.thingListListem
End NewType

and so on.

I'm getting ready to dive into Blitz Basic and will have endless questions coming over the weekend. Watch this space.

[idrougge]

Are you sure you can do that?

[E-Penguin]

Not at all sure. Hence the question!

Well, I would do it in c but that's a boring language. Every man and his dog does c.

I think pointers are stored as data.l so perhaps the pointer needs to be cast to / from the appropriate NewType. Is casting a thing in Blitz Basic?

[Daedalus]

You can just store the pointers as longwords in Blitz and they'll work fine. Pointers are broadly the same in Blitz as in C, but there are subtle differences in their implementation. You can define a pointer in a Newtype, but you access it without the *, so for your example you would access your link pointer as:

*nextItem = MyVariable.thingListItem\some_pointer_thing_here

The awkwardness comes from actually creating the items, which I think will have to be allocated in memory manually and then assigned to a pointer when that item is required. You can use SizeOf .thingListItem to get the size of the allocation, and use the standard exec memory routines. It should be relatively doable as a set of functions that you could put in an include is you wished to use them in multiple programs.

[Cylon]

@E-Penguin
Yes, you can do those things with BlitzBasic2.

There are caveats, of course.

here is an example:

It creates a list of titem and then adds the first node, then another. And links them together to a ring-like structure.

NEWTYPE.thing

  data.w

End NEWTYPE

NEWTYPE.titem

  ola.thing

  *nxt.titem

End NEWTYPE

Dim List exmpl.titem(10)


NPrint &exmpl(0) , " >> ",exmpl(0)\nxt
NPrint &exmpl(1)

If AddLast (exmpl())

  root.l= &exmpl()

  Print    root , " >> nxt ="

  exmpl()\nxt = root ;or 0 to end this

  NPrint   exmpl()\nxt

  store.l=exmpl()\nxt

  If AddLast (exmpl())

    Print    &exmpl(), " >> nxt ="

    exmpl()\nxt = store.l ; or root or 0 to end this

    NPrint   exmpl()\nxt
  EndIf

EndIf

NPrint "SizeOf thing : ",SizeOf.thing
NPrint "SizeOf titem : ",SizeOf.titem

MouseWait

End

Here is one tricky thing: In the example above you can see me using an index value for accessing list items. This is not (really) working in BB2. At least, it works until you change the list items somehow. then everything gets newly allocated and the index's points to ... somewhere. So don't do that. Even if it works somehow sometimes.

Pointers are casted and treated as LONGs, but you have to take care for yourself to not free a pointer to something or refer via a pointer to an address without veryfying the address. Blitz will also try to cast ANYTHING to ANYOTHER without telling you. Your job, Coder (well, you might get compiler errors, syntax errors, overflow errors - make the best of it).

[E-Penguin]

Sprite Multiplexing - what is it and how can you do it in blitz2

[Cylon]

You have only 8 sprites in hardware to display, so called sprite channels.
If you want to display more sprites than 8, you have to reuse the channels multiple times.

so, lets say you display one sprite in the upper part of the screen. a couple of milliseconds later the video hardware has passed that part of screen and therfore already displayed this sprite. Now you can use this channel to display another sprite lower on the screen, where the screen has not yet been drawd.

[Daedalus]

Blitz includes a DisplayLibrary command that sets this up in the Coplist for you, though I've never used it myself. Check out the CustomSprites command, bearing in mind that you'll need to add the desired value (4*number of sprites + 2) to the Custom space in your InitCopList line. This gives you a second use of each of the eight sprite channels, with channels numbered 8-15 instead.

[Cobe]

Ok, guys, is it just too late or AGA dualplayfield playfield 2 by default uses colors 8-23??

I'd say it is. Had to set bplcon3 bit 12-10 to 100 with displaycontrols 0,0,$1c00,0 now its 16-31.

[Daedalus]

By default the AGA dual playfield display uses colours 8-23 because that is compatible with ECS, which uses 0-7 for the first playfield and 8-15 for the second. As you point out, bits 10-12 set the pen offset of the second playfield, with %000 being no offset (starts at 0), %001 being 2, %011 being 8 (default ECS mode), all the way up to %111 being 128.

[amyren]

I have been looking for an example code on how to display an image. I have looked at the image.include.ab3 but I find that a bit confusing trying to work out what parts of that code I need.
What I would like to see is an example on eg. how to load an iff file and display it inside a window on the workbench.

[Daedalus]

If you're using AmiBlitz3 and the image.include.ab3 code, you simply load the image with image_Load{} and then blit it to the relevant rastport, which is part of the window you would like to use (this can be skipped if it's the currently used window). This can be opened with the standard Blitz commands, or with the AmiBlitz Window include.

It will look something like this using the image include and the standard Blitz window commands:

Optimize 5
XINCLUDE "image.include.ab3"

WbToScreen 0

If image_Load{0, "sys:prefs/presets/patterns/Amiga Waves.jpg"}
  wid.w = image_GetWidth{0}
  hei.w = image_GetHeight{0}
  *mywin.Window = Window(0, 100, 100, wid+10, hei+20, $140E, "Image Test", 1, 2)
  If *mywin
    image_Blit{0, 0, 0}
    Repeat
      ev.l = WaitEvent
      Delay_ 2
    Until ev = $200
  Else
    NPrint "Error opening window"
  End If
Else
  NPrint "Error loading image"
End If

End

You might have to add all.res to the residents list if you get an error saying Type not found or similar.

Edit: If you use image_Load{}, it loads the image using datatypes, so IFF, JPEG or whatever isn't a problem.

If you're using native screenmodes, the older method is simply to use LoadShapes to load the image, then WBlit to blit it to a window. Note that this method only works with IFF files, and will crash if it can't load the specified file.

[amyren]

Thanks for the reply.
I did try compiling that, first it came up with the error message that newsyntax was needed and was hinted to put optimize 4 at the beginning of the program.
So I did insert Optimize 4 at the top of the code, now it gives a compile error from line 2 (which is the line where the xinclude image.include.ab3 is) that the if block is to big.
Possibly wrong code begins here: ny
At this point it will also have opened the image.incude.ab3 and the cursor at line 1403

I was not sure what to do about this, so I tried to increase string buffer size and stacksize in compiler settings, but as expected this did not help.
And, I do have the all.res as resident.

[Daedalus]

Ugh, sorry about that - I typed it from memory without trying it. To be fair, I can't see why the hell it's giving that error, it's only a simple bit of code, and only yesterday I used image.include to blit an image in a window. I'll check it out...

Edit: Yep, it's doing the same thing for me too... And I've no idea why, but it works if you use Optimize 5 instead of 4. All that is is integer optimisation, but I guess it changes something with memory allocation or something that lets it work. I've updated the example anyway so that it's now known good code. Again, sorry about that!

[amyren]

Thank you very much. Yes, that works here too
I guess that optimize 5 equals optimize 4 + 1, so that switches on both integer and newsyntax.

I will do some experiments with this code now. I do notice that it will require the ab3zlib.library to run.

I have used AmiBlitz3 for teaching myself a bit basic here. I find the editor easier to work with than Blitz2. But I have been adapting my program so that it also will compile in Blitz2.
My idea behind that is that when the program is finished it should work on any Amiga without FPU , + newgen if possible. (I do use gadtools so I guess WB2 or 3 will be required as minimum.)

As image.include.ab3 is for AmiBlitz, I guess I must find another way to do this in Blitz2.
Is that loadshape and wblit the answer then, and will that work also will RTG?
Also if I stick to only iff images, could I get it to work as a standalone program without the need of any zlib's?

[Daedalus]

Originally Posted by amyren

I guess that optimize 5 equals optimize 4 + 1, so that switches on both integer and newsyntax.

Yep, that's it. Using numbers like 5 is a shortcut, but ultimately the argument is a set of binary flags. Bit 0 is the integer optimiser (value=1), bit 1 is the FPU optimiser (value=2) and bit 2 is the New Syntax option (value=4). So adding them together activates the relevant bits in the same way as a bitwise OR operation would.

I will do some experiments with this code now. I do notice that it will require the ab3zlib.library to run.

I believe zlib is only required for using PNG images directly. The jpeg.library is used for JPEG files directly, but you can also modify some flags at the top of the image.include.ab3 file to disable their use, in which case you can still use datatypes without extra libraries.

I have used AmiBlitz3 for teaching myself a bit basic here. I find the editor easier to work with than Blitz2. But I have been adapting my program so that it also will compile in Blitz2.

Indeed, AB3 is a much nicer environment for development.

My idea behind that is that when the program is finished it should work on any Amiga without FPU , + newgen if possible. (I do use gadtools so I guess WB2 or 3 will be required as minimum.)

GadTools is available for OS 1.x too, but isn't included as standard so it complicates things. There are also Intuition gadgets that will work on standard 1.x too, but they're pretty primitive and not particularly nice to use.

As image.include.ab3 is for AmiBlitz, I guess I must find another way to do this in Blitz2.

Yeah, for now anyway. A while back I started backporting the AB3 includes for use in Blitz 2.1, but have only done a few that I needed for a particular project (and even they aren't complete yet). It's actually kinda tricky since they use a lot of AB3-only features that need to be worked around. Perhaps some day...

Is that loadshape and wblit the answer then, and will that work also will RTG?

Yes, it should in theory anyway. If you do the coding in AB3, it will highlight any commands that use the custom chips directly in red, and this will let you know things that are likely to cause problems on RTG and NG systems. LoadShape and WBlit are system-friendly, so they *should* be ok. I suspect there may be palette issues on high- or true-colour screens though. But no harm in trying.

Also if I stick to only iff images, could I get it to work as a standalone program without the need of any zlib's?

Yep, see above. You can disable the requirement and still use datatypes to use any image format with image.include.ab3, but you lose out on some extra features like alpha channel support and so on.

[amyren]

Originally Posted by Daedalus

Yes, it should in theory anyway. If you do the coding in AB3, it will highlight any commands that use the custom chips directly in red, and this will let you know things that are likely to cause problems on RTG and NG systems. LoadShape and WBlit are system-friendly, so they *should* be ok. I suspect there may be palette issues on high- or true-colour screens though. But no harm in trying.

Oh, so thats why certain commands did turn red.
No wonder my timer commands did not work when testing it on MorhOS.
Is there another way to implement a timer without using custom chips?

Yep, see above. You can disable the requirement and still use datatypes to use any image format with image.include.ab3, but you lose out on some extra features like alpha channel support and so on.

I found that there was quite a lot to be disabled to get rid of the ab3zlib

I did comment away shamelessly every part with have zlib references and I also removed any PNG references. I might do the same with jpeg as well, since I probably will use only iff.

I think that image.include.ab3 file is much bigger than needed. I think that the demo-code could be removed and put in two different files.

Using my now image.include_mod.ab3 file does reduce the size of the executable by 23kb.
And if I use include instead of xinclude I would save another 83kb. In total the executable goes from 285kb to 179kb.
What is the difference between xinclude and include?

[Daedalus]

Originally Posted by amyren

Oh, so thats why certain commands did turn red.
No wonder my timer commands did not work when testing it on MorhOS.
Is there another way to implement a timer without using custom chips?

The OS-friendly way is to use timer.device, which is also a safer way of doing it than the Blitz way of directly accessing the CIA hardware, which may or may not already be in use elsewhere... AB3 has two timer includes that can be used, depending on your needs. gtimer.include is intended for GUI timings, and it can create signals to wake your program up at specified intervals. Kind of like a custom version of IDCMP_INTUITICKS events. The other is eclock.include, which is more like a count-up timer. It has high resolution and low resolution options, high resolution uses more CPU time but gives very accurate results for things like benchmarking file access etc., and resolution is better for timing longer operations like a 3D scene render.

I'm not sure if there's an easy way of using Blitz 2.1 commands - there may be some suitable commands in a 3rd party library, but I can't think of any right now. Otherwise, you can use timer.device directly in the same way as a C program would. The process is quite involved, but I'm sure there are plenty of C examples around for it that could easily be translated into Blitz.

I found that there was quite a lot to be disabled to get rid of the ab3zlib

I did comment away shamelessly every part with have zlib references and I also removed any PNG references. I might do the same with jpeg as well, since I probably will use only iff.

Hmmmm, I was sure there was a flag you could set to disable all zlib functionality. I'll have to look into it...

I think that image.include.ab3 file is much bigger than needed. I think that the demo-code could be removed and put in two different files.

Yeah, the demo code is pretty big, but it doesn't actually get included in the final executable (there are CNIF...CEND compiler directives surrounding it so the compiler ignores it if it's been included), and is often useful for testing an include.

Using my now image.include_mod.ab3 file does reduce the size of the executable by 23kb.

Yep, that's a good approach. If you really wanted to, you could even create custom includes for every program that you write, containing only the procedures and declarations you actually need. It's a lot of effort though...

And if I use include instead of xinclude I would save another 83kb. In total the executable goes from 285kb to 179kb.
What is the difference between xinclude and include?

That's very weird... XInclude is the same as Include except it only includes the requested file once, whereas Include will include it twice if it's used twice. It's bizarre that you're seeing that difference - if anything, Include should produce *larger* executables (and compile errors due to duplicated procedure labels). Are you sure you didn't change anything else in between, like turning off the debugger?

AB3 does produce large executables unfortunately, but there are also other things that affect the executable size and might help. First, disable the debugger before you create an executable. That stops it including a lot of extra trap code and so on that the debugger uses, but has no use in executables (and can even cause crashes in some cases). Second, once you've created the executable with Create executable... Use the Create Minimized Executable menu option instead to make the compiler take more passes and eliminate some unused code, but beware it will overwrite the previously created executable without warning. This takes a lot longer though so probably only necessary when you're ready for your final build, but you might find it makes a similar reduction in size as removing the unused parts of your includes.

[amyren]

Sorry, I think I must have have them swapped. Now when I tried to re-compile those with include and xinclude, it is clearly the x that makes the smaller executable.

I did a rewrite of the example to get it to load an iff using BlitzBasic2
It works but the colours looks terrible. I have not experimented with palette settings yet, could you advise me how I can adjust the colour output?

Here is the bb2 compatible example:

WBStartup
WbToScreen 0

If Exists("sys:test.iff")
LoadShape 0, "sys:test.iff"
If Window(0, 100, 100, 120, 140, $140E, "Image Test",1 ,2)
WBlit 0, 0, 0
Repeat
ev.l = WaitEvent
Delay_ 2
Until ev = $200
Else
NPrint "Error opening window"
End If
Else
NPrint "Error loading image"
End If

End

[Daedalus]

The palette issue is likely to do with Blitz not really understanding RTG, resulting in blitting without colours being taken into account. I'm not entirely sure of how to get around that with the standard commands, or if it's even possible.

The Mildred library is apparently quite good at dealing with chunky-format graphics operations (I believe it was used for the game Foundation), but I haven't used it myself so I can't say much else about it. From a quick look at the documentation it looks a little more involved than the standard commands.