Quads είχε και η
Nvidia NV1 πρωτού το industry περάσει στα triangles.
Ο τρόπος που rendάρει το 3DO είναι πολύ κοντά στο Saturn (αν και το τελευταίο έχει πρόβλημα με τις διαφάνειες). Το NDS από ότι έχω ακούσει όντως υποστηρίζει quad πέρα από triangles, αλλά δεν το κάνει με forward rendering οπότε γλυτώνει τα προβλήματα του Saturn/3DO.
Το περίφημο post του Exophase, έχω πέσει αρκετές φορές πάνω σε αυτό όταν ψάχνω σχετικά με quad rendering στις κονσόλες, και είναι αρκετά διαφωτιστικό αν και κάθε φορά που μαθαίνω κάτι για το 3DO ξαναεπιστρέφω για να καταλάβω καλύτερα αυτά που λέει και για το Saturn. Και το 3DO αυτό που κάνει είναι forward rendering και το κάνει έτσι ακριβώς όπως το περιγράφει, linear διαβάζει το bitmap και γράφει σε scaled directions στο framebuffer. Ενώ οι περισσότεροι software ή hardware renderers είναι linear στο framebuffer μέσα στην περιοχή του polygon και inverse rendering, sampling από μόνο τα απαραίτητα pixels του bitmap, έτσι είσαι σίγουρος πως καλύπτεις κάθε pixel στην περιοχή του πολυγώνου χωρίς overdraw ή underdraw. Αυτό στο forward rendering όντως θα δημιουργήσει overdraw, που αν έχεις blending φαντάζομαι θα γίνονται διπλόblends bitmap pixels που πέφτουν το ένα πάνω στο άλλο (αλλά και στα edges των texels αναλόγως με το πόσο καλός είναι ο renderer (σύγχρονοι renderers μπορούν να αποφεύγουν overdraw πλήρως στα edges), όπως αναφέρει κάπου ο Exophase) αλλά από ότι βλέπω στην πράξη στο 3DO έχω μηδέν προβλήματα με αυτό, ενώ σε info που διαβάζω (patent για το 3DO rendering που βρήκα κατά τύχη) μαρκάρουν τα pixels που έχουν γίνει cover ήδη κατά το rendering ενός cel, ώστε να γλυτώσουν το overdrawing, ειδικά όταν ενεργοποιούν transparency που θα δημιουργούσε artifacts (pixels παραπάνω blended από ότι θα έπρεπε) σε σημεία.
Οπότε ίσως το Saturn (αν ισχύει αυτό που λέει ο Exophase, γιατί δεν το έχω ψάξει ούτε ασχοληθεί με coding στο Saturn) να κάνει παραπάνω overdraw από το 3DO, αλλά και τα δυο με το forward rendering έχουν και το άλλο πρόβλημα, μπορεί να έχεις π.χ. ένα πολύγωνο πολύ μακρία και να rendάρει 5-6 pixels στην οθόνη, αλλά αν το texture του είναι π.χ. 256*256, θα κάνει read όλα αυτά τα 65536 pixel values από το bitmap, αν και τα περισσότερα θα πάνε πεταμένα. Για αυτό και παιχνίδια σε αυτές τις κονσόλες κάνουν texture LODing στα μακρινά όπως φαίνεται ξεκάθαρα στο παιχνίδι που δίχνω στο τέλος του video. Με inverse rendering αυτό και διάφορα άλλα προβλήματα θα είχαν λυθεί, δεν ξέρω γιατί επέλεξαν άλλη μέθοδο (ίσως τότε ήταν όλα πειραματικά και δεν είχαν καταλήξει στο standard).
To CPU του 3DO δεν έχει cache (είναι κάποιος ARM αλλά από τους παλαιότερους χωρίς cache) αλλά δεν ξέρω αν αυτό σχετίζεται. Όντως όταν στέλνω ένα η περισσότερα CELs για rendering, ο CPU περιμένει. Ένας άλλος λόγος πιστεύω είναι ότι το framebuffer κάθεται πάνω στην main RAM, είναι shared με το GPU κατά κάποιον τρόπο. Αυτό έχει ενδιαφέρον και πλάκα γιατί ενδιάμεσα του rendering τών CELs στο framebuffer, μπορώ να διαβάζω ή να γράφω pixels καθαρά με τον CPU (έχει ενδιαφέρον πως τα συνδίαζει το εντυπωσιακό 3DO Audio Visualization (
https://www.youtube.com/watch?v=1IPoV_9WoC4 ) όπου rendάρουν αυτά τα σχήματα με CELs αλλά μέτα πέφτουν διάφορα φίλτρα που φαντάζομαι είναι optimized CPU κώδικας πάνω στο framebuffer μιας και δεν μπορεί να κάνει το hardware αυτά τα φίλτρα φαντάζομαι). Μάλλον επειδή είναι unified, παγώνουν τον CPU μεταξύ του rendering του κάθε CEL ή λίστας από CEL που περνάς.
p.s. μην ανησυχείς, δεν κάνεις derail, ίσα ίσα άνοιξες συζήτηση. Έχω αρκέτα να πω (και ίσως πολλά από αυτά θα τα εξηγήσω καλύτερα σε μελοντκά videos) αλλά μου αρέσει να εξηγώ πράγματα που βρίσκω ενδιαφέροντα (και τυχαίνει να έχω ασχοληθεί) για τις αγαπημένες μας retro πλατφόρμες.
