Alchemist` Δημοσ. 2 Μαρτίου 2011 Δημοσ. 2 Μαρτίου 2011 Εδώ και λίγο διάστημα φτιάχνω ένα προγραμματάκι στο οποίο μπορεί κανείς να ζωγραφίσει "8bit" εικόνες, σε υψηλή ανάλυση... Τι εννοώ με αυτό... Θέλουμε π.χ. να φτιάξουμε ένα sprite του Mario με μέγεθος 32χ32 pixels... Αν το κάνουμε σε κανονικό μέγεθος, θα έχουμε μια εικόνα με 32χ32 μέγεθος... Το συγκεκριμένο πρόγραμμα έχει ως στόχο να φτιάξει μια "εξομοίωση" μιας 32χ32 εικόνας, η οποία όμως έχει μέγεθος στην πράξη π.χ. 1024χ768. Έτσι έχουμε μια 8bit εικόνα, σε υψηλή ανάληση... Η έκδοση αυτή είναι η 0.1, και είναι σε πολύ πρώιμο στάδιο. Ο αλγόριθμος θέλει πολλά resources σε υψηλές αναλύσεις, και γενικώς έχει πολλά προβλήματα και ελλείψεις... Τέλος πάντων, θα ήθελα την γνώμη σας για το όλο εγχείρημα, οπότε εδώ έχω ένα download link: http://www.mediafire.com/?jc7a4wvjw48l6f3 Μόλις το ανοίξετε, διαλέγετε την πραγματική ανάλυση της εικόνας, και κατόπιν διαλέγεται το πόσο πιξελιασμένη θα είναι (8x ή 16χ blocks). Προς το παρών έχει λίγες επιλογές και αναλύσεις. Όσο πιο μεγάλα blocks διαλέξετε τόσο πιο μεγάλο το πιξέλιασμα. Στον χώρο "ζωγραφικής" το ποντίκι λειτουργείο όπως το μολύβι του MS Paint, ενώ αριστερά έχει ένα Panel με χρώματα για να διαλέξετε, το οποίο μετακινείται σέρνοντας το από το πάνω σημείο του. Προς το παρόν δεν μπορείτε να αποθηκεύσετε την εικόνα, ή να ανοίξετε άλλες εικόνες, πάντως αν θελετε παίρνετε ένα screenshot Πατώντας το F9. Επίσης με το F4 γυρνάει σε Fullscreen.
bnvdarklord Δημοσ. 4 Μαρτίου 2011 Δημοσ. 4 Μαρτίου 2011 Τελειωνε ρε το fps και ασε τις ζωγραφικές Αστειευομαι... Καλό μου φάνηκε, αλλά υπάρχει καποιος λόγος που τρώει 25%cpu idle?
chiderboy Δημοσ. 4 Μαρτίου 2011 Δημοσ. 4 Μαρτίου 2011 Με το Gamemaker το φτιάχνεις αυτό; Μήπως θα ήταν καλύτερα να το δουλέψεις σε διαφορετική γλώσσα/σουίτα; Τελειωνε ρε το fps και ασε τις ζωγραφικές Έγω δεν αστειεύομαι όμως. Άντε και μας έχεις πορώσει...
Alchemist` Δημοσ. 5 Μαρτίου 2011 Μέλος Δημοσ. 5 Μαρτίου 2011 Ευχαριστώ για τα σχόλια... Με το Gamemaker το φτιάχνω... Δεν σκέφτομαι να προσωρήσω σε άλλη πλατφόρμα από την στιγμή που με καλύπτει η συγκεκριμένη... Τρώει 25% της cpu, γιατί δεσμεύει εξ' αρχής τα resources που χρειάζεται... Είτε Idle, είτε κάνεις οποιαδήποτε ενέργεια, το cpu usage θα παραμείνει στο 25%. Όσων αφορά το παιχνίδι, το επόμενο update Θα το ανεβάσω μέσα στις επόμενες 2 βδομάδες... Τελείωσα σήμερα τα editable controls για τον πρώτο παίκτη... Το μόνο που μας καθυστερεί είναι ασυμβατότητες με τα διάφορα τηλεχειριστήρια, και επίσης βαριέμαι να ξανασχεδιάσω το HUD για το Split Screen...
parsifal Δημοσ. 5 Μαρτίου 2011 Δημοσ. 5 Μαρτίου 2011 25% φαντάζομαι σε μηχάνημα με τετραπύρηνο επεξεργαστή, σε κάποιο 2πύρηνο θα έδειχνε 50% κ.ο.κ., έτσι δεν είναι; Πάντως συναντάται ως φαινόμενο και σε άλλα προγράμματα/μηχανές, όπου το thread του main event loop κάνει ενεργά συνεχές polling για νέα συμβάντα και απασχολεί μόνιμα έναν λογικό πυρήνα. Ένα σύγχρονο framework προγραμματισμού θα ήταν πιο ενδεδειγμένη λύση για τέτοιου είδους προγράμματα.
Alchemist` Δημοσ. 5 Μαρτίου 2011 Μέλος Δημοσ. 5 Μαρτίου 2011 25% φαντάζομαι σε μηχάνημα με τετραπύρηνο επεξεργαστή, σε κάποιο 2πύρηνο θα έδειχνε 50% κ.ο.κ., έτσι δεν είναι; Πάντως συναντάται ως φαινόμενο και σε άλλα προγράμματα/μηχανές, όπου το thread του main event loop κάνει ενεργά συνεχές polling για νέα συμβάντα και απασχολεί μόνιμα έναν λογικό πυρήνα. Ένα σύγχρονο framework προγραμματισμού θα ήταν πιο ενδεδειγμένη λύση για τέτοιου είδους προγράμματα. Δεν φταίει το Game Maker για αυτό.. Εγώ φταίω, γιατί για λόγους "πρόσθεσης δυνατοτήτων αργότερα", σε μια εικόνα 1024χ768 με 8χ blocks υπάρχουν περί τα ~13000 objects... Υπάρχει τρόπος να γίνει πολύ πιο ελαφρύ (με χρήση Grids, cpu usage έχει 5% στο 2ghz, 2core, λάπτοπ μου), τον οποίο έχω αρχίσει να ενσωματώνω τώρα. Θα κρατήσω και τις 2 εναλλακτικές λύσεις rendering,την μια για οικονομία recourses, και την άλλη για την λειτουργικότητας της... Βλέπουμε πάντως... Είναι πολύ νωρίς για να για να με κατακρίνετε έτσι Θα αργήσει πάντως το update, γιατί έχει δωθεί περισσότερο βάρος στο παιχνίδι. Υ.Γ. Βασικά μια χαρά τα πάει η GML με τόσες χιλιάδες Objects active, δε νομίζεις?
parsifal Δημοσ. 5 Μαρτίου 2011 Δημοσ. 5 Μαρτίου 2011 Χμμμ, είσαι σίγουρος ότι δεν οφείλεται σε κάποιο ατέρμονο loop της GML engine; Παρατήρησα τρέχοντας το εκτελέσιμο στο δικό μου 2πύρηνο μηχάνημα ότι, όντως, η διεργασία προκαλεί 50% CPU usage. Μπας και παίζει από πίσω κάποιος collision detection μηχανισμός ή κάτι παρόμοιο, όσο κι αν αυτό δεν έχει νόημα για το συγκεκριμένο τύπο εφαρμογής; Είναι η φύση της GML και η αποστολή της τέτοια που με οδηγεί σε μία τέτοια υπόθεση. Από την άλλη, ο αριθμός των objects που χρησιμοποιείς σε ένα πρόγραμμα bitmap σχεδιασμού, πέραν των αυξημένων απαιτήσεων σε RAM, δε θα έπρεπε να παίζει ρόλο στο CPU usage όταν το πρόγραμμα δεν κάνει τίποτε άλλο από το να περιμένει input από τον χρήστη! Τί σημαίνει το "active" στο «τόσες χιλιάδες Objects active»; Γιατί να είναι "active" τα objects αυτά; Σαν τί κάνουν δηλαδή; Κάτι άλλο παίζει εδώ πέρα...
Alchemist` Δημοσ. 5 Μαρτίου 2011 Μέλος Δημοσ. 5 Μαρτίου 2011 Χμμμ, είσαι σίγουρος ότι δεν οφείλεται σε κάποιο ατέρμονο loop της GML engine; Παρατήρησα τρέχοντας το εκτελέσιμο στο δικό μου 2πύρηνο μηχάνημα ότι, όντως, η διεργασία προκαλεί 50% CPU usage. Μπας και παίζει από πίσω κάποιος collision detection μηχανισμός ή κάτι παρόμοιο, όσο κι αν αυτό δεν έχει νόημα για το συγκεκριμένο τύπο εφαρμογής; Είναι η φύση της GML και η αποστολή της τέτοια που με οδηγεί σε μία τέτοια υπόθεση. Από την άλλη, ο αριθμός των objects που χρησιμοποιείς σε ένα πρόγραμμα bitmap σχεδιασμού, πέραν των αυξημένων απαιτήσεων σε RAM, δε θα έπρεπε να παίζει ρόλο στο CPU usage όταν το πρόγραμμα δεν κάνει τίποτε άλλο από το να περιμένει input από τον χρήστη! Τί σημαίνει το "active" στο «τόσες χιλιάδες Objects active»; Γιατί να είναι "active" τα objects αυτά; Σαν τί κάνουν δηλαδή; Κάτι άλλο παίζει εδώ πέρα... Κάθε τετραγωνάκι είναι ένα αντικείμενο... Δεν έχουμε ένα αντικείμενο στον δείκτη του ποντικιού και το αφήνουμε στο κάθε σημείο (πράγμα που κάνει η μέθοδος grid με ελάχιστα resources). Αυτό το έκανα με σκοπό να υπάρχει απόλυτος έλεγχος σε κάθε Pixel (-> τετράγωνο) (για pixel art προορίζεται το πρόγραμμα άλλωστε). Υπάρχει ένας συνεχής έλεγχος της κατάστασης των 13000 τετραγώνων, εξού και το cpu usage... Με αυτό το σύστημα (κάθε τετραγωνάκι να είναι μια οντότητα) ο χρήστης δεν μπορεί να περιοριστεί με κανένα τρόπο... Κάθε τετράγωνο μπορεί να κρατάει το δικό του ιστορικό ενεργειών, να μεταφερθεί, να προστεθούν διάφορα effects, να μεγαλώσει, να μικρύνει, να επιλεχθεί, να αλληλεπιδράσει με τα γειτονικά τετραγωνάκια, και πολλά άλλα... Δεν υπάρχει κανένα περιορισμός στο τι μπορεί να γίνει... Ακόμη και το να φτιάξει κανείς κάποιο animation είναι πολύ εύκολο (με μια απλή scripting language που σκοπεύω να ενσωματώσω)... Σίγουρα πρόκειται για σπατάλη πόρων, αλλά whatever, η δική μου, μη εμπορική εφαρμογή είναι... ότι θέλω κάνω για το καλύτερο imho αποτέλεσμα (πλακίζω)
parsifal Δημοσ. 5 Μαρτίου 2011 Δημοσ. 5 Μαρτίου 2011 Υπάρχει ένας συνεχής έλεγχος της κατάστασης των 13000 τετραγώνων, εξού και το cpu usage... Τον κάνεις ρητά εσύ αυτόν τον έλεγχο ή τον κάνει το runtime της GML, ακόμη κι αν εσύ δεν τον χρειάζεσαι; Εκεί θέλω να καταλήξω. Το να υπάρχει συνεχής έλεγχος του state όλων των αντικειμένων σε ένα σχεδιαστικό πρόγραμμα bitmap γραφικών, με μια πρώτη ματιά φαίνεται εντελώς περιττό ως κίνηση. Τα features που αναφέρεις ότι σκέφτεσαι να υλοποιήσεις στη συνέχεια (ιστορικό, effects κλπ.) απαιτούν μόνο «μνήμη» (το state που ανέφερα πιο πάνω). Και έξτρα υπολογισμούς μόνο ως απάντηση σε ερέθισμα, δηλαδή σχετικό input από τον χρήστη. Ο συνεχής έλεγχος θα ήταν χρήσιμος (αναγκαίος, βασικά) αν ήθελες να φτιάξεις π.χ. μία physics engine. Αλλά δεν φαίνεται να το πηγαίνεις προς τα εκεί. Επαναλαμβάνω, δε γνωρίζω αν πρόκειται για κάτι που μπορείς να αποφύγεις ή είναι το τίμημα που πρέπει να πληρώσεις για τις ευκολίες που σου παρέχει η GML. Υπέθεσα πως είναι το δεύτερο, γι' αυτό και σημείωσα πως αξίζει να εξετάσεις το ενδεχόμενο κάποιου παραδοσιακού event-driven framework προγραμματισμού με το οποίο δε θα έχεις τέτοια θέματα. Αν η σπατάλη πόρων δε σε ενοχλεί, ούτε σε ενοχλεί που ενοχλεί τους χρήστες των εργαλείων σου, αγνόησε ο,τι έχω γράψει ως τώρα!
Evgenios1 Δημοσ. 6 Μαρτίου 2011 Δημοσ. 6 Μαρτίου 2011 34% cpu ειναι πολλα. ΥΓ: Το interface μεσα στο window client ειναι directx8
Alchemist` Δημοσ. 6 Μαρτίου 2011 Μέλος Δημοσ. 6 Μαρτίου 2011 34% cpu ειναι πολλα. ΥΓ: Το interface μεσα στο window client ειναι directx8 DirectX 8 χρησιμοποιεί το Game Maker... (Αλήθεια πως το κατάλαβες?) Όπως και να 'χει, θα το διορθώσω το θέμα με τα system resources... Για αυτό άλλωστε το έφτιαξα και το τόπικ, για να πάρω σχόλια που θα με κατευθύνουν στον σωστό δρόμο... Όπως ξαναείπα έχει δωθεί βαρύτητα στο παιχνίδι αυτήν την στιγμή. Μόλις ανεβεί η επόμενη έκδοση του παιχνιδιού θα ασχοληθώ με το πρόγραμμα αυτό... Η λύση είναι ήδη γνωστή, απλά δεν έχει υλοποιηθεί. Ευχαριστώ για τον χρόνο σας, και απο την στιγμή που το θέμα του cpu usage imho έχει καλυφθεί, οποιος θέλει θα μπορούσε να πει πιθανές ιδέες για κάποιο στοιχείο που θα ήθελε να ενσωματωθεί, ή κάποιο άλλο πρόβλημα που συνάντησε. Ευχαριστώ εκ των προτέρων.
Προτεινόμενες αναρτήσεις
Αρχειοθετημένο
Αυτό το θέμα έχει αρχειοθετηθεί και είναι κλειστό για περαιτέρω απαντήσεις.