Show page

Differences

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

--- pm:prj2025:rnedelcu:vconstantinescu2109 [2025/05/28 13:08]
vconstantinescu2109 [Hardware Design]
+++ pm:prj2025:rnedelcu:vconstantinescu2109 [2025/05/28 15:23] (current)
vconstantinescu2109 [Bibliografie/Resurse]
@@ Line 138: / Line 138: @@
 . Galerie Proiect
-{{:pm:prj2025:rnedelcu:vconstantinescu2109:img_20250513_092714.jpg?300|}}
+{{:pm:prj2025:rnedelcu:vconstantinescu2109:whatsapp_image_2025-05-28_at_13.04.34.jpeg?300|}}
+{{:pm:prj2025:rnedelcu:vconstantinescu2109:whatsapp_image_2025-05-28_at_13.05.21.jpeg?300|}}
 {{:pm:prj2025:rnedelcu:vconstantinescu2109:whatsapp_image_2025-05-28_at_13.05.21_1_.jpeg?300|}}
-{{:pm:prj2025:rnedelcu:vconstantinescu2109:img_20250513_092707.jpg?300|}}
 ===== Software Design =====
-<note tip>
 Descrierea codului aplicaţiei (firmware):
   * mediu de dezvoltare (Arduino)
-  * Voi analiza codul pentru a explica implementarea software a proiectului conform cerințelor. Mai întâi, să vedem ce fișiere avem în proiect.
-  * 1. Stadiul Actual al Implementării Software
-Proiectul este implementat ca un sistem de gaming portabil cu următoarele componente principale:
 **Meniu Principal (`menu/`):**
 - Implementat folosind Arduino și un display OLED SSD1306
@@ Line 161: / 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.
+. **Optimizari**:
+   - Debouncing software pentru butoane – elimină dublările de input
+   - 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
+**Î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.
+. Structură cu 4 fișiere separate: Meniu + 3 jocuri independente
+Descriere:
+Fiecare joc era implementat într-un fișier .ino separat.
+Meniul principal era, de asemenea, un sketch separat.
+Se trecea manual din IDE între fișiere pentru a compila și încărca un joc anume.
+Avantaje:
+Codul era clar compartimentat și ușor de gestionat.
+Fiecare fișier se compila fără erori, separat.
+Limitări:
+Nu exista o tranziție reală între meniu și jocuri — doar testare individuală.
+Nu permitea rularea unui singur firmware complet, ceea ce era un dezavantaj pentru experiența utilizatorului.
+Încărcarea manuală era nepractică pentru un proiect final funcțional.
+. Integrarea Meniului cu un joc + celelalte două separate
+Descriere:
+Meniul principal era integrat într-un sketch împreună cu unul dintre jocuri.
+Celelalte două jocuri rămâneau în fișiere separate.
+Se testa funcționalitatea meniului și a tranziției către un joc.
+Avantaje:
+Permitea testarea logicii de selecție și tranziție între meniu și un joc real.
+A demonstrat că este posibilă integrarea parțială într-un singur fișier.
+Limitări:
+Limitări de memorie au apărut deja la adăugarea unui singur joc complet.
+Includerea tuturor celor 3 jocuri în același sketch devenea imposibilă pe Arduino Uno din cauza spațiului limitat de flash și RAM.
+. Integrarea completă într-un singur sketch (Eșec)
+Descriere:
+S-a încercat integrarea meniului și a celor 3 jocuri într-un singur fișier .ino.
+Codul menținea un state machine (enum sau variabilă) care comuta între stări: meniu / joc1 / joc2 / joc3.
+Se folosea Adafruit_GFX + Adafruit_SSD1306 pentru randarea pe ecran.
+Probleme întâlnite:
+La un anumit punct, ecranul OLED nu mai răspundea deloc.
+După debugging, s-a constatat că librăria Adafruit_SSD1306 bloca execuția în cazul în care primea prea multe apeluri către display() într-un sketch foarte mare.
+Consumul de RAM era aproape de 100% ⇒ crăpări ale programului.
+S-a încercat trecerea la U8g2 (bibliotecă mai stabilă și mai versatilă), însă:
+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)
+Idee:
+Deoarece memoria internă era insuficientă, s-a încercat o soluție „avansată” de a stoca fișiere .ino sau binare pe SD card și a le încărca dinamic (ca bootloader sau loader extern).
+Ce s-a făcut:
+Integrarea cardului SD și implementarea funcției SD.begin() și a citirii de fișiere binare.
+Încercarea de a scrie un bootloader simplificat care să detecteze și să ruleze un fișier .bin sau .hex de pe card.
+Rezultat:
+Arduino Uno nu suportă execuția dinamică de cod din memorie externă.
+Nu există suport nativ pentru „self-reprogramming” din sketch user-space.
+Soluția ar necesita un bootloader scris la nivel de AVR (în afara Arduino IDE), prea complex pentru constrângerile proiectului.
+Concluzie
+Cea mai viabilă soluție:
+Se păstrează meniu + un singur joc într-un sketch, iar celelalte se încarcă manual pentru demonstrație.
+Motive:
+Limitele de RAM și flash pe Arduino Uno.
+Conflictele între librării (în special Adafruit vs SD vs U8g2).
+Ecranul OLED devine instabil la coduri mari.
+Necesitatea unei interfețe clare pentru testare și prezentare.
-* 2. Biblioteci Folosite și Motivația Alegerii
+**Biblioteci Folosite și Motivația Alegerii**
-. **Adafruit_GFX și Adafruit_SSD1306:**
+{{:pm:prj2025:rnedelcu:vconstantinescu2109:screenshot_2025-05-28_144931.png?300|}}
-   - 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:**
+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.
-   - Motivație: Necesară pentru comunicarea I2C cu display-ul
-   - Facilități: Implementare standard pentru comunicare serială
-* 3. Elementul de Noutate
+**Elementul de Noutate**
 Elementul de noutate al proiectului constă în:
@@ Line 195: / 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 231: / 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.
+===== Concluzii =====
-</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 255: / 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>