Laptop-Frage

Schönen Tag, JCL!
Habe mal eine Frage. Der Publisher meines Projekts hat die A8 Engine nicht nur wegen den fehlenden Exportmöglichkeiten kritisiert (das Gerede über die Unity-Vorteile spare ich mir jetzt) – er hat aber einen Nachteil als besonders schwerwiegend kritisiert. Wenn man die laufende Anwendung auf einem Laptop abspielt und der Deckel des Laptops wird zur Laufzeit geschlossen, das Gerät fährt in Standby, und anschließend öffnet man den Deckel wieder – dann schmiert die Engine ab.
Das kann ich bestätigen – im Vollbildmodus.
Im Fenstermodus geht alles einwandfrei.
Kann man da was machen, oder ist das unvermeidlich?
Grüße
AS


...und wenn ich gerade beim fragen bin...
beim Start der Anwendung wird die (nur Lese-)Veriable
mouse_cursor.x und y immer im Bildschirm zentriert.

Ich würde gerne beim Anschalten meiner Mausfunktion diese
Variable immer in die Mitte setzen. So würde beim Erscheinen des Mauspfeils, dieser stets per mouse_pos.x=usw... zentriert sein. Ist das irgendwie möglich?
So ein reset der mouse_cursor-Variablen wieder zentriert auf dem Bildschirm?

Das erwähnte Standby-Problem ist uns zwar schon von manchen Usern gemeldet wurden, und wir haben auch so einen PC hier, aber ein zuverlässiger Workaround ist uns bisher nicht gelungen. Es gibt wohl auch keinen. Empfehlen Sie Ihrem Publisher, sich einen neueren Laptop zu kaufen.

Die Variable mouse_cursor können Sie nicht in die Mitte setzen, wohl aber den Mauspfeil per mouse_pos.

Natürlich geht das, mit der WINAPI-Funktion SetCursorPos.

Du kannst den Mouse Cursor (und somit die mouse_cusor variable) über den Befehl SetCursorPos an eine Position deiner Wahl setzen.

http://msdn.microsoft.com/en-us/library/windows/desktop/ms648394(v=vs.85).aspx

Sorry, ich hatte mich unklar ausgedrückt:

Die mouse_cursor Variable wird von Windows verwaltet und ist für die Engine read-only. Mit SetCursorPos können Sie aber natürlich die Windows-Mausposition und damit auch mouse_cursor verändern.

Die Position des Mauspfeils wird von mouse_pos, nicht von mouse_cursor bestimmt.

...
das sind die Chef-Entwickler-Ratschläge, bei denen man sofort wieder
weiss, in welchem Forum man sich befindet.
Danke an den Rest.

Deine Art Fragen zu stellen ist auch alles andere als angebracht wenn mir der Kommentar erlaubt ist.

und die Zeigefinger der Fanboys geben mir den Rest...
ich versprechs ja hoch und heilig, nach meinem aktuellen Projekt bin ich hier weg

pad kannst du mir eine einzige Zeile, welche oben in alphas Kommentar unangebracht ist, nennen? Eine absolute Standard Frage. Und einem der wenigen letzten kommerziellen Entwicklern im Forum zu empfehlen den Publisher blöde anzumachen erscheint auch doch zumindest ungeschickt. Aber gut, nicht mein Bier. Bin ja auch schon weg..

Ich bin jetzt absolut kein experte was DirectX und co im detail angeht, aber wen der laptop in den standby geht, geht dann nicht automatisch der context verloren?

Feigling! Drückeberger! Deserteur! Überläufer!!!
Sich nach so vielen Jahren einfach aus dem Staub zu machen ... das geht gar nicht!

Wie reagiert dieser Laptop eigentlich bei ANDEREN DirectX-Spielen, die nicht mit Gamestudio entwickelt wurden? Bleiben die erhalten?

Ich kann alpha_strike verstehen, hatte genau das gleiche Problem bei meinem Starlaxis-Projekt.

Aber es tritt auch bei neueren Laptops auf (bin Verkäufer in einer Elektrofachmarkt-Kette und habe da mehrere getestet), auch auf neuen Rechnern ist es das gleiche.

Nach mehreren Mails mit dem Support wurde das Problem seit dem letzten A8-Update etwas begrenzt, aber eine vollkommene Beseitigung ist wohl nicht möglich. Hängt anscheinend auch mehr von den Projekten ab, bei manchen tritt es auf, bei anderen nicht. Nur weiß anscheinend auch keiner, was es nun genau auslöst.

Schicke ich den Rechner während des Vollbildmodus per Tastenkombi in den Standby, treten nach dem letzten A8-Update
verschiedene Ergebnisse auf:

A) Es kommen von der Engine DirectX Fehlermeldungen (die kann man ja auch unterdrücken) und sie schaltet in den Fenstermodus
um dem Crash zuvorzukommen.

Meistens ist dies der Fall beim ersten Standy-Versuch.
Schaltet ich danach aber wieder in den Vollbildmodus und aktiviere den Standy erneut, kommt oft leider Möglichkeit B) ins Spiel:

Es kommen keine Fehlermeldungen, aber das Bild friert ein obwohl das Spiel an sich weiterläuft...



Ja, diese Problematik konnte ich bis auf eine Ausnahme nur bei GameStudio-Spielen erleben.


Meiner übrigens auch.


Da ich mich nach mehreren Jahren aber so gut an GameStudio gewöhnt habe, werde ich erstmal weitermachen. Habe momentan nicht die Zeit was neues zu lernen.
Muss auch sagen, dass ich GameStudio im Gegensatz zu z.B. Unity wesentlich einfacher finde. Ich möchte alles mit einem Skript steuern ohne Umwege. Ist aber vielleicht auch nur die Gewohnheit...°°

Auf jeden Fall freue ich mich auf den Android-Export, das ist ein Schritt in die richtige Richtung!

Hm, über diese Problematik hab ich mir noch nie Gedanken gemacht. Anyways, ich schalte bei meinen laptops auch immer ein, dass die nicht in den standby gehen, weil ich schon häufiger diverse Probleme auch mit ganz normalen Anwendungen hatte. Außerdem bin ich häufiger in der Situation, dass ich meinen laptop an einen normalen Bildschirm und Maus/Tastatur anschließe und den Deckel einfach schließe und eben will, dass er weiter läuft - da ich ihn ja wie einen regulären PC benutze an dem Bildschirm und das Laptop-Display nicht brauche.

Dennoch: Gehört dieses Verhalten (Deckel zu, standby) denn zu einem normalen use case bei einem Computerspiel? Ich finde das nämlich sehr merkwürdig, dass man ein Spiel startet und man dann einfach so in den standby geht. Das müsste dann ja auch passieren, wenn man einen Desktop PC in den standby fährt.

Dasselbe "feature" finde ich auch bei meinem smartphone und beim Nintendo 3DS sehr komisch - da werde ich auch immer gefragt ob ich das Spiel komplett beenden will... bzw. lässt er es häufig im Hintergrund weiter laufen. Wenn ich auf Beenden drücke oder zum Hauptmenü des Geräts zurückgehe, dann soll das Spiel auch gefälligst ausgehen ^^

Tut es auch.


Als ich von dem Problem das erste Mal hörte, dachte ich das auch. Aber einige Publisher legen da Wert drauf. Wir hatten z.B. mit BigFishGames diesbezüglich ziemliche Probleme. Erst nach dem oben erwähnten A8-Update, wo der Fehler nun nicht mehr so häufig auftritt, haben sie das Spiel akzeptiert.

Ich sehe da kein Problem, dass mal nen SPiel abstürzt beim zuklappen. Beim ersten Mal ist es nervig, dann weis man das und speicher einfach. Man könnte natürlich die memory-infos aus dem Arbeitsspeicher einfach in einer backup datei speichern und nach dem aufklappen wieder reinschreiben, wobei es mir persönlich eegal wäre ob das game beim standby abkackt

Mir auch, aber wenn das Spiel deswegen bei größeren Plattformen nicht akzeptiert wird, ist das mehr als ärgerlich.

Je nach Spiel sehe ich das als sehr wichtig an.
Lass es etwas sein, dass man z.B. in der U-Bahn auf nem kleinen EEE PC o.ä. zockt. Wenn man aussteigt, klappt man die Kiste schnell zu und fährt nicht erst alles runter.

Auf Arbeit wird bei mir z.B. nach Meetings grundsätzlich der Laptop zugeklappt. Da erwarte ich dann auch, dass sich diverse Tools zumindest schließen (oder eben wieder hochstarten), und keine Crashmeldungen auf dem Bildschirm sind.

Abgesehen davon sind reproduzierbare Crashes einfach unschön und wirken schlampig - von daher kann ich die Publisher an dieser Stelle schon verstehen.

Mir geht es da ähnlich wie HeelX. Gedanken darüber habe ich mir nämlich auch nicht gemacht. OK, ich habe das mal hier mit Torque Game Engine Advanced 1.8.2 und Unity 3.5.0f5 getestet. Im Fenstermodus sowie im Vollbildmodus reagieren beide Engines so, wie gewünscht. Keine Fehlermeldungen, keine Abstürze, einfach nix.

Edit: Bei Unity bin ich mir nicht sicher, aber TGEA 1.8.2 läuft mit DirectX und nicht openGL. Somit gleiche Voraussetzungen für Gamestudio.