Womit werden Spiele programmiert?
-
Das ist Absicht. Die wollen nicht das ihr dahinterkommt wie man Spiele erstellt
So halten die sich euch vom Hals. Ich sage nur die Illuminaten (oder so ählich) habe sich da breit gemacht
-
schon allein multi threads zu coden ist heavy ... :p
-
Ich behaupte auch mald as ist unmöglich.
-
Original erstellt von Netzwerk-Latenz:
Das ist Absicht. Die wollen nicht das ihr dahinterkommt wie man Spiele erstellt So halten die sich euch vom Hals. Ich sage nur die Illuminaten (oder so ählich) habe sich da breit gemacht 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 ;).
-
Original erstellt von 1ntrud0r:
schon allein multi threads zu coden ist heavy ... :pna hoffentlich kommt niemand auf diese idee bei spielen *multithreadgänsehaut*
rapso->greets();
-
Original erstellt von rapso:
na hoffentlich kommt niemand auf diese idee bei spielen *multithreadgänsehaut*Äh warum nicht?
Was wäre den so schlimm daran?
-
1. debuggen könnte scheisse sein, es haben sich schon öfters bei mir systeme aufgehängt, wenn ich ein breakpoint in einem multithread programm setzte.. ich weiß nicht weshalb.. vielleicht bug im devstudio?
2. es gibt öfters vielzuviel verschleiss z.B. die schlaue idee in einem thread bei niedrigster priorität auf den soundbuffer zuwarten
3. es gibt noch schlauere, die render und logic in seperaten threads machen, da kann man sich dann in den kopf schiessen wenn in ein und demselben bild objeckte nichtzueinander passen
4. wenn irgendein modul in einem spiel länger als 33ms zum durchlauf braucht, dann ist es scheissen programmiert oder die mindestanforderung ist zu hoch, wobei, was gibt es schon bei einem spiel das bei einer verzögerung von 32ms nicht korrekt funktioniert?... also braucht man, wenn man ein spiel plant, keinen zusätzlichen thread.threads sollte man nur bei multiprozessor und server anwendungen machen... was ein spiel nur als server braucht.
seh ich da wat total falsch?
rapso->greets();
-
quatsch. fast jedes aktuelle spiele benutzt threads. und zwar nicht zu wenig. 10 - 15 stück meistens
-
Original erstellt von rapso:
**threads sollte man nur bei multiprozessor und server anwendungen machen... was ein spiel nur als server braucht.seh ich da wat total falsch?**
Jipp, wenn das Spiel als Client in einem Netzwerkspiel läuft, dann sollte man Threads auch verwenden.
-
@<fiel>
komisch, soviele threads in einem spiel, wow. dann macht es EA, die firma bei der ich arbeite und andere firmen von denen ich das gegenteil weiss seit jahren falsch :D... selten dass ich bei einem spiel mehr als 2 threads insgesammt sah, und das auch nur dann im ladescreen, weil manche festplattenzugriffe länger als 100ms dauern und somit das rendering einer "loading..." animation nicht flüssig wäre... (oder biste doch nur ein troll?, die vermutung liegt nahe )@TGGC wenn man blocking benutzt beim socket, dann schon, man kann das aber auch per callbacks realisieren. Es gab letztens erst ne untersuchung (ich glaube von IBM) und die meinten im resúme, dass per callbacks (also system events) die http-server mehr seiten liefern könnten als per multithreading, weil der verschleiss wegen den threads die nur in einer schleife warten viel zu hoch ist.
rapso->greets();
-
Ich wundere mich ja selbst warum die Spiele mit sovielen Threads arbeiten. Ich weiss auch nicht was die da alles machen. Hab nochmal geguckt.
Praetorians - 13 Threads
Splinter Cell - 10 ThreadsBeides im Spiel, nachgeguckt mit dem Windows XP Taskmanager. Andere Spiele haben auch soviele Threads, hab nur gerade die beiden drauf.
-
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.
