M-am uitat și pe cod și pe ce ai zis și totul sună bine și frumos toată treaba<br>e că trebuie să luăm totul cu încetul, până după EEA nu mă bag să fac o<br>evaluare. Am mai vorbit cu Mihai și ne-am decis să renunțăm la engine
<br>fizic pentru că mi-am dat seama că nu e nevoie de așa ceva. Și vreau să<br>pornim de la un core foarte simplu și foarte bine scris la care să legăm<br>module pe parcurs, deci da o să fie pe modelul MVC sigur. Din lista ta
<br>mai tot o să fie pus într-un modul și legat la un moment dat, dar trebuie<br>tot luat cu încetul, să văd ce mai faci tu și ce mai face Mihai și după<br>dacă merge totul bine cred că o să băgăm consola de debug real-time.
<br>(Care da inițial nu o să facă mai nimic pentru că nu are cu ce lucra <br>dar e bine să ne apucăm de ea și o facem bine structurată chiar dacă<br>o să mai fie modificată de n ori pe parcurs, pentru valori suficient de
<br>mari ale lui n)<br><br>Andrei<br><br>2008/1/22 Andrei Savu <<a href="mailto:savu.andrei@gmail.com">savu.andrei@gmail.com</a>>:<br>> Salut,<br>> <br>> Chiar e o problem cu partea de move. Cred ca cel mai bine
<br>> ar fi sa existe un task separat care sa determine reactulizarea modelului<br>> inainte de randare. Ar fi destul de usor de implementat. <br>> <br>> Task-ul de randare trebuie sa se declanseze doar in functie de un interval
<br>> de timp specificat ( odata la 1/30 sec sau mai repede ) pentru a lasa <br>> restul task-urilor sa functioneze pentru a putea simula ok procese continue <br>> si interactiuni complexe. <br>> <br>> O sa incerc sa rescriu codul cat de curand. O sa incerc sa implementez o
<br>> coada de prioritati pentru ordonarea task-urile si un sistem de comunicare intre <br>> task-uri mai bun. Cred ca este necesara si o clasa de baza pentru model.<br>> <br>> As vrea sa fac un test si cu OpenGL. Am avut o problema cu initializarea prima
<br>> data. Cred ca o sa gasesc o solutie acum.<br>> <br>> <br>> <br>> <br>> On 1/20/08, Alex Eftimie <<a href="mailto:alex@rosedu.org">alex@rosedu.org</a>> wrote:<br>> > 2008/1/20 Andrei Savu <
<a href="mailto:savu.andrei@gmail.com">savu.andrei@gmail.com</a>>:<br>> > > Salut,<br>> > ><br>> > > Asa cum discutasem la ultima intalnire am implementat o versiune a buclei<br>> > > principale asa cum o vad eu.
<br>> > > Cred ca o arhitectura MVC se potriveste perfect in aceasta situatie pentru<br>> > > ca permita separarea foarte<br>> > > buna intre codul de logica a jocului, codul de tratare de intrari si codul
<br>> > > de randare. <br>> > ><br>> > > Implementarea mea se bazeaza pe ideea ca un joc este o aplicatie care poate<br>> > > fi impartita intr-o<br>> > > serie de task-uri care trebuie sa isi desfasoarea activitatea repetitiv si
<br>> > > intr-o anumita ordine. <br>> > ><br>> > > Daca privim lucrurile din aceasta perspectiva atunci devine clar ca bucla<br>> > > principala trebuie sa implementeze<br>> > > doar partea de comutare de task-uri. Separarea face posibila dezvoltarea in
<br>> > > mod independent a componentelor.<br>> > ><br>> > > Codul trimis este experimental si trebuie mult imbunatatit in ceea ce<br>> > > priveste lista de task-urilor si modul cum<br>
> > > acestea pot interactiona intre ele ( trebuie implementat un sistem de mesaje <br>> > > ).<br>> > ><br>> > > Pentru demonstrarea conceptului am adaptat codul scris de Alex Eftimie<br>
> > > pentru jocul de snake.<br>> > ><br>> > > Pentru construirea engine-ului o sa fie in continuare nevoie de o baza<br>> > > solida de clase pentru: <br>> > > - definirea unui set de clase pentru stocarea primitivelor din joc
<br>> > > - definirea unui set de clase pentru gestionarea spatiului virtual (<br>> > > partitionarea spatiului, LOD, incarcare dinamica de obiecte etc. ) <br>> > > - definirea unui set de clase pentru cinematica ( matematica si pattern
<br>> > > based )<br>> > > - definirea unui set de clase pentru elemente de interfata cu utilizatorul<br>> > > - definirea nivelelor de abstractizare necesare peste pyopengl <br>> > > - definirea unui set de clase pentru gestionarea input-ului ( tastatura
<br>> > > mouse, file based - pentru demo, poate si networking )<br>> > > - sistem de logging ( ar fi super cu facilitati remote pentru depanare <br>> > > realtime )<br>> > > - si multe altele ...
<br>> > ><br>> > > Asta sunt cateva dintre ideile care imi vin la ora asta. Evident ca toate<br>> > > astea si multe altele trebuie trecute pe hartie ( sau pe wiki )<br>> > > dezbatute si eliminate cat de mult se poate pana cand se ajunge la cerintele
<br>> > > pentru versiunea 1.0.<br>> > ><br>> > > Astept sa aud parerea voastra.<br>> > ><br>> > > Bafta in sesiune.<br>> > ><br>> > > --<br>> > > <a href="http://www.youmago.ro/">
http://www.youmago.ro/</a> - Descopera. Adauga. Compara. <br>> > > "Set your goals high, and don't stop till you get there." Bo Jackson<br>> > <br>> > Prea tare. Totusi, ce mi se pare mai putin intuitiv este ca "logica
<br>> > jocului", adica SnakeGame.move se face in SnakeInput. <br>> > In rest e genial... se vad clar avantajele limbajului: definirea unui<br>> > nucleu cu taskuri care sunt chiar threaduri. Imi place.
<br>> > <br>> > Alex<br>> > <br>> > --<br>> > Alex Eftimie<br>> > <a href="http://anaconda.cs.pub.ro/~alexef/">http://anaconda.cs.pub.ro/~alexef/</a> <br>> > _______________________________________________
<br>> > hfall-dev mailing list<br>> > <a href="mailto:hfall-dev@lists.rosedu.org">hfall-dev@lists.rosedu.org</a><br>> > <a href="http://lists.rosedu.org/cgi-bin/mailman/listinfo/hfall-dev">http://lists.rosedu.org/cgi-bin/mailman/listinfo/hfall-dev
</a><br>> > <br>> <br>> <br>> <br>> -- <br>> <br>> <br>> <br>> <a href="http://www.youmago.ro/">http://www.youmago.ro/</a> - Descopera. Adauga. Compara.<br>> "Set your goals high, and don't stop till you get there." Bo Jackson
<br>> _______________________________________________<br>> hfall-dev mailing list<br>> <a href="mailto:hfall-dev@lists.rosedu.org">hfall-dev@lists.rosedu.org</a><br>> <a href="http://lists.rosedu.org/cgi-bin/mailman/listinfo/hfall-dev">
http://lists.rosedu.org/cgi-bin/mailman/listinfo/hfall-dev</a><br>> <br><br>