Neuer User: DOSferatu

[DOSferatu]

Aber ich unterscheide zwischen Spiele und realer Welt und widerspreche der Behauptung das rein virtuelle Spiele Menschen zum realen Killer machen können. Wer hier keinen Unterschied macht, der sollte wirklich keine Killerspiele spielen.

Es ist nicht so, daß ich's nicht unterscheiden könnte. Mir machen diese Art Spiele nur keinen Spaß. Ich will meine Spielfigur ja irgendwie (wenn auch nur ein wenig) mögen oder so. Und Soldaten finde ich nicht "cool" oder so - eher im Gegenteil.
Aber der hauptsächliche Grund, warum ich sowas nicht spiele, ist, weil ich es irgendwie öde finde. Ich penne schon beim Zugucken fast ein.

Ich hätte gerne eine Auflösung von 19.200 x 12.000 Pixel und ein Rechner der damit eine 3D-Landschaft in Echtzeit mit Raytracing berechnen kann und damit 100 fps. erreicht und damit kilometerlange Maps erzeugt,
in den es nur so wimmelt von sich bewegenden Tieren, Pflanzen und Objekten und jedes diese Dinge anders aussieht und man alles interaktiv verändern kann.

Realität nervt mich. Deshalb spiel ich ja Computerspiele. Würde mich Realität interessieren, würde ich einfach vor die Tür gehen...
Hohe Auflösung erfordert ne Menge Speicher, Rechenzeit... im Klartext: Dieses idiotische Rechnerwettrüsten dieser hirnverbrannten Dauerzocker... - Naja, muß jeder selber wissen...
Die Urmenschen machten Schwanzvergleiche - die Raser machen den Schwanzvergleich mit ihren Karren - und die Zocker mit ihren Kisten... (Entschuldigung, falls mir die Begeisterung hier ein wenig fehlt. Ich bin wohl kein sogenannter "richtiger Mann"...)

Dann würde ich auch gerne verschiedene Genre von Spielarten miteinander verküpfen. Also z.b einen Egoshooter(wie Joint Operations) mit einem Strategie-Spiel(wie Companie of Heros) kombinieren.
Die Strategen dürfen dabei wie gewohnt aus der Vogelperspektive die Schlacht koordinieren und wenn genug Rohstoffe gesammelt wurden dann uns Egoshooter anfordern und uns Aufgaben geben die wir aus der Egoperspektive erledigen dürfen.

Das Problem ist, daß mich sowohl Egoshooter als auch Strategiespiele überhaupt nicht interessieren.

Eine Formel brauche ich nicht unbedingt selber verstehen um sie benutzen zu können, auch wenn mir das besser gefallen würde wenn ich die Formel auch verstehen kann.

Ich WILL ja alles verstehen. Daher schreibe ich auch alle meine Routinen selbst und verwende keine fertigen Bibliotheken.

Jetzt könnte natürlich jemand fragen, warum ich dann so ein Spiel wie Xpyderz gemacht habe:
Nun - es hatte eigentlich nur als ein kleiner Test angefangen, so etwas hinzukriegen. Und daher wollte ich irgend etwas einfaches machen. Und Ballerspiele sind nunmal das Primitivste, was man machen kann. Die Idee kam so zustande: Ein Kumpel hat mir vor etlichen Jahren mal erzählt, daß man von diesem "Snipes" (ein Textmodespiel für max. 5 Personen über IPX, ihrem Paket NWLITE als Testspiel beigelegt von Novell damals,,.) auch mal eine grafische Variante machen könnte. Und mir ist das Jahre später eingefallen. Xpyderz enthält nun aber mittlerweile viel mehr als dieses alte "Snipes", aber das Grundprinzip ist immer noch ähnlich. Aber vom Spielprinzip her ist Xpyderz natürlich primitiv - so wie jedes Ballerspiel. (Und 3D, realistischere (Truecolor-)Grafik und hohe Auflösungen machen ein Ballerspiel übrigens nicht weniger primitiv.)

Ich will damit nicht sagen, daß Ballerspiele immer Mist sind und nicht auch mal Spaß machen könnten. (Und ich spiele auch mal sowas, z.B. so Shoot'em'ups = 2D-Raumschiffballerspiele). Man sollte nur nicht so tun, als wäre das Raketenwissenschaft oder so. Wenn man Bock auf Ballern hat, hat man Bock auf Ballern - das ist ein ganz normaler hormonell bedingter Effekt. Sollte man nur nicht so ernst nehmen und dabei komplex erörtern wollen, wie intelligent und lehrreich sowas ist...

Den von der Politik erfundenen Terminus "Killerspiele" kann ich übrigens auch nicht mehr hören. Wenn man es ganz genau nimmt, ist Super Mario World ja auch ein Killerspiel. Dann dürfte man ja fast gar nichts anderes mehr spielen außer Patiencen oder Zahlenratespiele...
Die "Killerspiel"-Diskussion wird von irgendwelchen Scheuklappen-"Gutmenschen" immer dann herausgeholt, wenn etwas schlimmes passiert ist und man irgendwem die Schuld geben muß. Und man kann ja nicht einfach die Schuld bei gesellschaftlichen Mißständen suchen (z.B. daß sich um Problemschüler einfach nicht mehr gekümmert wird) - da müßte man ja evtl SELBER Verantwortung übernehmen. Und man kann ja auch nicht einfach frei herumliegende(leicht zu besorgende Waffen dafür verantwortlich machen und manchen Schützenvereinen auf die Finger klopfen - denn so CSU-Politiker sind ja oft selber im Schützenverein... Also, was macht ein etwas älterer Politiker, um irgendwo eine Schuldzuweisung vorzunehmen? Er sucht die Schuld bei dem, was ihn selber am wenigsten betrifft und ihm am meisten am Arsch vorbeigeht: Computerspiele.

[sehr off topic]
(Das erinnert einen immer an so Leute, die selbst starker Raucher sind, sich von fettem Essen ernähren, mehr Bier trinken als gut für sie ist und die zwei Schritte vor einem Herzinfakt stehen - und anderen Leuten, die nicht rauchen, keinen Alkohol trinken und ein wenig auf ihre Ernährung achten, ständig erzählen, wie schlimm Cola ist (die vielleicht ihr einziges Laster ist). Oder Leute, die selber lebensgefährlich fettleibig sind und kaum zwei Treppenstufen steigen können ohne daß ihnen schwindlig wird und sie Ringe vor den Augen zu sehen --- und Leuten, die ein wenig auf ihre Figur achten um sich normal bewegen zu können, um nicht für sich selbst und andere eine Beleidigung für die Augen zu sein (und es am Ende gar keine Kleidung mehr gäbe, in denen sie nicht beschissen aussehen würden) immer gleich Magersucht vorzuwerfen...)
Aber das ist natürlich nur eine Anmerkung und eine persönliche Meinung...
[/sehr off topic]

Und wer den Unterschied zwischen Computerspielen und der Realität nicht erkennt - der sollte nicht nur keine "Killerspiele" mehr spielen, sondern der gehört in die geschlossene Nervenheilanstalt.

[freecrac]

Hohe Auflösung erfordert ne Menge Speicher, Rechenzeit... im Klartext: Dieses idiotische Rechnerwettrüsten dieser hirnverbrannten Dauerzocker... - Naja, muß jeder selber wissen...

Neben-Effekt auf solchen MoBos für DOS Realmode-Anwendungen: Bei mir bleiben nur ca. 2.5 GB Ram nutzbar, auch dann wenn 8 GB Ram eingesteckt werden.
Mit älteren AGP/PCI-MoBos bekommt man bei 4GB aber mehr freien Speicher.

Xpyderz enthält nun aber mittlerweile viel mehr als dieses alte "Snipes", aber das Grundprinzip ist immer noch ähnlich. Aber vom Spielprinzip her ist Xpyderz natürlich primitiv - so wie jedes Ballerspiel. (Und 3D, realistischere (Truecolor-)Grafik und hohe Auflösungen machen ein Ballerspiel übrigens nicht weniger primitiv.)

Ich will damit nicht sagen, daß Ballerspiele immer Mist sind und nicht auch mal Spaß machen könnten. (Und ich spiele auch mal sowas, z.B. so Shoot'em'ups = 2D-Raumschiffballerspiele). Man sollte nur nicht so tun, als wäre das Raketenwissenschaft oder so. Wenn man Bock auf Ballern hat, hat man Bock auf Ballern - das ist ein ganz normaler hormonell bedingter Effekt. Sollte man nur nicht so ernst nehmen und dabei komplex erörtern wollen, wie intelligent und lehrreich sowas ist...

Die Egoperspektive hat den Vorteil das man überascht werden kann und hinter jeder Ecke sich etwa Unerwartes befinden kann. Man kann vom ersten Eindruck dann getäuscht und in eine Falle gelockt werden.
Das alleine erzeugt schon eine gewisse Neugier. Und je nach ob man sich durch dichtbesiedelte Gebiete, oder auf dem freien Feld mit weniger Deckungsmöglichkeiten sich mit seiner Gruppe unter Beschuss sich fortbewegt, ist ein angepasstes Vorgehen ratsam. Im freien Gelände bleibt man besser in Bewegung und sucht Möglichkeiten von zwei Flanken anzugreifen, oder den Gegner einzukreisen ohne selber überrant zu werden. Oder man bekömmt etwas Höherangst wenn man über ein schmales Brett in luftiger Höhe balanciert. So Unterscheiden sich 3D-Shooter mit der Egoperspektive doch erheblich von Shooter aus der Vogelperspektive oder gar in 2D.

Dirk

[wobo]

Neben-Effekt auf solchen MoBos für DOS Realmode-Anwendungen: Bei mir bleiben nur ca. 2.5 GB Ram nutzbar, auch dann wenn 8 GB Ram eingesteckt werden.
Mit älteren AGP/PCI-MoBos bekommt man bei 4GB aber mehr freien Speicher.

Habe ich nicht verstanden. Wieso sind unter Dos im RealMode wg. des MoBos nur ca. 2,5 GB möglich? Gut die Grafikkarte und ggf. noch andere Karten können sich was abzwacken, aber gleich 1,5 GB??

@DosFeratu: Wie geschrieben, ist auf meinem langsamen PC bei Deiner Jump-n-Run-Demo immer der Tastaturpuffer übergelaufen. Dies passiert aber nicht, wenn ich den emm386 installiert habe. Dann ist Deine Demo absolut flüssig (und der Tastaturpufferüberlauf tritt auch überhaupt nicht auf). Ich kann mir das nicht erklären. Für gewöhnlich macht der emm386 den PC ja nicht schneller.

wobo

[DOSferatu]

@DosFeratu: Wie geschrieben, ist auf meinem langsamen PC bei Deiner Jump-n-Run-Demo immer der Tastaturpuffer übergelaufen. Dies passiert aber nicht, wenn ich den emm386 installiert habe. Dann ist Deine Demo absolut flüssig (und der Tastaturpufferüberlauf tritt auch überhaupt nicht auf). Ich kann mir das nicht erklären. Für gewöhnlich macht der emm386 den PC ja nicht schneller.

Hab's mal mit und ohne EMM386 gestestet. Macht bei mir keinen Unterschied.
Ich habe einen mörderischen 486 DX-4 (eigentlich dieser sogenannte X5), mit 133 MHz.
Keine Ahnung, was da bei Dir braun ist.
Mit welchem Deiner DOS-Rechner spielst Du das denn? Mit dem 386sx16 oder mit dem 486dx40?

[freecrac]

Neben-Effekt auf solchen MoBos für DOS Realmode-Anwendungen: Bei mir bleiben nur ca. 2.5 GB Ram nutzbar, auch dann wenn 8 GB Ram eingesteckt werden.
Mit älteren AGP/PCI-MoBos bekommt man bei 4GB aber mehr freien Speicher.

Habe ich nicht verstanden. Wieso sind unter Dos im RealMode wg. des MoBos nur ca. 2,5 GB möglich? Gut die Grafikkarte und ggf. noch andere Karten können sich was abzwacken, aber gleich 1,5 GB??

Neben der Grafikkarte(GTX 295-PCIe) habe ich noch ein Soundkarte(Xfire-PCI) eingebaut. Den IDE-Controller habe ich deaktiviert und nutze nur den Sata-Controller. Alles zusammen belegt 1,5GB.
Mit REX Prefix oder den 64 Bitmode kann man natürlich auch mehr als 4GB adressieren wenn vorhanden.

@DosFeratu: Wie geschrieben, ist auf meinem langsamen PC bei Deiner Jump-n-Run-Demo immer der Tastaturpuffer übergelaufen. Dies passiert aber nicht, wenn ich den emm386 installiert habe. Dann ist Deine Demo absolut flüssig (und der Tastaturpufferüberlauf tritt auch überhaupt nicht auf). Ich kann mir das nicht erklären. Für gewöhnlich macht der emm386 den PC ja nicht schneller.

wobo

Das verstehe ich auch nicht.

Dirk

[wobo]

@DosFeratu: Wie geschrieben, ist auf meinem langsamen PC bei Deiner Jump-n-Run-Demo immer der Tastaturpuffer übergelaufen. Dies passiert aber nicht, wenn ich den emm386 installiert habe. Dann ist Deine Demo absolut flüssig (und der Tastaturpufferüberlauf tritt auch überhaupt nicht auf). Ich kann mir das nicht erklären. Für gewöhnlich macht der emm386 den PC ja nicht schneller.

Hab's mal mit und ohne EMM386 gestestet. Macht bei mir keinen Unterschied.
Ich habe einen mörderischen 486 DX-4 (eigentlich dieser sogenannte X5), mit 133 MHz.
Keine Ahnung, was da bei Dir braun ist.
Mit welchem Deiner DOS-Rechner spielst Du das denn? Mit dem 386sx16 oder mit dem 486dx40?

Alles auf meinem 486dx40vl (8MB PS/2, 70ns; 256k Cache; Spea V7 VEGA+ VGA (cl5426) mit 1 MB Videoram). Ist eigentlich 'ne schnelle Kiste. Kopiert auf die VGA ca. 10 MB/s (zum Vergleich: eine 16bit ISA ET4000 schafft max. 2.67 MB/s - auf jedem PC (sofern der ISA-Bus vorschriftsmäßig mit 8 Mhz getaktet ist). 2.67 MB/s ist wohl die praktische Obergrenze für Standard ISA. Praktische Obergrenze ist natürlich auch wieder theoretisch: wer kopiert denn schon ununterbrochen...).

Der 486dx40vl ist eigentlich so schnell, dass ich lange Zeit gar nicht wusste, wie ich diese Power ausnutzen kann - und auch heute noch damit Probleme habe. Mit Mathe habe ich mich seit knapp 20 Jahren nicht mehr beschäftigen müssen. 3D und sonstiges fällt damit weg. Und zeichnen kann ich auch nicht, so dass es halt mit Super-großen Bitmaps auch nix wird. Ich bin halt mit 'nem 286-12 und 'ner 8-bit-oak-VGA (ca. 500 kb/s) groß geworden, so dass sich schon hieraus meine intellektuelle Beschränkung auf 16x16 - Pixel grosse BitMaps ergibt ;->.

Den 386sx16 habe ich eigentlich nur aus 2 Gründen: zum einen ist sein Innenleben total aufgeräumt. Und er hat eine onboard 16bit vga (wd90c11), die 3.67 MB/s in der Sekunde schafft (mit 11 Mhz übertakter ISA-Bus). Mein Ballergame schafft auf dem 386sx16 in der Anfangsphase (wenn also so gut wie keine Gegner da sind) z.B. noch 35 FPS. Zum Vergleich: ein Original IBM PS/2 mit 386dx25 und original onboard vga (8bit, max. 600 kb/s), schafft in der gleichen Phase nur 12 FPS! Gut, mein Game braucht halt keine Mathe und ist defacto auf Sprite-Kopiererei beschränkt. Aber irgendwie zeigt das, was auch aus einer CPU wie dem 386sx eigentlich herauszuholen ist (oder wäre, wenn man coder-guru wäre), wenn sie adäquat ausgestattet ist. Außerdem kommt mir der 386sx entgegen, weil ich in Turbo Pascal programmiere. Turbo Pascal ist 16 bit, der 386sx (nach aussen) auch. Außerdem benutze ich bisschen 386er-Befehle (Flat4Grm, Unreal), was der 386sx auch ein bisschen kann.

Wenn ich also knallhart bin: ein (gut ausgestatteter) 386sx16 ist also für meine PC-Fähigkeiten vollkommen ausreichend.

Mein Dos-Rechner ist trotzdem der 486dx40, d.h. wenn ich nichts dazu schreibe, dann habe ich's auf diesem Rechner ausprobiert.

Ein 486dx133 ist natürlich schon 'ne Höllenmaschine. Der ist gut und gerne in allen Belangen dreimal so schnell wie mein 486dx40 und - wenn man 32bit nutzt - 18-mal so schnell wie mein (gut ausgestatteter) 386sx16, wenn ich mich nicht verschätzt habe.

Das erinnert mich jetzt an einen Artikel in der CHIP (war 'ne Computerzeitschrift) aus dem Jahr 1990. Das war die Zeit als noch 286-12 mit 8bit-vga verkauft wurden (und ausreichend waren). Das Maß aller Dinge war damals ein 486dx25 bzw. 486dx33 (Kostenpunkt DM 25.000). In dem Artikel stand tatsächlich, dass man NIEMALS eine CPU (auf Silizium-Basis) haben könnte, die mehr als 100 Mhz (HUNDERT!) hat. Dies sei die physikalische Grenze, da ansonsten die Leiterbahnen so heiß würden, dass die Elektronen von einer Bahn auf die andere springen würden. Naja - hat wohl noch niemand dran gedacht, dass man auf 'ne CPU Kühler und Lüfter draufklemmen kann.


Was den Tastaturpuffer-Überlauf und emm386 anbelangt: Irgendwie dämmert mir, dass ich dieses Phänomen in den 90ern schon mal festgestellt habe (Hatte halt 10 Jahre totale PC-Pause; außerdem programmiere ich immer ohne emm386 wegen Flat4Grm). Wenn bei mir der emm386 installiert ist, hatte ich auch früher wesentlich seltener einen Tastaturüberlauf. D.h., natürlich nicht, dass dann mein Rechner schneller ist. Er wird halt nur nicht verlangsamt, wenn das BIOS unterbricht, um das PC-Piepsen auszulösen. Erklären kann ich mir das allerdings trotzdem nicht. Der Tastaturpuffer ist ja auch mit emm386 nur 16 Byte groß...

wobo

PS: Meine Geschwindigkeitsbestimmungen der Datendurchsätze habe ich mit dem DOS-Programm dr.hardware vorgenommen. PC-Config (in der letzten Dos-Version 9.xx freeware) kommt überall auf ähnliche Größenwerte, wobei PC-Config immer nur den Byte - Durchsatz mißt (also keine Copys mit Word oder DWord).

[DOSferatu]

Ja, in meinem 486er ist auch eine Grafikkarte mit ET4000 Chip drin (heißt Horizon 64).
ABER: Sie ist PCI. Das könnte es vielleicht erklären. In Xpyderz und auch in diesem Demo wird in jedem Frame das ganze Bild komplett einmal aufgebaut. Sprites kommen noch dazu (ich schreibe direkt in den Grafikspeicher).
Also: Wenn ich - nur mal das "Level" alleine - pro Frame 64000 Pixel (320x200) setze. Dann braucht die Grafikkarte z.B. für 50 Frames/Sekunde mindestens 3,2 MB Datendurchsatz pro Sekunde.
Der Datendurchsatz meiner Grafikkarte ist knapp 17 MB pro Sekunde.

[wobo]

Ich hätte gerne eine Auflösung von 19.200 x 12.000 Pixel und ein Rechner der damit eine 3D-Landschaft in Echtzeit mit Raytracing berechnen kann und damit 100 fps. erreicht und damit kilometerlange Maps erzeugt,
in den es nur so wimmelt von sich bewegenden Tieren, Pflanzen und Objekten und jedes diese Dinge anders aussieht und man alles interaktiv verändern kann.

Ich dachte zuerst schon: freecrac, du hast Dich verschrieben und meinst 1920x1200... ;->>> ...kann ich aber irgendwie schon nachvollziehen, obwohl ich ja eher der Low-Performer bin.

wobo

[wobo]

Ja, in meinem 486er ist auch eine Grafikkarte mit ET4000 Chip drin (heißt Horizon 64).
ABER: Sie ist PCI. Das könnte es vielleicht erklären. In Xpyderz und auch in diesem Demo wird in jedem Frame das ganze Bild komplett einmal aufgebaut. Sprites kommen noch dazu (ich schreibe direkt in den Grafikspeicher).
Also: Wenn ich - nur mal das "Level" alleine - pro Frame 64000 Pixel (320x200) setze. Dann braucht die Grafikkarte z.B. für 50 Frames/Sekunde mindestens 3,2 MB Datendurchsatz pro Sekunde.
Der Datendurchsatz meiner Grafikkarte ist knapp 17 MB pro Sekunde.

Die et4000 dürfte aber eine der 2. Generation (et4000/w32) sein. Der Datendurchsatz von 17 MB/s ist mit dword-copy erfolgt, oder?

Ich nehme auch an, Du kopierst die Map mit dwords in die VGA. Meine Cirrus Logic VGA ist halt trotz VESA-Local-Bus nur 16 bittig, d.h. "movsd" bringt keinen großen Vorteil gegenüber "2*movsw". Wäre mit ein Grund, warum meinem PC bei XPYDERZ ein bisserl die Puste ausgeht.

(Aber keine Sorge. Wenn ich Weihnachten ein bisserl Zeit habe, schaue ich, was an meinem p75 so hängt.)

Und wie gesagt: Ins VGA zu kopieren, macht noch kein Game. Viel Zeit geht ja schon für's Kollisionsabfragen u.a. drauf. Ich verliere auch noch ein Viertel der Zeit allein für das Abfragen und Abwarten des VRetraces - und zwar unabhängig vom verwendeten PC (386sx, 486dx, p75). Zeit, die einfach brach liegt. Müßte auf Triple-Paging umstellen, wenn ich das richtig verstanden habe. Geht aber auch nicht, weil mir dann das VGA-Ram ausgeht...

Übrigens, ich wollte hier mit meinem "Gejammere" nicht den Eindruck erwecken, Deine Engines (XPYDERZ, Jump ' n Run) seien mir zu langsam. Im Gegenteil: ich habe den Eindruck, Deine Engines gehören jedenfalls zu den schnelleren. Es gibt auf meinem PC KEINE Engine, die derartiges Fullscreen-Scrolling (und noch Animationen, Gegner-"intelligenz" etc. obendrauf) in voller Framerate schafft. Entweder ist der Bildschirmausschnitt verkleinert oder die Framerate ist gering (Dxxm hat auch nur 13-18 FPS).

[DOSferatu]

Die et4000 dürfte aber eine der 2. Generation (et4000/w32) sein. Der Datendurchsatz von 17 MB/s ist mit dword-copy erfolgt, oder?

Ich habe das nicht selbst gemessen, sondern damals mal mit irgendeinem Programm.

Ich nehme auch an, Du kopierst die Map mit dwords in die VGA.

Ich "kopiere" gar nicht, ich schreibe das Level / die Sprites / den Text direkt in die VGA. Und das tue ich nur byteweise. Der Grund dafür ist, daß ich die Pixel nicht waagerecht, sondern senkrecht schreibe. (Wer weiß, wie der Mode-X funktioniert, wird auch ahnen, warum ich das so mache: wenn ich das "Level" schreibe, wechsle ich insgesamt nur 4x die Plane. Und nach jedem Wechsel schreibe ich alle 4. Spalten des Levels. Bei Sprites mache ich es etwas billiger: Die pixle ich zwar auch senkrecht - aber da wechsle ich die Plane nach jeder Spalte, soweit ich mich erinnere... - Die Arcade-Uni, die Levels und Sprites erzeugt ist halt schon 6 Jahre alt. Kann mich auch nicht mehr an jeden Unsinn erinnern, den ich da angestellt habe.

Meine Cirrus Logic VGA ist halt trotz VESA-Local-Bus nur 16 bittig, d.h. "movsd" bringt keinen großen Vorteil gegenüber "2*movsw". Wäre mit ein Grund, warum meinem PC bei XPYDERZ ein bisserl die Puste ausgeht.

Ich glaube nicht. Wie gesagt, ich schreibe byteweise.

Und wie gesagt: Ins VGA zu kopieren, macht noch kein Game.

Ich glaube doch. Wenn Doom mal abgestürzt ist, hat man halt gesehen, daß die den Mode-X benutzen.

[quote="wobo"}Viel Zeit geht ja schon für's Kollisionsabfragen u.a. drauf.[/quote]
Kollisionsabfragen? Meinste jetzt allgemein? Ja, bei Xpyderz geht ein guter Teil der CPU-Leistung dafür drauf. Oder soll ich das so verstehen, daß Du Kollisionsabfragen in Deinem Grafikpuffer (und pixelgenau) machst? Ich mache z.B. keine pixelgenauen Kollisionsabfragen. Das "Demo" da (mit GameSys2) kann 4 "Formen" benutzen - Quadrat, Kreis, Rechteck, Ellipse - die man "um die Figur" legen kann (beliebige Ausmaße) - der Mittelpunkt ist der Hotspot der Figur/des Sprites.

Ich verliere auch noch ein Viertel der Zeit allein für das Abfragen und Abwarten des VRetraces - und zwar unabhängig vom verwendeten PC (386sx, 486dx, p75). Zeit, die einfach brach liegt. Müßte auf Triple-Paging umstellen, wenn ich das richtig verstanden habe. Geht aber auch nicht, weil mir dann das VGA-Ram ausgeht...

Xpyderz kann man auch ohne V-Retrace Abfrage spielen. Da ich bei Mode-X 320x200 ganze 4 Bildschirmseiten habe, benutze ich die auch (mache sozusagen "Quadruple Buffering").

Übrigens, ich wollte hier mit meinem "Gejammere" nicht den Eindruck erwecken, Deine Engines (XPYDERZ, Jump ' n Run) seien mir zu langsam.

Ich weiß, daß mein Zeug nicht optimal ist und da noch einiges mehr drin wäre. Aber ich programmiere z.B. ja nur im 16bit-Mode (zwar mit 16/32 Bit Registern und mit den erweiterten Segmentregistern FS und GS). Und ich bin ja nicht id-Software...

Im Gegenteil: ich habe den Eindruck, Deine Engines gehören jedenfalls zu den schnelleren.

Naja... Das glaub ich zwar eher weniger. Ich wäre froh, wenn's so wäre...

Es gibt auf meinem PC KEINE Engine, die derartiges Fullscreen-Scrolling (und noch Animationen, Gegner-"intelligenz" etc. obendrauf) in voller Framerate schafft. Entweder ist der Bildschirmausschnitt verkleinert oder die Framerate ist gering (Dxxm hat auch nur 13-18 FPS).

Naja, es liegt eben viel am Datendurchsatz der Grafikkarte. Als ich meinen 286er auf 486/66 umgerüstet hatte, lief Doom trotzdem noch sehr ruckelig und nur im "LowRes" Mode war es einigermaßen OK. Aber das lag eindeutig an der alte "Original VGA" ISA Grafikkarte. Die hatte nur (mit demselben Tool getestet wie meine Horizon64) 0,5 MB / Sekunde Datendurchsatz. Nehmen wir also an, man hat unten diese Anzeige bei Doom eingeblendet und hat (grobe Schätzung) so 50000 Pixel pro Frame zu übertragen. Da kann sich jeder ganz einfach ausrechnen, daß das maximal 10 fps ergibt - egal, wie schnell die CPU oder die 3D-Routine ist. Ich hatte mich damals schon gewundert, daß das trotz 486/66 so ruckelt. Und als ich dann die jetzige Grafikkarte drin hatte, lief es plötzlich flüssig. Das Problem ist ja, daß eine langsame Grafikkarte das ganze System runterbremst. Weil die CPU, wenn sie etwas in die Grafikkarte schreibt, ja "wartet", bis es drinsteht. (Weil ja theoretisch der nächste Befehl den Wert wieder auslesen könnte...) Und die CPU kann den nächsten Wert erst schreiben, wenn der andere drin ist. Und bei geringem Datendurchsatz muß eine schnelle CPU halt dauernd auf die langsame Grafikkarte warten...

[wobo]

Kollisionsabfragen:

Pixelgenau? Auf meinen Rechnern, mit meinen Programmierfähigkeiten? Haut nicht hin! Bei einer Pixel genauen Kollisionsprüfung hätte man ja noch mehr Abfragen als beim Sprite-Setzen. Oder man müßte mit Bitmasken für die Sprites arbeiten und die testen (dürfte wohl die bessere Lösung sein). Habe ich aber alles noch nicht durchgedacht und noch nie versucht.
Meine Kollisionsabfragen sind einfache Rechtecke um die Sprites. Bei einem Action-Shooter-Game sollte das eigentlich langen. Im Regelfall rasen die Schüsse auf die Objekte bzw. die Objekte untereinander so schnell zu, dass die Rechteck-Abschätzung zu ausreichenden Ergebnissen führen sollte. Bei meinen Shooter habe ich das immer so gemacht und noch nie das Gefühl gehabt, eine Kollision wäre fehlerhaft erfolgt. (Anm.: ich gehe allerdings immer sehr tolerant mit mir und meinen Produktionen um... ...hier in Bayern sagt man eh all' Weil': "Passt scho'!").
Aber bei Jump 'n Run bin ich da schon kritischer. Zwar nicht bei der Gegner-Gegner bzw. Schuss-Objekt Kollision. Aber bei der Abfrage, ob mein Hero eine Plattform noch erwischt, bin ich schon kritisch, wenn er optisch über die Plattform hinwegsegelt und trotzdem abstürzt. Negatives Beispiel war für mich hier Bio Menace von Apogee.

Aber auch bei der Jump 'n Run - Engine sollte die Rechteck-Abschätzung auch in Bezug auf die Plattform ausreichen. Hinsichtlich oben genannter Fehler (BioMenace) gehe ich einfach davon aus, dass quasi nur ein Hero-Mittelpunkt abgefragt wird. Das halte ich für Kollisionsabfragen einfach nicht für ausreichend.

Deine Variationen für die Kollisionsabfragen (Quadrat, Kreis, Rechteck, Ellipse) fand ich übrigens äußerst innovativ. Hierauf wäre ich nie gekommen und hätte mich auch nicht getraut so zu denken. Es hat mir richtig Spass gemacht, damit rumzuspielen. Negativ aufgefallen ist mir dabei auch bei keiner Variante was.

Aber Rechteck scheint für mich dennoch das schnellste und zugleich ausreichend treffsicheres Mittel zur Abschätzung der Kollision zu sein. Die meisten Sprites dürften doch recht gut durch ein Rechteck umrissen werden, zumal die Sprites ja in der Regel als rechteckig angelegte BitMaps vorliegen. Das einzige, was ich mir mal gedacht habe, war, zwei Rechtecke zu machen, falls ein Objekt eher dreieckig ist. Also ein kleines Rechteck für die Dreiecksspitze und ein grosses für die Basis des Rechtecks.


Quadriple Paging:
Als Deine Engine ein wenig arg meinen PC zum Schwitzen gebracht hat - aber dafür sind PCs ja da! - habe ich mir schon den Kopf zerbrochen, ob/wie Du die 4. Bildschirmseite nicht zum Speichern der 32x32 - Tiles nutzen könntest. Allerdings gehe ich nicht davon aus, dass die Anzahl Deiner 32x32 auf max. 64 beschränkt ist...


Und der Speed Deiner Engine ist schon nicht so schlecht. Mit 3D kannste das nicht vergleichen. Da rechnet das Auge/Gehirn ja auch bei 13-18 fps die fehlenden Zwischenbilder aus. Bei 2D ist das schwieriger. Damit sich ein statisches Bitmap halbwegs flüssig bewegt, braucht man wohl 30-35 fps, besser 60-70 fps. Bei 2D ersetze ich persönlich (bzw. mein Hirn/Auge) fehlende fps nur dann, wenn das Animationsobjekt in den einzelnen Animationsschritten sehr dynamisch animiert ist. Bei einem Lebewesen geht das einfacher als bei einem Panzer/Raumschiff. Mir ist das aufgefallen, weil einige Verticalshooter z.B. Raketenwaffen haben, die über den Bildschirm rasen. Dabei überspringen die Raketen-Sprites immer gleich 10-20 Pixel, sind also sehr ruckelig. Das fällt aber nicht so auf, weil die Raketen immer sehr dynamisch animierte Rauchwolken nach sich ziehen. Dies unterstützt offensichtlich den Eindruck einer flüssigen Animation.


Außerdem darfst Du Deine wirklich saubere 256-Grad-Rotation sämtliche Deiner Objekte nicht vergessen. Du bist vielleicht nicht ID-Software, aber wenigstens doch IG-Software, oder?

Deine Jump 'n Run Demo gibt es nicht zufällig auch in 160x200 für den Hintergrund?

wobo

[DOSferatu]

Kollisionsabfragen: Pixelgenau? Auf meinen Rechnern, mit meinen Programmierfähigkeiten?

Ich hatte sowas vermutet, weil Du erst von Grafik und der Grafikpage geredet hast und dann von Kollisionsabfragen. Ich dachte, das hinge bei Dir zusammen und Du würdest das intern pixelgenau machen mit irgendwelchen Zusatzbuffern.

Deine Variationen für die Kollisionsabfragen (Quadrat, Kreis, Rechteck, Ellipse) fand ich übrigens äußerst innovativ. Hierauf wäre ich nie gekommen und hätte mich auch nicht getraut so zu denken. Es hat mir richtig Spass gemacht, damit rumzuspielen. Negativ aufgefallen ist mir dabei auch bei keiner Variante was.

Naja, es ist nur optional und man MUß das nicht benutzen. Es steht dem Benutzer des GameSys2 frei, ob er die Kollisionsbefehle überhaupt benutzt und wenn ja, welche davon.
Und es gibt schon etwas Negatives bei meiner Variante: Meine Variante testet, ob sich der Hotspot einer zweiten Figur innerhalb des "Shapes" (also Quadrat, Kreis, Rechteck, Ellipse) der testenden Figur befindet. Eigentlich ist das nicht ganz korrekt - denn normalerweise müßte die zweite Figur EBENFALLS einen solchen "Shape" um sich haben (Quadrat, Kreis, Rechteck, Ellipse) und der Kollisionstest müßte dann so erfolgen, daß getestet wird, ob sich beide Shapes schneiden. Aber das wäre ein wahnwitziger Rechenaufwand und wie Du schon richtig erkannt hast, sind einfache geometrische Formen um die Figur herum für eine normale Kollisionsabfrage völlig ausreichend. In der (internen) Dokumentation zu GameSys2 schlage ich vor, daß nicht JEDE Figur Kollisionstests macht. Denn: Es ist blödsinnig, Figur A mit Figur B zu testen und dann nochmal Figur B mit FIgur A.
Daher gibt es die "Typenbitmatrix" (16 Bit), die man beim Kollisionstest übergeben kann. Es werden dann nur Typen getestet, deren Typ ein Bit 1 ergibt.
Den Figurentypen (1 bis 255) kann man dann einen der 16 Typen (0 bis 15) zuweisen. Ein Beispiel: Typ 0 = Spielfigur, Typ 1 = Spielerschuß, Typ 2 = Feind, Typ 3 = Feindschuß, Typ 4 = Bonusgegenstand..,

Und der zweite (entscheidende) Vorschlag ist (um das Problem zu lösen, daß nur die in der Kollisions-Shape enthaltenen Hotspots getestet werden), daß die größeren Figuren die kleineren testen. D.h. daß nicht ein Schuß testet, was er getroffen hat, sondern ein Spieler oder Feind testet, wovon er getroffen wurde. Das hat zwei Vorteile: 1. Schüsse sind fast immer kleiner als Spielfiguren/Feindfiguren. 2. Es gibt viel mehr Schüsse als Spieler/Feindfiguren. Dadurch minimiert man die Anzahl Abfragen. (Abgesehen davon haben Schüsse etc meist - wenn sie nicht "Homing" sind - sehr einfache Bewegungsalgorithmen, im einfachsten Fall halt einen automatischen "Step" in eine Richtung und Weite bei jedem Spiel-Tick. Verzichtet man nun darauf, daß die Schüsse abfragen, was sie getroffen haben, kann so das Programm für die Schüsse klein und schnell gehalten werden.)

Aber Rechteck scheint für mich dennoch das schnellste und zugleich ausreichend treffsicheres Mittel zur Abschätzung der Kollision zu sein. Die meisten Sprites dürften doch recht gut durch ein Rechteck umrissen werden, zumal die Sprites ja in der Regel als rechteckig angelegte BitMaps vorliegen.

In Xpyderz benutze ich eine kreisförmige Kollisionsabfrage. (Ausnahme: DIe Kollision Panzer -> Level wird an den 4 Ecken des Panzers gemacht. Vorher war es nur der Hotspot, was den unschönen Effekt hatte, daß der Panzer ein Stück "in die Levelklötze hinein" fahren konnte. Die Kollsions-Ecken drehen sich übrigens mit, wenn sich der Panzer dreht.) Die kreisförmige Kollisionsabfrage bei Xpyderz ist nötig, weil das Ganze ja von oben passiert. Würde man es quadratisch machen, würe die Kollision, wenn sich die Figuren schräg zueinander stehen, eher reagieren, als wenn sie senkrecht/waagerecht zueinander stehen.

Das einzige, was ich mir mal gedacht habe, war, zwei Rechtecke zu machen, falls ein Objekt eher dreieckig ist. Also ein kleines Rechteck für die Dreiecksspitze und ein grosses für die Basis des Rechtecks.

Die Doom-Figuren haben 3 Kollsionspunkte (ein Dreieck). Dies wird z.B. für die Levelkollision benutzt. Würde nur ein einzelner Hotspot benutzt werden, könnten die Figuren durch die Lücken von Gitterstäben flitzen.

Quadriple Paging:
Als Deine Engine ein wenig arg meinen PC zum Schwitzen gebracht hat - aber dafür sind PCs ja da! - habe ich mir schon den Kopf zerbrochen, ob/wie Du die 4. Bildschirmseite nicht zum Speichern der 32x32 - Tiles nutzen könntest. Allerdings gehe ich nicht davon aus, dass die Anzahl Deiner 32x32 auf max. 64 beschränkt ist...

Die Anzahl der 32x32 Tiles bei Xpyderz ist in der Tat auf 64 beschränkt. Zu Anfang brauchte ein Tile wirklich noch 1 kB. Mittlerweile brauchen die Tiles nur noch 512 Bytes, weil sie je 16 aus 256 Farben nutzen (also 4bit-Pixel haben). Zu jedem Tile gibt es eine 16 Bytes Farbpalette. Aber ich habe es trotzdem auf 64 Tiles beschränkt (die brauchen jetzt 32kB Speicher, vorher 64kB). Ein Tile (Block) im Level hat aber ein Byte. Die oberen beiden Bits dieser Bytes werden bei der grafischen Darstellung ignoriert - nicht jedoch vom Spiel selbst - sie geben 4 mögliche Modi an:
00 = Tile verhält sich so, wie es aussieht.
01 = Tile ist durchgängig (funktioniert wie Fußboden). Sozusagen "Geheimgänge".
10 = Tile ist gesperrt für Teleportation. "Wilde" Teleporter (im Demo die mit den Magenta-Ringen) können nicht in solche Bereiche teleportieren. Hat ein Teleporter selbst diesen Mode, ist er "einseitig". Er kann teleportieren, aber es kann nicht zu ihm teleportiert werden.
11 = Tile ist "verschiebbar". D.h. man kann mit dem Panzer dagegenfahren und es durch die Gegend schieben (wenn keine anderen Blocks dahinter sind).

Außerdem darfst Du Deine wirklich saubere 256-Grad-Rotation sämtliche Deiner Objekte nicht vergessen. Du bist vielleicht nicht ID-Software, aber wenigstens doch IG-Software, oder?

Naja, mein "Softwarelabel" nennt sich Imperial Games.

Deine Jump 'n Run Demo gibt es nicht zufällig auch in 160x200 für den Hintergrund?

Technisch gesehen schon. Die Darstellungsroutine kann/könnte das. Aber ich habe keine Taste definiert, die das einschaltet.

[wobo]

Daher gibt es die "Typenbitmatrix" (16 Bit), die man beim Kollisionstest übergeben kann. Es werden dann nur Typen getestet, deren Typ ein Bit 1 ergibt.
Den Figurentypen (1 bis 255) kann man dann einen der 16 Typen (0 bis 15) zuweisen. Ein Beispiel: Typ 0 = Spielfigur, Typ 1 = Spielerschuß, Typ 2 = Feind, Typ 3 = Feindschuß, Typ 4 = Bonusgegenstand..,

Bei mir ist alles noch "hardcoded", was aber vielleicht auch daher kommt, dass ich nur Single-Player-Games mache. Da wird halt der Spieler mit allen (aktiven) Gegner geprüft und mit allen Gegnerschüssen, und alle Gegner mit allen Spielerschüssen. Ansonsten noch Spieler mit Bonusse. Aber Deine Idee mit den Typen behalte ich mal im Hinterkopf, für den Fall, dass ich es brauche.

Und der zweite (entscheidende) Vorschlag ist (um das Problem zu lösen, daß nur die in der Kollisions-Shape enthaltenen Hotspots getestet werden), daß die größeren Figuren die kleineren testen. D.h. daß nicht ein Schuß testet, was er getroffen hat, sondern ein Spieler oder Feind testet, wovon er getroffen wurde. Das hat zwei Vorteile: 1. Schüsse sind fast immer kleiner als Spielfiguren/Feindfiguren. 2. Es gibt viel mehr Schüsse als Spieler/Feindfiguren. Dadurch minimiert man die Anzahl Abfragen. (Abgesehen davon haben Schüsse etc meist - wenn sie nicht "Homing" sind - sehr einfache Bewegungsalgorithmen, im einfachsten Fall halt einen automatischen "Step" in eine Richtung und Weite bei jedem Spiel-Tick. Verzichtet man nun darauf, daß die Schüsse abfragen, was sie getroffen haben, kann so das Programm für die Schüsse klein und schnell gehalten werden.)

Deine weiteren Ausführungen - insb., dass größere Figuren testen sollen, ob sie getroffen sind und nicht kleinere, was sie treffen - musste ich jetzt mehrmals lesen und darüber nachdenken: Du hast, glaube ich, Recht. Zufällig mache ich das auch so in Wobobum 2, ohne dass ich mir das damals genauer überlegt habe...

Die Anzahl der 32x32 Tiles bei Xpyderz ist in der Tat auf 64 beschränkt. Zu Anfang brauchte ein Tile wirklich noch 1 kB. Mittlerweile brauchen die Tiles nur noch 512 Bytes, weil sie je 16 aus 256 Farben nutzen (also 4bit-Pixel haben). Zu jedem Tile gibt es eine 16 Bytes Farbpalette. Aber ich habe es trotzdem auf 64 Tiles beschränkt (die brauchen jetzt 32kB Speicher, vorher 64kB). Ein Tile (Block) im Level hat aber ein Byte. Die oberen beiden Bits dieser Bytes werden bei der grafischen Darstellung ignoriert - nicht jedoch vom Spiel selbst - sie geben 4 mögliche Modi an:
00 = Tile verhält sich so, wie es aussieht.
01 = Tile ist durchgängig (funktioniert wie Fußboden). Sozusagen "Geheimgänge".
10 = Tile ist gesperrt für Teleportation. "Wilde" Teleporter (im Demo die mit den Magenta-Ringen) können nicht in solche Bereiche teleportieren. Hat ein Teleporter selbst diesen Mode, ist er "einseitig". Er kann teleportieren, aber es kann nicht zu ihm teleportiert werden.
11 = Tile ist "verschiebbar". D.h. man kann mit dem Panzer dagegenfahren und es durch die Gegend schieben (wenn keine anderen Blocks dahinter sind).

Schön, dass sich noch jemand die Mühe macht, zwei übriggebliebene Bits zu nutzen!

Wenn Du die 64 Tiles auf der 4. Bildschirmseite speichertest, würdest Du Dir 32k Ram sparen und könntest (innerhalb der VGA) 4 Bitplanes auf einmal kopieren. Dies ginge auf alten Rechnern bestimmt schneller. So haben es übrigens viele Apogee und EpicMegagames - Spiele gemacht. Nachteil wäre natürlich, dass Du horizontal nur in 4-Pixel-Schritten scrollen kannst ... was natürlich ein technologischer Rückschritt für XPYDERZ wäre.

wobo

[DOSferatu]

Bei mir ist alles noch "hardcoded", was aber vielleicht auch daher kommt, dass ich nur Single-Player-Games mache. Da wird halt der Spieler mit allen (aktiven) Gegner geprüft und mit allen Gegnerschüssen, und alle Gegner mit allen Spielerschüssen. Ansonsten noch Spieler mit Bonusse. Aber Deine Idee mit den Typen behalte ich mal im Hinterkopf, für den Fall, dass ich es brauche.

Naja, in Xpyderz ist auch alles hardcoded, da benutze ich das GameSys2 nicht (da gab es das noch gar nicht). Aber trotzdem hatte ich Figurentypen (nur keine dieser "Sub-Typen", wie in GameSys2). Und die Kollisionsabfrage zwischen den maximal knapp 1600 Figuren habe ich eben mit meinem "Trick" gelöst (eine Kollisionsmatrix) - weil bei 1600 Figuren die Kollision von JEDE mit JEDER abzufragen wäre für keinen Rechner der Welt machbar... - Und weil sich diese Kollisionsmatrix bewährt hat, benutze ich diese auch (allerdings in Assembler programmiert) im GameSys2.

Das mit diesen "Sub-Typen" ist ja nur so eine Idee von mir, um mehrere Typen zusammenzufassen. Die "richtigen" Typen sind ja quasi die Figuren. Jedem Typ entspricht eine BESTIMMTE Figur. Also z.B. sowas wie Typ 47 = gelber Schuß oder sowas. Und die 16 "Sub-Typen" oder wie man die nennen will - die sind nur dazu gedacht, mehrere der Figurentypen nach ihrem "Wesen" zusammenzufassen. Beispiel: Im Singleplayer-Spiel braucht ein Spieler nicht seine eigenen Schüsse abzufragen und auch nicht irgendwelche Dekorations-Teile oder Explosions-Teilchen. Dann wird das eben in diesen 16bit als 0 angegeben und der spart sich die Berechnung der Abstände und das Reinschreiben in den "Kollisionsstack" und die Auswertung der Kollision, bei der DANN ERST rauskäme, daß sie keinen Effekt hat auf eine der beiden Figuren.

Deine weiteren Ausführungen - insb., dass größere Figuren testen sollen, ob sie getroffen sind und nicht kleinere, was sie treffen - musste ich jetzt mehrmals lesen und darüber nachdenken: Du hast, glaube ich, Recht. Zufällig mache ich das auch so in Wobobum 2, ohne dass ich mir das damals genauer überlegt habe...

Naja, wie gesagt, es hat zwei Gründe. Der eine ist eben, wie erwähnt, daß es statistisch gesehen mehr "Schüsse"/"Kleinteile" gibt als "große Figuren" wie Spieler oder "Feind"figuren.

Und der andere bezieht sich direkt auf die Kollisionsabfrage von GameSys2. Ich erkläre das mal kurz:
Achtung - das wird jetzt ein wenig "technisch" - und mathematisch:
Nehmen wir an, eine Figur hat einen "Umkreis" - innerhalb dessen alles abgefragt wird, was reinkommt. Aber das, was abgefragt wird, sind eben leider NICHT Umkreise der anderen Figuren, sondern nur deren Hotspots. So ein Hotspot liegt in 99% der Fälle immer in der MITTE der Figur. Bei einem Schuß (klein) ist es nicht so schlimm, ob man nur den Mittelpunkt abfragt, dann ist der Schuß eben schon halb im Umkreis des "Spielers" / "Feindes" drin (und man kann den Umkreis ja nur Not auch 2 Pixel weiter machen). Aber wenn es UMGEKEHRT liefe, wäre es anders - denn ein Schuß (weil klein), hätte ja einen viel kleineren Kollisions-Umkreis und würde auch nur die Mittelpunkte der "Spieler"/"Feinde" abfragen. Das würde bedeuten: 1. Die Kollision würde erst erkannt, wenn der Schuß schon sehr nahe dem Mittelpunkt des Spielers/Feindes wäre und 2. wenn der Schuß einen äußeren Bereich des Spielers/Feindes "streifen" würde, würde sein Kollisionsumkreis vielleicht gar nicht den Mittelpunkt des Spielers/Feindes einschließen und der Schuß würde ohne Effekt durch die betreffende Figur "durchgehen".

Dieses Problem KÖNNTE behoben werden, wenn man sowohl die abfragende Figur als auch alle abgefragten Figuren (virtuell) mit diesem Umkreis ausstattet (oder Umquadrat, Umrechteck, Umellipse), dann würden sich einfach die 2 Kreise treffen. In DIESEM SPEZIALFALL (wenn man NUR von KREISEN ausgeht), wäre es einfacher: Dann weist man jeder Figur zu Anfang einen Radius ihres Kreises zu, Und wenn sich 2 Figuren "annähern" (das wird ja mit der Kollisionsmatrix im Level festgestellt), dann berechnet man nur den ABSTAND beider ihrer Hotspots (Satz des Pythagoras) in ein Register (oder Variable) A und außerdem addiert man beide der zugewiesenen Radien in ein Register (oder Variable) B. Und wenn A<=B (also A kleiner oder gleich B) ist, dann haben sich beide Umkreise berührt und es war ein Treffer. Das wäre halt auch noch eine Methode.

Geht man nun allerdings von VERSCHIEDENEN möglichen "Um-Formen" (also Quadrat, Rechteck, Kreis, Ellipse) aus, gestaltet sich die Berechnung ein wenig schwieriger. Man kann Quadrat und Rechteck bei der Berechnung ja "gleichsetzen", ein Quadrat ist nur ein "besonderes Rechteck". Kreis ist ja auch nur eine "besondere Ellipse"... - selbst wenn man es auf diese Art reduziert, bleiben noch 3 verschiedene Berechnungs-Subroutinen, die man - je nach "Um-Form" der beiden Figuren gegeneinander prüfen muß:

Rechteck - Rechteck
Rechteck - Ellipse (das "Gegenstück" Ellipse - Rechteck ist ja die selbe Berechnung)
Ellipse - Ellipse

Dabei ist aber zu bedenken, daß für die Ellipsen entsprechend Potenzrechnungen und Divisionen dazukämen. Schon bei der Subroutine meines Ellipsenkollisionsbefehls (also Ellipse - Punkt) kommt da einiges vor. Ich versuche jedoch immer - zugunsten der Ausführungsgeschwindigkeit - Berechnungen wie Multiplikationen und vor allem Divisionen zu vermeiden oder (wenn's geht) so weit wie möglich aus den Schleifen auszulagern... Es ist nicht so, als ob ich diese Berechnungen nicht hinbekäme und eventuell setze ich mich mal irgendwann hin und baue auch die obengenannten Berechnungen für alle 10 "Zustände" ein: (Q-Q, Q-R, Q-K, Q-E, R-R, R-K, R-E, K-K, K-E, E-E).

Dann könnte ich z.B. eine 16bit oder 12bit oder sowas Speicherstelle für jede Figur definieren, beispielsweise so: 2 Bit geben die Form an und 14 Bit die Kollisionsweite.
Wenn die 2 Bit 00 oder 01 sind, ist es Quadrat (00) oder Kreis (01) und die 14 Bit sind die Kantenlänge bzw Radius. Wenn die 2 Bit 10 oder 11 sind, ist es Rechteck (10) oder Ellipse (11) und die 14 Bit werden in 2x 7bit aufgeteilt und es könnten noch ein Rechteck mit zwei Kantenlängen 0-127 bzw Ellipsen mit zwei Radien 0-127 sein. Achtung: Eigentlich stimmt das mit den Kantenlängen nicht ganz, denn die sind bei mir auch so wie "Radien", werden vom Hotspot aus gesehen. D.h. ein Rechteck mit den "Kanten" 8 und 13 wäre in Wirklichkeit 17*27 Pixel (X*2+1 und Y*2+1). D.h. in Stufen von 2 Pixeln ist es ein Wert 1-255. (Betrifft auch Kreise und Ellipsen - da es RADIEN sind. Die Durchmesser sind natürlich das Doppelte und der Hotspot kommt immer als +1 dazu. Schließlich hat eine "Form" von 0*0 Pixeln für eine Kollision ja keinen Sinn.

Es ist also nicht so, als hätte ich mir über die Problematik keine Gedanken gemacht. In den 18 Bytes (bzw 20 Bytes, bei Möglichkeit der "Figurenverkettung"), die für Jede Figur "per Standard" zu ihrer Darstellung vorgesehen sind, gibt es noch 4 unbenutzte Bits (die sind zwar derzeit nicht als "unbenutzt" deklariert, jedoch ist die Anzahl der Paletten auf 4096 beschränkt, weil das Segment, in dem die 16Byte-Paletten liegen, von mir auf 64kB beschränkt wird). In diesen 4 Bits könnte man da ja noch solche Optionen speichern für "besondere Figuren" (z.B. große unformige Endgegner, die aus mehreren Einzelfiguren bestehen oder sowas), die, wenn <>0, einen Offset angeben, in dem die entsprechende "Kollisionsvorschrift" liegt. - Ich weiß, ich fange schon wieder an, rumzulabern...

Schön, dass sich noch jemand die Mühe macht, zwei übriggebliebene Bits zu nutzen!

Naja - im Gegensatz zu anderen Leuten hier, die sogar den 4G-Mode benutzen können, benutze ich ja immer noch bloß den normalen Heap (die unteren 640kB - also quasi die ca. 600kB, die übrig bleiben. Ja, ich weiß, daß richtige Freaks über 630kB frei haben können - aber nicht alle Leute, die meine Spiele spielen wollen, sind richtige Freaks...).
Und wenn ich Speicher sparen kann, tue ich das auch. Und wenn es wirklich mal so ist, daß aufgrund der Anordnung oder aus anderen Gründen mal Bits oder Bytes "übrigbleiben", überlege ich immer mal zwischendurch, ob man die dann nicht für weitere Optionen benutzen könnte. (Ich weiß auch nicht, warum. Aber irgendwie schäme ich mich immer, wenn ich irgendwelche Formate entwickle, die den Speicher etc. nicht richtig ausnutzen.)
Und wenn ich wirklich mal "mehr" Speicher brauche als den Heap, arbeite ich ja bloß mit XMS (HIMEM.SYS), aber eben trotzdem nur im Real Mode (bzw. im V86-Mode, der macht für meine Zwecke zum RM erstmal keinen Unterschied). Ich frage mich, ob es eine Möglichkeit gibt, den 4G auch einzuschalten, wenn der Rechner bereits im V86-Mode ist. Normalerweise ja nicht (da IOPL=3), aber dieses DOS4GW bzw das PMODE können ja auch aus dem V86-Mode starten (DOOM, DukeNuken, etc.), also muß es ja gehen...

Wenn Du die 64 Tiles auf der 4. Bildschirmseite speichertest, würdest Du Dir 32k Ram sparen und könntest (innerhalb der VGA) 4 Bitplanes auf einmal kopieren. Dies ginge auf alten Rechnern bestimmt schneller. So haben es übrigens viele Apogee und EpicMegagames - Spiele gemacht. Nachteil wäre natürlich, dass Du horizontal nur in 4-Pixel-Schritten scrollen kannst ... was natürlich ein technologischer Rückschritt für XPYDERZ wäre.

Naja, die VGA-Karten haben ja Softscroll-Register, mit denen man den Bildausschnitt pixelweise vertikal bzw. horizontal verschieben kann (horizontal sogar 0 bis 8 Pixel, für die 9-Pixel-Textmodi). (Solche Softscroll-Register hat der C64 übrigens auch. Die meisten C64-Spiele mit Scrolling sind ja im Multicolor-Textmode gemacht, mit eigenen Text-Zeichensätzen, die dann zu den Grafikelementen zusammengesetzt werden.)

Aber... sobald es um Transparenz oder mehrere Ebenen geht, geht das nicht mehr so ohne Weiteres.
Und: Normalerweise sind Lesezugriffe auf den Grafikkartenspeicher noch langsamer als Schreibzugriffe. Ich bin froh, wenn ich so wenig wie möglich aus dem Grafikkartenspeicher lesen muß. Zusätzlich besteht der kleine Nachteil von Mode-X ja leider darin, daß 32-Bit-Kopieren nicht wirklich viel Sinn macht... wobei... Es ginge schon, wenn man die Tiles vorher in entsprechender Weise speichern würde. Na vielleicht, wenn ich Lust habe, schreibe ich mal etwas entsprechendes...

Das mit dem "im Grafikspeicher die Grafik speichern" ist/war wohl früher (prä-386er-Zeit) eher dafür gedacht, daß man dafür dann nicht extra die Segmente wechseln mußte, sondern alles gleich im Segment $A000 machen konnte. Bis 286er hatte man ja nur 4 Segmentregister: SS, CS, DS und ES, wovon man effektiv nur DS und ES quasi "uneingeschränkt" nutzen konnte. Aber seit 386er hat man ja zwei Segmentregister mehr (FS und GS).

Ich weiß, ich bin lame - weil ich für meine grafischen Spiele mittlerweile mindestens einen 386er mit VGA-Karte voraussetze. Ohne die 32-Bit-Register und ohne die beiden zusätzlichen Segmentregister wäre GameSys2 wohl nichtmal halb so schnell und auch der Grafikaufbau usw. wäre um einiges langsamer.

Es tut mir ja auch wirklich leid für die Leute, die meine Spiele auf 286ern oder auf XT (8086ern) spielen wollen und vielleicht mit CGA oder Hercules-Mono-Grafikkarte. Denn eigentlich mag ich alte Rechner ja auch und schäme mich auch ein wenig, daß ich so überkandidelte Highend-Geräte wie 386er mit VGA-Karte als Mindestvoraussetzung angeben muß.

[wobo]

Kollisionsprüfungen:

Nachdem ich nur Rechteck mit Rechteck prüfe (wie gesagt, Hotpots mag ich beim Spielen eigentlich nicht, wobei mir bei XPYDERZ gar nicht aufgefallen ist, dass Du auch mittels Hotspots die Kollisionen geprüft hast. Nimm' das bitte als Kompliment, weil mir die Kollisionsabfrage bei XPYDERZ sehr gut gefallen hat.), ist meine Kollisionsabfrage denkbar einfach:

z.B. FUNCTION RectangularTouch( x1,y1,b1,l1, x2,y2,b2,l2 : integer) : boolean;
BEGIN
RectangularTouch := ((x2+b2>x1) and (x2<x1+b1)) and
((y2+l2>y1) and (y2<y1+l1));
END;

Das ganze in BASM in der jeweiligen Kollisionsprüfungsschleife. Geht eigentlich recht fix. Zumindest auf einem 486sx25 (16 bit isa vga) hatte ich bei mir (max. 50 friendly fire, 20 badly fire, 40 Gegner gleichzeitig aktiv=on Screen) keine Probleme.

Da ich nur Rechtecke abschätze, spielt bei mir die Objektgröße keine Rolle. Es ist also egal, ob ich prüfe, ob Schüsse was getroffen haben oder ob ich prüfe, ob Gegner getroffen worden sind. Bei Hotspots ist das was anderes.

Aber es kommt halt immer auf die Anwendung an. Mein "keine Probleme" bezieht sich halt nur auf meinen schnöden Vertikalshooter. Sobald Rotationen ins Spiel kommen, dürften bloße Rechtecke wohl nicht mehr so ohne weiteres ausreichend sein. Man will sich ja auch vor Gegnern/Schüssen wegdrehen können (Nicht umsonst wirst Du die Kollisionspunkte des Panzers mitrotieren). Ich hatte mal einen Asteroids-Clone versucht, bei dem das Raumschiff ein bloßes Dreieck ist und sich um 360-Grad rotieren kann. Als ich dann versuchte eine pixelgenaue Kollision einzubauen, ist mein 386sx16 gestanden. Ohne jegliche Kollisionsprüfung hatte ich locker 35 FPS, mit Kollisionsprüfung 3 FPS. Ich hatte das dann so gelöst, dass ich zuerst aus den drei Dreieckskoordinaten ein Kollisionsrechteck bilde und dieses dann mit dem Kollisionsrechteck der Meteoriten auf Kollision abschätze, und erst dann ggf. eine pixelgenaue Kollisionsprüfung durchführe.

Schön, dass sich noch jemand die Mühe macht, zwei übriggebliebene Bits zu nutzen!

Naja - im Gegensatz zu anderen Leuten hier, die sogar den 4G-Mode benutzen können, benutze ich ja immer noch bloß den normalen Heap
[...]
Und wenn ich wirklich mal "mehr" Speicher brauche als den Heap, arbeite ich ja bloß mit XMS (HIMEM.SYS), aber eben trotzdem nur im Real Mode (bzw. im V86-Mode, der macht für meine Zwecke zum RM erstmal keinen Unterschied). Ich frage mich, ob es eine Möglichkeit gibt, den 4G auch einzuschalten, wenn der Rechner bereits im V86-Mode ist. Normalerweise ja nicht (da IOPL=3), aber dieses DOS4GW bzw das PMODE können ja auch aus dem V86-Mode starten (DOOM, DukeNuken, etc.), also muß es ja gehen...

Ich habe das Thema 4G und emm386/v86 für mich ad acta gelegt. Schließlich programmiere ich nur noch für mich und meine PCs und dann brauche ich kein emm386.

Im Netz bin ich dazu auch nicht fündig geworden. Irgendwo habe ich mal gelesen, daß es eine undokumentierte Funktion im emm386 gäbe, die von Win 3.11 genutzt wird. Nach Aufruf schaltet sich der emm386 ab und Win 3.11 kann den Protected Mode einschalten. Näheres dazu soll in Andrew Schulman "DOS undocumented" stehen, was ich nie gelesen habe. Fragt sich natürlich, ob das die anderen Speichermanager (qemm etc.) genauso unterstützen. Die andere Möglichkeit wäre wohl, einen VCPI-handler zu schreiben. Dann kann aber wohl gleich im Protected-Mode bleiben (mutmaße ich alles ganz laienhaft).


Nachtrag:
Hier habe ich den Artikel wiedergefunden:
http://www.df.lth.se/~john_e/gems/gem0022.html

Wenn Du die 64 Tiles auf der 4. Bildschirmseite speichertest, würdest Du Dir 32k Ram sparen und könntest (innerhalb der VGA) 4 Bitplanes auf einmal kopieren. Dies ginge auf alten Rechnern bestimmt schneller. So haben es übrigens viele Apogee und EpicMegagames - Spiele gemacht. Nachteil wäre natürlich, dass Du horizontal nur in 4-Pixel-Schritten scrollen kannst ... was natürlich ein technologischer Rückschritt für XPYDERZ wäre.

Naja, die VGA-Karten haben ja Softscroll-Register, mit denen man den Bildausschnitt pixelweise vertikal bzw. horizontal verschieben kann (horizontal sogar 0 bis 8 Pixel, für die 9-Pixel-Textmodi). (Solche Softscroll-Register hat der C64 übrigens auch. Die meisten C64-Spiele mit Scrolling sind ja im Multicolor-Textmode gemacht, mit eigenen Text-Zeichensätzen, die dann zu den Grafikelementen zusammengesetzt werden.)

Aber... sobald es um Transparenz oder mehrere Ebenen geht, geht das nicht mehr so ohne Weiteres.
Und: Normalerweise sind Lesezugriffe auf den Grafikkartenspeicher noch langsamer als Schreibzugriffe. Ich bin froh, wenn ich so wenig wie möglich aus dem Grafikkartenspeicher lesen muß. Zusätzlich besteht der kleine Nachteil von Mode-X ja leider darin, daß 32-Bit-Kopieren nicht wirklich viel Sinn macht... wobei... Es ginge schon, wenn man die Tiles vorher in entsprechender Weise speichern würde. Na vielleicht, wenn ich Lust habe, schreibe ich mal etwas entsprechendes...

Bei meinem Verticalshooter habe ich alles (Hintergründe, Sprites) auf Word-Boundary ausgerichtet, was im ModeX ja 8 Pixeln entspricht. Der Geschwindigkeitsvorteil ist enorm. Ich habe sogar die Spriteabfragen (Punkt setzen?) versucht word-weise zu bearbeiten: d.h. ich lese ein Word (für 2 nebeneinanderliegende pixel des Sprites) und frage dann ah und al ab, was ich setzen muss (also entweder ax, ah, al oder gar nix). Auf meinen Testrechnern (386sx16-486dx40vl) hat auch das Geschwindigkeit gebracht, obwohl ich es eigentlich nicht erwartet habe. Also: es lohnt sich. [PS: die Bitplanes habe ich anfangs 8* gesetzt, nämlich 4* für die Hintergründe und 4* für die Sprites. Als ich dann über Splitscreen eine Menüzeile eingebaut hatte, habe ich pro Frame die Bitplanes weitere ca. 20-50* gesetzt, weil ich zu faul war, auch hier in Richtung Bitplane-Setzen zu optimieren. Zu meinem Erstaunen gab es keine Geschwindigkeitseinbuße. Mittlerweile setze ich die Bitplanes wieder 4* pro Sprite (wovon es max. 110 (sehr kleine) auf dem Screen geben kann). Auch hier habe ich keinen Geschwindigkeitsnachteil. Es scheint also, dass das Bitplane - Setzen gar nicht sooo langsam ist. Jedenfalls bringt eine Optimierung von byte auf word - wenn die VGA 16bit ist - jedenfalls mehr]

Das mit dem "im Grafikspeicher die Grafik speichern" ist/war wohl früher (prä-386er-Zeit) eher dafür gedacht, daß man dafür dann nicht extra die Segmente wechseln mußte, sondern alles gleich im Segment $A000 machen konnte. Bis 286er hatte man ja nur 4 Segmentregister: SS, CS, DS und ES, wovon man effektiv nur DS und ES quasi "uneingeschränkt" nutzen konnte. Aber seit 386er hat man ja zwei Segmentregister mehr (FS und GS).

Ich denke eher es ist das, was ich oben geschrieben habe. Auf den damaligen Rechnern (auch vielen damaligen 386ern) wurden aus Kostengründen nur 8bit-VGAs verbaut. Mit kopieren innerhalb des Videorams konnte man 32bit kopieren und damit tatsächlich die Geschwindigkeit vervierfachen...

wobo