[News] BBC BASIC Beta Testing - 2009/03/06 r720

[cjgone]

Can you write an example program that draws a sprite from a matrix?

[benryves]

That depends on what you mean by "draws a sprite from a matrix".

[cjgone]

Erm, 8 x 8 sprite.

[benryves]

Use VDU 23 to define new characters and VDU 5 to plot characters anywhere on the screen, eg:

Code: Select all

10 *FONT LARGE
20 VDU 23,128,&3C,&5E,&8F,&DF,&FF,&FF,&7E,&3C
30 MOVE 100,100
40 VDU 5,128,4

[cjgone]

What does 128, 4, and 100 supposed to mean in that code block thing?

[benryves]

There is documentation.

VDU 4 and VDU 5 switch between (4) displaying text at the text cursor position (ie, within a fixed grid - like the home screen in the TI-OS) and (5) displaying text at the graphics cursor position (like the graph screen in the TI-OS).

VDU just sends data to the VDU emulator (the thing that handles text and graphics output), so VDU ASC("A") is equivalent to PRINT"A";. In a similar vein, VDU 128 is equivalent to PRINT CHR$(128); - it outputs character number 128 to the display (remember that the previous VDU 23 statement changed the appearance of character 128). BBC BASIC uses ASCII internally so only the first 127 characters are defined; this makes 128 a good number for your first sprite.

MOVE 100,100 moves the graphics cursor 100 logical pixels up and right from the origin (bottom-left hand corner) of the screen. Where that appears depends on your current MODE; in modes 3 and 4 there are four logical pixels to each device pixel horizontally and vertically, so it'll be 25 pixels up and right from the bottom-left.

[cjgone]

Thanks for the explanation, noting that the documentation itself is pretty vague imo.

Logical pixels some type of way of simplifying parts of pixels or something?

Where does 101 display compared to 103?

[benryves]

Every screen MODE on the BBC Micro had a logical resolution of 1280×1024, that is to say that MOVE 1280/2,1024/2 would put the graphics cursor in the middle of the display regardless of the actual screen mode - and hence physical resolution - in use.

The TI-83+ version uses a logical resolution of 384×256 (modes 3 and 4) or 384×320 (mode 0). This is to roughly approximate the region of the screen that would be visible on the BBC Micro based on the size of characters. (On the BBC Micro MODE 4 has a physical resolution of 320 pixels wide, which gives us 40 eight-pixel-wide characters horizontally. This means that each character is 1280/40=32 logical pixels wide. On the TI-83+, we have only 12 characters horizontally; 12*32=384).

The scaling of logical graphics coordinates to device pixels is a simple integer division; for four logical pixels to one physical pixel you'd see that 100, 101, 102 and 103 all resulted in 25; 104 would move along to 26.

If you don't like this approach, feel free to use *GSCALE to change the scaling (*GSCALE 1 results in a logical resolution that matches the physical resolution, 96×64).

[bwang]

Could you explain the use of the POINT statement? Specifically, the following bit of code:

Code: Select all

   
   10 DIM S% 19
   20 S%?0=&21
   30 S%?0=&21
   40 S%?1=&4C
   50 S%?2=&93
   60 S%?3=&11
   70 S%?4=&40
   80 S%?5=&93
   90 S%?6=&01
  100 S%?7=&F4
  110 S%?8=&02
  120 S%?9=&ED
  130 S%?10=&B0
  140 S%?11=&EB
  150 S%?12=&01
  160 S%?13=&0C
  170 S%?14=&00
  180 S%?15=&BEF
  190 S%?16=&30
  200 S%?17=&4C
  210 S%?18=&C9
  220 *GSCALE 1
  230 CLG
  240 *REFRESH OFF
  250 *FX4,1
  260 *ESCOFF
  270 D%=1
  280 A%=32
  290 U%=48
  300 REPEAT
  310   CALL S%:CALL S%
  320   RECTANGLE FILL A%+32,0,96-A%,1
  330   RECTANGLE FILL 0,0,A%,1
  340   IF RND(1)<.5 A%=A%-1 ELSE A%=A%+1
  350   IF A%<0 A%=0
  360   IF A%>63 A%=63
  361   IF POINT(U%,40) GOTO 411
  370   RECTANGLE FILL U%,40,0,1
  380   K%=INKEY0
  390   IF K%<>0 U%=U%+(K%=136)-(K%=137)
  400   *REFRESH
  410 UNTIL K%=13
  411 WAIT 100
  420 *REFRESH ON
  430 CLG:CLS
  440 *FX4,0
  450 *ESCON

does not work, because it exits almost immediately (I'm trying to make a tunnel game). If I take out line 361, it works, except then you can't die anymore.

[calc84maniac]

According to the documentation, a black pixel returns 0 and a white pixel returns 15. Try modifying your code to accommodate that.

[benryves]

Black returns 0 and white returns 15 - just not necessarily from the pixel you asked for. I'll find out where that's mucking up and fix it, thanks for the bug report!

[calc84maniac]

Wait... where did you get that? The problem with his code was that he was accidentally checking for collision with a white pixel instead of a black pixel.

[benryves]

Wait... where did you get that? The problem with his code was that he was accidentally checking for collision with a white pixel instead of a black pixel.

Oh, sorry, I completely missed bwang's post and thought you were reporting a bug. Either way it doesn't affect the problem that there is a bug; if you start up BBC BASIC (leaving it in its default state) and type in the following code

Code: Select all

PLOT 0,0:PRINT POINT(0,0)

it prints 15 (ie, white) even though there's a black pixel at (0,0).

Edit: I haven't had a chance to run your program yet, bwang, but GOTO-ing out of a loop structure (REPEAT in this case) will cause a memory leak if you do it a lot. Consider using either

Code: Select all

361   IF POINT(U%,40) EXIT REPEAT

or, if you'd like better compatibility with other older versions of BBC BASIC:

Code: Select all

361   IF POINT(U%,40) K%=13 : GOTO 410

See here for more information.

Edit 2: And that hand-assembled code scares me. Was there a particular reason not to use the inline assembler?

[darkstone knight]

Black returns 0 and white returns 15 - just not necessarily from the pixel you asked for. I'll find out where that's mucking up and fix it, thanks for the bug report!

aha, that was why my maze generator was buggy

[bwang]

Changing it to IF POINT(U%,40)=0 GOTO 411 doesn't work either. And the hand assembled code was copied from the ExecAsm page on WikiTI.