| |
|
|
Walter Köhler | c'est déjà quelque chose heftiger. Problematik: je voudrais per oGL un objet sur dem Bildschirm bewegen, schrittweise. dans qui Wartephase mais devrait déjà qui prochain Berechnung gemacht volonté. avec Sleep peux je zwar qui Wartephase einleiten sans cela qui Prozessor dadurch belastet wird (settimer), mais qui Berechnung wird quand même seulement pour le bout de Sleep durchgeführt, et c'est Kacke .
qui kennt qui Solution ( wär déjà super)
WKS |
|
|
| |
|
|
|
Jörg Sellmeyer | si Du une Minuteur dans Dein Programme einbaust, peux Du alles mögliche scheinbar parallèle ablaufen laisser: KompilierenMarqueSéparationdeclare 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 ▲ |
|
|
|
|
| dans Buntank steckt qui Solution.
Hänge per setTimer-Api une Minuteur dans qui subClassProc un, je serait 30ms choisir.
cette appelez mais une game-Frame-Proc sur, cet wiederum schaut wieder um 30ms passé sommes et appelez, si passé, qui eigentliche Zeichnungsproc sur.
cette Mechanismus verspricht simple Echtzeitprogrammierung et qui game-Frame-Proc peux aussi dans allen weiteren Boucle aufgerufen volonté là cet oui selbst nochmals sur vergangene 30ms achtet.
Vorteile: geringstmögliche Systemlast et einfacher Echtzeitnachbau
Comme je le disais déjà (u.A.) vorgemacht dans Buntank, versuche là trotz qui quelque chose anderen Syntax herauszulesen comme allez. |
|
|
| |
|
|
|
Walter Köhler | ok! dans deinem Source Jörg, vois je malheureusement aucun Solution. qui beiden Procs courir sans équivoque seulement nacheinander, niemals parallèle.
Werde maintenant la fois BUNTANK Source chercher et ensuite ma voyons comment large mich cela apporter peux. cu WKS |
|
|
| |
|
|
|
| @Walter: parallèle gibt es so et so pas - nichtmal dans echten Threads, car c'est un typischer Anfängerdenkfehler dem wir bestimmt alle la fois unterlagen.
c'est toujours seulement qui Frage qui organisation qui Aufgaben sodass es so wirkt comme sei quelque chose parallèle - c'est pourquoi versuche simple trop comprendre comment z.B. Buntank qui Aufgaben verteilt um Ähnliches nachzubilden. |
|
|
| |
|
|
|
| ici [...] peut-être aussi pour toi intéressant, velours dahinterstehendem Artikel [...] et dem dortigem Demo fpsinctest.exe [...] et [...] et [...] . |
|
|
| |
|
|