Show page

Differences

This shows you the differences between two versions of the page.

--- pm:prj2025:rnedelcu:vconstantinescu2109 [2025/05/28 14:18]
vconstantinescu2109 [Software Design]
+++ pm:prj2025:rnedelcu:vconstantinescu2109 [2025/05/28 15:23] (current)
vconstantinescu2109 [Bibliografie/Resurse]
@@ Line 147: / Line 147: @@
 ===== Software Design =====
-<note tip>
 Descrierea codului aplicaţiei (firmware):
   * mediu de dezvoltare (Arduino)
@@ Line 159: / Line 157: @@
 **Cele Trei Jocuri:**
 . **Joc1 (Super Mario):**
    - Implementare 2D a unui joc de platformă
    - Controlul personajului prin D-pad
    - Sistem de coliziuni și fizică simplă
+   - Terenul este generat procedural pe măsură ce jucătorul avansează. Acest lucru este evident din mai multe componente cheie:
+        Terenul este stocat într-un buffer circular (vector) numit terrainHeights cu o dimensiune de TERRAIN_SIZE:
+        Pe măsură ce jucătorul se mișcă înainte, noi blocuri de teren sunt generate în timp real prin funcția advanceTerrainWindowForward():
+        Generarea terenului este gestionată de generateNextBlockHeight() care creează modele variate de teren, inclusiv:
+        Găuri (spații goale)
+        Platforme
+        Trepte (sus și jos)
+        Secțiuni plate
+        Sistemul folosește o abordare de tip fereastră unde:
+        Doar o porțiune din teren este păstrată în memorie
+        Terenul vechi este eliminat pe măsură ce se generează teren nou
+        Terenul se înfășoară folosind aritmetica modulo pentru a menține buffer-ul circular
+        Generarea terenului este randomizată dar urmează anumite modele pentru a asigura jucabilitatea:
+        Menține o diferență maximă de înălțime
+        Creează găuri de diferite dimensiuni
+        Generează platforme la anumite înălțimi
+        Creează modele de trepte care urcă și coboară
+  - Coliziunile se bazează pe verificarea poziției pixelilor: Dacă jucătorul atinge un bloc (1), mișcarea este oprită. Coliziunile sunt implementate pentru sus/jos/stânga/dreapta și pentru detecția solului. Sistemul previne „căderea prin sol” și permite sărituri doar dacă  jucătorul se află pe o platformă.
+  - Mișcare: Jucătorul are viteză verticală și orizontală. Se aplică gravitație (un număr constant adunat la viteza verticală). Săriturile sunt limitate la o durată sau înălțime maximă.
 . **Joc2 (Space Invaders):**
-   - Joc de tip shoot'em up
-   - Sistem de proiectile și inamici
    - Sistem de scor
+   - Sistem de inamici: Inamicii sunt aranjați în rânduri, fiecare inamic fiind un obiect cu coordonate și stare (activ/inactiv). Se deplasează de la stânga la dreapta în sincron. Dacă un inamic ajunge la margine, toți coboară cu o linie și schimbă direcția.
+   - Sistem de proiectile: Proiectilele sunt stocate într-un array de obiecte active. La apăsarea butonului A, se creează un nou glonț cu poziția curentă a jucătorului. Se verifică coliziunile între proiectile și inamici. Dacă o coliziune este detectată, inamicul și glonțul dispar, iar scorul crește.
+   - Boss: După distrugerea unui număr de inamici, apare un inamic special ("boss"). Are viață mai mare și se mișcă independent. Necesită mai multe proiectile pentru a fi distrus.
 . **Joc3 (Breakout):**
-   - Joc de tip arcade cu mingie și paletă
+   - Scop: Jucătorul controlează o paletă care lovește o minge cu scopul de a distruge blocurile de sus.
    - Sistem de blocuri distructibile
-   - Fizică pentru mișcarea mingii
+   - Fizică pentru mișcarea mingii: Mingea are o velocitate (vx, vy) și poziție (x, y). Se deplasează la fiecare ciclu de joc, iar direcția se schimbă la coliziune: Cu margini → inversare vx, Cu tavan → inversare vy, Cu paleta → inversare vy și modificare dx în funcție de locul lovirii, Cu blocuri → inversare dy și eliminarea blocului
+   - Blocuri distructibile: Reprezentate ca o matrice de 1 și 0. La coliziune, blocul devine 0 și mingea își schimbă direcția.
+   - Multiplicare bile (power-up): După un scor atins sau după lovirea unui bloc special, se adaugă o a doua minge în joc. Fiecare minge este gestionată independent (poziție, coliziune, fizică). Se adaugă provocare și complexitate în gameplay.
-🎮 Descrierea jocurilor implementate
+. **Optimizari**:
-🧱 1. Super Mario (Platformer 2D)
-Scop: Jucătorul controlează un personaj care sare peste obstacole și colectează puncte, într-un nivel 2D generat simplificat.
-🔧 Generare de teren:
+   - Debouncing software pentru butoane – elimină dublările de input
-Terenul este stocat ca o hartă în memorie sub formă de matrice bidimensională de 0 și 1.
+   - Reducerea consumului RAM: Folosirea tipurilor PROGMEM pentru texte constante, Eliminarea bitmapurilor mari sau nefolosite, Reducerea dimensiunii codului (Cod modular, fără duplicări), Separare clară între logică, randare și input, Ajustarea frecvenței PWM pentru sunete mai clare la buzzer
-= bloc solid (platformă, obstacol)
-= aer (spațiu liber)
+**Încercările de Integrare Software a Meniului și Jocurilor**
-Terenul este generat static (hardcodat) pentru a reduce consumul de RAM.
+Pentru a aduce toate componentele proiectului împreună – meniul principal și cele 3 jocuri – au fost testate trei soluții majore de structurare software. Fiecare variantă a venit cu avantaje și limitări, iar mai jos sunt explicate pe rând.
-Se folosește un sistem de scrolling orizontal, unde doar o parte din hartă este afișată, iar restul este mutat pe ecran în funcție de poziția jucătorului (pseudo-generare procedurală).
-🎯 Coliziuni:
-Coliziunile se bazează pe verificarea poziției pixelilor:
-Dacă jucătorul atinge un bloc (1), mișcarea este oprită.
-Coliziunile sunt implementate pentru sus/jos/stânga/dreapta și pentru detecția solului.
-Sistemul previne „căderea prin sol” și permite sărituri doar dacă jucătorul se află pe o platformă.
-🏃‍♂️ Mișcare:
-Jucătorul are viteză verticală și orizontală.
-Se aplică gravitație (un număr constant adunat la viteza verticală).
-Săriturile sunt limitate la o durată sau înălțime maximă.
-👾 2. Space Invaders (Shoot’em up)
-Scop: Jucătorul controlează o navă care trage în inamici ce se apropie din partea superioară a ecranului.
-🧨 Sistem de inamici:
-Inamicii sunt aranjați în rânduri, fiecare inamic fiind un obiect cu coordonate și stare (activ/inactiv).
-Se deplasează de la stânga la dreapta în sincron.
-Dacă un inamic ajunge la margine, toți coboară cu o linie și schimbă direcția.
-🔫 Sistem de proiectile:
-Proiectilele sunt stocate într-un array de obiecte active.
-La apăsarea butonului A, se creează un nou glonț cu poziția curentă a jucătorului.
-Se verifică coliziunile între proiectile și inamici.
-Dacă o coliziune este detectată, inamicul și glonțul dispar, iar scorul crește.
-🧠 Boss:
-După distrugerea unui număr de inamici, apare un inamic special ("boss").
-Are viață mai mare și se mișcă independent.
-Necesită mai multe proiectile pentru a fi distrus.
-🔴 3. Breakout (Joc cu paletă și minge)
-Scop: Jucătorul controlează o paletă care lovește o minge cu scopul de a distruge blocurile de sus.
-⚽ Fizica mingii:
-Mingea are o direcție (dx, dy) și poziție (x, y).
-Se deplasează la fiecare ciclu de joc, iar direcția se schimbă la coliziune:
-Cu margini → inversare dx
-Cu tavan → inversare dy
-Cu paleta → inversare dy și modificare dx în funcție de locul lovirii
-Cu blocuri → inversare dy și eliminarea blocului
-🧱 Blocuri distructibile:
-Reprezentate ca o matrice de 1 și 0:
-= bloc prezent
-= bloc distrus
-La coliziune, blocul devine 0 și mingea își schimbă direcția.
-🔁 Multiplicare bile (power-up):
-După un scor atins sau după lovirea unui bloc special, se adaugă o a doua minge în joc.
-Fiecare minge este gestionată independent (poziție, coliziune, fizică).
-Se adaugă provocare și complexitate în gameplay.
-🧩 Concluzie
-Toate cele trei jocuri:
-Folosesc același motor de randare pe OLED
-Împart aceeași logică de butoane
-Se bazează pe principii simple de coliziune (bounding box/punct)
-Au fost scrise cu eficiență în memorie și procesare în minte
-Dacă dorești, pot genera și diagramele pentru logica fiecărui joc sau pseudocodurile implementărilor de coliziuni și mișcare. Vrei să adaug și secțiunea despre modul de testare și debugging?
-You said:
-Acum descrie cele 3 implementari incercate pentru a aduce totul impreuna: 1. 4 Fisiere separate (meniu + jocuri) 2. Meniu + 1 joc si 2 jocuri separate 3.Intregare intr-un singur fisier ( fara succes din cauza spatiului si a librariei adafruit care bloca ecranul la prea multe cereri de display => biblioteca u8g2 far success consum ram prea mare => incercare bootloader de pe card sd fara success de bootare
-ChatGPT said:
-Excelent! Iată o descriere clară, structurată și argumentată a celor trei încercări de integrare software ale proiectului tău. Poți include acest text în documentația pentru Milestone 3 sau pe GitHub în secțiunea de „Stadiu implementare software / Decizii de proiectare”.
-🔄 Încercările de Integrare Software a Meniului și Jocurilor
-Pentru a aduce toate componentele proiectului împreună – meniul principal și cele 3 jocuri – au fost testate trei soluții majore de structurare software. Fiecare variantă a venit cu avantaje și limitări, iar mai jos sunt explicate pe rând.
-🧩 1. Structură cu 4 fișiere separate: Meniu + 3 jocuri independente
+. Structură cu 4 fișiere separate: Meniu + 3 jocuri independente
 Descriere:
@@ Line 315: / Line 232: @@
 Încărcarea manuală era nepractică pentru un proiect final funcțional.
-🔗 2. Integrarea Meniului cu un joc + celelalte două separate
+. Integrarea Meniului cu un joc + celelalte două separate
 Descriere:
@@ Line 336: / Line 253: @@
 Includerea tuturor celor 3 jocuri în același sketch devenea imposibilă pe Arduino Uno din cauza spațiului limitat de flash și RAM.
-🧨 3. Integrarea completă într-un singur sketch (Eșec)
+. Integrarea completă într-un singur sketch (Eșec)
 Descriere:
@@ Line 357: / Line 274: @@
 U8g2 folosește mai mult RAM și nu era sustenabil pe Arduino Uno pentru proiectul complet.
-💾 Încercare finală: Boot de pe SD Card (Eșec)
+. Încercare finală: Boot de pe SD Card (Eșec)
 Idee:
@@ Line 376: / Line 293: @@
 Soluția ar necesita un bootloader scris la nivel de AVR (în afara Arduino IDE), prea complex pentru constrângerile proiectului.
-📌 Concluzie
+Concluzie
 Cea mai viabilă soluție:
@@ Line 391: / Line 309: @@
 Necesitatea unei interfețe clare pentru testare și prezentare.
-Dacă vrei, pot structura și fișierele tale .ino într-un folder cu meniu + loader minimal pentru demo, sau să generăm un meniu care indică doar ce jocuri există și cum pot fi accesate. Vrei și o diagramă logică a acestor încercări de integrare?
+**Biblioteci Folosite și Motivația Alegerii**
+{{:pm:prj2025:rnedelcu:vconstantinescu2109:screenshot_2025-05-28_144931.png?300|}}
+Alegerea acestor biblioteci a fost dictată de compatibilitatea cu platforma Arduino Uno și dimensiunea restrânsă a memoriei flash (32 KB). Toate bibliotecile sunt bine întreținute și documentate.
+**Elementul de Noutate**
-Tools
-* 2. Biblioteci Folosite și Motivația Alegerii
-. **Adafruit_GFX și Adafruit_SSD1306:**
-   - Motivație: Oferă suport nativ pentru display-ul OLED
-   - Facilități: Funcții de desenare optimizate, suport pentru fonturi
-   - Performanță: Optimizată pentru microcontrolere
-. **Wire.h:**
-   - Motivație: Necesară pentru comunicarea I2C cu display-ul
-   - Facilități: Implementare standard pentru comunicare serială
-* 3. Elementul de Noutate
 Elementul de noutate al proiectului constă în:
@@ Line 426: / Line 323: @@
 - Adaptarea jocurilor pentru un display OLED de dimensiuni reduse
-* 4. Utilizarea Funcționalităților din Laborator
+**Utilizarea Funcționalităților din Laborator**
 Funcționalitățile din laborator sunt utilizate în următoarele moduri:
@@ Line 462: / Line 359: @@
 Proiectul demonstrează o implementare software robustă care integrează multiple jocuri într-un sistem portabil. Arhitectura modulară permite ușoara adăugare de noi jocuri sau funcționalități. Sistemul de meniu oferă o experiență de utilizare intuitivă, iar implementarea hardware-ului este optimizată pentru performanță pe platforma Arduino.
-</note>
-DE FACUT: Implementat uniform codul pentru a nu mai avea module si sa fie totul deodata
 ===== Rezultate Obţinute =====
-<note tip>
+Mai multe versiuni ale aceleasi idei care se complimenteaza in complexitatea proiectului si inoperabilitatea completa a lui
-Care au fost rezultatele obţinute în urma realizării proiectului vostru.
-</note>
 ===== Concluzii =====
+O experienta interesanta dar nu as mai repetea-o, doar cu un proiect mai simplu
 ===== Download =====
 <note warning>
-O arhivă (sau mai multe dacă este cazul) cu fişierele obţinute în urma realizării proiectului: surse, scheme, etc. Un fişier README, un ChangeLog, un script de compilare şi copiere automată pe uC crează întotdeauna o impresie bună ;-).
-Fişierele se încarcă pe wiki folosind facilitatea **Add Images or other files**. Namespace-ul în care se încarcă fişierele este de tipul **:pm:prj20??:c?** sau **:pm:prj20??:c?:nume_student** (dacă este cazul). **Exemplu:** Dumitru Alin, 331CC -> **:pm:prj2009:cc:dumitru_alin**.
+Am atasat arhiva cu toate implementarile facute in stadiul lor dinaintea prezentarii
+{{:pm:prj2025:rnedelcu:vconstantinescu2109:gameboy-all-versions.zip|}}
 </note>
@@ Line 486: / Line 380: @@
 <note tip>
-Puteți avea și o secțiune de jurnal în care să poată urmări asistentul de proiect progresul proiectului.
+Draga jurnalule, am lucrat peste 40 de ore dar nu zilnic ci cumulat
 </note>
-===== Bibliografie/Resurse =====
+=====  =====
-<note>
-Listă cu documente, datasheet-uri, resurse Internet folosite, eventual grupate pe **Resurse Software** şi **Resurse Hardware**.
-</note>
 <html><a class="media mediafile mf_pdf" href="?do=export_pdf">Export to PDF</a></html>