not currently as RAND() maps differently to all the targets. I will put that on my TODO list. LFSR_SEED/LFSR_NEXT/LFSR_RANGE in the next release will be a seed-able pseudo rng.
telengard
Creator of
Recent community posts
sorry about that, it's a doc bug, the correct proc in crustyBASIC programs is RAND(). RND is a dialect thing, I'll update the docs, thanks for the report!
LFSR_NEXT etc are not fully implemented in 1.2.0, they are in 1.3.0 which is coming out later this week. A metric ton of fixes, updates and 2 new targets. :)
Hey Javajack, yes, you can do what you are trying to do, but `ARR AS ADDR OF U8` is an address parameter, not an array parameter. So inside the PROC you use PEEK/POKE with address math instead of ARR[I].
PROC SHUFFLE(ARR AS ADDR OF U8)
VAL AS U8
POKE ARR + 2, 99 ' write 99 to the 2nd index of ARR (3rd element 0 based)
V = PEEK(ARR + 2) ' read it back
ENDPROC
then call that with the address of the array
DECK[51] AS U8 SHUFFLE(ADDR(DECK)) ' or SHUFFLE(&DECK)
Array indexing on an address parameter, like ARR[2] or ARR(2), is not supported currently. I think I would like that too, for now you'd use PEEK/POKE.
For a real shuffle you pass the length too to handle the bounds of the array
SHUFFLEARR ADDR DECK, LEN(DECK)
thanks for the question!
Sorry about that! I was able to repro this, thank you for the bug report. It's fixed and will be in the next release (I'm shooting for next week).
For now, to get around that you can do this, which works. I tested it here with 1.2.0 and xvic.
K AS U8 LAST AS U8 WHILE 1 K = RAWKEY_CODE IF K <> 0 AND LAST = 0 THEN PRINT K ENDIF LAST = K ENDWHILE

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