• Αγαπητά μέλη: Για λόγους ασφαλείας, τα παλιά σας user passwords έχουν καταργηθεί. Πατήστε εδώ για password reset ώστε να ορίσετε νέο συνθηματικό. Μη ξεχάσετε να ελέγξετε τον spam folder σας για το email που θα παραλάβετε. Aν πιστεύετε ότι έχετε εγγραφεί με email address που έχει καταργηθεί, παρακαλούμε να επικοινωνήσετε μαζί μας στο info@retromaniax.gr για να αποκαταστήσουμε το πρόβλημα.

3DO rendering tech video

Optimus

RetroActive
Joined
9 Δεκ 2006
Μηνύματα
458
Αντιδράσεις
69
Μόλις τελίωσα ένα ακόμα ενδιαφέρον video όπου δίχνω πως τα vectors που χρησιμοποιούνται στο 3DO hardware για κάθε CEL (όπου ένα CEL αντιστοιχεί σε ένα bitmap που stretchάρεται ώστε να κάνει render quads) για να κάνουν από zooming/rotating sprites έως πολύγωνα και μερικά πιο περιέργα σχήματα. Δίχνω και το αποτέλεσμα ένος special flag (CCB_MARIA) που απλώς κάνει skip το κομμάτι του rendering που γεμίζει solid τα texels, οπότε βλέπεις μόνο points του grid της επιφάνειας. Αυτό το gimmick είχε χρησιμοποιηθεί σε ένα παιχνίδι το Total Eclipse, αλλά δίχνω και πως γίνεται το Doom 3DO σουρωτήρι όταν το ενεργοποιώ για κάθε CEL. (Και ναι, ξαναδουλεύω στο Doom 3DO κώδικα και θα προσπαθήσω να βγάλω μια πρώτη μικρή έκδοση σύντομα, δεν θα βελτίωσει πολύ την ταχύτητα ακόμα (αυτό θέλει περισσότερο έρευνα και δουλειά) αλλά θα προσθέσω και μερικά εξτρά features).

https://www.youtube.com/watch?v=P8X_oJGCTSs
 

Wally

Retired Admin
Joined
19 Ιαν 2006
Μηνύματα
25.222
Αντιδράσεις
2.500
Το εκανες ταληρακια! Να σαι καλα. Εσωσες πολυ κοσμο απο πολυ διαβασμα.

Παρολο που δεν ασχολουμαι, μου αρεσει πολυ να διαβαζω για renderers και τετοια.

Επισης τα quads ως αουτσαιντερς μου αρεσουν (χαχαχαχα)

Νομιζω απο σπιτικες κονσολες μονο το Saturn, το 3DO και το DS υποστηριξαν quad. 

Θυμαμαι επισης να διαβαζω οτι το Saturn ειχε κατι σαν forward rendering οπου τελικα λογω quads κατεληγε σε πολυ "ξαναζωγραφισμα" και σπαταλουσε δυναμη. Οταν μαλιστα εμπαιναν και εφε, καλα κρασια. Δεν ξερω αν αυτο ισχυε και για το 3DO.

EDIT: βρηκα αυτο που ειχα διαβασει. Eιμαι τσακαλι :)

Saturn did quads a different way, and it also had a ton of problems. Unlike most other 3D hardware I know of, Saturn used a sort of "forward rendering", where it mapped lines from a sprite to stretched lines in screen space (the norm, "backwards rendering", maps pixels in screen space back to the texture, and marches through the screen one at a time). This technique suffered from a serious amount of internal overdraw, where pixels in the same quad are drawn on top of each other. This happens for two reasons. Because the line algorithm suffers from integer roundoff at the edges, adjacent lines would normally leave some gaps between them, so the lines are drawn thicker by inserting an extra pixel where they change slope. And, when the two control edges of the quad are not the same size, multiple lines from the sprite naturally overlap.This overdraw results in wasted fillrate. Especially if you drew triangles (as degenerate quads) in the wrong way, resulting in a ton of overdraw as every line converged on the same point. It also makes the 50% blended draw mode very glitchy, because the overdraw pixels get blended multiple times. That's why very few 3D games use it, instead opting to use the garish mesh mode.
Πηγη

EDIT2: Ελπιζω να μην σου κανω derail το thread αλλα μιας και σε βρηκα... :) Ειχα επισης καπου διαβασει (δεν το βρισκω τωρα) οτι επειδη το 3DO δεν ειχε cache, κατα τη διαρκεια του texture mapping η CPU δεν ηταν διαθεσιμη για κατι αλλο!
 
Τελευταία επεξεργασία από έναν συντονιστή:

Optimus

RetroActive
Joined
9 Δεκ 2006
Μηνύματα
458
Αντιδράσεις
69
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 πλατφόρμες.
 

Imgema

Alien RetroDatabase
Joined
4 Ιον 2009
Μηνύματα
4.756
Αντιδράσεις
721
+1 για το video. Παρόλο που δεν καταλαβαίνω το 90% τα γουστάρω αυτού του είδους τα τεχνικά explanations.

Μην κάνω κι εγώ derail αλλά η φωνή σου είναι ίδια με του ektelion.
 

Nemo

RetroMuseum GateKeepeR
Joined
9 Ιαν 2006
Μηνύματα
4.695
Αντιδράσεις
1.172
Τελευταία επεξεργασία από έναν συντονιστή:
Μπλουζα