Ich experimentiere hier noch. Das ist noch nicht mal eine 0.1 Version.

Der low level ist bewußt so gewählt. Einen ganzen Screen rein auf Bitmapebene zu realisieren. Da kann man noch richtig Speed rausholen, bis zum Assembler hin, auf reiner Speicheradressierungsebene, wenn man sich mit dem Bitmap-Format auskennt. Wer will kann hier auch anderes Fensterrendering wie WinForms einbauen, vielleicht DirectX?

Als nächstes will ich hier keine Engine bauen, auf die man Need for Speed aufsetzen kann. Es geht hier rein um rundenbasierte Spiele, wo die Spieler gemütlich klicken. Da soll kein Echtzeit-Genre mit rein. Meine Motive sind da eher, solche Spiele wie Millenium oder Deuteros umzusetzen, oder eben X-Force.

Die kanonische Klasse war ein erster Versuch, eine komplette Klasse zu speichern und zu laden. Es ist schon jetzt möglich per Script eine eigene Klasse zu bauen und die wenigen Zeilen Code, die es zum Laden/Speichern braucht in sein Script zu kopieren. Diese kanonische Klasse wird später direkt durch Script instanziert und angesprochen, da darf an der Struktur nichts geändert werden, sonst läuft das Scripting nicht mehr. Deshalb sollen die Scripter sich ja auch selber eine Versionsnummer in ihren Spielsatz einbauen, die sie abfragen, um nicht ausversehen alte inkompatible Spielsätze zu laden. Ich werden auch noch Versuche starten, wo ich die mygame.load und mygame.save per script überlade, bzw. sogar die ganze data-klasse per script überlade. Das ist dann immer noch kanonisch, aber jeder Scripter(Gamecoder) kann seine Kanone dann selber laden.



Das steht genau ein Posting über deinen. Das wiederhole ich nicht nochmal. Und die fertigen Konzepte hat Natter schon gepostet. Die Logik aus den fertigen X-Force Konzepten muss nur übertragen werden.

Ich weiß. Ich will nur frühzeitig gegensteuern, wo ich potentielle Probleme sehe.


Dazu sage ich: Premature optimization. Zumal das Pixel rumschubsen nie und nimmer ein Flaschenhals sein wird (solange man sich nicht völlig doof anstellt), sondern das kompliziertere Verhalten, was auf Ebenen passiert, die deine Engine ignoriert (und somit auch nicht optimieren kann).


Kann man das? Ich kann nur die Skripte sehen, nicht den Quellcode der Engine, und ich kenne mich mit den verwendeten Frameworks auch nicht so gut aus.

Aber selbst wenn man kann, ist die Frage, ob das so sinnvoll ist. Das ist nämlich. Eine komplett andere Basis für das Rendering zu nehmen, will ich nämlich garnicht. Ich will eine höhere Abstraktionsebene, damit so Dinge wie scrollbare Listen, Tooltips, Tabs, bunt formatierter Text, Radio-Buttons, Checkboxes, etc. mit wenig Aufwand zur Verfügung stehen. Denn von X-Force wissen wir, dass diese Dinge gebraucht werden, und wenn die Engine selbst so etwas nicht bereit stellt, dann werden Spielsätze es selbst implementieren müssen, und das Ergebnis wird auch noch schlechter sein als nötig.


Klar. Von optimierten Display lists, shadern, global illumination, etc. redet ja auch keiner. Es gibt noch eine ganze Menge Zwischenstufen zwischen dem Status quo und der Need for Speed Engine ;-)



Oh, ich glaube, ich etwas falsch verstehe. Das kommt davon, wenn ich habe nur die Forumsposts und die Skripte als Grundlage für mein Verständnis habe ;-) Mein Eindruck war, dass es eine Klasse in der Engine gibt:

class Data {
    int version;
    string spielsatz;
    // ...
}

die gefälligst für alle Spielsätze bindend sein soll. Wenn das nicht so ist, dann habe ich nichts gesagt.



Tut mir leid, aber nein, steht es nicht. Du beschreibst lediglich den Workflow, wie aus Dateien auf der Festplatte ausführbarer Code wird. Das ist der uninteressante Teil. Was ich meine ist die "API" sozusagen. Was steht tatsächlich in den Skripten, um dieses und jenes Feature umzusetzen? Wie wird auf Daten wie z.B. den Kontostand (Credits) der Organisation, oder die Liste der Gegenstände im Lager, oder auf die Aliens im aktuell laufenden Bodeneinsatz zugegriffen? Wie werden diese Daten geändert, wie wird z.B. per Skript ein UFO erstellt?

Das ist ein wichtiger Aspekt, denn schließlich sollen ja je nach Spielsatz Skripte und Daten und Features hinzukommen und entfernt werden können. Einfach dem ersten Instinkt zu folgen und zu sagen "Das ist alles in der Game Klasse, die speichert und macht dann alles" ist schon in einem monolithischen Spiel von einem einzigen Entwickler miserables Design[1], aber wenn dann noch von mehreren unabhängigen Leuten auf inkompatible Weise Änderungen durchgeführt werden, wird es ein Albtraum. Dafür muss eine praktikable Lösung gefunden werden, und zwar bevor so viel Code auf die "einfache" Art geschrieben wurde, dass der Wechsel richtig weh tut.

[1]: Diese Behauptung lasse ich mal einfach so im Raum stehen, da sie meiner Erfahrung nach relativ unumstritten ist. Bin aber bereit sie zu verteidigen, wenn jemand Zweifel anmeldet.

Mir kommt das eher so vor als wenn du die Probleme förmlich suchst.



Welche Ebenen ignoriere ich? Du kannst per Script das ganze Framework ansprechen. Derzeit nutze ich Routinen aus der System.Drawing Klasse für mein Gamescreen, der einzig und alleine auf eine Bitmap pro­ji­zie­rt. Dann schnappe ich mir noch ne WinForm um das Bitmap im Fenster darzustellen.

Das einzige was ich aushebele ist dieser ganze ContainerMüll, worauf ich kein Bock habe. Text im Button-> Button im Stackpanel, Stackpanel in Grid, Grid in Page, Page in Windows.

Ich wage mal zu behaupten, das hinter dieser ganzen Containerlogik am Ende auch nur auf reinem Speichermanagement gearbeitet wird. Und anstatt jedem Button, jedes Label, jede Textbox zu resizen, lege ich mir vorher auf ein feste Größe fest, baue den Screen und Resize nur einmal das Bild insgesamt. Diese ganze Containerlogik hat durchaus ihren Sinn und ist genial, wenn du mit Designern deine Masken zusammenbaust, aber je mehr du deine Masken dynamisieren willst, desto unlustiger wird der Spass.



Quellcode ist einsehbar, sind alle in der VisualStudio.Zip mit drin.



Steht es doch.

Game.exe <- Logik und X-Force Rewrite
EngineX <- Game-Klasse, Fenster-Klasse und ScriptX

Game-Klasse = "API"

Erste Prototypen der API hochscrollen und Seite 8 hier im Forum clicken.
Oder ins Coding gucken oder meine eingebaute Info-Seite anklicken oder ins Scripting gucken.
Alles was mit myGame anfängt ist die Ansteuerung der "API".

Im Moment ist mein Webspace aber down, 10 Jahre zahlen dafür ist ok, aber wenn man den mal einmal nutzt und ein bischen Traffic verursacht machen sie zu. Muß ich mich nach was anderen umsehen.

Ansonsten kann das Scripting jetzt includen und ein erster Testbeep kommt aus einer instanzierten Klasse.

myClass <- die wird rein vom scripter definiert und hier der code zum speichern der data klasse, copy pasten, klassennamen austauschen und dann geht das saven und loaden auch mit der eigenen klasse

        // Data-Klasse in eine XML-Datei serilisieren (speichern)
        public void save(Data data, string filename)
        {
            XmlSerializer serializer = new XmlSerializer(typeof(Data));
            FileStream file = new FileStream(filename, FileMode.Create);
            serializer.Serialize(file, data);
            file.Close();
        }

        public Data load(string filename)
        {
            try
            {
                XmlSerializer serializer = new XmlSerializer(typeof(Data));
                FileStream file = new FileStream(filename, FileMode.Open);
                //Die Deserialize()-Methode gibt ein Object zurück. => casten!
                Data data = serializer.Deserialize(file) as Data;
                file.Close();
                return data;
            }
            catch
            {
                return new Data();
            }
        }

Ich kann mir schon vorstellen, das man auch mit einem stark skriptbasierten Ansatz wie der von Kamor vorgeschlagene arbeiten kann. Mir geht es mehr darum, dass der Spielsatzersteller mindestens genauso im Blick sein sollte, wie die Modifizierbarkeit. Anders gesagt, das "Startskript" z.B. sollte ein Spielsatzersteller zunächst garnicht zu Gesicht bekommen. Denkbar wäre ein Editor, in dem man verschiedene "Module" per Häkchen oder Auswahlliste auswählt, und das Startskript daraus automatisch erzeugt wird (und entsprechende dafault-Skripte einbindet).
Wenn man das im Blick hat (Spielsatzersteller, die erstmal nur kreativ sein wollen - und erst viel später vielleicht an Grenzen stoßen und sich dann evtl. mit Skripten beschäftigen - die dann auch durch gute apis mit möglichst einfachen Befehlen großen Einfluss erlauben müssen), kann es durchaus sein, dass Kamors Ansatz trotzdem gut geeignet ist. Ich hatte bei den Diskussionen nur den Eindruck, dass dieser Aspekt völlig vernachlässigt wird. Auch die Fehlersuche sollte dabei mit bedacht werden.

Tut mir leid, wenn das so rüber kommt. Wir haben wohl sehr verschiedene Ausgangspunkte. Ich will dir nichts böses :-)

Zu GUI/"Container-Müll":
Ich bin nicht ganz sicher was du hiermit meinst:
Sagst du, solche Dinge sollen mit WPF (oder was auch immer) gemacht werden und über die Bitmap drüber geklatscht werden? Hmmm... vielleicht kann man das machen, ich weiß wie gesagt nicht viel über das Framework. Ich bin aber nicht überzeugt, dass damit der EngineX alle Verantwortung abgenommen ist. Ich als Entwickler würde mich nicht jedes mal mit WPF rumschlagen wollen, ich würde einen visuellen Designer oder zumindest ein für Menschen lesbares und änderbares Dateiformat haben wollen, mit dem ich deklarativ meine Seiten anlegen kann. Aus Sicht der Engine sind die GUI Elemente zwar völlig dynamisch und unvorhersehbar, aus Sicht der Spielsätze und sogar der "game logic" Schicht sind die allermeisten 100% starr.


Oh, gut *kleinlaut*

Ist der auf einem Stand mit dem .exe download? Ich finde nämlich in der Game Klasse (Game.cs, Game.Designer.cs) die Methoden, die vom Skript aufgerufen werden, nicht.


Das ist keine Antwort. Die Game-Klasse enthält derzeit nichts, was annährend die Punkte berührt, die ich aufgezählt habe. Sie kann (und ich hoffe ich habe nicht schon wieder das übersehen) Assets laden und Spielstände speichern und lagen. Das ist schön und gut, es ist ein Experiment und noch nicht dazu gekommen. Deshalb rede ich ja von Planung. Den Quellcode den ich vor mir habe, und das was ich aus den Skripten ableiten kann, sagt mir nicht, was du vorhast bezüglich dem ganzen Spiellogikkram. Und selbst wenn ich mir was zusammenreimen könnte, würde ich es ansprechen, da ich ja schon mal falsche Schlussfolgerungen gezogen habe ^^ Außerdem kann eine API, die alle diese Dinge umfasst, nicht einzig und allein aus einer Klasse bestehen. tl;dr: Wie sieht die Zukunft der Game-Klasse aus?

@Natter: Ja, da stimme ich zu.

Engine -> Game -> Gameskripter/Gamesetbauer -> Gamesetmoder

Engine stellt API für die Gameskripter/coder
Game stellt API für die Gameskripter/Gamesetbauer
Gamesetscripter/Gamesetbauer desigen ihre Datenstrukturen und basteln Skripts
Gamesetmoder manipulieren nur noch Daten und Verändern evtl. einen Namen in den Skripten

Dabei gibt es eine API in der Engine
Es gibt eine API im Game
Vielleicht auch noch auf Gamesetebene ein API.

Derzeit startet Skripting zwischen Engine und Game. Skripting kann aber auch zwischen Game und Gamesetbauer starten. Es kann sogar noch weiter beschnitten werden. Dabei lässt sich das Scripting immer weiter beschneiden, so das man mehrere Komplexitäten dort anbieten kann.

Dann nochmal. Ich teste hier. Das ist (noch) kein Rewrite. Wie, wann oder wer die Game.exe coded ist noch nicht definiert.

Auf jedenfall habe ich jetzt einen schon brauchbaren Ansatz für

Scripting in C#

Als nächstes suche ich eine elegante Lösung für das Problem klassischer Game-Loop gegen Fenster-Event/Smalltalk-Steuerung“ wie das auch immer heißt.

Ein WinFormsfenster oder ein WPf-Fenster oder auch andere Fenster lassen sich nicht so einfach einbinden. Hinzu kommt noch das Skripting.

Dann nochmal zu meine Game-Klasse, die ist im Prinzip eine sehr vereinfachte Background-Builderklasse. Ich kann ebensogut mein Screen im Fenster als Hintergrund definieren und da dann noch Buttons, Listen, Textboxen im Fenster drübersetzen. Dabei kann sowohl im Background geklickt werden, wie auch vorne in den Objekten der Fensterklasse.

Also meine derzeitigen Themen sind die Basics

Scripting
Gameloop
Fensterhandling
Multi-Threading
Timer
Event/Delegation
Callbacks
Backgroundbuilder
Bitmapmanipulation (rotate, blackwhite, infrarot, heller, dunkler, …)
Areas (Sprites)
Printing
Fonts
Serilizieren von Klassen


Und dann könnte ich mal Hilfe gebrauchen, wie ich an die Ressourcen von X-Force komme. Gibt es die Grafiken aus den Pack-Dateien auch in zugänglicheren Format (Download) ?

Ein erster Gameloop ist fertig.

http://www.kamorspace.de/xforce/EngineX-VisualStudio.zip

und nochmal der Link auf die ausführbare Variante

http://www.kamorspace.de/xforce/EngineX.zip

neue Version

Gameklasse sauber zum Winbackgroundimage durchgeschleift
Win Rezise funktioniert
Doublebuffering gegen flackern eingebaut
ESC zum Fensterschließen eingebaut
Gameklasse kann Winklasse informieren das sich Content geändert hat, dadurch zeitnahe Reaktion im Fenster möglich
Mausclick auch für WinForms sauber durchgeschleift
Meinen alten PakView mit eingebaut, der kann aber nur das Pakinhaltsverzeichnis anzeigen und unkomprimierte Dateien daraus exportieren.

Animierte Areas(Sprites) über Skripting sind theoretisch schon möglich, gibt aber noch keine eleganten Befehle dafür, die das vereinfachen. Es können mehrere Game Instanzen gestartet werden.
Buttons, Listen, Textareas, … können nun über den Backscreen gelegt werden.

Terrorangriff in Niedersachsen

Gameloop sieht schon etwas besser aus, erzeugt aber noch hohe Speicherlast und crasht dann auch. Ich schicke derzeit ein ganzes Bitmap über invoke/deligate ans Fenster. Hier muss ich noch eine bessere Lösung einbauen.

Ich weiß nicht ob dass so stimmt. Ich dachte du arbeitest beruflich viel mit C? Und meine Erfahrungen berufen sich auch nur auf eher kleineren Projekten bei denen OOP ich mal als "Overkill" bezeichne.
Zwischen einer Website oder einem Kommandozeilentool und einem ausgewachsenem Spiel liegen schon Welten. Bisher habe ich hier auch nicht wirklich viel gemacht.

Ich weiß aber dass man bei etwas größeren Projekten schnell in einer Sackgasse landet oder zu viel macht (Siehe sujin's "Programmiert ein Spiel, kein Framework") wenn man nicht wirklich weiß was man überhaupt will/braucht.
Aber man kommt auch nicht weit wenn man alles selbst und von vornherein Perfekt und Vorbildlich machen will, man unterschätzt da schnell den Aufwand und die eigene Unwissenheit.
Beispiel: "Wir brauchen eine mehrsprachige Website!" Fatal wenn man da nun was ausdenkt und sein Mini-CMS/Framework umschreibt damit jedes Wort nun in Deutsch, Englisch und Russisch angezeigt werden kann.
...Um dann festzustellen dass die fertige Website tatsächlich nur Deutsch + 3 englischen Seiten besteht. Davon ein vermeintlich problematisches Formular. ..1 kurzer Satz + die 3 Eingabefelder "Name", "Email" und "Text"...

Wo wir dabei sind.. Wieviele von den Gamesets wurden tatsächlich in mehr als einer Sprache angeboten? Sollte man -- in Anbetracht unserer Manpower -- XForce2 einfach nur rein Englisch + ein "non-english"-Forum anbieten?
IMHO macht es ohne hin recht wenig Sinn etwas vor der 1.0 zu übersetzen. Und ein "nachrüsten" mittels GNU getText ist nicht so ein großer Aufwand wenn man Texte nicht kreuz und quer in den Quelltexten verteilt. Bei den meisten Sprachen brauch man nicht viel mehr als "printf(...)" durch "printf(_(...))" ersetzen, den Rest erledigt man mit ausgereiften Tools wie http://poedit.net/




Jo dann sind mehr oder weniger alle bisherigen "Experimente" hinfällig.



Nicht wirklich.
Ein Paar Sachen findest du hier im Forum verteilt,
http://doc.xforce-online.de/ger_pages/Addons/Ressourcen.html und ich glaub auch im Bugtacker.

Die Daten in den Packs sind teilweise LHA-Komprimiert. Ich hatte da mal ein Tool zum "umpacken" geschrieben. Nach Anwendung waren die Daten zwar noch in xForce-kompatiblen Packs, konnten dann aber relativ einfach gelesen werden. Dies könnt ich so umschreiben dass es gleich alles auspackt, Kompatibilität ist ja nun überflüssig. Da müsstest du dich aber etwas gedulden. Aber da gibt es ja noch die ungeklärte Frage was wiederverwendet werden darf.


Die binden dort nicht .Net 4.5 ein, sie programmieren es größtenteils (kein WPF...) nach. Ist also nicht 100% kompatibel, wenn auch kompatibler als Lazarus zu Delphi. Problem sind hier aber auch wieder die externen Libs wenn es sie nicht auch für Linux gibt.
Man kann zwar mit MonoDevelop unter Linux in C# programmieren, aber kein (aktuelles?) MS-VS Projekt bearbeiten. Zumindest kann ich dein Code selbst mit der neusten 5.9 unter Windows nicht compilieren ("Projekttype wird nicht unterstützt").
Zudem weiß ich nicht wie zukunftssicher Mono unter Linux ist. Die Entwickler scheinen sich nur noch auf Smartphones zu konzentrieren.

Ein Spiel in der VM? Naja bis "xForce 2" fertig ist...

Experimentierst du eigentlich noch Ergebnisoffen oder steckst du schon in der Umsetzung?

Nochmal eine bessere Version hochgeladen. Rendering optimiert. Ich hatte dort unnötige Neuinstanzierungen drin und was ganz übel in die Speicherlast reingeschlagen hatte, war das ich jedes Area neu aus den Ressourcen geladen und auf die Areagröße umgerechnet hatte. Jetzt werden die Areas beim Areabuild und nicht mehr beim Layerbuild aus den Ressourcen geladen und auf die richtige Größe gebracht und dort gecached.

Gameloop läuft dadurch wesentlich stabiler. Größenveränderung von Areas, Sprites geht noch nicht, da fehlt eine Funktion in der Areaklasse die den Areabitmapbuffer(Cache) neu berechnet.


Schade, dachte die hätten da eine Art „DosBox“ für Windows gebaut.

Umsetzung Engine Ja
Umsetzung Game(X-Force Rewrite) Nein

„Ufo’s über Deutschland“ dient nur dem Testing und zu Demonstrationszwecken.

Ich habe mal das ScriptX rausgezogen und auf ne Console-Anwendung gelegt. Vielleicht kommt Mono damit klar. Sind nur zwei Dateien x.exe und test.txt. Muss aber per Command-Line gestartet werden, sonst siehst(hörst) nicht viel, weil die Console sonst gleich wieder zugeht. In der test.txt passiert nicht viel, außer ein System-Beep. Wenn der Beep aber ausgeführt wird, könnten wir noch ein Versuch nachlegen.

http://www.kamorspace.de/xforce/scriptxconsole.zip

Ich muß das nochmal genauer erläutern.

Das Ganze ist immer noch ein Feldversuch bzw. ein Experiment. Dabei versuche ich die Gemeinsamkeiten von Spielen in eine zentrale Engine zu stecken.

Bisher war es immer so:

Ich wollte (mal wieder) eine Spielidee umsetzen (programmieren).
Jedesmal wurde ich mehr und mehr in Ein-/und Ausgabe Programmierung gezogen und immer weiter weg, von meiner eigentlichen Spielumsetzung (Idee).
Irgendwann habe ich die Lust verloren, weil egal was ich an Ideen umsetzen wollte, immer erst das ganze wieder und wieder in die Ein-/Ausgabelogik gebettet werden musste.

Deshalb versuche ich jetzt in meinem Ansatz, diesen ganzen I/O-Scheiß für alle meine Ideen zu kapseln. Meine erste Ebene dieser Kapselung soll Spiele, wie Millenium oder Deuteros umsetzen können oder auch ein/zwei eigene Ideen. Das ich jetzt schon Landkarten anklicken kann, daran ist mehr oder weniger Andiana schuld mit ihrem Vorschlag irgendwo auf Seite 7. Durch anklickbare Karten kann die Engine Spiele, wie Risiko, etc. unterstützen. Eine weitere Ebene wäre es, wenn ich diese Karten auf einen Globus projizieren könnte, das versuche ich gerade umzusetzen. Dieser Punkt wäre eine nette Option für einen X-Force Rewrite. Auf der anderen Seite, kann ich damit aber auch genausogut den Mond ablichten und eine Landkarte für ein Mondbasis-Game darunterlegen.

Also ich versuche schon Konzepte für einen X-Force Rewrite einzubauen, aber nur insofern, als das ich eine Möglichkeit biete, wie man es machen könnte.

Ansonsten habe ich jetzt eine neue Win-Loop, eine echte Loop, über Timer angestoßen und mit einer Stopwatch synchronisiert. Das vom Game gebaute Bitmap wird jetzt durch diese Loop im Fenster dargestellt. Hier mal wieder mein Dank ans WWW und den Suchmaschinen für die vielen Infos zu diesem Thema. Alleine hätte ich das nicht geschafft. Ausserdem gibt es noch erste Prototypversuche zum Globus (bisher noch ein Kreis) und ein bischen Vektorgrafik wie im Klassiker „Elite“ eingesetzt wird.

Neue Version oben. Das war ein harter K(r)ampf. Nach aussen hin sieht es nicht nach viel aus, aber glaubt mir, ich habe zwischendurch geweint.

Winloop steuert jetzt ungebremst das Gamerendering an. Die Darstellung des Backgrounds geschieht jetzt durch Überschreiben von OnPaintBackground. Die Mask-Klasse übernimmt jetzt das Rendering selber und arbeitet dabei schon im Ansatz intelligent. Layers werden nur neu berechnet, wenn sich dort auch etwas verändert hat. Layers werden dabei sowohl im Einzelnen gecached, wie auch in einer Art Stapel.

Die Mask-Klasse wurde dabei mehre male radikal umstrukturiert, was einer Herz-OP gleichkam und bietet jetzt selber eine erste API. Sie ist in einer ersten Form gegen Multi-Threading von außen abgesichert. Es gibt an wichtigen Stellen Dispose-Befehle, die das Speichermanagement doch nicht unerheblich entlasten. Langfristig muß die Mask-Klasse noch besser abgeschottet werden und Zugriffe von außen auf diese Klasse sollten nur noch über Methoden erlaubt werden. Direktzugriffe auf die Klasse können einfach nicht gegen Multi-Threading abgesichert werden.

Leider hat mich dieser K(r)ampf an anderen Fronten nicht weiter vorrankommen lassen, aber es gibt jetzt erste Areaeffekte und der Mouse-Click kann vom Scripter gehandelt werden.

Für Ufo´s über Deutschland heisst das:
Bei einem Länder-Click wird das Land Schwarz-Weiß geschaltet.
Das Ufo „landet“ jetzt mit Hilfe von areaResize.
Wenn das Ufo gelandet ist, kann nochmal auf Niedersachsen geclickt werden.
Der letzte Klick demonstriert nur noch, daß eine Maske komplett ausgetauscht werden kann.

Damit sollte eine erste Ebene der Game-Programmierung möglich sein. Mehrere Screens, die sich durch Klick durchschalten lassen.

Nächster Schwerpunkt wird jetzt die Beschaffung von Grafik-Material sein.

Hey,

nur eine kleine Aufmunterung: Ich finde es Super das hier noch was in Bewegung ist ! Cool das das Projekt doch nicht ganz am liegen ist und noch irgendwo getüftelt wird. Als absoluter non-coder meinen Respekt und Dank an euch!

Bin gespannt wies weitergeht :P

Gruß,
Red

Es geht weiter. Neue Version oben. Hatte zwischendurch andere Prioritäten.

Schwerpunkt Beschaffung von Grafik-Material

Habe die Links von Andiana abgegrast. Dann habe ich per Snipping Tool Grafiken aus dem X-Force und Tutorial Packs exportiert. Diese Grafiken habe leider nicht die Original-Größe. Der Engine ist das aber egal, die skaliert sowieso auf die gewünschte Areagröße. Trotzdem wäre es natürlich schöner, wenn man die Default-Grafiken 1:1 aus den Packs oder anderen Quellen exportieren könnte.

Exportierte X-Force Grafiken und DL´s sind alle mit im Download drin.

Des weiteren habe ich für den Millenium-Rewrite Grafiken per Screenshot eingefangen und mit dem berüchtigtem mspaint zugeschnitten. (Sorry, ich habe im Moment keine Lust mich mit anderen Grafik-Programmen auseinanderzusetzen. Da hoffe ich dann doch darauf, daß sich langfristig Grafiker motivieren lassen, die sich in diesem Fachgebiet auskennen.

Derzeit sind auch noch alle Screenshots mit im Download drin, was etwas ungünstig auf die Download-Größe umschlägt.

Packs und Pak-View habe ich dafür wieder rausgenommen.

Es gibt jetzt zwei neue Testumgebungen (Millenium und X-ForceBasis).

Millenium demonstriert einen ersten Screen mit Hover und Unhover-Effekt. Ausserdem zeigt der Maus-Click den area.write und stellt das ganze über bitmapfont mit Original Millenium Zeichen dar.

Dafür habe ich aus den ganzen Screenshots, das kleine und große ABC zusammengeschnitten plus Sonderzeichen die ich gefunden habe. Langfristig kann ein Millenium-Rewrite natürlich über andere Fonts und Grafiken dargestellt werden. Aber für die Weiter-Entwicklung der EngineX hat mich dieser Vorgang gut weitergebracht und auch wieder motiviert.

Die Mask-Klasse unterstützt jetzt eigene Events (Click, Hover, Unhover) und übernimmt Rendering und Maus-Checks mit Hilfe der WinForms-Klasse selber. Die Game-Klasse wird zukünftig einen anderen Namen erhalten und sich wahrscheinlich nur noch auf Ressourcen und Datei-Management beschränken. Eine neue Game-Klasse zu bauen, obliegt dann den Game-Codern/Scriptern. Evtl. ändere ich den Namen der Mask-Klasse auch noch in Screen-Klasse?

Weitere technische Details sind im Infobereich der EngineX.exe nachzulesen.

Der X-Force Basis Test hat mich etwas mehr Zeit gekostet, weil ich dort einen Rendering-Fehler der X-Force *.png Formate hatte. Wo die Logik des Fehlers genau herkommt weiß ich noch nicht, aber die Fehlerstelle habe ich zumindest korrigieren können. Es hat was mit Transparenz oder Rahmen im *.png Format zu tun. Auf jeden Fall entsteht der Fehler, wenn ich die *png erst skaliere und dann transparent schalte. Der Fix ist sie erst transparent zu machen und dann zu skalieren. Wie gesagt ist mir noch unverständlich, wieso das so ist, aber der Fix geht zumindest.

Um diesen Fehler zu finden habe ich viel Zeit gebraucht, aber dabei auch den Unterschied zwischen Alpha-Transparenz und Bitmap-Transparenz erörtert. Das Thema ist noch nicht vom Tisch, aber für die Engine heisst das, es sollen beide Möglichkeiten unterstützt werden. Einfach Bitmap-Transparenz ist optimal für Grafiken die zum Hintergrund durchscheinen sollen und für die Klick-Schablonen. Alpha-Transparenz ist optimal wenn man Wasserzeicheneffekte oder transparente Text-Ebenen bauen will, die im Ganzen zum Hintergrund durchscheinen. Im X-Force Basistest Beispiel gebe ich ein Systemfont mit Alpha-Transparenz 255 und 100 aus. Ansonsten demonstriert der X-Force Basistest ebenso wie der Millenium-Test nochmal den Hover-Event (aber hier ohne Unhover-Event) und stellt die exportierten X-Force Basis Bau Grafiken da. Mit einem Click auf den Aufzug kann dabei zwischen der Maske oberirdische Basis und der Maske unterirdische Basis hin und her geschaltet werden.

Dann komme ich nochmal zu meiner Aussage Feldversuch. Da bin ich schon länger dran vorbei-geschossen. Der ursprüngliche Ansatz sollte nur feststellen, ob ich das in C#, Python oder Lazarus umsetzen kann. Dabei ist Können nicht unbedingt das richtige Wort, weil wir können das alle, wenn wir wollen und die Zeit dafür haben. Also ist es primär eine Frage der Zeit und dann kann das Ergebnis des Feldversuches nur ein Ergebnis für mich haben.

C# und .NET Framework

Hier habe ich schon viel Zeit investiert, ich habe für Probleme schon umgesetzte Code-Strukturen. Teilweise kann ich ganze Funktionen oder sogar Klassen aus anderen Projekten importieren.

Ein weiterer Grund für C# und .NET Framework ist für mich, das ich parallel noch ein anderes Projekt auf dieser Basis programmiere. Und hier ist es nicht förderlich, bei parallelen Projekten (die sowieso schon unterschiedliche Objekte bedienen) auch noch den Sprachsyntax, Umgebung(Framework) oder sogar IDE (Visual-Studio) zu ändern.

Eine weitere Fragestellung meines Feldversuches war, ob Portierung oder Rewrite. Ich habe das hier an der einen oder anderen Stelle im Forum überflogen und erlaube mir diesbezüglich jetzt mal folgende Gesamtaussage.

Portierung nach Lazarus
Gesamtzeitlicher Aufwand gegenüber X-Force-Komplett Rewrite geringer.
Einstiegshürde (Erstaufwand, Schwierigkeit) für die Portierung sehr hoch. Es braucht Einarbeitung in den Original Delphi-Code und Kenntnisse von Lazarus. Dabei müssen sowohl Pre-Compiler Syntax übersetzt werden, wie auch ganze Objekte(Klassen) durch andere Objekte(Klassen) dargestellt werden.

Mir fehlt da derzeit die Zeit und auch die Gehirnmasse für. Das wenige Hirn, was ich noch habe, lade ich dann doch lieber mit kompatiblen C# Code und quäl mich weiter mit dem Framework rum.

Ein weiterer Unterschied zwischen Portierung und Rewrite ist der Aspekt, wesentlich freier programmieren zu können. Schwierigkeitsgrad für den Rewrite ist insgesamt höher(Summe), aber lässt sich besser kapseln, so daß es nicht zu dem Overkill-Schwierigkeitsgrad(Einstiegshürde) wie bei einer Portierung kommt.

Ansonsten kommt jetzt auch noch der Sommer dazwischen. Bischen Sonne und frische Luft tut mir auch ganz gut. ;-)

Da ich hier irgendwie das Gefühl habe ich bin alleine hier, versuche ich die Diskussion nochmal anzufachen.

Alle wollen das es irgendwie weitergeht hier, das ist klar. Keiner hat aber Zeit, Motivation, bzw. den Wissenstand, um den aktuellen Release weiterzucoden. Der derzeitige Sourcecode scheint hier wirklich niemanden mehr zu motivieren. Selbst für eine Portierung findet sich niemand, der das das durchziehen kann. Also der Code scheint so abschreckend zu sein, das alle hier irgendwie lieber den Rewrite bevorzugen. Diesbezüglich haben wir jetzt mehrere Ansätze zu diesem Thema.

Einmal von sujin mit python, einmal von Kreks mit C# und XNA und mein Ansatz mit C# und dem vorhanden Framework.

Dann wurde hier im Forum schon über viele Themen diskutiert, die eigentlich in der Ebene schon weiter oben anzutreffen sind. Ich fange jetzt aber mal auf der Ebene ganz unten an.

1. Manpower
Mit unseren derzeitigen Manpower bräuchten wir eigentlich die Diskussion hier gar nicht weiterführen, weil da müssen sich mindestens zwei finden für eine Diskussion. Des weiteren kann es bei einer Diskussion nur Demokratie geben, wenn die Beteiligen zu dem Thema gleichberechtigt sind. Angenommen wir hätten 10 Projektbeteiligte, aber nur einer programmiert die Basis und die anderen schauen zu, dann kann es da einfach keine Demokratie geben. Wer die Basis programmiert, entscheidet den Dialekt. Haben wir aber zwei People, die die Basis programmieren wollen, dann gibt es da Demokratie. Wobei, das auch nicht 50:50 ist. Kann ja sein, das von den Zweien einer wesentlich aktiver coden kann/will, dann hat der, der mehr Zeit in die Basis investiert auch mehr Stimmrecht.

2. Mac/Linux/Windows
Crosscompiling ist eine schöne Sache, wenn es derjenige der die Basis programmiert umsetzen will/kann. Mein Ding ist es nicht. Man muss dann auf Objekte setzen, die auf alle Systeme kompatibel zu bedienen sind. Des weiteren muss das Coding natürlich auch auf den verschiedenen Systemen getestet werden.

3. Programmiersprache

Delphi - Borland -> http://www.isdelphidead.com/ (wenn man das nötige Kleingeld hat.)
Pascal – Lazarus – Delphi-naher Dialekt
Python - Why Python is Slow -> https://jakevdp.github.io/blog/2014/05/09/why-python-is-slow/ *grins*
Java – braucht Java Development Kit zum programmieren und eine Runtime-Umgebung zum ausführen für die reinen User. IDE vielleicht Eclipse
C# - Managed Code – nicht wirklich plattformübergreifend, aber VisualStudio als IDE und ein großes Framework von Haus aus (hier ginge auch noch Visual C++ .NET oder Visual Basic die aufs gleiche Framework zugreifen)
C++ Hybrid zwischen maschinennah und hohem Abtraktionsniveau.
C sehr maschinennah, sprich damit auch schnell
Assembler – wenn man wirklich schnell programmieren will

Also die Wahl der Programmierumgebung entscheidet nicht unwesentlich über Systemlast und Geschwindigkeit auf der einen Seiten, und Abtraktionsniveau auf der anderen Seite.

Ich kann nur immer wieder meinen Hut vor den Programmierern der ersten Stunde ziehen, die noch in Assembler programmiert haben. Die waren noch kreativ und haben mit wenig Syntax viel Logik programmiert. Heute auf hohem Niveau, wenn wir die Objekte bedienen, gibt es diese Kreativität nicht mehr. Wie wir programmieren schreibt uns das Objekt vor. Dabei brauchen wir inzwischen viel Syntax für wenig Logik.

Doom wurde dann in c programmiert, schon etwas mehr Komfort, wie Assembler, aber natürlich auch schon langsamer. Das zieht sich dann immer weiter so. Wir bekommen immer mehr Funktionalität und bezahlen das mit Systemlast. Wenn du heutzutage Programmierer ansprichst, das ihr Game zu langsam läuft, sagen sie dir nur, kauf dir neue Hardware.

Wir müssen also jetzt entscheiden was uns wichtiger ist. Speed oder hohes Abstraktionsniveau?
Ich bevorzuge für Spiele eher Geschwindkeit.

Als nächstes müssen wir uns entscheiden ob uns Grafik wichtiger ist oder wir mehr Prioriät auf Textmanipulationen legen. Ich bevorzuge für Spiele eher Grafik.

Also braucht es erstmal primär eine Funktionalität Grafik zu handeln und das bitte mit ausreichend Speed. Text ist übrigens auch nur Grafik.

Sujin möchte gerne eine höhere Abstraktionsebene, damit so Dinge wie scrollbare Listen, Tooltips, Tabs, bunt formatierter Text, Radio-Buttons, Checkboxes, etc. mit wenig Aufwand zur Verfügung stehen. Dies bedeutet dann aber auch mehr Systemlast. Hier stellt sich dann die Frage, wie entsprechende Objekte, die das handeln, in der Systemlast aussehen.

Damit kommen wir zu den Objekten, die wir einsetzen wollen.

Wenn wir wenig selber programmieren wollen, nehmen wir gleich ein GameMaker System.

GameMaker: Studio Goes Free -> https://www.yoyogames.com/news/227

Hier noch ein Vergleich anderer Game-Engine
http://www.google.de/imgres?imgurl=http://www.gamesparks.com/wp-conten t/uploads/2014/06/gamemaker-layout.png&imgrefurl=http://www.gamesparks .com/blog/game-engine-analysis-and-comparison/&h=400&w=900&tbnid=EbqNy nOG_GgSnM:&zoom=1&tbnh=90&tbnw=203&usg=__qPvSBuXS0wDfyJV78k28Erv_nCs=& docid=SKBEtvmt_pMKKM

Ansonsten wenn wir doch ein bischen mehr programmieren wollen, wurde hier die FIFE engine - open-source multi-platform isometric game engine erwähnt.

Languages Supported: C++ and Python

http://archivewiki.fifengine.net/Tutorial:_Hello_World_from_scratch

falls aber jetzt jemand meint, das erspart ne Menge Zeit, hat er da zwar recht, aber der Zeitaufwand ist immer noch sehr hoch. Hier ist ein netter Bericht zu Unknown Horizons die die Engine einsetzen.

http://www.linux-community.de/Internal/Artikel/Print-Artikel/LinuxUser /2012/11/Das-Strategiespiel-Unknown-Horizons

Ansonsten gibt es auch noch den Ansatz den Kreks gemacht hatte mit C# und XNA

https://www.google.de/search?q=xna&tbm=isch&tbo=u&source=univ&sa=X&ved =0CDMQsARqFQoTCJOe5vuWksYCFYboLAodGPwBvw&biw=1536&bih=732

Dennoch bedeuten GameMaker-Umgebungen oder programmierbare GameEngines nicht gerade wenig Aufwand, um sich dort einzuarbeiten. Grundsätzlich gilt hier immer, das man nach ersten schnellen Erfolge später in Phasen kommt, wo man sich tief in die Objekte, Strukturen reinarbeiten muss, weil irgendwas nicht klappt. Des Weiteren hat man in bestimmten Bereichen keinen Einfluß mehr auf die Programmierung. Man muß die Dinge manchmal so als gegeben nehmen, auch wenn man es gerne anders hätte.

FIFE engine sieht gut aus, ohne Frage. Dann braucht es aber für die Basis Manpower, die das in Phyton oder C++ umsetzen können/wollen. Und bei der Komplexität braucht es auch einen Grafiker.

Also Manpower die wir nicht haben. Sujin sagt selber er hatte keine Zeit, Kreks ist leider verschollen, Dirk und Natter sind auch nur noch „Schläfer“ ;-) (Anspielung auf Dune der Wüstenplanet - Der Schlafende muss erwachen.“ Ne, die haben auch keine Zeit.

Bleiben noch Andiana, MADetter und meine Wenigkeit.

Das ist ein kniffliges Thema. Zum einen, ja, wer an der Seitenlinie rumsteht hat kein Recht den anderen was aufzudrängen, und wer Gutes beiträgt muss auch gehört werden. Aber es gibt noch andere wichtige Aufgaben als Code zu produzieren, und "der Aktivste ist hat im Zweifel Recht" ist keine gute Einstellung. Viele Open-Source-Projekte haben Anwandlungen von Meritokratie (aus gutem Grund), und Quantität ist nicht gleich Qualität. Eine gute Idee zeichnet sich nicht dadurch aus, dass sie von jemandem mit viel Freizeit stammt (auch wenn ein Mindestmaß an Freizeit nötig ist, um andere von der Idee zu überzeugen).

Das alles ist aber eh so müßig wie in einer dreiköpfigen anarchistischen Kommune darüber zu diskutieren, was man machen soll wenn man in den UN Sicherheitsrat berufen wird. Ein funktionierendes Team fällt nicht vom Himmel, aber es lässt sich auch nicht durch Worte heraufbeschwören, und oft überleben Pläne nicht den Kontakt mit der Realität. Über Organisationsstruktur zu reden, bevor es etwas gibt, was man organisieren kann, ist meiner Meinung nach Zeitverschwendung.

Aber wo ich gerade meinen Senf zu allem gebe: Ich habe inzwischen meine Zweifel, ob das Modell "Ich mache mein Ding und dann werden schon Leute kommen" überhaupt irgendeine Chance hat. Wenn ich jetzt viel Zeit hätte, die ich in so ein Projekt stecken könnte, ich würde raus gehen und versuchen Leute zu rekrutieren (nicht statt zu programmieren, aber auch).


Der Autor sagt ja schon im ersten Absatz, dass man da sehr wohl drum herum arbeiten kann :D Der Trick ist, so viel Code in einer anderen Sprache zu schreiben, dass ein Großteil der tatsächlichen Logik in schönem Python geschrieben werden kann, ohne viel Effizienz zu opfern. Insbesondere muss man also gute Abstraktionen finden. Der Erfolg von Python im Scientific Computing zeigt, dass das Prinzip wunderbar funktioniert, und die letzten paar Iterationen meines Engine-Designs machen mir Hoffnung, dass das auch für Spiele machbar ist.

Das Prinzip ist ein Entity-System, in dem es nicht ein paar monolithische Klassen gibt, die die ganze Funktionalität unter sich aufteilen, sondern ein offenes System im Stil einer relationalen Datenbank: Es gibt Entitys in der Spielwelt, an die beliebig verschiedene Klumpen von Daten angehängt werden können und die von untereinander unabhängigen Prozessen manipuliert werden. Diese Prozesse manipulieren immer nur Entitys, die für sie interessante Daten haben (z.B. jene, die UFO-Daten haben). Es gibt keine Interaktion zwischen Prozessen, höchstens insofern, dass zwei Prozesse die gleichen Daten auf einer Entity schreiben und lesen können (und vielleicht gibt es noch Events).

Das hat nicht nur diverse Vorteile für die eigentliche Spiellogik und Architektur der Engine, es lässt sich auch wunderbar optimieren: Die "Klumpen von Daten" werden statisch typisiert (auch wenn eine gegebene Entity alle oder keine davon haben kann) sodass der Speicher effektiv organisiert ist und die CPU gut damit rechnen kann. Prozesse können in, sagen wir, Python geschrieben werden, aber auch in der Sprache, in der der Kern der Engine geschrieben ist. Wenn man dann zum Beispiel das ISO-Rendering in C umsetzen will, muss nur die Rendering-Funktion in C geschrieben werden, und der ganze Python-Code muss sich nicht darum sorgen. Der C-Code seinerseits kriegt eine Datenstruktur fast wie man sie per Hand in einer "pures C" Engine entwerfen würde, und kann mit der effizient arbeiten.


Ich will dir echt nicht zu nahe treten, aber das ist eine sehr naive Formulierung. Es ist nicht so sehr, dass die Schlussfolgerungen falsch wären (außer bei Assembler, dazu gleich mehr), sondern die Charakterisierung "effizient = keine Abstraktion". Dass man den Fehler häufiger sieht, macht ihn nicht besser. Diese Denkweise ist nicht nur faktisch falsch, sie ist auch aktiv schädlich, wenn man versucht, Programme effizient zu machen.

Zunächst muss ich formell Beschwerde einreichen gegen die Idee, eine Programmiersprache hätte eine Eigenschaft namens "Geschwindigkeit". Man kann fast alles in fast allen Sprachen tun, inklusive der meisten Optimierungen. Was natürlich nicht heißt, dass alle Sprachen gleich gut sind, um effiziente Programme zu schreiben:

Manche Sprachen haben einfach ihrer Natur nach einen konstanten Overhead für jede einzelne Operation, die ausgeführt wird (z.B. Python). In Maßen lässt sich so etwas mit JIT Compilern optimieren aber es wird immer irgendwo zwischen unglaublich schwer und unmöglich sein, z.B. die Performance eines optimalen äquivalenten C-Programms zu erreichen.
Manche Sprachen haben zwar die Option, verschiedene Optimierungen manuell anzuwenden, aber es ist so aufwändig und die ganzen Bibliotheken machen es nicht, womit es nicht wirklich praktikabel ist, das überall durchzuziehen. Ein schönes Beispiel ist C#, wo man zwar Werttypen (structs) haben kann, aber 99% alles Typen notwendigerweise Referenztypen sind.
Andere Sprachen sind zwar Zeile für Zeile "optimal", aber so unhandlich, dass logische Optimierungen auf der Strecke bleiben, womit die Performance des gesamten Programms dann am Ende trotzdem scheiße ist. Damit kommen wir zu Assembler. Ein guter Grund, dass heute fast nie Assembler benutzt wird, ist Wirtschaftlichkeit (egal welche Metrik du für Produktivität nimmst, die Produktivität mit Assembler ist grauenhaft, so dass es meist nicht ökonomisch ist, darin zu programmieren. Aber selbst mit praktisch unbegrenzter Zeit ist Assembler im großen und ganzen nicht "schneller". Compiler Optimierungen sind simpel, heuristisch, und in ihrem Ausmaß beschränkt, und einige von ihnen gleichen "nur" Effizienzverluste aus, die von der Übersetzung einer Hochsprache in Assembler herrühren, aber sie funktionieren und sie sind automatisiert. Der Compiler wird nicht müde, der Compiler macht keine Fehler (oder zumindest viel weniger als Menschen). Optimierungen, für die ein Mensch nie die Zeit und Lust und Aufmerksamkeit hat, serviert der Compiler gratis. Und, wie Eingangs gesagt, eine höhere Abstraktionsebene ist nicht nur bequemer, sie ermöglicht auch, tiefgreifende Änderungen im "big picture" vorzunehmen. Letztlich ist es viel effizienter, drei Schritte zu machen, als drei hundert Schritte zu machen, selbst wenn im zweiten Fall jeder Schritt für sich etwas schneller passiert.

Es ist nicht der Fall, dass C und C++ (und Rust, um Schleichwerbung zu machen) Effizienz für Bequemlichkeit opfern und sind nur deshalb so beliebt, weil sie relativ wenig Effizienz in relativ viel Bequemlichkeit umwandeln. Tatsächlich opfern sie idealerweise gar keine Effizienz (oft nicht ganz wahr, aber so gut wie). Stattdessen schaffen sie Bequemlichkeit via gut gewählter Abstraktionen, so genannte "zero-cost abstractions"! Das sind Abstraktionen, die auf Maschinencode abgebildet werden können, ohne dabei zusätzliche Kosten reinzubringen, verglichen mit handgeschriebenem Assembler-Code, der das gleiche macht. Deshalb ist das:



... für sich genommen Unsinn. Ich verstehe schon, was du meinst, aber auch das ist nicht richtig. Natürlich soll es schnell sein. Aber alles in einer möglichst low-level Sprache zu schreiben, führt nicht zu Geschwindigkeit. Die Frage ist nicht, wie viel abstrahiert wird, sondern wie effizient der Maschinencode ist, der am Ende ausgeführt wird, und dafür ist die Sprache nur eine von vielen Zutaten.



Die möchte ich für Spielsatzersteller. Ob sie fertig verpackt sind oder einer von uns die bastelt, ist mir Wurst. Und jetzt kommst du schon wieder mit Effizienz... die Frage ist nicht, ob bunter Text und Scrollleisten existieren werden - sie werden auf jeden Fall gebraucht für etwas wie "X-Force 2". Die Frage ist, wie und von wem sie programmiert werden, und das beeinflusst die Effizienz.

An dieser Stelle muß ich auch nochmal auf ein anderes Thema lenken. Der eigentliche Grund, wieso ich mit einem eigenen Rendering angefangen hatte, sind unterschiedliche Auflösungen und Fullscreen-Umschaltung.

Wenn man sich so ein Produkt anguckt, wie WOW dann gibt es für alle mögliche Auflösungen entsprechend angepasste Grafiken. Der Vollbild-Modus funktioniert da natürlich einwandfrei auch über mehrere Bildschirme. Es gibt dort auch noch die Möglichkeit eines Fenster-Vollbildmodus. Für sowas braucht man aber jede Menge Know-How und auch Man-Power in der Grafik-Abteilung.

Ansonsten ist es eher üblich sein Spiel im normalen Vollbildmodus darzustellen. Ich arbeite mit zwei Monitoren und habe da schon unterschiedlichste Nebeneffekte bei schlechter Programmierung gehabt. Das X-Force startet derzeit gar nicht bei mir im Vollbild. Dosbox meint, wenn es die Monitorauflösung umschaltet, den zweiten Screen dementsprechend verschieben zu müssen. Ich erinnere mich auch noch an Erlebnisse, wo ich danach mein Desktop neu aufräumen konnte, weil ein Vollbildmodus so klein war, das die Desktopicons vom Win-System nach einem Crash des im Vollbildmodus ausgeführten Programmes total verschoben waren. Selbst neuere Spiele wie z.B. Civ4 machen im Vollbildmodus bei zwei Monitoren noch Probleme und holen z.B. andauernd die Maus zurück, wenn man kurz aufn zweiten Monitor will. Also Vollbildmodus kann schon manchmal nerven.

Auf der anderen Seite gibt es dann Spiele, die den Fenstermodus unterstützen, aber nur für ausgesuchte Auflösungen.

X-Force unterstützt hier z.B. 800x600, 1280x800, 1024,768.

Ich fahre aber auf mein System 1920x1080, da könnt ihr euch ausrechnen, wie das ohne Vollbildmodus aussieht.

Auf Vollbild 1280X800 16bit bekomme ich ne Fehlermeldung rein, auf 800X600 und 32 Bit gibt’s nur schwarzen Screen mit bischen flackern. Raus komme ich dann nur noch über Affengriff und Taskmanger und muss x-Force dann manuell killen.

Unabhängig von X-Force ist es weiterhin üblich für jede Grafikauflösung die entsprechende Grafik zu produzieren. Ne Menge Arbeit für ein Coder, der keine Grafikabteilung nebenan hat.

Im Handybereich und der App-programmierung (Android) ist das noch netter, da werden dann von jeder Grafik mal eben 4, 5 oder 6 verschiedene Varianten erwünscht. Android kümmert sich dann zwar alleine um die Wahl des Bitmaps (sofern der Name stimmt) aber richtig spassig ist das nicht, wenn man für jede Auflösung separate Grafiken erstellen muß.

Deshalb hatte ich mein eigenes Rendering gestartet, halt mit der Prio auf Grafik. Ich wollte unkompliziert Grafik in meine Programmierumgebung mit einbauen, dabei sollte die Größe der Grafik egal sein. Und Anstatt Vollbildmodus und mehreren statischen Auflösungen, unterstütze ich einfach das Resizing des Fensters. Ich nehme mir für meine Area eine schickes Bitmap, egal wie groß, dabei werden auch schon diverse Formate mit eingeladen. Dann wird das Bild in der Größe maskiert, und auf einen Hintergrundbildschirm mit einer fixen Auflösung projiziert. Der User stellt dann finale am Fenster seine Wunschgröße des sichtbaren Fensters ein. Per Resize individuell oder per Doppelclick auf die Titeleiste gleich maximiert.

Nehmen wir jetzt aber die übliche höhere Abstraktionsebene für die Textausgabe/Texteingabe, sprich scrollbare Listen, Tooltips, Tabs, bunt formatierter Text, Radio-Buttons, Checkboxes, etc. wird uns von dieser Abstraktionsebene auch das damit verbundene Resizing-Verhalten aufgedrückt. Für Desktop-Anwendungen hat das auch Sinn, da bleiben dann alle Texte gleich groß, das Ganze resized nicht wirklich, vielmehr verändern sich die Positionen und die Größe der umschließenden Container.

Im Zeitalter der immer größer werdenen Auflösungen, bauen die besseren Programme(Browser, Textverarbeitung, aber auch manche Games) dann in die entsprechenden Elemente eine Zoomfunktion ein, um die immer kleiner werdenden Schriften zu kompensieren.

Ich kann übrigens über meine winforms-klasse diese Elemente durchaus aufrufen. Nur Resizen die Inhalte dieser Elemente im Fenster nicht proportional, da sie eigene Schrittgrößen-Definitionen haben.

An der Stelle muß ich dann mal fragen, was ihr besser findet.

Feste Auflösungen, also im Prinzip nur Vollbildmodus oder Fenstervollbildmodus, weil der normale Fenstermodus ohne Resize-Möglichkeit nicht wirklich schön ist, plus Bearbeitung und Handling der Grafiken für alle zu unterstützenden Auflösungen.

Oder halt der simple Ansatz
Gebt mir "irgendeine Grafik" und stell dir dein Fenster selbst ein, wie es dir am besten gefällt.