Από πού προέρχονται όλα τα byte;

Μεγάλη ερώτηση Dion! Θα το απαντήσω, και όχι μόνο επειδή είσαι το νέο αφεντικό μου, αλλά επειδή είναι μια καλή ερώτηση. (αλλά και επειδή είσαι το νέο αφεντικό μου.)

Θέλω όμως να ξεκαθαρίσω κάτι εδώ: δεν συγκρίνουμε πραγματικά τα Apples-to-Apples, οπότε ας καθορίσουμε πρώτα κάποιες τεχνολογίες.

Πώς λειτουργεί ο Mario

Ας μιλήσουμε λοιπόν για το πώς λειτούργησε το πρωτότυπο παιχνίδι Super Mario, από μια προοπτική.

Η αρχική κονσόλα NES σχεδιάστηκε μόνο για την παραγωγή εικόνων με πλάτος 256 και ύψος 240. που σημαίνει ότι η τελική εικόνα που έπρεπε να εμφανίζεται στην οθόνη είχε μέγεθος 180kb.

Εκτός αυτού, το NES είχε μόνο 2kb μνήμης RAM. Η ίδια μια κασέτα θα μπορούσε να χωρέσει 8k έως 1mb δεδομένων παιχνιδιού. Έτσι, δεν υπήρχε τρόπος να ενσωματώσετε ολόκληρο το περιεχόμενο του παιχνιδιού στην κύρια μνήμη. Βασικά, ένα υποσύνολο των δεδομένων κασέτας 1MB πρέπει να φορτωθεί στη μνήμη RAM 2kb και να χρησιμοποιηθεί για την απόδοση της οθόνης 180kb. Πώς το επιτυγχάνει αυτό;

Φύλλα Sprite.

Τα φύλλα Sprite περιέχουν μικρά πλακάκια γραφικών, τα οποία επαναχρησιμοποιούνται ξανά και ξανά. Για παράδειγμα, παρακάτω είναι ένα remake του αρχικού φύλλου super mario sprite:

Κάθε μικρό τετράγωνο 16x16 εικονοστοιχείων αντιπροσωπεύει ένα «πλακάκι» και οι καλλιτέχνες θα τα έδεσαν μαζί για να δημιουργήσουν τα πραγματικά επίπεδα. Τα ίδια τα επίπεδα, μόλις έγιναν μια τεράστια σειρά 2D ευρετηρίων στο φύλλο sprite. (Μιλώ για αυτό με περισσότερη λεπτομέρεια στο Μάθημα 3 του μαθήματος HTML5 Game Development @ Udacity ή στο βιβλίο μου HTML5 Game Development Insights.) Εφαρμόστε κάποια κωδικοποίηση Run-Length, ή κάποια βασική LZ77 και λαμβάνετε ένα αρκετά συμπαγής μορφή για επίπεδα.

Έτσι, με έννοιες όπως φύλλα πλακιδίων και φύλλα sprite, μπορούμε να χρησιμοποιήσουμε ένα μικρό σύνολο εικόνων για να δημιουργήσουμε μεγάλες σκηνές και κόσμους. Έτσι λειτουργούν τα περισσότερα παιχνίδια. Ακόμα και τα τρισδιάστατα παιχνίδια θα έχουν ένα σύνολο κοινών υφών που εφαρμόζονται πολλές φορές και μέρη σε όλο το ίδιο το παιχνίδι.

Ας μιλήσουμε τώρα για τη γενική συμπίεση εικόνας.

Πώς συμπιέζονται οι εικόνες

Εδώ είναι το " μη δίκαιο " μέρος αυτής της σύγκρισης. Οι γενικοί αλγόριθμοι συμπίεσης εικόνας δεν έχουν γνώση τομέα για τα εικονοστοιχεία μέσα τους. Τα JPG, PNG, WebP έχουν σχεδιαστεί για φωτογραφίες και όχι για πολλές οθόνες παιχνιδιών . Το αποτέλεσμα είναι ότι για ένα δεδομένο μπλοκ 16x16 pixel, αυτοί οι αλγόριθμοι υποθέτουν ότι είναι μοναδικοί μεταξύ της εικόνας. Εκτός από κάποια κβαντοποίηση χρώματος, δεν υπάρχει πραγματική λογική για να προσδιοριστεί εάν ένα άλλο μπλοκ 16x16 θα μπορούσε να είναι ένα ακριβές αντίγραφο του τρέχοντος. Αυτό γενικά σημαίνει ότι υπάρχει ένα χαμηλότερο όριο στο πώς συμπιέζεται ένα δεδομένο μπλοκ δεδομένων.

Για παράδειγμα, το JPG διασπά μια δεδομένη εικόνα σε μπλοκ pixel 8x8, μετατρέπει το χώρο χρώματος RGB σε έκδοση YCbCr και, στη συνέχεια, εφαρμόζει μετασχηματισμό διακριτού συνημίτου σε αυτά. Μόνο μετά από αυτό το βήμα, έρχεται ένας κωδικοποιητής χωρίς απώλειες και βλέπει αν μπορεί να ταιριάξει με κοινές διπλές ομάδες χρησιμοποιώντας DPCM ή RLE.

Έτσι, το μόνο μέρος όπου δύο μπλοκ μπορεί να συμπιεστούν σε 1 μπλοκ, είναι εάν η μετα-DCTd έκδοσή τους είναι ίδια και η RLE μπορεί να κάνει πρόοδο. Αυτό δεν συμβαίνει τόσο συχνά.

Παρά τα άλλα μειονεκτήματά του, το PNG είναι πολύ καλύτερο από αυτή την άποψη. Η συμπίεση PNG είναι εντελώς χωρίς απώλειες (έτσι η ποιότητα της εικόνας σας είναι υψηλή, αλλά η εξοικονόμηση συμπίεσης είναι χαμηλή) και βασίζεται στον κωδικοποιητή DEFLATE, ο οποίος συνδυάζει το LZSS μαζί με την αριθμητική συμπίεση. Το αποτέλεσμα είναι ότι οι μεγάλες διαδρομές παρόμοιων εικονοστοιχείων μπορεί να καταλήξουν να μειωθούν σε πολύ μικρότερο μέγεθος. Γι 'αυτό μια εικόνα με πολύ ομοιόμορφο φόντο θα είναι πάντα μικρότερη ως PNG αντί για JPG.

Η παρακάτω εικόνα είναι αρχείο PNG 5,9kb, ενώ η εικόνα JPG είναι 106kb

Μήλα εναντίον Dragonfruit

Το σημείο μου εδώ είναι ότι είναι κάπως άδικο να συγκρίνεις περιεχόμενο παιχνιδιού με μία μόνο εικόνα στο Διαδίκτυο.

Από την πλευρά του παιχνιδιού, ξεκινάτε με ένα μικρό σύνολο επαναχρησιμοποιήσιμων πλακιδίων και τους δείχνετε για να δημιουργήσετε τη μεγαλύτερη εικόνα σας, μπορούμε να το κάνουμε αυτό, γιατί γνωρίζουμε πώς πρόκειται να γίνει το παιχνίδι. Από την άλλη πλευρά, το JPG / PNG / WebP προσπαθεί απλώς να συμπιέσει τα δεδομένα που μπορεί να βρει σε τοπικά μπλοκ, χωρίς πραγματική επιθυμία να ταιριάξει το επαναλαμβανόμενο περιεχόμενο. Η συμπίεση εικόνας είναι σαφώς σε μειονεκτική θέση εδώ, δεδομένου ότι δεν έχουν προηγούμενη γνώση του χώρου δεδομένων τους, δεν μπορούν πραγματικά να κάνουν προσδοκίες γι 'αυτό.

Εννοώ, σκεφτείτε το Demo Scene που είναι εξαιρετικά μεγάλο σε αυτό το είδος. Μπορούν να σπάσουν 30 λεπτά ολόκληρου του 3d shooter σε 64kb επειδή καταλαβαίνουν και γνωρίζουν πολλά περισσότερα για τα δεδομένα τους.

Απλώς δείχνει, με τη σωστή γνώση για τα δεδομένα σας, μπορείτε να κάνετε υπέροχα πράγματα με συμπίεση.

Ανυπομονώ.

Προφανώς, έχουμε μεγαλώσει από τις οθόνες 256x240 των ημερών NES. Το τηλέφωνο στην τσέπη μου έχει 1.920 x 1.080 pixel οθόνης @ έχει μέγεθος 5,2 ”, δίνοντάς το ~ 423 pixel ανά ίντσα πυκνότητας. Για να το συγκρίνουμε με τον ίδιο αριθμό εικονοστοιχείων που είναι ~ 33 οθόνες super-mario ή μάλλον 8 MB δεδομένων pixel Δεν νομίζω ότι κάποιος εκπλήσσει ότι οι αναλύσεις οθόνης αυξάνονται, αλλά συνοδεύεται επίσης από την ανάγκη για περισσότερα δεδομένα .

Αυτό είναι κάτι για το οποίο έχω πει για λίγο τώρα. Ενώ έχουμε μεγαλύτερες οθόνες, τα κανάλια περιεχομένου πρέπει να αυξήσουν τις εξόδους ανάλυσής τους, προκειμένου να εξακολουθούν να φαίνονται καλά στις ρυθμίσεις υψηλότερης πυκνότητας (διαφορετικά, θα έχουμε θόλωση κλιμάκωσης ..). Αυτό, φυσικά, αναγκάζει τα πακέτα βιντεοπαιχνιδιών μας να μεγαλώνουν, τις ιστοσελίδες μας να μεγαλώνουν και ακόμη και τα βίντεο συνεχούς ροής του YouTube να μεγαλώνουν. Βασικά, στέλνουμε περισσότερα δεδομένα σε μικρότερες συσκευές μόνο λόγω ανάλυσης οθόνης. Ποιο, για τα επόμενα 2 δισεκατομμύρια άτομα σε αναδυόμενες αγορές, σε συνδέσεις 2G, είναι σαν τη χειρότερη ιδέα ποτέ

Αλλά διαχωρίζω. Αυτή είναι μια διαφορετική θέση.