Προς το περιεχόμενο

Προτεινόμενες αναρτήσεις

Δημοσ.

Ένας λιτός κλώνος του 2048 υλοποιημένος σε 700 γραμμές C/C++ & Windows API.

 

 

  Εμφάνιση κρυμμένου περιεχομένου

 

  • Like 4
  • Απαντ. 272
  • Δημ.
  • Τελ. απάντηση

Συχνή συμμετοχή στο θέμα

Συχνή συμμετοχή στο θέμα

Δημοσιευμένες Εικόνες

Δημοσ.

Ωραίος (ως συνήθως) φίλε Dx!

 

Για να γίνει compile με mingw-g++ ο κώδικας αρκεί να προστεθεί ένα

#include <cstdio>
ώστε να αναγνωρίζει το BUFSIZ και κατόπιν στη γραμμή εντολών:

g++ -std=c++11 xd2048.cpp -o xd2048.exe -lkernel32 -luser32 -lcomdlg32 -lgdi32 -lcomctl32 -Wl,--subsystem,windows
Στα πολύ βιαστικά, το έβαλα να ειδοποιεί με message-box τον παίκτη όταν χάνει και να τον προτρέπει να επιλέξει Restart αν θέλει να ξεκινήσει νέο παιχνίδι.

 

Επειδή τις κινήσεις τις κάνεις με αναδρομή σε void συνάρτηση και δεν έκατσα να κάνω μετατροπή με bool τιμή επιστροφής και propagation της στους διαδοχικούς callers, προσέθεσα στα γρήγορα μια απλή συνάρτηση HasAdjacentCells() που ελέγχει επιτόπου το grid και την έβαλα στο case WM_KEYDOWN της GameProc.

 

Το αποτέλεσμα είναι πως η ειδοποίηση δεν βγαίνει αμέσως μόλις γεμίσει το grid, αλλά μόλις επιχειρηθεί κίνηση ακριβώς μετά από εκεί (btw, ελπίζω να μη χάλασα κάποια άλλη λειτουργικότητα του game... αν και λογικά δεν πρέπει να χάλασα κάτι).

 

Κώδικας:

 

  Εμφάνιση κρυμμένου περιεχομένου

 

ΥΓ. Για να είμαι απολύτως ειλικρινής, με χαλάσανε λιγάκι τόσες πολλές global μεταβλητές, αλλά οκ είπαμε... τον χαβαλέ μας κάνουμε :)

  • Like 1
Δημοσ.
  Αναφορά σε κείμενο

ΥΓ. Για να είμαι απολύτως ειλικρινής, με χαλάσανε λιγάκι τόσες πολλές global μεταβλητές, αλλά οκ είπαμε... τον χαβαλέ μας κάνουμε  :) 

Yup! Το έγραψα quick & dirty ίσα - ίσα να χωράει σε μια ανάρτηση (ήταν δουλεία μερικών ωρών).

 

Υ.Γ.

 Πριν πολύ καιρό είχα γράψει ένα ακόμα παιχνίδι από ένα άλλο παρόμοιου περιεχομένου topic του forum, ήταν ένα Battleship Solitaire ξανά σε C/C++ & Windows API, μου είχε βγει περίπου 1000 γραμμές - - κάποια στιγμή λέω να το αναρτήσω.

 

 Με αυτό τον τρόπο φρεσκάρω το WinAPI μου που & που ;-)

Δημοσ.

Έκανα πριν από λίγο ένα commit, όπου μαζί με ένα προηγούμενο, έχουν πλέον προστεθεί πλήρη σχόλια σε όλα τα πηγαία αρχεία πλην των mvhist.c/mvhist.h (αυτά από αύριο).

 

Επίσης μόλις σήμερα παρατήρησα πως στο δικό μου fork, όταν είχα βάλει tag στο Version Bump commit το Github το πέρασε αυτόματα και στα Releases. Οπότε geomagas, μήπως πρέπει να κάνεις tag κι εσύ στο blessed master για να περάσει κι εκεί downloadable release;

Δημοσ.

Όταν κάνεις fetch ένα branch, από τη μάνα του το git σου φέρνει και όλες τις tags που δείχνουν στα objects που σου φέρνει.

 

Όταν όμως χρησιμοποιείς το UI του github δεν ξέρω τι διαδικασία γίνεται. Οι tags είναι πολύ σημαντικό θέμα ενός VCS οπότε υποθέτω πως σίγουρα το κάνει το github αλλά δεν το χρησιμοποιώ και δεν ξέρω πώς γίνεται.

 

Είναι δραστική αλλαγή οπότε δεν μπορώ να την προτείνω σε άλλους αλλά προσωπικά χρησιμοποιώ το github μόνο σαν hosting (και chat όταν χρειάζεται code review) facility. Οποιαδήποτε ενέργεια θέλω να κάνω την κάνω μέσω git και αν κάποια ενέργειά μου χρειάζεται να "επικοινωνήσει" με το github χρησιμοποιώ τα tokens που παρέχει. Αντί λοιπόν να κάνω κάτι merge από το ui του github, μπορώ να το κάνω από το git και απλά να γράψω στο τέλος του commit "fixes #42" και αυτόματα θα κλείσει το bug 42.

Δημοσ.

Ας υποθέσουμε ότι κάνω checkout και τα δύο, σε local copies (geomagas/2048cc και migf1/2048cc), αντιγράφω το migf1/2048cc/tags στο geomagas/2048cc και μετά κάνω commit, λες να πάει κάτι πολύ στραβα; (μπορώ να το τεστάρω φτιάχνοντας ένα dummy repo, αλλά είπα να ρωτήσω πρώτα)

 

BTW, χρησιμοποιώ svn από commandline.

 

---

 

Είπσης, δεν θα ήταν πιο σκόπιμο να βάλω πχ τον migf1 στους contributors ώστε να μη χρειάζεται να συντηρεί καν δικό του fork, αλλά να κάνει commit απ' ευθείας;

Δημοσ.
  Στις 19/7/2014 στις 10:35 ΠΜ, geomagas είπε

Είπσης, δεν θα ήταν πιο σκόπιμο να βάλω πχ τον migf1 στους contributors ώστε να μη χρειάζεται να συντηρεί καν δικό του fork, αλλά να κάνει commit απ' ευθείας;

Εφόσον δουλεύετε σε ξεχωριστά branches και δεν υπάρχει θέμα με conflicts και χαζομάρες, λογικό μου ακούγεται.

 

 

 

  Στις 19/7/2014 στις 10:35 ΠΜ, geomagas είπε

Ας υποθέσουμε ότι κάνω checkout και τα δύο, σε local copies (geomagas/2048cc και migf1/2048cc), αντιγράφω το migf1/2048cc/tags στο geomagas/2048cc και μετά κάνω commit, λες να πάει κάτι πολύ στραβα; (μπορώ να το τεστάρω φτιάχνοντας ένα dummy repo, αλλά είπα να ρωτήσω πρώτα)

 

BTW, χρησιμοποιώ svn από commandline.

Εφόσον έκανες clone, λογικά θα είναι στο .git/packed-refs αλλά δεν αντιγράφεις ποτέ έτσι χύμα το αρχείο. Κάνε fetch.

% for i in migf1 geomagas ; do
> git clone -v git://github.com/${i}/2048cc ${i}  
> done
Cloning into 'migf1'...
remote: Counting objects: 222, done.
remote: Compressing objects: 100% (112/112), done.
remote: Total 222 (delta 132), reused 179 (delta 108)
Receiving objects: 100% (222/222), 972.68 KiB | 282.00 KiB/s, done.
Resolving deltas: 100% (132/132), done.
Checking connectivity... done
Cloning into 'geomagas'...
remote: Counting objects: 221, done.
remote: Compressing objects: 100% (111/111), done.
remote: Total 221 (delta 132), reused 178 (delta 108)
Receiving objects: 100% (221/221), 972.54 KiB | 289.00 KiB/s, done.
Resolving deltas: 100% (132/132), done.
Checking connectivity... done

% cd geomagas 
% git fetch --tags -v ../migf1
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0)
Unpacking objects: 100% (1/1), done.
From ../migf1
 * [new tag]         v0.3a3     -> v0.3a3
Μετά κάνε push (με --tags για να είσαι σίγουρος) στο github και θα πρέπει να εμφανίζεται στις tags.

 

Στο παρόν repo δεν παίζει και τόσο ρόλο αλλά υπάρχει και πιο δόκιμη λύση.

% git clone -v git://github.com/geomagas/2048cc geomagas
Cloning into 'geomagas'...                                                
remote: Counting objects: 221, done.
remote: Compressing objects: 100% (111/111), done.
remote: Total 221 (delta 132), reused 178 (delta 108)
Receiving objects: 100% (221/221), 972.54 KiB | 467.00 KiB/s, done.
Resolving deltas: 100% (132/132), done.
Checking connectivity... done

% cd geomagas 
% git remote add migf1 git://github.com/migf1/2048cc.git
% git remote -v update
Fetching origin
From git://github.com/geomagas/2048cc
 = [up to date]      master     -> origin/master
Fetching migf1
remote: Counting objects: 1, done.
remote: Total 1 (delta 0), reused 1 (delta 0)
Unpacking objects: 100% (1/1), done.
From git://github.com/migf1/2048cc
 * [new branch]      master     -> migf1/master
 * [new tag]         v0.3a3     -> v0.3a3
% git remote rm migf1
Και έτσι έλαβες μόνο όσα objects δεν είχες (σε αυτή τη περίπτωση μόνο το tag) αντί να κατεβάσεις 2 φορές το σύνολο των objects.
Δημοσ.
  Αναφορά σε κείμενο

Ας υποθέσουμε ότι κάνω checkout και τα δύο, σε local copies (geomagas/2048cc και migf1/2048cc), αντιγράφω το migf1/2048cc/tags στο geomagas/2048cc και μετά κάνω commit, λες να πάει κάτι πολύ στραβα; (μπορώ να το τεστάρω φτιάχνοντας ένα dummy repo, αλλά είπα να ρωτήσω πρώτα)

 

Αν χρειάζεσαι μόνο κάποια συγκεκριμένα commits, τότε git cherry-pick hashvalue

 

  Αναφορά σε κείμενο

 

Είπσης, δεν θα ήταν πιο σκόπιμο να βάλω πχ τον migf1 στους contributors ώστε να μη χρειάζεται να συντηρεί καν δικό του fork, αλλά να κάνει commit απ' ευθείας;

Μπορείς φυσικά να τον προσθέσεις (δηλαδή να του δώσεις write privileges) αλλά αν θέλετε να έχετε code review, τότε ούτως η άλλως το development θα πρέπει να γίνεται σε ξεχωριστό branch. Μετά το ποιος θα κάνει το merge στο master (ή όποιο branch αποφασίσετε ότι θα είναι το stable) και πόσο pedantic θα είστε στους κανόνες που θα συμφωνήσετε, ε, αυτό ειναί απόφαση των devs :)

 

http://nvie.com/posts/a-successful-git-branching-model/

Δημοσ.
  Στις 19/7/2014 στις 10:50 ΠΜ, pmav99 είπε

Μπορείς φυσικά να τον προσθέσεις (δηλαδή να του δώσεις write privileges) αλλά αν θέλετε να έχετε code review, τότε ούτως η άλλως το development θα πρέπει να γίνεται σε ξεχωριστό branch. Μετά το ποιος θα κάνει το merge στο master (ή όποιο branch αποφασίσετε ότι θα είναι το stable) και πόσο pedantic θα είστε στους κανόνες που θα συμφωνήσετε, ε, αυτό ειναί απόφαση των devs :)

+1

 

  Στις 19/7/2014 στις 10:50 ΠΜ, pmav99 είπε

Για ένα project αυτού του βεληνεκούς (και λίγο μεγαλύτερου ακόμη) δεν είναι λίγο overkill το git-flow ? Ακόμη και το github που έχει 25-30 άτομα και πολύ πιο συνεχή και γρήγορη ανάπτυξη χρησιμοποιούν κάτι πολύ πιο απλό

Δημοσ.

@imitheos

Δεν διαβασα τώρα το link που παραθέτεις, αλλά νομίζω ότι το έχω διαβάσει παλιότερα, και αν θυμάμαι καλά αυτό που λέει είναι ότι όταν κάνεις deploy 50 φορές την ημέρα τότε φυσικά και δεν υπάρχει η έννοια του stable ή του release. Για αυτό και δεν μπορεί να δουλέψει το gitflow στο github ή στο twitter.

 

Από την άλλη όμως, και το blog που περιγράφει το git-flow αλλά και αυτό που περιγράφει το github-flow νομίζω ότι πρέπει να διαβαστoύν από όλους όσους ψάχνονται με DVCS workflows.

 

Έχω ένα φίλο πάντως που το χρησιμοποιεί στα πάντα και μου λέει ότι δεν υπάρχει θέμα. Απλά έχει και αυτό ένα initial learning curve (όπως και κάθε workflow άλλωστε), το οποίο όμως αν πρωτοξεκινάς με DVCS ανεβάζει και άλλο τον όγκο αυτών που πρέπει να μάθεις.

 

ΥΓ1. Για το git-flow υπάρχει επίσης και τo gitflow extension

ΥΓ2. Για το mercurial υπάρχει και το αντίστοιχο hg-flow extension

  • Like 1
Δημοσ.

Ευχαριστώ και τους δύο.

 

@imitheos, όταν κάνω git clone git://...., κατά το push μου λέει:

  You can't push to git://github.com/geomagas/2048cc.git
  Use https://github.com/geomagas/2048cc.git

Αν πάλι προσπαθήσω git clone https://..... δεν δουλεύει. Χάνω κάτι;

 

EDIT: Παράλειψη. Για το https παίρνω το url όπως το δίνει το github (κάτω δεξιά "HTTPS Clone url") και "δεν δουλεύει" σημαίνει ότι βγάζει "Cloning into ......." και μένει εκεί επ' άπειρον.

Δημοσ.
  Στις 19/7/2014 στις 12:37 ΜΜ, geomagas είπε

Ευχαριστώ και τους δύο.

 

@imitheos, όταν κάνω git clone git://...., κατά το push μου λέει:

  You can't push to git://github.com/geomagas/2048cc.git
  Use https://github.com/geomagas/2048cc.git
Αν πάλι προσπαθήσω git clone https://..... δεν δουλεύει. Χάνω κάτι;

 

Από συνήθεια κάνω πάντα clone με git:// γιατί χρησιμοποιώ ssh κλειδί για το push οπότε σε μπέρδεψα. Για να μην κάνεις ξανά clone με https:// άλλαξε το url.

% git remote -v set-url --push https://github.com/geomagas/2048cc.git
Μετά όταν κάνεις push θα σου ζητάει username και pass.

 

Αν για url δηλώσεις https://geomagas@github.com/κτλ τότε θα σου ζητάει μόνο pass κάθε φορά και αν δηλώσεις https://geomagas:pass@github.com/κτλ δεν θα σου ζητάει ούτε pass.

 

Το σκέτο set-url αλλάζει γενικά την url ενώ έτσι που στο έχω δώσει με την --push παράμετρο θα αλλάξει μόνο την push url οπότε θα κάνεις fetch μέσω git που είναι πιο γρήγορο / έξυπνο.

Δημιουργήστε ένα λογαριασμό ή συνδεθείτε για να σχολιάσετε

Πρέπει να είστε μέλος για να αφήσετε σχόλιο

Δημιουργία λογαριασμού

Εγγραφείτε με νέο λογαριασμό στην κοινότητα μας. Είναι πανεύκολο!

Δημιουργία νέου λογαριασμού

Σύνδεση

Έχετε ήδη λογαριασμό; Συνδεθείτε εδώ.

Συνδεθείτε τώρα

  • Δημιουργία νέου...