* The top 4 bits of $D018 (VM10-VM13) control the base of graphics memory
* The bottom 3 bits of $D011 (YSCROLL) and $D016 (XSCROLL) let you delay screen display by 0-7 pixels in either axis
* The 4th bit of $D011 (RSEL) and $D016 (CSEL) let you shrink the screen viewport so it's visibly 304x192 pixels (in NTSC) even though the screen memory is still 320x200.
VM10-13 lets you establish a double-buffer, you can switch instantly between a front and back buffer by changing $D018. While you are scrolling, you copy the front buffer to the back buffer, offset by 8 horizontal pixels (1 byte) or 4 vertical pixels, then add in new map data on the edge you're scrolling towards. On each frame, you update XSCROLL/YSCROLL by one pixel so the visible screen is moving towards your new screen, then once it's moved all 8/4 pixels, switch to the new buffer.
The cost of copying all that graphics memory is expensive, so split it across the 8/4 frames.
Experimenting with C64 BASIC taught me a lot back in the day, but it quickly became clear that for any real game dev you need to be using assembly.
But a few years later, the Amiga brought us DPaint and Blitz Basic, and suddenly it was very possible to make a pretty competent game in BASIC as a self-taught teenager with no Internet access. That’s probably a better choice for anyone wanting to experiment with retro game dev using the tools of the period without resorting to assembly language
That depends on what you mean by “real game dev”. I did a few game things of my own in BBC BASIC, eventually with a bit of 6502 assembly in key places, back in the day. On those machines you can still happily run a basic game loop in interpreted BASIC, the whole thing for text-based games, you just need to get down to the bare CPU for things like sprites, other rapid graphics drawing, and maybe some other number crunching (I did some basic compression in assembly for lots of text, though it wasn't really effective, if you are already doing graphics in assembly, then it probably makes sense to do collision detection and such there too, etc.).
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".
> 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).
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.
It had a nice set of built-in graphics functions and an inline assembler, amongst other things.
I can still remember that VDU 23 was the command to redefine a character, so much easier than doing the same sort of thing on the C64 (copy the character set from ROM to RAM, get the VIC to use the RAM copy with POKE statements, modify the desired character)
> It had a nice set of built-in graphics functions
IIRC those were actually in the “OS” ROM, with BASIC just having syntactic sugar to call them, rather than being part of the BASIC ROM itself, so you could call them from elsewhere (i.e. your own assembly code, even if you'd paged the BASIC ROM out to make some RAM available in that bit of the address space on the BBC Master).
> and an inline assembler, amongst other things.
That assembler was great when I was cutting my programming teeth and progressing a bit beyond BASIC to better understand the hardware.
BBC BASIC has some other crucial, more basic, features that were missing from other 8-bit micros. Actual named functions and procedures were key¹, and long variable names were useful² where some BASICs only allowed one or two characters³.
--------
[1] Other BASICs had no more than GOTO and GOSUB/RETURN, usually only allowing you to jump to line numbers, not names/labels. There was even some support for local variables making proper recursion possible up to a point (limited by the small stack).
[2] if limiting for long code due to memory constraints
[3] or allowed more but only respected the first couple, BBC BASIC syntax in theory allowed up to 248 characters⁴ but only respected the first 40 and practically you still limited yourself to a few (say, up to 10 for some for clarity, 1 for things like loop counters to save space in your code, CPU time in the interpreter, and space in the interpreter's variable dictionary).
[4] the absolute limit to what you could actually use in a line, itself having a length limit of 256-minus-a-few, and at that length all you could do was assign a single digit or print the value.
C64 Basic was V2 of a dialect of the Microsoft derived Basic for the PET. It was out of date already compared to the latest V4 because the older version fit into a smaller ROM to save costs.
AMOS was also another beloved alternative on the Amiga.
Just cross-checked my memories, Worms was written in Blitz BASIC, another example of good ideas matter more than programming languages, assuming that it is good enough for the implementation.
I owe having learnt Timex BASIC, Turbo BASIC, AMOS, Turbo Pascal, Z80, 68000, and 80x86 Assembly, before learning C, to understanding it not being that special.
There's a lot that can be improved in the code, such as just using FOR...TO...STEP would be much faster.
In general, this is a routine that is super easy to write in 6502 assembly. Most magazine BASIC games had something like that, with a few such routines that were POKEd in memory at startup. Several were written in a relocatable fashion so that they could be copied easily from one game to the next.
Man does this bring back memories of my old Atari 800 and entering or writing games in BASIC for it. Something extremely nostalgic about that kind of development for some of us.
What you really need:
http://1amstudios.com/2014/12/07/c64-smooth-scrolling/
https://www.c64-wiki.com/wiki/Scrolling
* The top 4 bits of $D018 (VM10-VM13) control the base of graphics memory
* The bottom 3 bits of $D011 (YSCROLL) and $D016 (XSCROLL) let you delay screen display by 0-7 pixels in either axis
* The 4th bit of $D011 (RSEL) and $D016 (CSEL) let you shrink the screen viewport so it's visibly 304x192 pixels (in NTSC) even though the screen memory is still 320x200.
VM10-13 lets you establish a double-buffer, you can switch instantly between a front and back buffer by changing $D018. While you are scrolling, you copy the front buffer to the back buffer, offset by 8 horizontal pixels (1 byte) or 4 vertical pixels, then add in new map data on the edge you're scrolling towards. On each frame, you update XSCROLL/YSCROLL by one pixel so the visible screen is moving towards your new screen, then once it's moved all 8/4 pixels, switch to the new buffer.
The cost of copying all that graphics memory is expensive, so split it across the 8/4 frames.
Experimenting with C64 BASIC taught me a lot back in the day, but it quickly became clear that for any real game dev you need to be using assembly.
But a few years later, the Amiga brought us DPaint and Blitz Basic, and suddenly it was very possible to make a pretty competent game in BASIC as a self-taught teenager with no Internet access. That’s probably a better choice for anyone wanting to experiment with retro game dev using the tools of the period without resorting to assembly language
That depends on what you mean by “real game dev”. I did a few game things of my own in BBC BASIC, eventually with a bit of 6502 assembly in key places, back in the day. On those machines you can still happily run a basic game loop in interpreted BASIC, the whole thing for text-based games, you just need to get down to the bare CPU for things like sprites, other rapid graphics drawing, and maybe some other number crunching (I did some basic compression in assembly for lots of text, though it wasn't really effective, if you are already doing graphics in assembly, then it probably makes sense to do collision detection and such there too, etc.).
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.
> 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).
C64 Basic did have integers.
A floating point
A$ string
A% int
as you would expect ints are quicker.
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.
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.
BBC BASIC was far better than C64 BASIC.
It had a nice set of built-in graphics functions and an inline assembler, amongst other things.
I can still remember that VDU 23 was the command to redefine a character, so much easier than doing the same sort of thing on the C64 (copy the character set from ROM to RAM, get the VIC to use the RAM copy with POKE statements, modify the desired character)
> It had a nice set of built-in graphics functions
IIRC those were actually in the “OS” ROM, with BASIC just having syntactic sugar to call them, rather than being part of the BASIC ROM itself, so you could call them from elsewhere (i.e. your own assembly code, even if you'd paged the BASIC ROM out to make some RAM available in that bit of the address space on the BBC Master).
> and an inline assembler, amongst other things.
That assembler was great when I was cutting my programming teeth and progressing a bit beyond BASIC to better understand the hardware.
BBC BASIC has some other crucial, more basic, features that were missing from other 8-bit micros. Actual named functions and procedures were key¹, and long variable names were useful² where some BASICs only allowed one or two characters³.
--------
[1] Other BASICs had no more than GOTO and GOSUB/RETURN, usually only allowing you to jump to line numbers, not names/labels. There was even some support for local variables making proper recursion possible up to a point (limited by the small stack).
[2] if limiting for long code due to memory constraints
[3] or allowed more but only respected the first couple, BBC BASIC syntax in theory allowed up to 248 characters⁴ but only respected the first 40 and practically you still limited yourself to a few (say, up to 10 for some for clarity, 1 for things like loop counters to save space in your code, CPU time in the interpreter, and space in the interpreter's variable dictionary).
[4] the absolute limit to what you could actually use in a line, itself having a length limit of 256-minus-a-few, and at that length all you could do was assign a single digit or print the value.
C64 Basic was V2 of a dialect of the Microsoft derived Basic for the PET. It was out of date already compared to the latest V4 because the older version fit into a smaller ROM to save costs.
AMOS was also another beloved alternative on the Amiga.
Just cross-checked my memories, Worms was written in Blitz BASIC, another example of good ideas matter more than programming languages, assuming that it is good enough for the implementation.
I owe having learnt Timex BASIC, Turbo BASIC, AMOS, Turbo Pascal, Z80, 68000, and 80x86 Assembly, before learning C, to understanding it not being that special.
Sword of Fargoal and Pirates! were both almost entirely written in uncompiled BASIC.
There's a lot that can be improved in the code, such as just using FOR...TO...STEP would be much faster.
In general, this is a routine that is super easy to write in 6502 assembly. Most magazine BASIC games had something like that, with a few such routines that were POKEd in memory at startup. Several were written in a relocatable fashion so that they could be copied easily from one game to the next.
Man does this bring back memories of my old Atari 800 and entering or writing games in BASIC for it. Something extremely nostalgic about that kind of development for some of us.