Page 9 of 11

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Sun 22 Feb, 2009 11:28 pm
by cjgone
Can you write an example program that draws a sprite from a matrix?

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Mon 23 Feb, 2009 12:00 am
by benryves
That depends on what you mean by "draws a sprite from a matrix". :)

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Mon 23 Feb, 2009 3:04 am
by cjgone
Erm, 8 x 8 sprite.

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Mon 23 Feb, 2009 3:16 am
by 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

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Sat 28 Feb, 2009 11:47 pm
by cjgone
What does 128, 4, and 100 supposed to mean in that code block thing?

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Sun 01 Mar, 2009 2:10 am
by benryves
There is documentation. :P

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.

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Sun 01 Mar, 2009 8:08 am
by 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?

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Sun 01 Mar, 2009 12:57 pm
by 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).

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Thu 05 Mar, 2009 11:24 pm
by 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.

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 1:27 am
by calc84maniac
According to the documentation, a black pixel returns 0 and a white pixel returns 15. Try modifying your code to accommodate that. :)

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 2:51 am
by 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!

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 3:36 am
by 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.

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 11:00 am
by benryves
calc84maniac wrote: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. :D Was there a particular reason not to use the inline assembler?

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 3:42 pm
by darkstone knight
benryves wrote: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 :P

Re: [News] BBC BASIC Beta Testing - 2009/02/18 r718

Posted: Fri 06 Mar, 2009 4:17 pm
by 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.