Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

1

04.12.2011, 16:13

Textur bewegen lassen

Hallo zusammen!

Ich habe eine Übungsaufgabe zum Breakanoid Spiel bekommen. Wir sollen die Textur im Intro-Bildschirm entlang eines imaginären Rechtsecks bewegen. Dazu muss ich wahrscheinlich innerhalb der intro.cpp die Zeilen 130-133 bearbeiten, richtig?

Mir fehlt leider grade ein Ansatzpunkt wie ich da am besten vorgehe ?(
Ich muss ja den X Wert aller 4 Vertizes gleichmäßig erhöhen, bis zu einer bestimmten Grenze. Dann den Y Wert bis zu einer bestimmten Grenze. Dann X wieder um den gleichen Wert verringen wie er vorher erhöht wurde und dann das gleiche mit Y. Geht das auch irgendwie per Abkürzung?

Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von »-Ricken-« (04.12.2011, 16:20)


David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

2

04.12.2011, 17:19

Darf ich fragen, in welchem Zusammenhang du/ihr diese Aufgabe bekommen hast/habt?

3

04.12.2011, 17:43

Als sowas wie ein "Checkpoint" ob alle soweit ihre Materialien installiert und funktionsfähig am laufen haben.

Habe es jetzt mal mit einer switch Anweisung versucht, aber dadurch erhalte ich nur eine andauernde Bewegung nach Links.

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
        // Texturkoordinaten verschieben 
    for(DWORD dwVertex = 0; dwVertex < 4; dwVertex++)
    {
   switch(tb_phase)
    {
   case 0:
       if (aVertex[3].vTex0.x<2.0f) aVertex[dwVertex].vTex0.x -= (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       else tb_phase=1;
       break;
   case 1:
       if (aVertex[dwVertex].vTex0.y<0.0f) aVertex[dwVertex].vTex0.y -= (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       else tb_phase=2;
       break;
   case 2:
       if (aVertex[dwVertex].vTex0.x>2.0f) aVertex[dwVertex].vTex0.x += (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       else tb_phase=3;
       break;
   case 3:
       if (aVertex[dwVertex].vTex0.y>0.0f) aVertex[dwVertex].vTex0.y += (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       else tb_phase=0;
       break;
    }
                
    }


Scheinbar wird also aVertex[3].vTex0.x nie größer. Aber ich dachte dass durch veränderung der Koordinaten erst die sichtbare Bewegung entsteht?!

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

4

04.12.2011, 18:20

Da Du alle 4 Cases nacheinander durchläuft, rechnet sich das alles direkt zu +-0. Da kann also nix passieren.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

5

04.12.2011, 18:27

Okay, Fehler erkannt. Ich habe mir jetzt 2 Hilfsvariablen moveX und moveY erschaffen und zumindest die Bewegungsrichtung- und abfolge stimmt schonmal.
Allerdings "springt" das Bild beim Wechsel von eienr Phase in die nächste immer ein Stück, so dass die Bewegung insgesamt noch sehr unrund ist. Jemand ne Idee?

C-/C++-Quelltext

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
for(DWORD dwVertex = 0; dwVertex < 4; dwVertex++)
    {
   switch(tb_phase)
    {
   case 0:
       if (moveX<400) 
       {
       aVertex[dwVertex].vTex0.x -= (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       moveX++;
       }
       else tb_phase=1;
       break;
   case 1:
       if (moveY<400) 
       {
       aVertex[dwVertex].vTex0.y -= (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       moveY++;
       }
       else tb_phase=2;
       break;
   case 2:
       if (moveX>0) 
       {
       aVertex[dwVertex].vTex0.x += (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       moveX--;
       }
       else tb_phase=3;
       break;
   case 3:
       if (moveY>0) 
       {
       aVertex[dwVertex].vTex0.y += (g_pBreakanoid->m_fTime + (float)(dwVertex)) * 0.01f;
       moveY--;
       }
       else tb_phase=0;
       break;
    }
                
    }

6

05.12.2011, 11:42

Hat niemand eine Idee? So sieht das noch ziemlich unschön aus...

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

7

05.12.2011, 12:32

Weiß nicht. Auf jeden Fall ist es noch immer falsch, dass Du die tb_phase innerhalb der Schleife änderst. Du musst erst alle Vertices ändern und danach die Phase umschalten, sonst befinden sich während der Schleife verschiedene Vertices in verschiedenen Phasen.
Außerdem änderst Du auf diese Art Deine moveX und moveY Variablen 4mal pro Update, nämlich einmal pro Schleifendurchlauf. Das ist sicher auch nicht so gedacht.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

8

05.12.2011, 17:09

Letzteres ist mir auch schon aufgefallen und ich glaube dass das auch der Grund für den Fehler ist. Mir fehlt allerdings eien Idee wie ich das geschickter lösen kann :(
tb_phase wird ja erst geändert wenn moveX bzw. moveY einen bestimmten Wert haben. Bis dahin wurden doch alle Vertizes schon verändert.

BlueCobold

Community-Fossil

Beiträge: 10 738

Beruf: Teamleiter Mobile Applikationen & Senior Software Engineer

  • Private Nachricht senden

9

05.12.2011, 18:10

Nein, wurden sie eben nicht. Falls sie es wurden, dann ist das Zufall, weil die Breite und Höhe ein Vielfaches von 4 sind. Dennoch ist es falsch.
Teamleiter von Rickety Racquet (ehemals das "Foren-Projekt") und von Marble Theory

Willkommen auf SPPRO, auch dir wird man zu Unity oder zur Unreal-Engine raten, ganz bestimmt.[/Sarkasmus]

David Scherfgen

Administrator

Beiträge: 10 382

Wohnort: Hildesheim

Beruf: Wissenschaftlicher Mitarbeiter

  • Private Nachricht senden

10

05.12.2011, 19:05

Du benutzt m_fTime wie ein "Delta T", ist es aber nicht!

Werbeanzeige