Womit werden Spiele programmiert?

[spiele_programmierer]

Um mal zurück zum Thema zu kommen :

Spiele in VisualBasic und Java geschrieben werden.
Die erstgenannte Sprache wird wegen ihrer Stabilität und ihrer Intuitiven Semantic
sehr bevorzugt genommen, die letztere wegen OOP und hauptsächlich wegen Geschwindigkeit.

[rapso]

lol

nene Qbasic und java-script, damit kann man nur was erreichen...

also weder basic noch java werden genutzt, sicherlich gibt es vielleicht ein paar ausnahmen, aber bei java ist immer im hintergrnd der gedanken, dass dort ne schlechte performance ist und wegen dem garbage collector ne menge müll rumliegen kann. VB hingegen ist dafür da leicht oberflächen zu stöpseln und nicht rechenaufwändige spiele zu machen.. sicherlich, du kannst auch ein javaspiel fürs handy coden

aber normalerweise wird c++ genutzt, in den meißten fällen bei pcspiele der von M$ und bei konsolen der vom devkit.

rapso->greetS();

[Sgt. Nukem]

http://www.chrissawyer.com/faq3.htm
"What language was RollerCoaster Tycoon programmed in?
It's 99% written in x86 assembler/machine code (yes, really!), with a small amount of C code used to interface to MS Windows and DirectX."

Naja, das glaube ich trotzdem nicht. Glaubt das eigentlich irgendwer hier?? Sicher, über JavaScript und PHP kann man sich lustig machen, aber wie sieht dat hiermit aus?!? Allein mit BNE und dem Kack 'ne vernünftige Schleife zu coden is' doch schon übel. Geschweige denn Eingabedaten der Maus zu bearbeiten, und den Scheiß zu zeichnen... najaaa...
Gut, aufwendige 3D-Berechnungen gibt's ja nicht... okay...

Ahhhhrg, und Sgt. Nukem hat's verraten, da werden wohl bald ein paar Leute in schwarzen Anzügen (oder was auch immer die tragen) an seiner Tür klopfen .

NEEEEEEEEEEEEEEEEEEEEEEEEIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIINNNNNNNNNNNNNNNNNNNNNNNNNN.....................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

[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.