hey JavaJack, pretty cool, this using the SPRITE api? looks like maybe a vic20? how did you make the animation?
Viewing post in Bouncing letter
VIC-20, yeah. It's just TILE_PLOT() in an infinite while loop with x,y,dx,dy where dx & dy alternate between 1 and -1. I couldn't really tell if I was "doing it right". It was a crapton of trial and error. I also got warnings about adding u8 and i8... but I didn't know how to do it otherwise. Also in hindsight maybe this is better done with CELL_PUTC()?
Unrelated to the bouncing letter program, I got really weird results with INKEY_CODE() and RAWKEY_CODE() under the Vice VIC-20 emulator. Holding down a key like tilde in the emulator would generate a stream of 3 different numbers for some reason.
thanks for the info... there's always more than 1 way to do things, no way is truly "right". :)
CELL_PUTC() is better to use if you aren't using all of the TILE api, but they end up with the same result on screen. CELL_PUTC() is a little more low level, but you have a little more control over things like color etc with the TILE version. You can do what you are doing with the SPRITE api as well (see the example\multi\sprite.cbs).
I imagine you are alternating something like this in a loop?
CELL_PUTC X, Y, CELL_CODE(ASC("A"))
CELL_PUTC X, Y, CELL_CODE(ASC(" "))
The next version will have some helpers that make that a little less verbose when you are using direct values like "A", etc and not calculating them.
CELL_PUTC X, Y, "A" CELL_PUTC X, Y, " "
I did repro and fix the issue with held keys getting scanned (was picking up key repeats), so INKEY_CODE/RAWKEY_CODE will be as expected the next release (which will be soon).
And your issue with the warning, that's just about having to deal with a I16 tmp due to the unsigned and signed being done in a single statement. totally legit, the warning is just for performance. I did update the compiler to handle this better since it will be a common thing folks do.
I'm no 6502 guru. Does adding u8 and i8 really need 16 bit ops?
0000 0011 ($03 = +3) + 1111 1111 ($FF = -1)
Expected result +2
Or maybe there's some way to do INC and DEC (x++ isn't very BASIC-esque, though.)
BTW another nice-to-have would be expression-based consts.
const TILE_COLUMNS_LESS_1 = TILE_COLUMNS - 1 '21
Definitely not required, but the compiler is general purpose and pretty conservative right now (I try and get it correct and then optimize) and uses a 16 bit temporary there to avoid guessing wrong when signed and unsigned values mix as it doesn't always fit when doing the math. You were + / - 1 so that's a specific case that should be optimized later in the pipeline, I will work on that.
I like your idea of INC(#) / DEC(#) for "in place" updates. And yup, I agree, the --/++ is a C thing, not BASIC. :)
Expression based CONSTs are supported but TILE_COLUMNS was a no arg accessor PROC. I've updated it (and some others) to be read-only scalars so you can use the initializer you mentioned (and a compiler error will happen when attempting to use a PROC in a const expr initializer).