| |
|
|
Walter Köhler | Das ist schon etwas heftiger. Problematik: Ich möchte per oGL ein Objekt auf dem Bildschirm bewegen, schrittweise. In der Wartephase soll aber schon die nächste Berechnung gemacht werden. mit Sleep kann ich zwar die Wartephase einleiten ohne das der Prozessor dadurch belastet wird (settimer), aber die Berechnung wird trotzdem erst nach Ablauf von Sleep durchgeführt, und das ist Kacke .
Wer kennt die Lösung ( wär schon klasse)
WKS |
|
|
| |
|
|
|
Jörg Sellmeyer | Wenn Du einen Timer in Dein Programm einbaust, kannst Du alles mögliche scheinbar parallel ablaufen lassen: KompilierenMarkierenSeparierendeclare icon1&,button1&,choicebox&,oglwindow&,klick%,ende%,klick2%
Proc baueMenue
CHOICEBOX& = CREATE(CHOICEBOX,%HWND,2,0010,0050,0170,0500)
addstring(choicebox&,box)
addstring(choicebox&,bla)
addstring(choicebox&,blaBla)
BUTTON1& = @Create(BUTTON,%HWND,TEST,0010,0500,0080,0060)
Endproc baueMenue
proc test
whileloop 100
inc Klick2%
drawtext 50,200, Klick2%
drawtext 0,230, gettext$(Choicebox&)
wend
endproc test
Proc Test2
whileloop 10
sleep 1000
Drawtext 0,30, Test2 gewählt
inc Klick%
Drawtext 100,30, Klick%
wend
endproc test2
*** HAUPTPROGRAMM *****
windowtitle Menutest
declare mItem%
CLS 0
showmax
popup &Datei
appendmenu 110,&Neuer Test
popup &Hilfe
appendmenu 210,&Hilfe F11
baueMenue
SetTimer 1
whilenot ende%
waitinput
SetText BUTTON1&,Str$(&getTickcount)
select %menuItem
caseof 110:test2 startet den Teil mit Sleep
otherWise
endSelect
if iskey(34)BildRunter
drawtext 0,0, Bild runter Taste
inc Klick%
drawtext 100,0, Klick%
ELSEIF @Clicked(BUTTON1&) diese Berechnung soll gemacht werden während Proc test2 arbeitet
test
endif
setmenuitem 0
endwhile
KillTimer
usecursor 0
end
|
|
|
| Windows XP SP2 XProfan X4... und hier mal was ganz anderes als Profan ... | 09.06.2008 ▲ |
|
|
|
|
| In Buntank steckt die Lösung.
Hänge per setTimer-Api einen Timer in die subClassProc ein, ich würde 30ms wählen.
Dieser ruft aber eine game-Frame-Proc auf, diese wiederum schaut wieder um 30ms vergangen sind und ruft, wenn vergangen, die eigentliche Zeichnungsproc auf.
Dieser Mechanismus verspricht einfache Echtzeitprogrammierung und die game-Frame-Proc kann auch in allen weiteren Loop aufgerufen werden da diese ja selbst nochmals auf vergangene 30ms achtet.
Vorteile: geringstmögliche Systemlast und einfacher Echtzeitnachbau
Wie gesagt schon (u.A.) vorgemacht in Buntank, versuche dort trotz der etwas anderen Syntax herauszulesen wie es geht. |
|
|
| |
|
|
|
Walter Köhler | ok! In deinem Source Jörg, sehe ich leider keine Lösung. Die beiden Procs laufen eindeutig nur nacheinander, niemals parallel.
Werde jetzt mal BUNTANK Source suchen und dann ma sehen wie weit mich das bringen kann. cu WKS |
|
|
| |
|
|
|
| @Walter: Parallel gibt es so und so nicht - nichtmal in echten Threads, denn das ist ein typischer Anfängerdenkfehler dem wir bestimmt alle mal unterlagen.
Es ist immer nur die Frage der Organisation der Aufgaben sodass es so wirkt als sei etwas parallel - deshalb versuche einfach zu verstehen wie z.B. Buntank die Aufgaben verteilt um Ähnliches nachzubilden. |
|
|
| |
|
|
|
| Hier [...] vielleicht auch per Dich interessant, samt dahinterstehendem Artikel [...] und dem dortigem Demo fpsinctest.exe [...] und [...] und [...] . |
|
|
| |
|
|