Hi,
I mostly write in BASIC with the odd spot of assembler here and there. Mostly not very speedy, simple games, like snake for example, which can be mostly text based using user defined characters for graphics.
I'm wondering if there would be a vast increase in speed if I were to write these in assembler. If I'm using OSWRCH calls to place the characters on screen would I get a significant speed increase? I guess it would remove the overhead of BASIC having to interpret the code before execution over and over again. But then I think BBC BASIC is pretty optimised so maybe not. I can't think of another way other than writing directly to screen memory which I think would be more complex than I want to attempt.
I guess I could write some simple code and compare execution times.
I know some of you write code that counts what scan line is being updated in order to avoid flicker from updating that part of the screen while it's being refreshed. Does the FX (or is it a VDU) instruction that waits for VSYNC (?) help with that without slowing down your code too much?
How does that work? Do you wait for VSYNC, which I think is the beam going back to the top left of the display, before you do any screen updates?
Sorry for all the random questions
Benefits of machine code in text based games?
Re: Benefits of machine code in text based games?
You can think of vsync as being two characters rows of the bottom of the screen and it taking 7 more to get back up to display the first, at least in a 32 character row mode.
Even updating the position of a sprite would take longer than moving it, clearing it and restarting it in assembler, at least for a two to four mode 1 character sprite. Drawing at the gfx pointer is very slow in the OS because it can do much more than you usually want.
For snake, I would expect mode 7 basic too hopefully hit 50fps, but mode 1 might struggle. I have written space invaders in mode 7, it was 25fps just.
For something like mode 7 pong, I would expect basic to be ok. You can always just convert the slowest bits until it is fast enough.
Somewhere I posted a spirited from basic thread with sprite code in ASM.
Even updating the position of a sprite would take longer than moving it, clearing it and restarting it in assembler, at least for a two to four mode 1 character sprite. Drawing at the gfx pointer is very slow in the OS because it can do much more than you usually want.
For snake, I would expect mode 7 basic too hopefully hit 50fps, but mode 1 might struggle. I have written space invaders in mode 7, it was 25fps just.
For something like mode 7 pong, I would expect basic to be ok. You can always just convert the slowest bits until it is fast enough.
Somewhere I posted a spirited from basic thread with sprite code in ASM.