PS zu vorhin:
von der Idee des Prozeduralen Aufbaus ausgehend, muss es ja möglich sein,
irgendwann im Programmablauf zu fragen "Holla, liegt denn ein Event an?"
dafür ist
da, und das gibt ggf. #Null zurück, damit man in klassischer PB-Manier prüfen kann
man könnte jetzt natürlich WindowEvent und WaitWindowEvent(TimeOut) dahingehend ändern, dass die niemals #Null sondern ggf. -1 zurückgeben,
und die Konstanten #PB_Event_TimeOut = -1 und #PB_Event_QueueEmpty = -1 einführen, aber das wäre nur kosmetisch, außerdem wäre die If Event Konstruktion nicht mehr möglich.
Deine Sichweise, dass eine Ereignisverarbeitung nur dann durchlaufen werden sollte wenn überhaupt ein Ereignis anliegt, ist ja nicht verkehrt,
allerdings wohl mit den prozeduralen Ansprüchen von PureBasic nicht als Bedingung in der Sprache selber durchsetzbar.
die Kommandos selber dürften das dann nicht ermöglichen, und damit fällt das ganze Freiheitskonzept.
Dann würde ich sagen, es war eine "übliche" Vorgehensweise, weil es gibt ja jetzt Timer.
Leider wurde mein Vorschlag beim Alpha-Testing, einen optionalen Callback Parameter
hinzuzufügen ignoriert.
Ich denke mal, für Screens sollte sich der Timer auch eignen, zumal dadurch eine etwas
regelmässigere Abarbeitung stattfindet. Aber ist nicht mein Interessengebiet, aber testen
solltet Ihr das mal
jeder der nicht nur sporadisch Spiele schreibt sondern sich weitergehend mit dem Thema auseinandersetzt, muss sich grundlegende Gedanken über das Timing machen.
ist schon immer so gewesen, und schon vor Jahren haben die erfahreneren Progger Timer oder Threads benutzt,
und die die gerade aus dem Anfängerbereich entwachsen waren, mit SetFrameRate und einem Delay(0) damit man nicht ganze 100% verbrät.
durch das neue Flag #PB_Screen_SmartSynchronization wurde dieses alte Auslastungsproblem auch gelöst.
Aber PureBasic ist und bleibt auch eine Sprache für den Einsteiger.
Gerade die Tatsache, dass es möglich ist, mit einer Handvoll Befehlen ein Sprite auf den Bildschirm zu kriegen, ist das womit PureBasic seine Hobby-Programmierer im Spielebereich zieht.
Wenn man einsteigt und Ideen hat will man sich nicht drei Monate lang durch eine Anleitung fressen müssen, man will seine Bildchen sich bewegen sehen!
gerade seine Unkompliziertheit ist das, was PureBasic für den Einsteiger attraktiv macht,
und deshalb
DARF es in diesem Bereich keine schärferen Restriktionen in der Sprache selber geben.
Dass man dann nach und nach lernt, seine Ereignisse vernünftig zu verarbeiten und zu timen und nicht seine CPU zu braten ist ein Entwicklungsprozess.
Für den unge-time-ten WindowedScreen ist immer noch die innere Event-Schleife die angesagte Vorgehensweise.
(*)
das ist schon kompliziert genug für nen Anfänger.
Und wer weitergehend sich ein vernünftiges Framework aufbauen will, der sieht sich mit noch ganz anderen Problemen konfrontiert als dem Timing und seinen Events.
(*) für dich als Nicht-Spiele-Programmierer:
das große Problem bei Spielen ist, dass die Darstellung synchron zum Refresh des Monitors sein muss, nicht synchron zu irgendeinem Timer-Callback.
Damit kommt ein kompletter Problemkomplex hinzu von dem ein Anwendungsprogrammierer völlig verschont bleibt.
deswegen sind die Screen- und Flip-Befehle auf diese Synchronität ausgelegt, und wurden über die Zeit weiterentwickelt die CPU zu entlasten.
das Spielgeschehen selber kann man von Timern steuern lassen, die müssen dann aber asynchron zur Darstellung verarbeitet werden,
und genau das ist der Punkt, warum man einen Anfänger im Spielebereich mit Timern in Ruhe lässt, der hat genug mit der Darstellungssynchronität zu tun.
).
