Αξιολογότατο scrolling στον CPC
- Έναρξη μίζας Ace
- Ημερομηνία έναρξης
Εξαρταται για ποιο scrolling μιλας - γιαυτο με τα 2 "μπερδεμενα" χρωματα ή για τα αλλο με τα 16 σωστα ?
Κλασσικος Wally
...σε γειτονικο thread σχολιασε το αργο ...κασσετοφωνο του 800XL που ηταν το ιδιο αργο με του ORIC1 (!!) ...λες και οοολα τα υπολοιπα ηταν συγκρισιμα 
fgbrain
RetroActive
- Joined
- 27 Οκτ 2006
- Μηνύματα
- 324
- Αντιδράσεις
- 34
Οντως, στα video του YouTube χάνουν σε smoothness απο την πραγματικότητα, αλλά σου δίνουν μια ιδέα...
http://uk.youtube.com/watch?v=MavWmgzr2P8
(Στο απλό 6128, η μόνη διαφορά είναι η έλλειψη του parallax εφε με τα δέντρα & DMA sampled ήχος - αλλά έχει raster scroll στο background που δεν φαίνεται στο video!)
PS: Harris Kladis pics rule
http://uk.youtube.com/watch?v=MavWmgzr2P8
(Στο απλό 6128, η μόνη διαφορά είναι η έλλειψη του parallax εφε με τα δέντρα & DMA sampled ήχος - αλλά έχει raster scroll στο background που δεν φαίνεται στο video!)
PS: Harris Kladis pics rule
Optimus
RetroActive
- Joined
- 9 Δεκ 2006
- Μηνύματα
- 481
- Αντιδράσεις
- 181
1) videoram
Μου αρέσει αυτό το forum από άποψης τεχνικής ανάλυσης και ιστορίας του Amstrad. Το συγκεκριμένο ερώτημα είναι ένα που με βασάνιζε πάντα. Δυστυχώς είδα το forum αργά και ήδη διάβαζα για μισή ώρα όλα τα posts. Έχουν δωθεί κάποιες διευκρινίσεις ήδη αλλά δεν μπορώ να μην μπω στον πειρασμό να συζητήσω μερικά τεχνικά θέματα και άλλες προεκτάσεις.
Είχα διαβάσει πως ο Alan Sugar προτίμησε τον επεξεργαστή Z80 έτσι ώστε να υπάρχει και η πιθανότητα να βγουν γρήγορα πολλά παιχνίδια ports απο τον ήδη δημοφιλή Spectrum.
Όντως ο Spectrum έχει 256*192 ανάλυση με 1bit per pixel χρώμα. Δηλαδή σε ένα byte χωρούσαν 8 pixels. Αυτό μας κάνει (256 * 192) / 8 = 6144 = 6kb.
Και όμως, σε όλη την οθόνη μπορούσε να απεικονίσει 16 χρώματα. Αυτό γινόταν γιατί εκτός από τα 6kb υπήρχαν και άλλα 768bytes (αν θυμάμαι καλά) που ορίζανε για κάθε μικρή περιοχή 8*8 pixels τα δύο χρώματα της 1bit απεικόνησης. 32*24 tiles, 4bits για το πρώτο χρώμα και άλλα 4 για το δεύτερο.
Οπότε ενώ μέσα σε μια περιοχή 8*8 το χρώμα είναι 1bit, δηλαδή δεν μπορεί να χωρέσει 3ο χρώμα (πάρτε το art studio του spectrum και δοκιμάστε να ζωγραφίσετε τρία διαφορετικά χρώματα πολύ κοντά το ένα στο άλλο, αρκεί να βρίσκονται μέσα στο ίδιο tile). Αυτός ο συνδιασμός "λίγα χρώματα ανά περιοχή" και ένας μικρός πίνακας που ορίζει διαφορετική παλλέτα (ας το πούμε έτσι για να καταλάβετε) για κάθε διαφορετικό character tile μπορούσε μεν να διατηρήσει μικρή την videoram για γρήγορη μεταφορά (υπόψιν όμως, θα πρέπει και ο μικρός 768 byte πίνακας να μετακινηθεί στο scrolling εκτός και αν έχει κανείς ορίσει ίδια χρώματα για κάθε tile αν και είναι τόσο μικρός που ελάχιστα επηρρεάζει την ισχύ), αλλά να μην είναι φαινομενικά εντελώς ασπρόμαυρα τα games αλλά να φαίνται και καλά ότι έχουν 16 χρώματα.
Αυτή η τεχνική χρησιμοποιήθηκε και στον C64 αλλά και στις περισσότερες 8bit consoles και computers από όσο έχω παρατηρήσει, απλώς π.χ. στον C64 στην 160*200 ανάλυση επιτρέπονται 3 χρώματα per tile (4*8 pixels από τα χοντρά όμως στο Χ) συν το χρώμα του background που δεν επιτρέπεται να είναι διαφορετικό per tile. Αυτό μειώνει κάπως τα color clashes και αν βάλεις και τα hardware sprites του C64 αυτά μπορούν να έχουν τα δικά τους χρώματα ανεξάρτητα από το background.
Ο Amstrad ήταν η εξαίρεση με αποκορύφωση τα πολύ καλά χρώματα που μπορούσαν να mixarιστούν όλα μαζί χωρίς προβλήματα (τύχαινε βέβαια να έχει και πολύ καλή παλέττα με ζωηρά χρώματα, ακόμα αναρωτιέμαι γιατί ο C64 είχε τόσο μουντά χρώματα στην παλέτα του) αλλά ως αποτέλεσμα μεγάλη videoram. Π.χ. σε 160*200 με full 16 χρώματα, δηλαδή 4bit color άρα 2 pixels ανά byte, έχουμε (160*200)/2 = 16000 = περίπου 16kb. Και οι μεγαλύτερες αναλύσεις μειώνουν αντίστοιχα το βάθος χρώματος ώστε και πάλι να βγαίνουν 16000bytes. Είναι το ίδιο.
Όποτε στα conversions από τον Spectrum που δεν είχε hardware scrolling λογικό ήταν το soft scrolling που οριακά πήγαινε ομαλά με τα 6kb να πηγαίνει σχεδόν 3 φορές πιο αργά με τα 16kb αφού περνούσαν τον ίδιο κώδικα που μετακινούσε ένα ένα byte. O C64 αντίστοιχα είχε 8kb εκτός και αν χρησιμοποιούσε την character mode screen (ο Spectrum από όσο ξέρω δεν είχε κάτι αντίστοιχο στο hardware, άλλο tiles(περιοχές) και άλλα characters) με μήκος 1kb μην λαμβάνοντας υπόψιν βέβαια τους πίνακες που ορίζουν τα χρώματα των characters ή περιοχών (άλλο ένα kbyte για μονόχρωμα και άλλο ένα kbyte για multicolor mode με τα 3 χρώματα ανά χαρακτήρα).
Μου αρέσει αυτό το forum από άποψης τεχνικής ανάλυσης και ιστορίας του Amstrad. Το συγκεκριμένο ερώτημα είναι ένα που με βασάνιζε πάντα. Δυστυχώς είδα το forum αργά και ήδη διάβαζα για μισή ώρα όλα τα posts. Έχουν δωθεί κάποιες διευκρινίσεις ήδη αλλά δεν μπορώ να μην μπω στον πειρασμό να συζητήσω μερικά τεχνικά θέματα και άλλες προεκτάσεις.
Είχα διαβάσει πως ο Alan Sugar προτίμησε τον επεξεργαστή Z80 έτσι ώστε να υπάρχει και η πιθανότητα να βγουν γρήγορα πολλά παιχνίδια ports απο τον ήδη δημοφιλή Spectrum.
Όντως ο Spectrum έχει 256*192 ανάλυση με 1bit per pixel χρώμα. Δηλαδή σε ένα byte χωρούσαν 8 pixels. Αυτό μας κάνει (256 * 192) / 8 = 6144 = 6kb.
Και όμως, σε όλη την οθόνη μπορούσε να απεικονίσει 16 χρώματα. Αυτό γινόταν γιατί εκτός από τα 6kb υπήρχαν και άλλα 768bytes (αν θυμάμαι καλά) που ορίζανε για κάθε μικρή περιοχή 8*8 pixels τα δύο χρώματα της 1bit απεικόνησης. 32*24 tiles, 4bits για το πρώτο χρώμα και άλλα 4 για το δεύτερο.
Οπότε ενώ μέσα σε μια περιοχή 8*8 το χρώμα είναι 1bit, δηλαδή δεν μπορεί να χωρέσει 3ο χρώμα (πάρτε το art studio του spectrum και δοκιμάστε να ζωγραφίσετε τρία διαφορετικά χρώματα πολύ κοντά το ένα στο άλλο, αρκεί να βρίσκονται μέσα στο ίδιο tile). Αυτός ο συνδιασμός "λίγα χρώματα ανά περιοχή" και ένας μικρός πίνακας που ορίζει διαφορετική παλλέτα (ας το πούμε έτσι για να καταλάβετε) για κάθε διαφορετικό character tile μπορούσε μεν να διατηρήσει μικρή την videoram για γρήγορη μεταφορά (υπόψιν όμως, θα πρέπει και ο μικρός 768 byte πίνακας να μετακινηθεί στο scrolling εκτός και αν έχει κανείς ορίσει ίδια χρώματα για κάθε tile αν και είναι τόσο μικρός που ελάχιστα επηρρεάζει την ισχύ), αλλά να μην είναι φαινομενικά εντελώς ασπρόμαυρα τα games αλλά να φαίνται και καλά ότι έχουν 16 χρώματα.
Αυτή η τεχνική χρησιμοποιήθηκε και στον C64 αλλά και στις περισσότερες 8bit consoles και computers από όσο έχω παρατηρήσει, απλώς π.χ. στον C64 στην 160*200 ανάλυση επιτρέπονται 3 χρώματα per tile (4*8 pixels από τα χοντρά όμως στο Χ) συν το χρώμα του background που δεν επιτρέπεται να είναι διαφορετικό per tile. Αυτό μειώνει κάπως τα color clashes και αν βάλεις και τα hardware sprites του C64 αυτά μπορούν να έχουν τα δικά τους χρώματα ανεξάρτητα από το background.
Ο Amstrad ήταν η εξαίρεση με αποκορύφωση τα πολύ καλά χρώματα που μπορούσαν να mixarιστούν όλα μαζί χωρίς προβλήματα (τύχαινε βέβαια να έχει και πολύ καλή παλέττα με ζωηρά χρώματα, ακόμα αναρωτιέμαι γιατί ο C64 είχε τόσο μουντά χρώματα στην παλέτα του) αλλά ως αποτέλεσμα μεγάλη videoram. Π.χ. σε 160*200 με full 16 χρώματα, δηλαδή 4bit color άρα 2 pixels ανά byte, έχουμε (160*200)/2 = 16000 = περίπου 16kb. Και οι μεγαλύτερες αναλύσεις μειώνουν αντίστοιχα το βάθος χρώματος ώστε και πάλι να βγαίνουν 16000bytes. Είναι το ίδιο.
Όποτε στα conversions από τον Spectrum που δεν είχε hardware scrolling λογικό ήταν το soft scrolling που οριακά πήγαινε ομαλά με τα 6kb να πηγαίνει σχεδόν 3 φορές πιο αργά με τα 16kb αφού περνούσαν τον ίδιο κώδικα που μετακινούσε ένα ένα byte. O C64 αντίστοιχα είχε 8kb εκτός και αν χρησιμοποιούσε την character mode screen (ο Spectrum από όσο ξέρω δεν είχε κάτι αντίστοιχο στο hardware, άλλο tiles(περιοχές) και άλλα characters) με μήκος 1kb μην λαμβάνοντας υπόψιν βέβαια τους πίνακες που ορίζουν τα χρώματα των characters ή περιοχών (άλλο ένα kbyte για μονόχρωμα και άλλο ένα kbyte για multicolor mode με τα 3 χρώματα ανά χαρακτήρα).
Optimus
RetroActive
- Joined
- 9 Δεκ 2006
- Μηνύματα
- 481
- Αντιδράσεις
- 181
2) scrolling
Hardware scrolling είχε ο Amstrad, και όχι μόνο. Αλλά το πόσο εύκολο ήταν να το χειριστείς και τι δυνατότητες είχε ήταν σχετικό.
Δεν έχω παίξει και πολύ με τον CRTC του Amstrad αλλά θυμάμαι έναν register που αλλάζει την αρχική διεύθυνση όπου δείχνει η video ram του CPC. Οπότε αλλάζοντας αυτόν τον register μπορούσε φαινομενικά να μετακινηθεί μια ολόκληρη οθόνη ξοδεύοντας ούτε 1%% της ισχύς. Απλώς το hardware αποφάσιζε να ξεκινήσει τη σχεδίαση της οθόνης από γειτονική διεύθυνση σε σχέση με την αρχική, που την όριζες πια εσύ.
Έλα όμως που αυτή η διεύθυνση δεν ήταν γειτονική ανά ένα pixel. Ούτε ανά ένα byte αν θυμάμε καλά. Ήταν ανά 2 bytes δηλαδή ένα χαρακτήρα/8 pixels σε Mode 1 ανάλυση (320*200). 4 pixels σε Mode 0 (160*200) για τα records. Νομίζω πως τέτοιο είναι το scrolling στο ghost and goblins όταν περνάει στην επόμενη οθόνη.
Δηλαδή το hardware δεν σου επέτρεπε να ελέγχεις εύκολα το scrolling ανά pixel. Για να κάνεις pixel perfect scrolling υπήρχαν άλλες τεχνικές. Π.χ. η αποθήκευση ενός background 4 φορές, η κάθε μια να είναι μετακινημένη 1 pixel πιο μετά σαν στατικό γραφικό από την κάθε προηγούμενη. Εναλλάξ αυτές οι τέσσερις εικόνες σε κάθε video ram page και μετά hardware scrolling μια στις τέσσερις φορές, κάπως έτσι το πετύχενες. Αλλά αν η videoram του amstrad είναι 16kb τότε καταλαβαίνεις πως ήδη χαραμίζεις 64kb ram μόνο για αυτό. Νομίζω δεν έχω δει κανέναν να σκρολάρει μια fullscreen εικόνα per pixel σε κάποιο demo ή παιχνίδι αλλά ανά δύο pixels (μόνο δύο εναλασσόμενα background με διαφορά δύο pixels μεταξύ τους) πρέπει να έχω δει. Βέβαια με την χρησιμοποίηση επαναλμβανόμενων κομματιών γραφικών και μικρότερων περιοχών στην οθόνη σκρολλαρίσματος ίσως να είναι πιο εύκολο. Έχω δεν per pixel text scrollers σε demos.
Στον C64 που είχα ασχοληθεί λίγο με coding, στο character mode screen είναι πολύ πιο εύκολο αυτό. Ο C64 δεν έχει video ram address scrolling. Μπορείς μόνο να ορίσεις την video ram στη $2000, στην $4000, στην $6000 διεύθυνση κλπ. Αλλά απαγορεύεται π.χ. να την ορίσεις στο $2001, $2002, $2004 ή κάπου ενδιάμεσα. Αντιθέτως έχει απευθείας per pixel hardware scrolling είτε στο Χ, είτε στο Υ, αλλά από 0 έως 7 pixels. Βάλε όμως το background να είναι φτιαγμένο από character tiles στο συγκεκριμένο mode (ώρες ώρες έχω δει backgrounds που δεν καταλαβαίνεις ότι είναι φτιαγμένο από characters, νομίζεις ότι είναι στο multicolor bitmap mode τους που είναι κανονικά graphics), και σκρολάρεις από 0 έως 7 και όταν δεν έχεις το 8 απλώς μετακινείς το 1kb των characters (και ίσως βέβαια και τα άλλα 1 ή 2kb των πινάκων που ορίζουν τα χρώματα για αυτές τις περιοχές, αναλόγως) ένα χαρακτήρα αριστερά (ή δεξία, δεν θυμάμαι τη φορά του hardware scrolling τώρα) και θέτεις ξανά το scroll register από το 7 στο 0 και ξανά. Είναι πραγματικά πολύ εύκολο!!! Το δυσκολότερο θα είναι στα bitmap modes όπου η videoram είναι 8kb χωρίς να λαμβάνουμε υπόψη τους πίνακες χρωμάτων των tiles. Έχω δει demos να το καταφέρνουν. Πως άραγε δεν ξέρω.. επίσης το καταπληκτικό Turrican από ότι καταλαβαίνω χρησιμοποιεί μια char screen από πίσω (με κάποια επαναλαμβανόμενα patterns στα γραφικά) και hardware sprites από μπροστά. Καμιά φορά βλέπεις πολλά graphics σε parallax forground scrolling και λες πως στο καλό αλλά παίζει sprite multiplexing για παραπάνω sprites από το θεωρητικό και πολλές άλλες τεχνικές που είναι δύσκολό να περιγράψω εδώ..
Για vertical scroll στον Amstrad είναι λίγο πιο εύκολα τα πράγματα. Με το CRTC register που αλλάζεις την video ram address από 0 έως 2048 bytes, ανά 80 bytes αφού έχει φτάσει τέρμα δεξιά στο Χ πηγαίνει στον επόμενο χαρακτήρα (+8 pixels στο Y), έτσι είναι η videoram του amstrad, αντί να πάει στη δεύτερη γραμμή όπως θα περίμενε κανείς. Αλλά υπάρχει register που θυμίζει το 0-7 pixels στο Y hardware scroll του C64 που σε συνδιασμό με το πρώτο έχουμε σχετικά εύκολα per pixel Y scrolling χωρίς πολαπλά versions του background και αηδίες. (Σας παραπέμπω στον text scroller των Focus diskmags #1 και #2 του FG Brain)
Φυσικά υπάρχουν και άλλες κουράσεις όπως, όταν αλλάζεις την videoram φτάνεις σε ένα τέρμα στη μνήμη όπου θα πρέπει να την ξαναβάλεις πίσω, θα πρέπει όμως εκεί να σχεδιάζεις σιγά σιγά όσο σκρόλαρης δύο σελίδες την μεθεπόμενη σελίδα για να μην χρειαστεί να κάνεις μετακίνηση 16kb πάλι. Δύσκολο να το εξηγήσω, αλλά κούραση. Βάλε και τη μνήμη, αλήθεια δεν έχω δοκιμάσω να κάνω έναν έστω vertical scroller στον Amstrad μέχρι στιγμής ενώ στον C64 έτυχε λόγο demoproject να ασχοληθώ κυρίως με hardware coding. Θα θελήσω μια μέρα να το δοκιμάσω έτσι για να έχω μια καλύτερη εικόνα..
Hardware scrolling είχε ο Amstrad, και όχι μόνο. Αλλά το πόσο εύκολο ήταν να το χειριστείς και τι δυνατότητες είχε ήταν σχετικό.
Δεν έχω παίξει και πολύ με τον CRTC του Amstrad αλλά θυμάμαι έναν register που αλλάζει την αρχική διεύθυνση όπου δείχνει η video ram του CPC. Οπότε αλλάζοντας αυτόν τον register μπορούσε φαινομενικά να μετακινηθεί μια ολόκληρη οθόνη ξοδεύοντας ούτε 1%% της ισχύς. Απλώς το hardware αποφάσιζε να ξεκινήσει τη σχεδίαση της οθόνης από γειτονική διεύθυνση σε σχέση με την αρχική, που την όριζες πια εσύ.
Έλα όμως που αυτή η διεύθυνση δεν ήταν γειτονική ανά ένα pixel. Ούτε ανά ένα byte αν θυμάμε καλά. Ήταν ανά 2 bytes δηλαδή ένα χαρακτήρα/8 pixels σε Mode 1 ανάλυση (320*200). 4 pixels σε Mode 0 (160*200) για τα records. Νομίζω πως τέτοιο είναι το scrolling στο ghost and goblins όταν περνάει στην επόμενη οθόνη.
Δηλαδή το hardware δεν σου επέτρεπε να ελέγχεις εύκολα το scrolling ανά pixel. Για να κάνεις pixel perfect scrolling υπήρχαν άλλες τεχνικές. Π.χ. η αποθήκευση ενός background 4 φορές, η κάθε μια να είναι μετακινημένη 1 pixel πιο μετά σαν στατικό γραφικό από την κάθε προηγούμενη. Εναλλάξ αυτές οι τέσσερις εικόνες σε κάθε video ram page και μετά hardware scrolling μια στις τέσσερις φορές, κάπως έτσι το πετύχενες. Αλλά αν η videoram του amstrad είναι 16kb τότε καταλαβαίνεις πως ήδη χαραμίζεις 64kb ram μόνο για αυτό. Νομίζω δεν έχω δει κανέναν να σκρολάρει μια fullscreen εικόνα per pixel σε κάποιο demo ή παιχνίδι αλλά ανά δύο pixels (μόνο δύο εναλασσόμενα background με διαφορά δύο pixels μεταξύ τους) πρέπει να έχω δει. Βέβαια με την χρησιμοποίηση επαναλμβανόμενων κομματιών γραφικών και μικρότερων περιοχών στην οθόνη σκρολλαρίσματος ίσως να είναι πιο εύκολο. Έχω δεν per pixel text scrollers σε demos.
Στον C64 που είχα ασχοληθεί λίγο με coding, στο character mode screen είναι πολύ πιο εύκολο αυτό. Ο C64 δεν έχει video ram address scrolling. Μπορείς μόνο να ορίσεις την video ram στη $2000, στην $4000, στην $6000 διεύθυνση κλπ. Αλλά απαγορεύεται π.χ. να την ορίσεις στο $2001, $2002, $2004 ή κάπου ενδιάμεσα. Αντιθέτως έχει απευθείας per pixel hardware scrolling είτε στο Χ, είτε στο Υ, αλλά από 0 έως 7 pixels. Βάλε όμως το background να είναι φτιαγμένο από character tiles στο συγκεκριμένο mode (ώρες ώρες έχω δει backgrounds που δεν καταλαβαίνεις ότι είναι φτιαγμένο από characters, νομίζεις ότι είναι στο multicolor bitmap mode τους που είναι κανονικά graphics), και σκρολάρεις από 0 έως 7 και όταν δεν έχεις το 8 απλώς μετακινείς το 1kb των characters (και ίσως βέβαια και τα άλλα 1 ή 2kb των πινάκων που ορίζουν τα χρώματα για αυτές τις περιοχές, αναλόγως) ένα χαρακτήρα αριστερά (ή δεξία, δεν θυμάμαι τη φορά του hardware scrolling τώρα) και θέτεις ξανά το scroll register από το 7 στο 0 και ξανά. Είναι πραγματικά πολύ εύκολο!!! Το δυσκολότερο θα είναι στα bitmap modes όπου η videoram είναι 8kb χωρίς να λαμβάνουμε υπόψη τους πίνακες χρωμάτων των tiles. Έχω δει demos να το καταφέρνουν. Πως άραγε δεν ξέρω.. επίσης το καταπληκτικό Turrican από ότι καταλαβαίνω χρησιμοποιεί μια char screen από πίσω (με κάποια επαναλαμβανόμενα patterns στα γραφικά) και hardware sprites από μπροστά. Καμιά φορά βλέπεις πολλά graphics σε parallax forground scrolling και λες πως στο καλό αλλά παίζει sprite multiplexing για παραπάνω sprites από το θεωρητικό και πολλές άλλες τεχνικές που είναι δύσκολό να περιγράψω εδώ..
Για vertical scroll στον Amstrad είναι λίγο πιο εύκολα τα πράγματα. Με το CRTC register που αλλάζεις την video ram address από 0 έως 2048 bytes, ανά 80 bytes αφού έχει φτάσει τέρμα δεξιά στο Χ πηγαίνει στον επόμενο χαρακτήρα (+8 pixels στο Y), έτσι είναι η videoram του amstrad, αντί να πάει στη δεύτερη γραμμή όπως θα περίμενε κανείς. Αλλά υπάρχει register που θυμίζει το 0-7 pixels στο Y hardware scroll του C64 που σε συνδιασμό με το πρώτο έχουμε σχετικά εύκολα per pixel Y scrolling χωρίς πολαπλά versions του background και αηδίες. (Σας παραπέμπω στον text scroller των Focus diskmags #1 και #2 του FG Brain)
Φυσικά υπάρχουν και άλλες κουράσεις όπως, όταν αλλάζεις την videoram φτάνεις σε ένα τέρμα στη μνήμη όπου θα πρέπει να την ξαναβάλεις πίσω, θα πρέπει όμως εκεί να σχεδιάζεις σιγά σιγά όσο σκρόλαρης δύο σελίδες την μεθεπόμενη σελίδα για να μην χρειαστεί να κάνεις μετακίνηση 16kb πάλι. Δύσκολο να το εξηγήσω, αλλά κούραση. Βάλε και τη μνήμη, αλήθεια δεν έχω δοκιμάσω να κάνω έναν έστω vertical scroller στον Amstrad μέχρι στιγμής ενώ στον C64 έτυχε λόγο demoproject να ασχοληθώ κυρίως με hardware coding. Θα θελήσω μια μέρα να το δοκιμάσω έτσι για να έχω μια καλύτερη εικόνα..
fgbrain
RetroActive
- Joined
- 27 Οκτ 2006
- Μηνύματα
- 324
- Αντιδράσεις
- 34
Optimus
υπάρχουν και άλλα κολπάκια στο h/w scroll..!!
για byte-perfect mode 0 (2 pixels) μπορείς να χρησιμοποιήσεις και τον register 3 του crtc και στο επόμενο frame τους registers 12 & 13 (video ram address)
επίσης, αντί να γεμίσεις όλη την οθόνη (16kb), την κόβεις σε δυο - τρεις "ζώνες", οπότε γλυτώνεις μνήμη!!
για vertical pixel (byte) perfect, με κάλυψες, γίνεται με τον register 5 (τιμές 0 έως 7) και σε κάθε 8 pixels αλλάζεις το offset ανάλογα...
βέβαια, υπάρχει και το demo Shadow of the Beast με 14 επίπεδα parallax scrolling σε overscan, αλλά είναι το μόνο που χρησιμοποιεί 64kb video ram (απόσο ξέρω) - και ακόμα δεν έχω καταλάβει τι κάνει (ο Θεός...)
υπάρχουν και άλλα κολπάκια στο h/w scroll..!!
για byte-perfect mode 0 (2 pixels) μπορείς να χρησιμοποιήσεις και τον register 3 του crtc και στο επόμενο frame τους registers 12 & 13 (video ram address)
επίσης, αντί να γεμίσεις όλη την οθόνη (16kb), την κόβεις σε δυο - τρεις "ζώνες", οπότε γλυτώνεις μνήμη!!
για vertical pixel (byte) perfect, με κάλυψες, γίνεται με τον register 5 (τιμές 0 έως 7) και σε κάθε 8 pixels αλλάζεις το offset ανάλογα...
ευχαριστώ που μου θύμισες τα νιάτα μου
βέβαια, υπάρχει και το demo Shadow of the Beast με 14 επίπεδα parallax scrolling σε overscan, αλλά είναι το μόνο που χρησιμοποιεί 64kb video ram (απόσο ξέρω) - και ακόμα δεν έχω καταλάβει τι κάνει (ο Θεός...)
Optimus
RetroActive
- Joined
- 9 Δεκ 2006
- Μηνύματα
- 481
- Αντιδράσεις
- 181
3) Sprites
Μου την έδινε που και τα sprites στον Amstrad είχαν σπαστή κίνηση. Φυσικά υπήρχε και εδώ το per pixel πρόβλημα, αλλά εντάξει μπορούσε κανείς να έχει τέσσερα versions τών sprites (ή δύο σε 160*200) ένα pixel μετακινημένο το κάθε ένα από το άλλο και να εναλλάσει. Μόνο που θα έτρωγε μνήμη αυτό. Αλλά δεν ήταν μόνο αυτό, ήταν και η ταχύτητα. Θυμάμαι παιχνίδι που αρκεί να μπει ένα τρίτο ή τέταρτο sprite στο παιχνίδι για να πέσει η ταχύτητα στο μισό.
Ενώ αν έχεις hardware sprites που σου επιτρέπουν και να τα τοποθετήσεις σε όποια pixel position θέλεις, klein. Βλέπε C64. Εκεί πολύ ομαλή per pixel κίνηση sprite συνδυασμένα με το hardware scrolling, ήταν όλα τζετ.
Είναι και το άλλο. Συνδιασμός στον Amstrad hardware scrolling και software sprites; Χμμ,. δεν το έχω δοκιμάσει βέβαια, αλλά στις περιπτώσεις των demos που θέλανε τρελό συγχρονισμό για κάποια hardware scrolling κόλπα, ήταν κάπως δύσκολο να συνδιαστούν και sprites και ειδικά όταν έχεις συγχρονήσει τον κώδικα που ζωγραφίζει τα sprites με τα raster lines και τα split screens, μάλλον το τυχαία να βγει και ένας τρίτος εχθρός θα χαλάσει το timing.
Τουλάχιστον αυτό μου είχε πει ο Overflow που είχε βγάλει το Shadow of the Beast CPC preview με τα 9 parallax scrollings και το τερατάκι που κινάς με τα κουμπιά. Ο κώδικας του drawing ήταν συγχρονισμένος σε κομμάτια με τον κώδικα των hardware splittings και του timing που χρειαζόταν. Δεν είναι εύκολο να βάλει κανείς τυχαία κάποιους καινούριους εχθρούς που εμφανίζονται λέει. Το timing είναι ακριβώς. Είναι δύσκολο να το εξηγήσω (περίπου καταλαβαίνω αν και δεν έχω κάτσει να γράψω αντίστοιχο κώδικα), αλλά λέει ότι π.χ. στον Amstrad CPC+ με τα hardware sprites αλλά και hardware line interrupts (ή δεν ξέρω πως λέγονται, από τον C64 λέω τόν όρο) που δεν σε αναγκάζει σε cycle timing πια, λέει πως θα ήταν εφικτό να κάνει κανείς ένα game με αυτήν την engine.
Αλλά υπάρχουν και demos και games που επιδυκνύουν το πόσα πολλά sprite μπορεί ο Amstrad να βγάλει. Τουλάχιστον σε static backgrounds και όχι τόσο σε hardware scrolling ones. Βλέπε CPC sprite records ή το Zapt Ball's (θα ανεβάσω video)
Θα ανεβάσω και για το SOTB preview. Δεν φαίνεται να υπάρχει..
Μου την έδινε που και τα sprites στον Amstrad είχαν σπαστή κίνηση. Φυσικά υπήρχε και εδώ το per pixel πρόβλημα, αλλά εντάξει μπορούσε κανείς να έχει τέσσερα versions τών sprites (ή δύο σε 160*200) ένα pixel μετακινημένο το κάθε ένα από το άλλο και να εναλλάσει. Μόνο που θα έτρωγε μνήμη αυτό. Αλλά δεν ήταν μόνο αυτό, ήταν και η ταχύτητα. Θυμάμαι παιχνίδι που αρκεί να μπει ένα τρίτο ή τέταρτο sprite στο παιχνίδι για να πέσει η ταχύτητα στο μισό.
Ενώ αν έχεις hardware sprites που σου επιτρέπουν και να τα τοποθετήσεις σε όποια pixel position θέλεις, klein. Βλέπε C64. Εκεί πολύ ομαλή per pixel κίνηση sprite συνδυασμένα με το hardware scrolling, ήταν όλα τζετ.
Είναι και το άλλο. Συνδιασμός στον Amstrad hardware scrolling και software sprites; Χμμ,. δεν το έχω δοκιμάσει βέβαια, αλλά στις περιπτώσεις των demos που θέλανε τρελό συγχρονισμό για κάποια hardware scrolling κόλπα, ήταν κάπως δύσκολο να συνδιαστούν και sprites και ειδικά όταν έχεις συγχρονήσει τον κώδικα που ζωγραφίζει τα sprites με τα raster lines και τα split screens, μάλλον το τυχαία να βγει και ένας τρίτος εχθρός θα χαλάσει το timing.
Τουλάχιστον αυτό μου είχε πει ο Overflow που είχε βγάλει το Shadow of the Beast CPC preview με τα 9 parallax scrollings και το τερατάκι που κινάς με τα κουμπιά. Ο κώδικας του drawing ήταν συγχρονισμένος σε κομμάτια με τον κώδικα των hardware splittings και του timing που χρειαζόταν. Δεν είναι εύκολο να βάλει κανείς τυχαία κάποιους καινούριους εχθρούς που εμφανίζονται λέει. Το timing είναι ακριβώς. Είναι δύσκολο να το εξηγήσω (περίπου καταλαβαίνω αν και δεν έχω κάτσει να γράψω αντίστοιχο κώδικα), αλλά λέει ότι π.χ. στον Amstrad CPC+ με τα hardware sprites αλλά και hardware line interrupts (ή δεν ξέρω πως λέγονται, από τον C64 λέω τόν όρο) που δεν σε αναγκάζει σε cycle timing πια, λέει πως θα ήταν εφικτό να κάνει κανείς ένα game με αυτήν την engine.
Αλλά υπάρχουν και demos και games που επιδυκνύουν το πόσα πολλά sprite μπορεί ο Amstrad να βγάλει. Τουλάχιστον σε static backgrounds και όχι τόσο σε hardware scrolling ones. Βλέπε CPC sprite records ή το Zapt Ball's (θα ανεβάσω video)
Θα ανεβάσω και για το SOTB preview. Δεν φαίνεται να υπάρχει..
fgbrain
RetroActive
- Joined
- 27 Οκτ 2006
- Μηνύματα
- 324
- Αντιδράσεις
- 34
μάλλον το δεύτερο...
γιατί στην ουσία αλλάζεις το offset (byte προς byte) απο όπου ξεκινά η video ram!
αλλά το οπτικό αποτέλεσμα είναι το ίδιο..
πρέπει κατόπιν βέβαιως να ξαναυπολογίσεις τα sprites σου αναλόγως... καθώς η video ram μπερδεύεται αρκετά!!!
έτσι ακριβώς δουλεύει και η basic όταν πατήσεις το κάτω βελάκι στο κάτω μέρος της οθόνης, για να scroll-αρει επάνω (ή κάτω)
γιατί στην ουσία αλλάζεις το offset (byte προς byte) απο όπου ξεκινά η video ram!
αλλά το οπτικό αποτέλεσμα είναι το ίδιο..
πρέπει κατόπιν βέβαιως να ξαναυπολογίσεις τα sprites σου αναλόγως... καθώς η video ram μπερδεύεται αρκετά!!!
έτσι ακριβώς δουλεύει και η basic όταν πατήσεις το κάτω βελάκι στο κάτω μέρος της οθόνης, για να scroll-αρει επάνω (ή κάτω)
Optimus
RetroActive
- Joined
- 9 Δεκ 2006
- Μηνύματα
- 481
- Αντιδράσεις
- 181
4) Vector graphics
@FG Brain: Καταρχήν με πρόλαβες με το SOTB (ανεβάζω το video), ναι πρέπει να ήταν 14 και όχι 9 όπως γράφω. Ενδιαφέρον και το κολπάκι για mode0 byte scrolling, θα ξαναδώ το CRTC sheet για να δω τι παίζει με αυτούς τους registers.
Η όλη συζήτηση που κάνω δεν είναι φυσικά για να μελετήσω ποιός είναι ο καλύτερος υπολογιστής αλλά επειδή με ενδιαφέρει τεχνικά αλλά και για να διδαχθούν και οι υπόλοιποι (αν και τα μεγάλα μου κείμενα μάλλον θα κουράζουν).
C64 και vector graphics.
Είναι ενδιαφέρον ότι η σύγκρηση με τα MHz είναι άκυρη αλλά και για διαφορετικούς αλγορίθμους παίζουν άλλα πράγματα.
Καταρχήν ο Z80 στα 4Mhz δεν είναι τέσσερις φορές πιο γρήγορος από τον 6502/6510 στο 1Mhz. Αυτό εξαρτάται και από τους κύκλους μηχανής που πιάνουν αντίστοιχες εντολές στους δύο επεξεργαστές και από τις διαφορές και δυνατότητες των εντολών και καταχωρητών κάθε επεξεργαστή.
Ας πούμε η πιο συνηθισμένη εντολή για να γράφεις ένα byte στη μνήμη μπορεί να είναι η LD (HL),A στον Amstrad(Z80) που πιάνει 2 nop cycles δηλαδή 8 κύκλους μηχανής. Στον C64(6502) όλα γίνονται με direct memory addressing π.χ. STA $D020 και πιάνει 4 κύκλους μηχανής.
Αυτό στον Amstrad θα ήταν:
LD HL,&hD020
LD (HL),A
αλλά ας υποθέσουμε ότι το HL είναι φορτωμένο από πριν με τη διεύθυνση και ας συγκρίνουμε μόνο το γράψιμο στη μνήμη. Τότε ο C64 θα έτρωγε και πάλι τους μισούς κύκλους μηχανής. Twice fast at the same Mhz!
Η αντίστοιχη direct memory addresing εντολή του Amstrad είναι:
LD (&hD020),A
και τρώει 4 nop cycles (θα εξηγήσω αυτό το nop cycles μετά) δηλαδή 16 machine cycles. 4 φορές περισσότερο από την αντίστοιχη.
Ο C64 έχει και το
STA $address, X ή STA $address, Y
όπου X και Y δύο 8bit registers
δηλαδή κάτι σαν pointers, π.χ. to STA $4000, X θα γράψει στην διεύθυνση ($4000 + Χ)
και μπορείς στη συνέχεια να κάνεις INX για να αυξήσεις το X οπότε να πας στην επόμενη διεύθυνση.
Μόνο έναν κύκλο παραπάνω (5)
Του Amstrad το αντίστοιχο είναι
LD (IX+dd),Α
πολύ διαφορετικό βέβαια, γιατί τώρα ο IX είναι ο 16bit register και το νούμερο dd είναι 8bit τιμή, ανάποδο από την C64 version και πιάνει και 5 NOP cycles (20 machine cycles, 4 φορές πιο αργό και πάλι)
Αλλά θα μου πεις, για αυτό στα optimized software demo effects θα προτιμήσω να χωρέσω τις βασικές διευθύνσεις στους HL, DE, BC και να χρησιμοποιώ μόνο την πρώτη μορφή για να γράφω ή να διαβάζω από/στη μνήμη. Και όταν θέλω να πάω γειτονικά στα επόμενα values/pixels/whatever θα κάνώ ένα INC L ας πούμε ή INC H για vertical αν έχω θέσει έτσι αντίστοιχα τα data μου.
Πολλά όμως effects βολεύουν να βλέπεις σε μακριές αποστάσεις στη μνήμη. Και με τα γρήγορα opcodes για direct memory addresing του C64 και 1 κύκλο παραπάνω για τον X,Y pointer μόνο πραγματικά πολλά effects στον C64 είναι μεγάλα unrolled codes (ξετιλυγμένοι κώδικες όπου έχουν αφερεθεί τα loops και βρίσκεται μόνο η ουσία μέσα ), από ακολουθίες LDA, STA, LDA, STA, LDA , STA, STA, STA, κλπ. όπου στον Amstrad τα αντίστοιχα εφέ ή θα τα έκανες με τους αργούς, ή θα προτιμούταν για ταχύτητα να έχεις τις διευθύνσεις στου 16βιτ registers και απλά θα χανόταν αυτό το απευθείεας.
Έχω και πρακτικά και θεωρητικά (σε χαρτί) σκεφτεί διάφορα software effects πως θα μπορούσα να τα κάνω γρήγορα σε Amstrad και σε C64 και βάλε και την μισή videoram (8kb έναντι 16kb) και πραγματικά σε πολλά εφέ το 1Mhz του C64 φτάνει τα 4Mhz του Amstrad, και σε πολλά μου βγαίνουν ελαφρώς πιο αργά ή πιο γρήγορα, δηλαδή κοντράρονται!
Απίστευτο.
Και όσο αφορά τα vector graphics, για να δείτε την diversity, το πόσο δεν μετράνε τα MHz και πόσο κερδίζει εδώ ο Amstrad,.
..δυστυχώς τα demos του C64 δείχνουν πιο γρήγορα 3d vectors από τον Amstrad αλλά αυτό γιατί δεν έχει ασχοληθεί ο κόσμος στον Amstrad. Το μόνο realtime vector demo με flat polygons ας πούμε ήταν του Face Hugger του 1992 και από εκεί και πέρα ο κόσμος έκανε hardware scrollers. Και στον C64 έχω δει ακόμα και gouraud shading 3d objects με καλύτερη ταχύτητα και ποιότητα από τα flat polygons του Face Hugger Ultimate megademo.
Αλλά πιστεύω ότι μπορεί να βγάλει πιο γρήγορα (και πιο όμορφα λόγο χρωμάτων) 3d ο Amstrad λόγο opcodes και registers και πάλι.
Πολύ απλά, βασικά στοιχεία στα 3d είναι fixed point arithmetic (για μηχανήματα που δεν έχουν FPU) και interpolation, πολύ interpolation.
Καθόμουν και σκεφτόμουν μερικά πράγματα και πως θα γίνουν στον Amstrad. Οι 16bit registers είναι σωτηρία. 8-8 fixed point. Έχεις τον 16bit register HL ας πούμε που χωρίζεται στον H και τον L τους 8bitους registers. Μπορείς να παραστήσεις με τον H το ακέραιο μέρος και με τον L τον δεκαδικό χωρίς αυτό να φαίνεται. Με το ADD HL,DE που πιάνει 2 nop cycles μόνο, αν έχεις στο DE έναν άλλον αριθμό σε 8-8 fixed point μορφή (που μπορούν να προυπολογιστούν πριν το actual effect ή μόνο μια φορά per frame) μπορείς να κάνεις βήμα προς βήμα interpolation και μετά έχεις απευθείεας τον H το ακέραιο κομμάτι (δεν σε ενδιαφέρει στο τέλος το δεκαδικό) για γράψιμο του pixel color ή οτιδήποτε γίνεται κάνεις interpolate στην πορεία.
Δεν έχω κάτσει να το κάνω στην πράξη. Αλλά είναι πολύ straight forward. Σε ένα Spectrum demo, στο τελικό scroller κοτσάρανε οι coders το inner loop της texture mapping routine και χρησιμοποιούσε ακριβώς αυτά σαν θεωρία στην προηγούμενη παράγραφο.
Είναι straightforward. Στον 6502 του C64 αυτό θα έπρεπε να το κάνεις simulation με 2 8bit τιμές στη μνήμη που θα κάναν το 16bit register, additions, carry checks, πολύ παραπάνω δουλειά. Από περιέργια και θεωρητικά κάθησα και σκέφτικα αντίστοιχα γρήγορες ρουτίνες interpolation optimized για 6502 και πάλι σε αυτό ο Z80 των 4Mhz είναι 3 φορές πιο γρήγορος από τον 6502 των 1Mhz.
Και από τη στιγμή που τα 3d είναι τίγκα στα fixed point και interpolations, φαντάζεσεστε πόσο εποφελείται σε αυτά τα εφφέ με τους αντίστοιχους optimized κώδικες όμως ο CPC και ο Spectrum. Αλλά όχι λόγο Mhz!!!
Και δείτε πόσο diversity υπάρχει, πόσο δεν μετράνε τα mHz αλλά πόσο κάποιοι registers, addressing modes, διαφορετικά opcodes και αρχιτεκτονικές θα ευνοήσουν άλλους αλγορίθμους. Βάλε και τα video modes και hardware tricks. (Π.χ. στην Amiga είναι άβολα τα per pixel bitmap effects και πολύ γρήγορα τα flat polygons λόγο bitplanes). Το ενδιαφέρον για μένα αυτό είναι, πόσο μπορεί κανείς να τα μελετήσει, να γράψει κώδικα για τα δύο αντίστοιχα μηχανήματα και να δει τι είναι αυτό που κάνει τη διαφορά και όχι πάντα στους ίδιους αλγορίθμους..
..ίσως είναι incomprehensible αλλά με έπιασε και πάλι.
In a nutsheel. O C64 γ***ει σε πολλά effects (ακόμα και per pixel bitmap effects), στο 1/4 των Mhz λόγο 6510, αλλά ο CPC και ο Spectrum μπορούν να είναι καλύτεροι σε 3D λόγω Z80 και 16bit registers και σχετικά γρήγορο 16bit addition.
------------------
Btw,. περί nop timing.
1 NOP (no operation, δεν κάνει τίποτα, η εντολή που πιάνει συνήθως τα λιγότερα machine cycles) πιάνει 4 machine cycles στον Amstrad.
Γιατί στον Amstrad μετράμε και τις άλλες εντολές σαν πολλαπλάσια των κύκλων μηχανής της NOP εντολής;
Καταρχήν π.χ. η LD (HL),A πιάνει 2 NOP cycles δηλαδή 8 machince cycles στον Amstrad. Αλλά στον Spectrum πιάνει λιγότερο παρόλο που έχει τον ίδιο Z80. Νομίζω 7 ή 6.
Για κάποιο λόγο το hardware στον Amstrad στρογγυλοποιεί τους κύκλους μηχανής στα 4 cycles, δηλαδή 4,8,12,16, κλπ.. πετιούνται τζάμπα δηλαδή κανά δύο cycles. Έχει να κάνει σχέση με το συγχρονισμό του επεξεργαστή με το hardware.
From wiki:
(All CPC models were based on a Zilog Z80 processor clocked at 4MHz. Because a common pool of RAM is shared with the video circuits, the Z80 may only make a memory accesses every four cycles - which has the effect of rounding all instruction cycle lengths up to the next multiple of four. The speed is therefore roughly equivalent to a 3.3MHz machine.)
Έτσι γιατί να λέμε 4,8,12,16 cycles και αφού όλα είναι πολλαπλάσια του 4 να μην λέμε 1,2,3,4 NOP cycles (που πιάνει 4 machine cycles)
Καταλαβαίνετε και το impact. O CPC με τον Z80 στα 4Mhz δεν είναι λίγο πιο γρήγορος από τον Spectrum με τον Z80 στα 3.5Mhz, ίσα ίσα πάνω κάτω το ίδιο (το 3.3Mhz που λέει το wiki είναι estimation. Μπορεί ένας κώδικας να χρησιμοποιεί opcodes που τυχαίνει ο πραγματικός αριθμός cycles να είναι και αντίστοιχο πολλαπλάσιο του 4 οπότε ουσιαστικά να μην πετιέται τίποτα)
Πολύ ανάλυση. Θα σταματήσω εδώ..
Πάρτε και το video του
@FG Brain: Καταρχήν με πρόλαβες με το SOTB (ανεβάζω το video), ναι πρέπει να ήταν 14 και όχι 9 όπως γράφω. Ενδιαφέρον και το κολπάκι για mode0 byte scrolling, θα ξαναδώ το CRTC sheet για να δω τι παίζει με αυτούς τους registers.
Η όλη συζήτηση που κάνω δεν είναι φυσικά για να μελετήσω ποιός είναι ο καλύτερος υπολογιστής αλλά επειδή με ενδιαφέρει τεχνικά αλλά και για να διδαχθούν και οι υπόλοιποι (αν και τα μεγάλα μου κείμενα μάλλον θα κουράζουν).
C64 και vector graphics.
Είναι ενδιαφέρον ότι η σύγκρηση με τα MHz είναι άκυρη αλλά και για διαφορετικούς αλγορίθμους παίζουν άλλα πράγματα.
Καταρχήν ο Z80 στα 4Mhz δεν είναι τέσσερις φορές πιο γρήγορος από τον 6502/6510 στο 1Mhz. Αυτό εξαρτάται και από τους κύκλους μηχανής που πιάνουν αντίστοιχες εντολές στους δύο επεξεργαστές και από τις διαφορές και δυνατότητες των εντολών και καταχωρητών κάθε επεξεργαστή.
Ας πούμε η πιο συνηθισμένη εντολή για να γράφεις ένα byte στη μνήμη μπορεί να είναι η LD (HL),A στον Amstrad(Z80) που πιάνει 2 nop cycles δηλαδή 8 κύκλους μηχανής. Στον C64(6502) όλα γίνονται με direct memory addressing π.χ. STA $D020 και πιάνει 4 κύκλους μηχανής.
Αυτό στον Amstrad θα ήταν:
LD HL,&hD020
LD (HL),A
αλλά ας υποθέσουμε ότι το HL είναι φορτωμένο από πριν με τη διεύθυνση και ας συγκρίνουμε μόνο το γράψιμο στη μνήμη. Τότε ο C64 θα έτρωγε και πάλι τους μισούς κύκλους μηχανής. Twice fast at the same Mhz!
Η αντίστοιχη direct memory addresing εντολή του Amstrad είναι:
LD (&hD020),A
και τρώει 4 nop cycles (θα εξηγήσω αυτό το nop cycles μετά) δηλαδή 16 machine cycles. 4 φορές περισσότερο από την αντίστοιχη.
Ο C64 έχει και το
STA $address, X ή STA $address, Y
όπου X και Y δύο 8bit registers
δηλαδή κάτι σαν pointers, π.χ. to STA $4000, X θα γράψει στην διεύθυνση ($4000 + Χ)
και μπορείς στη συνέχεια να κάνεις INX για να αυξήσεις το X οπότε να πας στην επόμενη διεύθυνση.
Μόνο έναν κύκλο παραπάνω (5)
Του Amstrad το αντίστοιχο είναι
LD (IX+dd),Α
πολύ διαφορετικό βέβαια, γιατί τώρα ο IX είναι ο 16bit register και το νούμερο dd είναι 8bit τιμή, ανάποδο από την C64 version και πιάνει και 5 NOP cycles (20 machine cycles, 4 φορές πιο αργό και πάλι)
Αλλά θα μου πεις, για αυτό στα optimized software demo effects θα προτιμήσω να χωρέσω τις βασικές διευθύνσεις στους HL, DE, BC και να χρησιμοποιώ μόνο την πρώτη μορφή για να γράφω ή να διαβάζω από/στη μνήμη. Και όταν θέλω να πάω γειτονικά στα επόμενα values/pixels/whatever θα κάνώ ένα INC L ας πούμε ή INC H για vertical αν έχω θέσει έτσι αντίστοιχα τα data μου.
Πολλά όμως effects βολεύουν να βλέπεις σε μακριές αποστάσεις στη μνήμη. Και με τα γρήγορα opcodes για direct memory addresing του C64 και 1 κύκλο παραπάνω για τον X,Y pointer μόνο πραγματικά πολλά effects στον C64 είναι μεγάλα unrolled codes (ξετιλυγμένοι κώδικες όπου έχουν αφερεθεί τα loops και βρίσκεται μόνο η ουσία μέσα
), από ακολουθίες LDA, STA, LDA, STA, LDA , STA, STA, STA, κλπ. όπου στον Amstrad τα αντίστοιχα εφέ ή θα τα έκανες με τους αργούς, ή θα προτιμούταν για ταχύτητα να έχεις τις διευθύνσεις στου 16βιτ registers και απλά θα χανόταν αυτό το απευθείεας.Έχω και πρακτικά και θεωρητικά (σε χαρτί) σκεφτεί διάφορα software effects πως θα μπορούσα να τα κάνω γρήγορα σε Amstrad και σε C64 και βάλε και την μισή videoram (8kb έναντι 16kb) και πραγματικά σε πολλά εφέ το 1Mhz του C64 φτάνει τα 4Mhz του Amstrad, και σε πολλά μου βγαίνουν ελαφρώς πιο αργά ή πιο γρήγορα, δηλαδή κοντράρονται!
Απίστευτο.
Και όσο αφορά τα vector graphics, για να δείτε την diversity, το πόσο δεν μετράνε τα MHz και πόσο κερδίζει εδώ ο Amstrad,.
..δυστυχώς τα demos του C64 δείχνουν πιο γρήγορα 3d vectors από τον Amstrad αλλά αυτό γιατί δεν έχει ασχοληθεί ο κόσμος στον Amstrad. Το μόνο realtime vector demo με flat polygons ας πούμε ήταν του Face Hugger του 1992 και από εκεί και πέρα ο κόσμος έκανε hardware scrollers. Και στον C64 έχω δει ακόμα και gouraud shading 3d objects με καλύτερη ταχύτητα και ποιότητα από τα flat polygons του Face Hugger Ultimate megademo.
Αλλά πιστεύω ότι μπορεί να βγάλει πιο γρήγορα (και πιο όμορφα λόγο χρωμάτων) 3d ο Amstrad λόγο opcodes και registers και πάλι.
Πολύ απλά, βασικά στοιχεία στα 3d είναι fixed point arithmetic (για μηχανήματα που δεν έχουν FPU) και interpolation, πολύ interpolation.
Καθόμουν και σκεφτόμουν μερικά πράγματα και πως θα γίνουν στον Amstrad. Οι 16bit registers είναι σωτηρία. 8-8 fixed point. Έχεις τον 16bit register HL ας πούμε που χωρίζεται στον H και τον L τους 8bitους registers. Μπορείς να παραστήσεις με τον H το ακέραιο μέρος και με τον L τον δεκαδικό χωρίς αυτό να φαίνεται. Με το ADD HL,DE που πιάνει 2 nop cycles μόνο, αν έχεις στο DE έναν άλλον αριθμό σε 8-8 fixed point μορφή (που μπορούν να προυπολογιστούν πριν το actual effect ή μόνο μια φορά per frame) μπορείς να κάνεις βήμα προς βήμα interpolation και μετά έχεις απευθείεας τον H το ακέραιο κομμάτι (δεν σε ενδιαφέρει στο τέλος το δεκαδικό) για γράψιμο του pixel color ή οτιδήποτε γίνεται κάνεις interpolate στην πορεία.
Δεν έχω κάτσει να το κάνω στην πράξη. Αλλά είναι πολύ straight forward. Σε ένα Spectrum demo, στο τελικό scroller κοτσάρανε οι coders το inner loop της texture mapping routine και χρησιμοποιούσε ακριβώς αυτά σαν θεωρία στην προηγούμενη παράγραφο.
Είναι straightforward. Στον 6502 του C64 αυτό θα έπρεπε να το κάνεις simulation με 2 8bit τιμές στη μνήμη που θα κάναν το 16bit register, additions, carry checks, πολύ παραπάνω δουλειά. Από περιέργια και θεωρητικά κάθησα και σκέφτικα αντίστοιχα γρήγορες ρουτίνες interpolation optimized για 6502 και πάλι σε αυτό ο Z80 των 4Mhz είναι 3 φορές πιο γρήγορος από τον 6502 των 1Mhz.
Και από τη στιγμή που τα 3d είναι τίγκα στα fixed point και interpolations, φαντάζεσεστε πόσο εποφελείται σε αυτά τα εφφέ με τους αντίστοιχους optimized κώδικες όμως ο CPC και ο Spectrum. Αλλά όχι λόγο Mhz!!!
Και δείτε πόσο diversity υπάρχει, πόσο δεν μετράνε τα mHz αλλά πόσο κάποιοι registers, addressing modes, διαφορετικά opcodes και αρχιτεκτονικές θα ευνοήσουν άλλους αλγορίθμους. Βάλε και τα video modes και hardware tricks. (Π.χ. στην Amiga είναι άβολα τα per pixel bitmap effects και πολύ γρήγορα τα flat polygons λόγο bitplanes). Το ενδιαφέρον για μένα αυτό είναι, πόσο μπορεί κανείς να τα μελετήσει, να γράψει κώδικα για τα δύο αντίστοιχα μηχανήματα και να δει τι είναι αυτό που κάνει τη διαφορά και όχι πάντα στους ίδιους αλγορίθμους..
..ίσως είναι incomprehensible αλλά με έπιασε και πάλι.
In a nutsheel. O C64 γ***ει σε πολλά effects (ακόμα και per pixel bitmap effects), στο 1/4 των Mhz λόγο 6510, αλλά ο CPC και ο Spectrum μπορούν να είναι καλύτεροι σε 3D λόγω Z80 και 16bit registers και σχετικά γρήγορο 16bit addition.
------------------
Btw,. περί nop timing.
1 NOP (no operation, δεν κάνει τίποτα, η εντολή που πιάνει συνήθως τα λιγότερα machine cycles) πιάνει 4 machine cycles στον Amstrad.
Γιατί στον Amstrad μετράμε και τις άλλες εντολές σαν πολλαπλάσια των κύκλων μηχανής της NOP εντολής;
Καταρχήν π.χ. η LD (HL),A πιάνει 2 NOP cycles δηλαδή 8 machince cycles στον Amstrad. Αλλά στον Spectrum πιάνει λιγότερο παρόλο που έχει τον ίδιο Z80. Νομίζω 7 ή 6.
Για κάποιο λόγο το hardware στον Amstrad στρογγυλοποιεί τους κύκλους μηχανής στα 4 cycles, δηλαδή 4,8,12,16, κλπ.. πετιούνται τζάμπα δηλαδή κανά δύο cycles. Έχει να κάνει σχέση με το συγχρονισμό του επεξεργαστή με το hardware.
From wiki:
(All CPC models were based on a Zilog Z80 processor clocked at 4MHz. Because a common pool of RAM is shared with the video circuits, the Z80 may only make a memory accesses every four cycles - which has the effect of rounding all instruction cycle lengths up to the next multiple of four. The speed is therefore roughly equivalent to a 3.3MHz machine.)
Έτσι γιατί να λέμε 4,8,12,16 cycles και αφού όλα είναι πολλαπλάσια του 4 να μην λέμε 1,2,3,4 NOP cycles (που πιάνει 4 machine cycles)
Καταλαβαίνετε και το impact. O CPC με τον Z80 στα 4Mhz δεν είναι λίγο πιο γρήγορος από τον Spectrum με τον Z80 στα 3.5Mhz, ίσα ίσα πάνω κάτω το ίδιο (το 3.3Mhz που λέει το wiki είναι estimation. Μπορεί ένας κώδικας να χρησιμοποιεί opcodes που τυχαίνει ο πραγματικός αριθμός cycles να είναι και αντίστοιχο πολλαπλάσιο του 4 οπότε ουσιαστικά να μην πετιέται τίποτα)
Πολύ ανάλυση. Θα σταματήσω εδώ..
Πάρτε και το video του
fgbrain
RetroActive
- Joined
- 27 Οκτ 2006
- Μηνύματα
- 324
- Αντιδράσεις
- 34
όντως διαπιστώνεις ότι δεν μετράνε μονάχα τα mhz αλλά και η εσωτερική αρχιτεκτονική του επεξεργαστή
αυτό βεβαίως σημαίνει ότι απαιτείται special optimization απο τον προγραμματιστή για κάθε μηχάνημα... οπότε να τι έλεγα σε προηγούμενα posts περι spectrum ports :whothehell:
Optimus μου αρέσουν οι ιδέες σου...!
αλλά ξεχνάς ότι ο Z80A έχει δεύτερο σετ registers & undocumented set εντολών που μετράνε πολύ παραπάνω επίσης
anyway, νομίζω ότι ξεφύγαμε απο το θέμα του thread
αλλά χαίρομαι να συζητάω παλιές καλές ιστορίες
αυτό βεβαίως σημαίνει ότι απαιτείται special optimization απο τον προγραμματιστή για κάθε μηχάνημα... οπότε να τι έλεγα σε προηγούμενα posts περι spectrum ports :whothehell:
Optimus μου αρέσουν οι ιδέες σου...!
αλλά ξεχνάς ότι ο Z80A έχει δεύτερο σετ registers & undocumented set εντολών που μετράνε πολύ παραπάνω επίσης
anyway, νομίζω ότι ξεφύγαμε απο το θέμα του thread
αλλά χαίρομαι να συζητάω παλιές καλές ιστορίες
Nemo
RetroMuseum GateKeepeR
- Joined
- 9 Ιαν 2006
- Μηνύματα
- 4.694
- Αντιδράσεις
- 1.411
[μια μικρη Παρενθεση]
Μια και εγινε αναφορα στο C64 (και την Cpu του )
,μην ξεχναμε οτι και το Drive του C64 ειχε 6502 cpu & 2k ram
:animrolleyes: Παρακαλω συνεχιστε ,δεν θελω επουδενι
να διακοψω την πολυ ενδιαφερουσα εξελιξη του τοπικ
Μια και εγινε αναφορα στο C64 (και την Cpu του )
,μην ξεχναμε οτι και το Drive του C64 ειχε 6502 cpu & 2k ram
:animrolleyes: Παρακαλω συνεχιστε ,δεν θελω επουδενι
να διακοψω την πολυ ενδιαφερουσα εξελιξη του τοπικ
Optimus
RetroActive
- Joined
- 9 Δεκ 2006
- Μηνύματα
- 481
- Αντιδράσεις
- 181
Ναι, και έχω ακούσει ορισμένοι democoders χρησιμοποιούν τον 6502 του drive σαν δεύτερο επεξεργαστή συνήθως στις vector engines τους. Το drive υπολόγιζε τα 3d maths για τα λίγα vertices ενός object και έστελνε τα αποτελέσματα για να κάνει το κυρίως rendering ο main processor. Φυσικά το bandwidth ήταν αργό, οπότε το να πεις πως θα μοιράσω την ισχύ ώστε να κάνει το μισό εφέ το drive και το άλλο μισό ο επεξεργαστής δεν στέκει. Ενώ καμιά 10αριά 3d points να τα κάνεις rotate και έχεις ελάχιστα να στείλεις στο κυρίως επεξεργαστή ήταν ok. Αν και σήμερα δεν έχω ακούσει να το χρησιμοποιούν πολύ στα demos πια. Μπορούν να κάνουν τα 3d maths πια με γρήγορους τρόπους στον main processor. Τι άλλο θα μπορούσε να επωφεληθεί αφού είναι τόσο αργό το bandwidth μεταξύ drive και main επξεργαστή;
Πάντως το drive του C64 με τις default rom routines για loading είχε πάναργο φόρτομα (το είδα και νόμιζα σχεδόν ότι ήταν κασέτα!). Αλλά πολλοί democoders φορτώνουν πρώτα έναν δικό τους loader στο drive για να έχουν γρήγορο φόρτωμα στα demos. Και loading ενώ παίζει η μουσική (έτσι εξηγούνται όλα αυτά τα trackmo demos)
Πάντως το drive του C64 με τις default rom routines για loading είχε πάναργο φόρτομα (το είδα και νόμιζα σχεδόν ότι ήταν κασέτα!). Αλλά πολλοί democoders φορτώνουν πρώτα έναν δικό τους loader στο drive για να έχουν γρήγορο φόρτωμα στα demos. Και loading ενώ παίζει η μουσική (έτσι εξηγούνται όλα αυτά τα trackmo demos)