[egypturnash]

C64 BASIC is kind of a mess, there's zero support for graphics and sound. Your code rapidly becomes a giant pile of POKEs and PEEKs, and all your operations become absurdly slow because all the math routines are floating point only, so there's a ton of integer/fp conversion overhead on something as simple as "peek a memory location, AND/OR it with a few values taken from variables stored as floating point, poke it back".

Assembly becomes really attractive really quickly.

[dspillett]

> C64 BASIC is kind of a mess, there's zero support for graphics and sound.

Which is surprising because one of the advantages of the C64, IIRC, for games was that it had built in sprite manipulation so you didn't have to do the work yourself on the CPU (unless you wanted something more flexible than the one standard sprite format).

[Woansdei]

C64 Basic did have integers.

A floating point

A$ string

A% int

as you would expect ints are quicker.

[izacus]

Err, ints are internally stored as floats as well and that leads to some really interesting performance quirks where you'd not expect.

There were BASIC compilers for C64 which generated significantly faster code just because they actually used ints for integer operations.

[RiverCrochet]

Not on C64 BASIC. C64 BASIC converted ints to floats internally and converted them back to ints when needed.

What sidestepped part of that conversion was using variables instead of literal constants. So, doing something like N0=0, and using the variable N0 instead of 0 was faster.

Additionally, C64 looked up variables in the order they were defined, so variables defined later were slower. If your program used 0 a lot, you'd want to have N0=0 as the first statement in your program. I typically had N0=0 and N1=1 as those were common to use.

QBasic was so much faster and implemented differently. DEFINT A-Z at the top of the program typically sped it up significantly if you didn't use floating point. This might have worked on GW-BASIC as well.