I’ve had a silly obsession for a long time, trying to make Sultan’s Maze go faster.
For the last several evenings, GPT and I have worked through the code, routine by routine.
Each piece was ported to cpctelera_next, one routine at a time.
Everything was tested carefully (though I can’t guarantee a 100% bug-free experience!), and my optimisation ideas were added as well.
Remember: for solid fill rectangles, it is best to do it with horizontal lines. Like this (sdcc assembler):
ld hl,#nbOctetToPrint ; Need to use 16 bit... Sorry.
call prepare_jump_line ; set the jump to a certain amount of octets to write
ld hl,#screenAddress ; First screen octet to set
ld a,#valueToUse ; the fill octet
call print_sub_line ; Let's do it
; Here hl = next adress of printed octets
; so just recompute hl for your next line and call print_sub_line to print
; same number of octets
ret
; print_sub_line
; hl = 0 .. 79
; hl,de modified
prepare_jump_line:
ld de,#fill_line_a_end ; points to end of jump table
add hl,hl ; 2 octet by ld (hl),a inc hl
sbc hl,de ; hl = jump address
ld (#print_sub_line + 1),hl ; [SMC] Set the jump address
ret
; need a jp because 80x2 > +127 (max for jr). if planning less than 63 octets
; or having a fixed amount of pixel set by default, jr can be enough
; add 8 bit arithmetic could be used in prepare_jump_line
print_sub_line:
jp #fill_line_a_end ; [SMC] Jump based on prepare_jump_line computation
.rpt 80
ld (hl),a ; set screen octet to value
inc hl ; next screen octet
.endm
fill_line_a_end:
ret