Womit werden Spiele programmiert?

[nman]

Original erstellt von rapso:
threads sollte man nur bei multiprozessor und server anwendungen machen... was ein spiel nur als server braucht.

Also ich weiß nicht, ich mag Anwendungen die gut parallelisierbar sind sehr gerne, die laufen auf meinem Rechner so schön schnell wenn ich ihn wiedermal an den openMosix-Cluster meines Cousins angeschlossen habe!
Warum soll fortschrittliche Technologie nur für Server gut sein? (Das mit der Komplexität allein zählt nicht, wenn das so wäre dürfte man auch kein C programmieren, denn VisualBasic ist schließlich viel einfacher aufgebaut...)

edit: Und dass Rollercoaster Tycoon fast nur in Assembly programmiert wurde glaube ich auch nicht.

[ Dieser Beitrag wurde am 18.03.2003 um 22:10 Uhr von nman editiert. ]

[rapso]

soweit ich weiß, wäre es schwachsinn ein cluster im singlethread zu haben... das ist ein ganz anderer zusammenhang.

wozu parallesieren, wenn man nur eine cpu hat, das bringt nur performance verlust.

aber ich gebe dir recht, sowas macht auch spass, ich lasse in der firma auch manchmal meine raytracer auf 100maschinen die nacht durchlaufen ...

rapso->greets();

[nman]

Original erstellt von rapso:
soweit ich weiß, wäre es schwachsinn ein cluster im singlethread zu haben... das ist ein ganz anderer zusammenhang.

Genau das ist der Punkt, darum freue ich mich immer wieder über Programme die MT laufen!

(Stimmt dennoch nicht immer - wenn ich SingleThreaded Anwendungen auf meinem Rechner starte und der damit überfordert ist werden diese automatisch an einen stärkeren Rechner im Netz abgegeben, das ist überaus praktisch...)

[rapso]

muss man beim cluster wenn man das programmiert irgendwas mit kommunikation regeln oder läuft das wie ein standart multiprozessor system?

rapso->greets();

[nman]

Bei openMosix musst Du gar nichts regeln, das läuft völlig automatisch!
edit: http://openmosix.sourceforge.net/ Schaus Dir mal an, das is viel leichter zu benutzen als man glauben könnte!

[ Dieser Beitrag wurde am 18.03.2003 um 23:03 Uhr von nman editiert. ]

[B*sti]

Gibts das auch für Windows Netzwerke?

[TGGC]

Original erstellt von rapso:
die callbacks werden wohl so gehandhabt wie schon seit eh und je, oder glaubst du, dass es irgendwo in windows einen thread gibt der die ganze zeit z.B. den tastaturstatus abfragt.. den netzwerk status, den soundkarten status?

Tatsächlich laufen die Gerätetreiber nicht als Thread irgendeines Spiels, wär ja auch doof, beim Beenden des Spiels würde der Gerätetreiber als zugehöriger Thread ebenso beendet und man könnte nicht mehr darauf zugreifen.

Original erstellt von rapso:
und wozu hat ein pc dann interrupts...

z.b. um Multitasking zu realisieren

Original erstellt von rapso:
**die callbacks werden als message an jede applikation geschickt, ganz normal, und solange die die nicht annimt, stopfen interrupts die in buffer.

as easy as it is**

Ja in der Theorie hört sich das alles easy an, aber wie läuft denn sowas in der Realität? Wie schickt man denn eine "Message"? Wie signalisiert ein Applikation, das sie nicht annimmt? Was passiert, wenn ein Interrupt in dem Moment auftritt, wo man den Buffer gerade halb ausgelesen hat?

[fiel]

Nein, das sind wirklich echte Threads des Spiels.

[rapso]

Original erstellt von TGGC:
Ja in der Theorie hört sich das alles easy an, aber wie läuft denn sowas in der Realität? Wie schickt man denn eine "Message"? Wie signalisiert ein Applikation, das sie nicht annimmt? Was passiert, wenn ein Interrupt in dem Moment auftritt, wo man den Buffer gerade halb ausgelesen hat?

eine applikation muss nicht signalisieren dass sie nicht annimt, es geht anderesrum, wenn sie fähig ist eine z.B. socketverbindung anzunehmen, dann regestriert sie einen callback und bekommt denn dann, wenn jemand connected...

solche callbacks gibt es auch für sound (jedenfalls gab es die in dx5.. seitdem nutz ich andere soundapi und kann nix zu sagen)

das problem dass ein interrupt auftaucht mitten indem man nen buffer ausließt, das besteht schon ewig und ist eigentlich kein problem. als ich zu doszeiten noch selber treiber gecodet hab, ging das so vor sich, dass die app nicht selbst gelesen hat, sondern die funktion zum lesen aufgerufen hat, diese hat erst den buffer kopiert und dann den status über den buffer aktualisiert.

also meißt sind das ringbuffer, in den fällen hat man dann den (im treiber) globalen pointer nach dem copy erhöcht und wann auch immer ein interrupt auftritt, er bringt keine probleme mit sich...

außer buffer-overflows, doch für diese fälle muss das tcp/ip herhalten.

rapso->greets();

[Sgt. Nukem]

mov ax, mode
int 10h
les di, [SEGMENT]
mov al, BYTE PTR color
mov ah, al
mov cx, 32000
rep stosw
end.

Feddich!!! R-Tycoon 3!

[nman]

Original erstellt von B@sti:
Gibts das auch für Windows Netzwerke?

Nein, nicht dass ich wüsste.

[SnorreDev]

@Sgt. Nukem:
Warum sollte ein RT nicht in ASM realisiert worden sein?

Wenn man es richtig anstellt, kann man WinAPI, DX usw. ohne großen Aufwand nutzen. Für ganz faule - Auf C/C++ funktionen in der MSVCRT.DLL und ähnliches zugreifen - geht wirklich. Z.B. Malloc läßt sich super nutzen *g

Edit: http://www.deinmeister.de/wasmtut.htm -> kuckt euch das doch mal an - das ist nicht so Krass mit ASM. Solange man Macros & Co verwenden kann

Und nochwas - er nutzt MASM - warum sollten dann Schleifen mit diesem MACRO Asm schwer sein? Schon mal IF - ELSE oder ähnliches genutzt?

[ Dieser Beitrag wurde am 19.03.2003 um 15:45 Uhr von SnorreDev editiert. ]

[TGGC]

Original erstellt von rapso:
eine applikation muss nicht signalisieren dass sie nicht annimt, es geht anderesrum, wenn sie fähig ist eine z.B. socketverbindung anzunehmen, dann regestriert sie einen callback und bekommt denn dann, wenn jemand connected...

Dir ist aber schon klar, das eine hochpriore ISR in einem Treiber nicht einfach eine Callback in deinem Programm aufrufen kann. Dann wird deine Callback die selben Privilegien haben, wenn sie abstürzt, schiesst sie dann den ganzen Rechner ab. Und das wollen wir ja nich ;).

Original erstellt von rapso:
das problem dass ein interrupt auftaucht mitten indem man nen buffer ausließt, das besteht schon ewig und ist eigentlich kein problem.

Sicher gibts das Problem schon lange und es ist auch schon lange gelöst (BTW: nicht von mir ), aber wenn du unter Windows direkt dein Spiel von einem IRQ rufen lässt, dann müsstest du dieses Rad ja neu erfinden.

Original erstellt von rapso:
als ich zu doszeiten noch selber treiber gecodet hab, ging das so vor sich, dass die app nicht selbst gelesen hat, sondern die funktion zum lesen aufgerufen hat, diese hat erst den buffer kopiert und dann den status über den buffer aktualisiert.

Ja aber das bringt ja nix, dann muss deine Applikation ja ständig diese Funktion aufrufen, um zu überprüfen, ob neue Daten da sind. Gerade eine solche Verschwendung von CPU Zeit will man gerade mit Threads verhindern. Der Thread legt sich einfach schlafen und wird erst wieder aktiv, wenn Daten angekommen sind. Das meinte ich auch damit, das mehrere Threads in einem Spiel meist nur für Sachen, wie auf Netzwerkpakete zu warten, gut sind.

[rapso]

Original erstellt von TGGC:
**
Dir ist aber schon klar, das eine hochpriore ISR in einem Treiber nicht einfach eine Callback in deinem Programm aufrufen kann. Dann wird deine Callback die selben Privilegien haben, wenn sie abstürzt, schiesst sie dann den ganzen Rechner ab. Und das wollen wir ja nich ;).**

mir schon, dir auch oder wozu schreibst du etwas, was ich schon früher hier beschrieben habe.. den callback regestriert man bei windows und bekommt das als message wie auch tastatur eingaben... (troll doch nicht dauernt so rum)

Original erstellt von TGGC:
Sicher gibts das Problem schon lange und es ist auch schon lange gelöst (BTW: nicht von mir ), aber wenn du unter Windows direkt dein Spiel von einem IRQ rufen lässt, dann müsstest du dieses Rad ja neu erfinden.

wer will das? ich holle mir die messages von windows...

Original erstellt von TGGC:
Ja aber das bringt ja nix, dann muss deine Applikation ja ständig diese Funktion aufrufen, um zu überprüfen, ob neue Daten da sind. Gerade eine solche Verschwendung von CPU Zeit will man gerade mit Threads verhindern. Der Thread legt sich einfach schlafen und wird erst wieder aktiv, wenn Daten angekommen sind. Das meinte ich auch damit, das mehrere Threads in einem Spiel meist nur für Sachen, wie auf Netzwerkpakete zu warten, gut sind.

nein, meine funktion macht garnix ich bekomm eine windows message und arbeite die ab, wenn nichts ansteht dann kommt logic und rendering und dann von vorne.. ein ganz normaler mainloop.. und wenn eine message davon meinem spiel sagt, dass neue daten da sind, hollt es die daten ab.
also da ist kein dummer thread der in einer schleife läuft und auf daten wartet so wie bei einem extra thread (der entweder in der app oder im treiber oder im winapi in der schleife läuft)

rapso->greets()

[Sgt. Nukem]

Für ganz faule - Auf C/C++ funktionen in der MSVCRT.DLL und ähnliches zugreifen - geht wirklich. Z.B. Malloc läßt sich super nutzen *g

Toll. Am Ende hat man dann ein C/C++ Programm mit einer Handvoll Inline-Assembler-Aufrufen, oder wie!?

Und nochwas - er nutzt MASM - warum sollten dann Schleifen mit diesem MACRO Asm schwer sein? Schon mal IF - ELSE oder ähnliches genutzt?

Hmmm... also eigentlich bin ich fest davon überzeugt, daß IF - (THEN -) ELSE nichts mit "Schleifen" zu tun haben...
Naja, ich kenn' nur 8086er Assembler, und nur'n bißchen. Wenn also das "Macro" in dem Wort so viele Vorteile bringt.... naja...

[rapso]

da gibt es auch .while...

[TGGC]

Original erstellt von rapso:
nein, meine funktion macht garnix ich bekomm eine windows message und arbeite die ab, wenn nichts ansteht dann kommt logic und rendering und dann von vorne.. ein ganz normaler mainloop.. und wenn eine message davon meinem spiel sagt, dass neue daten da sind, hollt es die daten ab.
also da ist kein dummer thread der in einer schleife läuft und auf daten wartet so wie bei einem extra thread (der entweder in der app oder im treiber oder im winapi in der schleife läuft)

Ich glaub du hast da was nicht ganz verstanden. Die ISR ruft nicht irgendeine Callback in deinem Code auf bzw. schickt eine Message an die WndProc. Warum das so sein muss, sagte ich ja schon. Wenn ein IRQ auftritt, dann legt sich dein Prozess erstmal zwangsweise schlafen und der IRQ wird behandelt. Dann wird erstmal überprüft wohin die Daten müssen. Wenn sie zu deinem Fenster gehören, wird das dann als Message in dessen Input Queue gelegt. (Wohlgemert passiert das nicht alles in der einen ISR, die ISR löst es nur aus.) Ist das alles erledigt, wird dein Programm wieder geweckt und läft weiter. Aber du musst jetzt erstmal die Message holen und an die WndProc schicken, sonst passiert gar nix. Du musst also doch immer die Queue pollen, sonst funktioniert es nicht. (Die zweite Möglichkeit, nämlich asynchron auf die Messages zu warten, funktioniert wieder nur mit mehreren Threads. Einer wartet (schlafend) auf die neue Message, während der andere ein neues Frame berechnet.)

Wenn man jetzt aber in einem anderen Thread auf den (z.b. Netzwerk-) Event wartet, wird nachdem ISR abgelaufen ist, direkt zu diesem Thread gewechselt. Dieser bearbeitet dann das Ereignis und legt sich wieder schlafen, indem er wieder die asynchrone Funktion ruft. Dann läuft der "Hauptthread" dort weiter, wo er durch den IRQ unterbrochen wurde.

Arbeitet man also mit mehreren Threads muss man nichts pollen o.ä., sondern alle Threads werden im Idealfall genau dann angeschoben, wenn sie gebraucht werden. Dafür muss man aber halt mit einigen Nachtteilen, wie Synchronisation, leben.

[rapso]

du hast es echt nicht verstanden
also:

du sagst windows, du möchtest eine message bekommen, wenn daten zum empfangen verfügbar sind

in dem main loop, wo du auch maus und tastatur messages bekommst, bekommst du dann diese message dass daten verfügbar sind, das aber auch nur, falls welche da sind, das brauchst du nie zu prüfen.
danach kannst du gleich die logic aufrufen, die die daten verarbeitet, dann das rendering und dann wieder von vorn.

0% rechenlast für nicht vorhandene daten in der applikation.
kein bisschen synchronisationsprobleme.
keine reibungsverluste durch task bzw threadwechsel an irgendeiner stelle in der eigenen app.

optimaler prozess ablaufe

empfang von daten (key,maus,net,sound,...), bearbeitung in der logic, ausgabe durch rendering.

ich sehe nicht, wo da ein problem sein sollte, bzw. wo es zu irgendwelchen nachteilen kommt.

aber ich bin mir sicher, du findest etwas kleines spizfindiges, das einem auf einer P4HT maschine irgendeinen vorteil bringt.

rapso->greets();

[TGGC]

Original erstellt von rapso:
in dem main loop, wo du auch maus und tastatur messages bekommst, bekommst du dann diese message dass daten verfügbar sind, das aber auch nur, falls welche da sind, das brauchst du nie zu prüfen.

Du bekommst nicht einfach so Messages du musst sie schon holen. Dabei überprüfst du dann ja auch automatisch.

Original erstellt von rapso:
0% rechenlast für nicht vorhandene daten in der applikation.

Daten verursachen ja ehh keine Rechenlast.

Original erstellt von rapso:
kein bisschen synchronisationsprobleme.

Doch, nur das Windows die erledigt.

Original erstellt von rapso:
keine reibungsverluste durch task bzw threadwechsel an irgendeiner stelle in der eigenen app.

Ich sag doch, beim IRQ geht den Thread ehh schlafen.

Original erstellt von rapso:
optimaler prozess ablaufe

Was auch immer das heisst.

Original erstellt von rapso:
ich sehe nicht, wo da ein problem sein sollte, bzw. wo es zu irgendwelchen nachteilen kommt.

Das Problem ist die responsiveness und ein u.U. nicht zum Anwendungsfall passendes Modell. Solange es kein Problem gibt brauchst du auch nicht explizit mehrere Threads nutzen. (Oben wurde ja festgestellt das ein Programm bereits implizit genügend Threads anstösst.)

[rapso]

wie oft denn noch

du hollst die messages auf jeden fall

auf jeden falls!!!!!

ließt du überhaupt nicht was ich schreibe?

du hollst windows messages z.B. für tastatur, für maus und auch für netzwerk, aber wenn dir das zu aufwändig ist, wie willst du dann deine daten bekommen?

ob du nun mit netzwerk oder ohne arbeitest, man hollt im main loop auf jedenfall einmal die info ein ob welche anliegen

die betohnung liegt bei EGAL... egal ob netzwerk oder nicht

das bedeutet 0% rechenlast zusätzlich fürs netzwerk wenn keine daten anliegen, ganz im gegenteil zum Thread...

das ist doch nicht wirklich unmöglich zu verstehen

*letztepostindiesemthreadgemachthat*

oder verTrollst du mich hier die ganze zeit nur?

rapso->greets();