itch.io

that seems totally fine, it was definitely a compiler optimization bug w/ PEEK, but it's fixed.   :)

I've been able to narrow down the cause, I've been a little too aggressive with the zero page and depending on what calls are made, it blows away that 1 line stub.  I've fixed it and it will be in the next release, thanks for the report! 

Just curious, were you doing PEEKs in that program by any chance?  If you can share the listing, I'd be curious (and can use it as a regression test).

Yup, this is a regression with the peephole optimizer, it's fixed and will be in the next release.  All of the array work I was doing caused this to show up.  Unit test added to ensure it doesn't happen again too.   :)

Thanks for the report, super helpful!

Hey JavaJack, 

No problem, glad to fix them, anything you find I'll add to the next release for sure.  The input bug you had reported should be fixed as well (the overly repeating keystrokes).

As for running more than once, depending on the program, I noticed it will return to a prompt on the vic-20, it usually depends on what the program does. I will look into this and report back with a more definitive answer.

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.

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

Casting is on my TODO list

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.

hey JavaJack, pretty cool, this using the SPRITE api?  looks like maybe a vic20?  how did you make the animation?

this seems like a fun game!  any chance you can share the .prg/.d64 so I can try it on my C64?  I couldn't get the 1-4 keys to work in the browser version.

is the pico8 cart available?  I play on the steam dec

Any chance of posting the cart?  Would like to play it on my Steam Deck.

Awesome, thank you!

Was going to ask the same thing, would like to play this on my Steam Deck.