Suchergebnisse
Suchergebnisse 1-14 von insgesamt 14.
Wieder 100% Systemleistung, aber eine feste Framrate, was ich eig nicht unbedingt wollte... Ich glaube ich gebe es einfach auf...
Hm das warum hab ich ja noch dazu editiert. Die Lösung mit den Threads klingt interessant. Wie genau sollte ich das dann machen?
Das kann doch wohl nicht die einzige Lösung sein, oder? Wie ich im 1. Post schon sagte, würde ich gerne auf Sleep() verzichten (Wenn der Nutzer genau in einem "falschen" Moment (der Moment an dem gesleept wird) eine Taste nur kurz drückt wird dies nicht erkannt. Außerdem kommt es einem durch Sleep sowieso schon so vor, als wäre die Steuerung träge, da die Wahrscheinlichkeit den Sleepmoment zu erwischen viel höher ist, als diesen aben nicht zu erwischen)
Hab ja gesagt, dass das nicht funktionieren kann... Das funktioniert ja eigentlich nur bei WinAPI GUIs die auf eine Nutzereingabe warten sollen... Bin nur schon so verzweifelt, dass ich alles durchprobiere. Bei deiner Lösung war es ja auch wieder ne Dauerschleife, was automatisch 100% Auslastung bedeutet (oder nicht?)
Das hatte ich doch gemacht und es hat trotzdem 100% verbraucht... Habe nun etwas gefunden, was jedoch nicht die Lösung sien kann, da die Steine nun nicht mehr regelmäßig runterkommen (ist auch klar warum): 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 while (GetMessage(&msg, NULL, 0, 0)) { TranslateMessage(&msg); DispatchMessage(&msg); if((SDL_GetTicks()-tick)/speed>=0.1){ tick=SDL_GetTicks(); if(spielfeld.check_valid(&m_block_now->klotz[0][0], m_block_now->x, (...
Den Code ab frame.Update() habe ich auch in die if gepackt, die Auslastung war trotzdem bei 100% Die else-Anweisung läuft einfach dauerhaft durch, denn auch wenn gar nichts in der else steht, ist die Auslastung bei 100%
Jetzt hab ich meine Schleife so: 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 while(msg.message != WM_QUIT) { if(PeekMessage( &msg, 0, 0, 0, PM_REMOVE )) { TranslateMessage( &msg ); DispatchMessage( &msg ); } else { if((SDL_GetTicks()-tick)/speed>=0.1){ tick=SDL_GetTicks(); if(spielfeld.check_valid(&m_block_now->klotz[0][0], m_block_now->x, ((m_block_now->y)+1), true)&&(m_block_now->y < 20)) { m_block_now->y+=1; } else { s...
Oh :-D Das nächste mal genauer lesen. Tut mir leid
In der Schule benutzen wir auch noch 6.0 und haben damit keinerlei Probleme... Deswegen denke ich, dass es auch daran liegen könnte. Kommt ja imer darauf an, was man kompilieren möchte.
Könntest du mir denn vllt ein kleines Codebeispiel dazu geben? Finde im Netz nicht so wirklich was, was auf meinen Fall passt... Ich verstehe einfach nur nicht wie das ganze die Prozessorleistung reduzieren soll, da ich ja immernoch in einer Dauerschleife bleiben muss, um zu wissen wann der Stein ein Stück runter muss. Tut mir leid wenn ich grade zu dumm bin um das zu verstehen :-D
Vielleicht liegt es aber auch am Code...
So weit ich weiß, wartet PeekMessage doch so lange bis eine Eingabe vom Nutzer kommt, oder nicht? Denn das wäre nicht gut, da der Stein ja nach einer Weile automatisch runter kommen soll.
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 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 while(done==0) { if(frame.KeyDown(SDLK_ESCAPE)) { done=1; } if(frame.KeyDown(SDLK_UP)) { if((SDL_GetTicks()-last)/250>=0.1){ if(spielfeld.check_valid(m_block_now->get_next(), m_block_now->x, m_block_now->y, false...
Hallo. Ich habe mein erstes Spiel mit der SDL und C++ fast schon fertig. Es ist ein Tetrisklon. Nun habe ich jedoch eine Frage: Da der Spielablauf in einer Dauerschleife abläuft, ist auch die Prozessorauslastung dauerhaft auf 100%. Wie kann man das vermeiden? Denn so viel Rechenleistung wird nun wirklich nicht für ein Tetris gebraucht. Mir kam schon die Idee den Windowsspezifischen Befehl "Sleep()" zu benutzen, was jedoch bedeuten würde, dass es zu Verzögerungen in der Erkennung der Eingaben des...
14.05.2024, 02:06
Zum Seitenanfang
