Womit werden Spiele programmiert?

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();

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()

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();

@rapso: solange du deine rechtschreibfehler nicht beseitigst wird er sie zum anlass nehmen um deinen post lächerlich zu machen! "holen" mit einem "l", nicht "hollen"! und "auf jeden fall", nicht "auf jeden falls"!

TGGC muss immer recht haben es hat keinen sinn mit ihm zu diskutieren.