Jump to content
Sign in to follow this  
Optimus

3DO rendering tech video

Recommended Posts

Μόλις τελίωσα ένα ακόμα ενδιαφέρον 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

  • Thanks 4

Share this post


Link to post
Share on other sites

Το εκανες ταληρακια! Να σαι καλα. Εσωσες πολυ κοσμο απο πολυ διαβασμα.

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

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

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

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

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

Quote

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 δεν ηταν διαθεσιμη για κατι αλλο!

  • Like 1

Share this post


Link to post
Share on other sites

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 πλατφόρμες.

 

  • Like 1

Share this post


Link to post
Share on other sites

+1 για το video. Παρόλο που δεν καταλαβαίνω το 90% τα γουστάρω αυτού του είδους τα τεχνικά explanations.

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

Share this post


Link to post
Share on other sites

 

offtopic  (derail συνέχεια) 

Spoiler

 

9 hours ago, Imgema said:

 

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

Από ότι φαίνεται ενωμεταξύ σαν να έχουμε χάσει  επεισόδια >>> εδώ

 

 

Edited by Nemo

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...