Blitz Basic 2 basics

[Nightshft]

Tried it. Works super fine. Thanks a lot Rob!

[E-Penguin]

Originally Posted by Stejjie

How do you get text to wrap in a window you've opened, rather than have it "fall off" the edge? I'm sure I used to know, but can't remember for the life of me!

There's an OS call to get the length of a string, in pixels, if printed to a given RastPort. You could use it to implement wrapping by testing whether the line would fit in the window or whether it needs to be split.

http://amigadev.elowar.com/read/ADCD.../node0485.html

[mahen]

Hi everyone ! A couple of noobs questions !

1) Regarding UsePath
- does it make the code any faster or is that just to save the coder time ? I thought the latter was pretty obvious but I read the former somewhere in a Blitz guide...

- can I use it with a complex expression, like the following one in which Enemy is a list of newtypes and chord is a newtype ? Doesn't seem to work.

UsePath Enemy()\chord

The program runs but the value returned is incorrect.

- is it possible to "reset" UsePath ?

2) A more general question when using lists, newtypes etc... Is it possible / useful / advised to optimize by reducing the number of sub-levels ? I guess each indirection level is cpu cycles consuming ? (not sure indirection is the right English term)

3) Regarding the TED editor
- Sometimes I have to write a line of code which exceeded the max number of allowed characters. Is it possible to split a line of code into several lines ?

4) Updating text
- Playing with FNS library to display bitmap fonts. I guess, in order to update some text at a given position, I should blit a black rectangle over the already existing text ? Is there a faster way ? Or maybe I should use Shapes or Sprites (in which case, maybe the FNS lib is not the solution ?!)

5) CLS
I get the message "command only available from the Amiga mode" when using this command from a Statement. BUT this is invoked from my main game loop which is in Blitz mode. And if I call CLS from the main loop, it works ?!
Alternatively : how am I supposed to clear the bitmap in Blitz mode then ?

Thanks everyone :-)

[Daedalus]

Originally Posted by mahen

Hi everyone ! A couple of noobs questions !

1) Regarding UsePath
- does it make the code any faster or is that just to save the coder time ? I thought the latter was pretty obvious but I read the former somewhere in a Blitz guide...

I haven't benchmarked it, but I expect it's just a compiler directive that makes the code quicker to write but doesn't make a difference to the executable.

- can I use it with a complex expression, like the following one in which Enemy is a list of newtypes and chord is a newtype ? Doesn't seem to work.

UsePath Enemy()\chord

The program runs but the value returned is incorrect.

Yes, this should work. I've done this in AmiBlitz 3 anyway without issues. It's possible that Blitz 2 has a bug in that area though... Are you sure you're still using the backslash to reference the field?

UsePath Enemy()\chord

NPrint \x

- is it possible to "reset" UsePath ?

Yes, sort of. the UseLastPath command will step the current path back to the previous path used. I'm not sure if it works to get rid of the first path set entirely, but that doesn't really make sense to do anyway.

2) A more general question when using lists, newtypes etc... Is it possible / useful / advised to optimize by reducing the number of sub-levels ? I guess each indirection level is cpu cycles consuming ? (not sure indirection is the right English term)

In general, yes, traversing more levels will take more CPU time. Whether that makes a big difference depends on how tight you are for CPU cycles in your main loop. If you're accessing particular sublevels a lot in a short space in time, perhaps using a pointer to them would make sense.

3) Regarding the TED editor
- Sometimes I have to write a line of code which exceeded the max number of allowed characters. Is it possible to split a line of code into several lines ?

Are you using the original TED editor? Switch to SuperTED, which allows longer lines I think. Even if it doesn't, it's a much better editor. AmiBlitz 3 allows lines to be split across multiple lines by using special characters to tell the compiler to combine lines, though I might suggest that there's most likely a way of making the line shorter within the constraints of Blitz too.

4) Updating text
- Playing with FNS library to display bitmap fonts. I guess, in order to update some text at a given position, I should blit a black rectangle over the already existing text ? Is there a faster way ? Or maybe I should use Shapes or Sprites (in which case, maybe the FNS lib is not the solution ?!)

That's probably the quickest way alright, and as far as I know, there's no way to automatically draw the background. With the standard Print command you can set a jammode to blank the background, but the standard Print system comes with its own limitations.

5) CLS
I get the message "command only available from the Amiga mode" when using this command from a Statement. BUT this is invoked from my main game loop which is in Blitz mode. And if I call CLS from the main loop, it works ?!

Ah yes, this is a funny one. What's happening is that the Blitz or Amiga mode is applied by the compiler based on where they are in the listing itself, not the program flow when running. So if your program flow jumps in and out of a section in Blitz mode (e.g. using Gosub or a procedure), you can hit against this error. You need to position the Blitz and Amiga commands in such a way that code is always in the desired mode, both in terms of program flow and the code listing.

Alternatively : how am I supposed to clear the bitmap in Blitz mode then ?

You can draw a giant rectangle in colour 0. From memory, there are also issues with CLS in certain circumstances and I think I used this method as an alternative to using CLS.

[mahen]

Daedalus : wow, that was extremely helpful ! THANK YOU !

Originally Posted by Daedalus

Are you sure you're still using the backslash to reference the field?

UsePath Enemy()\chord NPrint \x

Oh my. Nope ! For a silly reason : the Blitz2_guide I use (found on Aminet) which contains the documentation in Amiga Guide format is not displayed properly and all backslashes are missing...

I have to check whether it's an issue in the .guide or in the Multiview / datatypes provided with OS 3.2.x.

If you're accessing particular sublevels a lot in a short space in time, perhaps using a pointer to them would make sense.

OK ! I have to check how to use pointers in Blitz then.

Also, I think I'll optimize by pre-computing some calculations involving * and / at the relevant time. More memory used but faster code. In general, I should look for a way to profile my code.

Are you using the original TED editor? Switch to SuperTED, which allows longer lines I think. Even if it doesn't, it's a much better editor. AmiBlitz 3 allows lines to be split across multiple lines by using special characters to tell the compiler to combine lines, though I might suggest that there's most likely a way of making the line shorter within the constraints of Blitz too.

Yep, using SuperTED 2.52. I like it, it's very fast on my machine. And I figured out there were some nice goodies which were not enabled by default, like the debugger (man, I spent hours pin-pointing issues which I would have found instantly !).

You need to position the Blitz and Amiga commands in such a way that code is always in the desired mode, both in terms of program flow and the code listing.

Ohhhhh ! Okay that kinda makes sense. A given procedure could be theorically invoked from different parts of the code which could be in different modes... I guess the compiler could check that but well, no big deal

You can draw a giant rectangle in colour 0. From memory, there are also issues with CLS in certain circumstances and I think I used this method as an alternative to using CLS.

Thank you, I'll try that ! I should look up some double-buffer examples.

Thank you again so much for your help. There more I tinker with Blitz 2 the more I think I would have been a HUGE fan of it back in the days. I only had AmigaBasic.

BTW I quickly gave AmiBlitz 3 a try, but I guess my machine being on the lower end side, it's not optimal. (030@50)

[Daedalus]

Originally Posted by mahen

Oh my. Nope ! For a silly reason : the Blitz2_guide I use (found on Aminet) which contains the documentation in Amiga Guide format is not displayed properly and all backslashes are missing...

I have to check whether it's an issue in the .guide or in the Multiview / datatypes provided with OS 3.2.x.

That's an issue with versions of the AmigaGuide datatype from OS 3.0 on unfortunately. Backslashes need to be escaped with a second backslash to be displayed properly, but then you get double backslashes when viewed on OS2. I guess that version is just pretty old. It might be worth digging the version out that's included in AmiBlitz 3... Some things will be changed but 99% is the same, and AFAIK all the formatting is fixed.

OK ! I have to check how to use pointers in Blitz then.

If you've used them in another language it should be pretty straightforward

Also, I think I'll optimize by pre-computing some calculations involving * and / at the relevant time. More memory used but faster code. In general, I should look for a way to profile my code.

There are a few techniques that can be used, most of which aren't Blitz-specific, such as poking background colours for fractions of a frame, counting frames with an interrupt for longer things, or setting up a timer.

Ohhhhh ! Okay that kinda makes sense. A given procedure could be theorically invoked from different parts of the code which could be in different modes... I guess the compiler could check that but well, no big deal

Yeah, the compiler is a bit primitive in that regard and only works from top to bottom. It affects compiler directives and other things too, like how procedures having to be defined before they're called.

BTW I quickly gave AmiBlitz 3 a try, but I guess my machine being on the lower end side, it's not optimal. (030@50)

Ah, yes, it will be a little sluggish then. You've probably got the optimal installation now then.

[mahen]

Hi ! I'm a bit lost regarding the pointers...
I could find very little information about them actually.

In the BB manual, there is only this :

Using Pointers
When doing many operations on a particular subfield in a NewType a temporary pointer
variable of the same subfield type can be created and that used instead of the larger (and
slower) path name:
UsePath a(i)\alien\pos
replaced by:
UsePath *a
*a.pos=a(i)\alien

What I'm trying to achieve is this (because given my current code there are slowdowns induced by a specific area) :

I have a list of the Enemy newtype.
This newtype contains a look-up table initialized when it's created. (an array) called precalcSat which contains intermediate RGB values. (in this test, 1 enemy = a copper bar of variable size and colour)

Instead of invoking the following from my main loop :
Enemies()\precalcSat[i]
I'd like to use a pointer to the beginning of the precalcSat array.
I tried :
*pt = Enemis()\precalcSat[0]
and tried accessing to pt(i) but to no avail. Tried many different syntaxes.

Thanks a lot

(for some reason using this LUT doesn't speed up the code as much as expected. But it's better when removing those accesses)

[Daedalus]

So you're creating that pointer outside the main loop? You have to be careful because in a dynamic list array, the elements aren't necessarily contiguous so you can't use pointer arithmetic to jump around. However, the contents of the Newtype should allow that sort of navigation.

*pt = Enemis()\precalcSat[0]
and tried accessing to pt(i) but to no avail. Tried many different syntaxes.

Did you pre-declare the pointer elsewhere? What type is it? Your assignment here won't work because it's setting the pointer address to the value of precalcSat[0], which I'm assuming is a byte value?

To get the address of a variable, use the & symbol:

*pt = &Enemis()\precalcSat[0]

NPrint "Sat value 2: ", peek.b(*pt + 2)

Assuming the array is defined as bytes. The example from the documents uses the root of a Newtype, not an individual entry, which returns the address of that Newtype and so doesn't need the & symbol.

Regarding the LUT speedup, it's indeed possible the problem is memory accesses. What type of variables are you using, and on which CPU? By default Blitz uses "quick" types, which are a fixed-point, 32-bit type, and despite their name are actually quite slow to deal with, especially on the 68000. You're better of using a word type (16-bit integer) for things like array indices and anywhere else that integers work.

[mahen]

Hi !

Yep, I use words as the default type !

But if I only plan to use the content of the precalcSat array (which itself is part of a Newtype list), values will be contiguous anyway, so no issue ?

Nope, I didn't pre-declare the pointer. I thought pointers were longs ?

Thank you !

edit : 030@50 setup, btw !

Edit : so I tried this
*pt = Enemies()\precalcSat[0]
And Peek.w(*pt+i)
But it doesn't return the right value... hm...

[mahen]

Hi ! I have new questions :-)

1) When using the dual playfield mode : is it possible to have some kind of "mask" or "window" so that, for instance, the background is only visible in the center of the screen and not in the border ?

(otherwise, the easy solution is just to make sure the foreground has a colour different from 0 so that it gets opaque).

Just asking as I'm aiming at very lightweight 2*1 bit playfields. If I have so sacrifice one colour to add opacity, well, I'll have to switch to 2 bits playfields ;-)


2) Also, another question : is there somewhere an example of "CustomSprites" ? (sprites multiplexing). As usual, the manual is pretty... obscure to me

[Daedalus]

Sorry, could've sworn I replied to this...

Originally Posted by mahen

But if I only plan to use the content of the precalcSat array (which itself is part of a Newtype list), values will be contiguous anyway, so no issue ?

Yes, each instance of the array will be contiguous, just the elements of the lists (so each instance of the array) can move relative to each other.

Nope, I didn't pre-declare the pointer. I thought pointers were longs ?

Yep, pointers are longs, but if you want to treat the pointer as if it's the thing it points to (typically a Newtype), you need to declare it as that type. For example, *myscreen.Screen = Screen(...). The address of the Screen struct / Newtype will be a longword but you can access the fields at that address using *myscreen\Width for example.

Edit : so I tried this
*pt = Enemies()\precalcSat[0]
And Peek.w(*pt+i)
But it doesn't return the right value... hm...

What's happened there is that you've assigned the value stored in the array element 0 as the address of the pointer. This isn't where the array lives which is what the & symbol does.

Also, if it's an array of words, you need to skip 2 bytes at a time:

Peek.w(*pt + (i * 2))

Though, as suggested elsewhere, using a left shift there will be faster than a multiply (if slightly harder to follow):

Peek.w(*pt + (i LSL 1))

Originally Posted by mahen

1) When using the dual playfield mode : is it possible to have some kind of "mask" or "window" so that, for instance, the background is only visible in the center of the screen and not in the border ?

Hmmm, I don't know. It might be possible by fidding with some low-level stuff, but there isn't a simple way to do it in Blitz as far as I know.

(otherwise, the easy solution is just to make sure the foreground has a colour different from 0 so that it gets opaque).

This is probably how I would do it.

2) Also, another question : is there somewhere an example of "CustomSprites" ? (sprites multiplexing). As usual, the manual is pretty... obscure to me

I don't have an example to hand, but from memory it's simple enough. The manual is particularly weak in this are, though the basic info is there once you get used to the quirks of how it was written. Essentially what you need to do is reserve the space needed when you declare the display using InitCopList. For Custom... commands, you add positive values for this space.

The manual lists (4 x numsprites + 2) as the amount of space needed, so for 8 sprites it should be 4 x 8 + 2, which is 34. Use this value with InitCoplist. If you have any other custom copper commands, you'll need to calculate their offsets on the coplist, but for simplicity just use one to start with.

Once that's done, you declare your sprite break Y position with CustomSprites. The CCOffset is to accommodate other Custom... commands, so leave that at 0. Then you should be able to use a second set of sprite channels numbered 8-15 in the area below the declared Y position.

[mahen]

Thank you so much for the replies !!

I have yet another issue :-) with dual playfields.
I have 2*2 bits bitmaps, and hence, a 8 colours copperlist.

I understood the first 4 colours of the palette were for the "back playfield" and the following 4 for the "front playfield".

I can indeed use AGAPalRGB to define the first 4 correctly.
However, altering colours 4-7 of my palette make no difference at all to the front playfield. For instance, I blit some aliens in the foreground, and they always appear in a kind of dark blue which does NOT belong to the palette at all.

Any idea ?

(out of curiosity, I tried to swap the playfields, and, obviously, it has the same consequences : I cannot alter the values of the front playfield - which used to be the back one).

BTW, when invoking DisplayBitmap I specify the foreground, then the background. I have probably overlooked something obvious

I have read somewhere there could be an offset of 16. Tried that to no avail.

EDIT : anyway, it's not good. Because actually it appears that, DisplayBitmap must be invoked with the background THEN the foreground (which is not what I read in the manual).
So... The first colours of my palette would be for the foreground. Which is not what I had read... Sigh ! In both cases, I cannot alter the colours of the other playfield so the problem remains.

[mahen]

Stumbled upon this : https://eab.abime.net/showthread.php?t=104666
Which probably answers my issues.

"you need to bear in mind that the palettes will overlap by default, since AGA defaults to OCS/ECS compatibility mode. This means that the palette for the second playfield starts at 8, not 16, so your first picture will use pens 0-15, the second will use pens 8-23. Use DisplayControls to adjust BPLCON3 (I can't remember the exact bits) to adjust the offset so that the second playfield uses pens 16-31."

I'm not 100% conviced yet, though. As I use 4 colours playfields, the overlap should not be an issue...
Also, it doesn't explain why, for the moment, I can see stuff in a dark blue which does NOT belong to my palette (I tried to set the whole palette to white to make sure), or why for fore/background seem to be inverted.

[Daedalus]

Yeah, I think the foreground and background are mixed up in the manual. What you need to keep in mind is that the offset doesn't care about how many bitplanes you use - it's always 8. So in your case, where you have colours 0-3 for your first field, the second field will use colours 8-12, leaving colours 4-7 doing nothing. Sprite colours then are offset to 16.

When you set up your display and your palette, you need to take this into account - specify 16 colours even if you're only using 2+2 bitplanes so that the entries in the palette are available to you.

[mahen]

Thanks !
Hmm...

Still no luck. Then I "upgraded" my CopList to 16 colours instead of 8 and... The background which used to be invisible suddenly showed the right colours. Even though I have 2 2 bits bitmaps...

Is 8+8 colours dual playfield illegal ? Mysterious stuff !

[Daedalus]

Yeah, that's the expected behaviour. Sorry, I should have been clearer - both the palette and the display (which means the Coplist declaration) need to have enough colours to cover the palette entries you need, regardless of bitplanes used. You'll need to set both to 32 colours to use sprites, for example, because they use palette entries 16-31.

[mahen]

Ah, okay, it makes sense then ! I guess that won't make me lose the benefit of having lightweight bitmaps (2 bitplanes) in terms of speed of blitting & memory !

thanks again

[Cobe]

Originally Posted by mahen

1) When using the dual playfield mode : is it possible to have some kind of "mask" or "window" so that, for instance, the background is only visible in the center of the screen and not in the border ?

(otherwise, the easy solution is just to make sure the foreground has a colour different from 0 so that it gets opaque).

Just asking as I'm aiming at very lightweight 2*1 bit playfields. If I have so sacrifice one colour to add opacity, well, I'll have to switch to 2 bits playfields

Mask/window no.. But
If by a center and not in the boder you mean exactly not smaller than other playfiled you could poke bplcon3 border balnk.