Είχα μια ανόητη εμμονή εδώ και πολύ καιρό, προσπαθώντας να κάνω το Sultan’s Maze να τρέχει πιο γρήγορα.
Τα τελευταία βράδια, το GPT κι εγώ δουλέψαμε πάνω στον κώδικα, ρουτίνα προς ρουτίνα.
Κάθε κομμάτι μεταφέρθηκε στο cpctelera_next, μία ρουτίνα τη φορά.
Τα πάντα δοκιμάστηκαν προσεκτικά (αν και δεν μπορώ να εγγυηθώ μια εμπειρία 100% απαλλαγμένη από bugs!), ενώ προστέθηκαν και μερικές από τις δικές μου ιδέες βελτιστοποίησης.
Θυμηθείτε: για ορθογώνια με συμπαγές γέμισμα, είναι προτιμότερο να το κάνετε με οριζόντιες γραμμές. Όπως αυτό (sdcc assembler):
ld hl,#nbOctetToPrint ; Χρειάζεται να χρησιμοποιηθούν 16 bit... Συγγνώμη.
call prepare_jump_line ; ορισμός του jump για συγκεκριμένο αριθμό octets προς εγγραφή
ld hl,#screenAddress ; Πρώτο octet οθόνης προς ορισμό
ld a,#valueToUse ; το octet γεμίσματος
call print_sub_line ; Ας το κάνουμε
; Εδώ hl = επόμενη διεύθυνση των εκτυπωμένων octets
; οπότε απλά επανυπολογίστε το hl για την επόμενη γραμμή σας και καλέστε το print_sub_line για να εκτυπώσετε
; τον ίδιο αριθμό octets
ret
; print_sub_line
; hl = 0 .. 79
; hl,de τροποποιημένα
prepare_jump_line:
ld de,#fill_line_a_end ; δείχνει στο τέλος του πίνακα αλμάτων (jump table)
add hl,hl ; 2 octet ανά ld (hl),a inc hl
sbc hl,de ; hl = διεύθυνση άλματος
ld (#print_sub_line + 1),hl ; [SMC] Ορισμός της διεύθυνσης άλματος
ret
; απαιτείται jp επειδή 80x2 > +127 (μέγιστο για jr). Εάν σχεδιάζονται λιγότερα από 63 octets
; ή υπάρχει σταθερός αριθμός pixel ορισμένος από προεπιλογή, το jr μπορεί να είναι αρκετό
; θα μπορούσε να χρησιμοποιηθεί αριθμητική 8 bit στο prepare_jump_line
print_sub_line:
jp #fill_line_a_end ; [SMC] Άλμα με βάση τον υπολογισμό του prepare_jump_line
.rpt 80
ld (hl),a ; ορισμός octet οθόνης στην τιμή
inc hl ; επόμενο octet οθόνης
.endm
fill_line_a_end:
ret
Χρησιμοποιήθηκαν οι συναρτήσεις γραμμών του cpctelera_next.
Ωστόσο, για το γέμισμα των τοίχων, οι γραμμές χρησιμοποιούνται μόνο γύρω από τις άκρες, όπου δεν χωράνε τα πλακίδια (tiles). Το μεγαλύτερο μέρος της υφής ενός τοίχου γεμίζεται με πλακίδια.