Inzwischen haben ja wahrscheinlich die meisten mitgekriegt, daß im DHCC eine Tutorial-Reihe zu SDL von mir zu finden ist.

Ich habe mir die letzten Tage Gedanken gemacht, wie ich diese Reihe am besten weiterführen sollte nachdem die grundlegendsten Dinge geklärt sind.

Zunächst einmal wären da die Themengebiete, die es bei SDL noch zu behandeln gibt:
- Maus (kommt in Kapitel 5)
- Transparenz/Colorkeying (kommt in Kapitel 6)
- direkter Zugriff auf die Bildschirmoberfläche (PutPixel und so)
- Palette
- Audio
- CD-ROM
- Joystick (ich hab kein Joystick, also vergeßt's *g*)
- Multithreading
- Interface für OpenGL

Welche dieser Themen sind eurer Ansicht nach am wichtigsten?

Und noch etwas: Ich persönlich denke, daß ein reines Abhandeln der einzelnen SDL-Funktionen ziemlich fad wäre und habe deswegen vor, mehr oder weniger ein kleines Spiel zu programmieren (wie ich ja im Tutorial auch schon erwähnt habe). Das hat zur Folge, daß das Tutorial ab Kapitel 6 immer weniger mit SDL zu tun haben wird (also vielleicht 20% SDL, 80% Spieleprogrammierung). Was haltet ihr davon?

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

- Multithreading
- Interface für OpenGL
würde mich persönlich interessieren.

Wegen OGL kannst du auch unter http://nehe.gamedev.net schauen. Findest auch relativ viel.

Zitat:

Hellfire postete
- Multithreading
- Interface für OpenGL
würde mich persönlich interessieren.

Dito

Are you gonna miss me ?
Only until I go to the Newsstand and buy a Hustler

Naja, es geht ja nicht um OpenGL selbst sondern mehr um das Interface von SDL zu OpenGL. Ich werde natürlich nicht OpenGL selbst komplett behandeln, da würde ich ja noch durchdrehen...

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Egal was du schreibst, ich werde lesen ^_^

Generell Multithreading und erweiterte Animationstechniken *langsamsdlfanwerd*

void CHudSayText :: EnsureTextFitsInOneLineAndWrapIfHaveTo( int line ) -- Aja?

Was wollt ihr eigentlich alle mit Multithreading? Im Endeffekt hat SDL ja nix mit Multithreading zu tun, und MT ist auch nicht unbedingt das Tollste... aber naja, ich werde wohl mal was zum Thema schreiben :)

Allerdings braucht man, um Threading vernünftig erklären zu können, irgendeine Basis, so daß das Threading auch Sinn bringt. Und die Situationen, in denen Threading Sinn macht sind meist recht komplex.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Nunja ich sags mal so. Jeder der mal Java programmiert hat und dort mit Threads gearbeitet hat (da smacht man in Java dauernd) wird sich von C ein wenig "verarscht" vorkommen. Denn Multithreading in Java ist so simpel geregelt, dass man es einfach gerne verwendet (ausserdem kommt man bei Internetanwendungen und Spielen wohl kaum drum herum). Bei C (bei reinem C unter DOS gibt es kein Multithreading, deswegen muss man schon in Linux programmiert haben, um zu wissen wie es geht *g*) und C++ (WinAPI) ist MT längst nicht so simpel. Und SDL stellt eine drastische Vereinfachung dar und zwar für C/C++ (soweit ich das auf deren Homepage gelesen habe). Deswegen fände iche s interessant. Nicht für mich persönlich sondern für Leute die gerne mal wissen wollen wie MT funzt und es an einfachen Beispielen lernen wollen.

So =)

void CHudSayText :: EnsureTextFitsInOneLineAndWrapIfHaveTo( int line ) -- Aja?

auf jeden fall multithreading und animierte grafiken (war das jetzt oben dabei? -egal)

die idee mit dem spiel wäre nicht schlecht aber ich finde es sollte erstmal primär um SDL gehen :)

Zitat:

Denn Multithreading in Java ist so simpel geregelt, dass man es einfach gerne verwendet (ausserdem kommt man bei Internetanwendungen und Spielen wohl kaum drum herum).

Ich komme mir etwas seltsam vor, denn ich habe erst vor zwei Tagen einen entsprechenden Rant auf den GameDev-Foren geschrieben. Aber was solls.

Die Behauptung, man käme bei Spielen nicht um Threads herum, ist lächerlich, zumindest heutzutage und wahrscheinlich auch noch die nächsten paar Jahre.

Es gibt grundsätzlich nur zwei Situationen, in denen man Threads braucht.

1) Du schreibst eine GUI-Anwendung, die eine bestimmte rechen- oder I/O-intensive Arbeit im Hintergrund erledigt. Denkbar ist hier z.B. ein Komprimierungsprogramm, bei dem schonmal im Hintergrund ein paar 100MB oder auch GBs hin- und herverschoben werden. Im Fall dieses Komprimierungsprogramms würdest du dann in einem Thread die GUI managen während der andere den Komprimierungsalgorithmus durchführt. Hierbei werden individuelle Threads verwendet.
In diesem Fall sind Threads notwendig, da die Realtimeanwendung GUI sonst nicht mehr schnell genug reagieren könnte.

2) Ein Hochleistungsprogramm (zumeist ein Server, wobei dieser Fall sogar auf Spiele zutreffen könnte) wird über einen Pool aus Arbeiterthreads gemanagt falls es auf einem Multiprozessorsystem ausgeführt wird. Dadurch kann die Leistung der zusätzlichen Prozessoren ausgenutzt werden.
Hier geht es um nicht-individuelle Threads (aka jeder Thread führt den gleichen Code aus) und pure Leistung. Es sollten nicht mehr Threads als CPUs vorhanden sein, es sei denn die Threads führen Blocking Operations aus (also entweder zeitaufwendige nicht-asynchrone [d.h. normale] I/O oder Operationen auf blocking sockets).

In allen anderen Fällen führt Multithreading zu einer Zunahme an benötigten Betriebssystemen, zusätzlichen Taskswitches und einem Performanceverlust durch die Notwendigkeit von Locks etc...
Zudem wird der Code unübersichtlicher. In Java ist dies zwar vielleicht nicht der Fall, das geht aber sicherlich auch auf Kosten der Effizienz des Lockings.

Gerade bei Spielen spielt noch ein weiterer Faktor eine wichtige Rolle. Multithreading ist eine kritische Angelegenheit. Nur weil man zwei Threads auf zwei CPUs laufen hat heißt das noch lange nicht, daß das Programm doppelt so schnell läuft. Dies kann allerhöchstens dann der Fall sein wenn die Threads komplett unabhängig voneinander sind. Dies ist z.B. bei HTTP-Servern fast der Fall, da der Großteil der Zeit mit I/O oder mit dem Parsen und Ausführen von Scripts verbracht wird. Diese Scripts sind natürlich voneinander unabhängig [Anm: Ich rede hier von einem tatsächlich gethreadeten Server, und keinem prozessbasierten wie z.B. Apache]

Bei einem IRC-Server ist das aber schon nicht mehr der Fall. Was ist z.B. wenn zwei Ops in einem Channel sind, und es trifft gleichzeit ein "MODE #channel -o anderer_op" von beiden ein? Hierbei handelt es sich um eine Race Condition, und die Threads müssen Critical Sections oder Locks für sich beanspruchen während sie die Operation ausführen, damit es nicht zu Datenkorruption kommt. Je größer die Überlappung der Datenbereiche, auf die die Threads zugreifen, ist, desto mehr solcher Locks braucht man.
Zusätzlich treten dann noch Cache-Pingpong-Effekte (bei MP-System) auf wenn man einen Datenbereich hat, der von vielen Threads sowohl gelesen als auch geschrieben wird, da ja immer wieder die Caches der CPUs synchronisiert werden müssen.

So gesehen: Für ein richtig großes MMO-Spiel kann Threading durchaus etwas bringen, und vielleicht sehr begrenzt auch etwas für andere Spiele. Generell sind Threads aber bei weitem nicht die Lösung eines Problems, sondern lediglich ein Hilfsmittel zur eigentlichen Lösung.

Und gerade bei Spielen sind diese überlappenden Datenbereiche traditionell extrem groß, noch größer als bei einem IRC-Server.

So gesehen ist es eigentlich ganz gut, daß Multithreading von C nicht gerade einfach gemacht wird.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.

Ich habe nicht gesagt, dass man bei der Programmierung von Spielen nicht anders vorgehen kann. Man kann selbstverständlich ein Spiel schreiben, das nur aus dem Game-Loop besteht, keine Frage. Aber (du hast es schon gesagt) was ist, wenn man ein Multiplayer Spiel programmiert? Du kommst bei der Programmierung leistungsfähiger Server garnicht darum herum, Threads zu verwenden. Ein Grossteil der Socket Funktionen (z.B. es gibt auch noch viele andere Beispiele) warten bis sie ihre Aufgabe erledigt haben und kehren dann erst zurück. Und was ist, wenn der Server dabei auch noch rein zufälligerweise Grafik und andere Sachen verwalten muss? Ich würde mal sagen, spielen würde dann unheimlich Spass machen, vor allem wenn das Spiel alle 10 Sekunden stehenbleibt.

Du magst das so sehen, dass MT kaum benötigt wird, aber diese Ansicht teile ich in keiner Hinsicht.

So =)

void CHudSayText :: EnsureTextFitsInOneLineAndWrapIfHaveTo( int line ) -- Aja?

Zitat:

Ein Grossteil der Socket Funktionen (z.B. es gibt auch noch viele andere Beispiele) warten bis sie ihre Aufgabe erledigt haben und kehren dann erst zurück.

Eben genau deshalb gibt es Non-Blocking-Sockets...

Wenn ein MMO-Server auch noch Grafik verwalten muß dann stimmt übrigens etwas am Design nicht. Wenn man für administrative Aufgaben ein graphisches Frontend braucht dann sollte das in Form eines gesondert authorisierten Clients ablaufen.

Ich darf nun noch einmal anmerken: Threads erhöhen _nicht_ die Performance, sondern sie erniedrigen sie. Andererseits muß man irgendwie von MP-System Vorteile ziehen können, z.B. im Fall eines MMO. Einfach irgendwelche Threads dann zu implementieren ist aber Quatsch auf Grund der angesprochenen Probleme mit Locks.

Im Falle eines MMO ergibts sich aber eine recht elegante Möglichkeit (IMO). Zunächst einmal könnte man Datenbankoperationen in ein gesondertes Programm (oder Thread) auslagern. Zweitens könnte man die Welt in mehrere Abschnitte unterteilen, und diese dann jeweils von einem einzelnen Thread verwalten lassen. Dadurch ließen sich die notwendigen Locks minimieren, da ja nur an den Grenzen Probleme auftreten können.

cu,
Prefect

Widelands - Gemütliche Aufbaustrategie, Free Software
Noch ein Blog - Lerne, wie die Welt wirklich ist, aber vergiss niemals, wie sie sein sollte.