Womit werden Spiele programmiert?
-
oder auch MS Visual C++ 7 -> 13 Threads. Was machen die damit?
-
@rapso:
Aber woher wird denn diese callback dann aufgerufen, wenn nicht aus einem anderem Thread? Bei DPlay8 ist's zumindest so, das dies aus einem anderen Thread geschieht.Mensch, den Headhunter wollten die doch auch schon, EA nimmt tatsächlich jeden 8).
-
und trotzdem hat EA noch so die ziemlich besten Spiele auf dem Markt. Echt verblüffend
-
Naja - die besten Games von EA???
Mhhh - das halte ich für ein Gerücht. Das ist doch meist nur das 10. Sequel vom 10 Sequel und dann der abklatsch vom 5. Sequel.Ein paar verschönerungen in der Grafik - und ändern der Teamnamen - das reicht :-S
Mir währs lieber, EA würde sich mal wieder auf die guten alten Zeiten besinnen und doch Bards Tale 4 fertig stellen
-
@SnorreDev:
Na und, Hauptsache viel verkauft 8).
-
Jupp - komischerweise kaufen es die Leute noch. Die Firman haben doch schon Angst was neues zu bringen, da die meisten inovativen Sachen leider floppen :-S
Siehe z.B. Looking Glass...
-
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?
und wozu hat ein pc dann interrupts...
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
ps. nö, mit EA hab ich noch nicht wirklich kontakt, ich kenne bloss leute von da, weil die mal meine mitarbeiter waren :).. wie auch von anderen firmen.
die vielen threads sind keine von den programmen selbst ausgelösten, das können welche vom treiber sein, denn das sind dann nur sowat wie haltepunkte die nicht ausgeführt werden, bis ein event auftaucht (z.B. drawindexprimitiv ist fertig), dass sind aber nicht wirklich mehrere parallel ablaufende dinge...
rapso->greets();
-
Original erstellt von SnorreDev:
**Jupp - komischerweise kaufen es die Leute noch. Die Firman haben doch schon Angst was neues zu bringen, da die meisten inovativen Sachen leider floppen :-SSiehe z.B. Looking Glass...**
stimmt
man muss sich da nur z.B. den FM2003 anschauen oder fifa, jedes jahr bekommt der ein leicht anderes styling und ein neues features und das verkaufen die dann als vollversion und schöpfen so den markt auf günstige weise ab.
rapso->greets();
-
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.
-
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();
-
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.....................!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
-
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. ]
-
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();
-
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...)
-
muss man beim cluster wenn man das programmiert irgendwas mit kommunikation regeln oder läuft das wie ein standart multiprozessor system?
rapso->greets();
-
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. ]
-
Gibts das auch für Windows Netzwerke?
-
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?
-
Nein, das sind wirklich echte Threads des Spiels.
-
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();
