MaxCoderz

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

_________________
Ticalc profile:

http://www.ticalc.org/archives/files/au ... 10173.html

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

Erm, 8 x 8 sprite.

_________________
Ticalc profile:

http://www.ticalc.org/archives/files/au ... 10173.html

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

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

_________________
Ticalc profile:

http://www.ticalc.org/archives/files/au ... 10173.html

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.

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?

_________________
Ticalc profile:

http://www.ticalc.org/archives/files/au ... 10173.html

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).

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


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.

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

_________________
~calc84maniac has spoken.

Projects:
F-Zero 83+
Project M (Super Mario for 83+)

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!

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.

_________________
~calc84maniac has spoken.

Projects:
F-Zero 83+
Project M (Super Mario for 83+)

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
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
or, if you'd like better compatibility with other older versions of BBC BASIC:

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?

aha, that was why my maze generator was buggy

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.