Neuer User: DOSferatu

Stellt Euch der DOS-Forum Community vor!
bttr

Beitragvon bttr » So 30. Sep 2007, 18:00

@elianda

Warum tust dir XPx64 an? Weil's bei Geeks "in" ist? Wenn du nicht mehr als 4 GiB RAM im PC hast, ist das vollkommen überflüssig.

@Odin

CPUID gibt's auch auf vielen 486ern.
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3667
Registriert: Mi 24. Mai 2006, 20:29

Beitragvon Dosenware » So 30. Sep 2007, 19:45

elianda hat geschrieben:Was auch erschreckend ist, so bekannte Tools wie CPU-Z, das CPU Eigenschaften anzeigt (fuer die Leute die ihren Rechner nicht kennen) erkennt aeltere CPUs nicht und/oder crasht einfach auf aelteren OS. (z.B. Cyrix 5x86 mit NT4)


Das muss nichts heißen, bei mir lauefts auf einem K6 II 500 (Via MPV3 Board, 98;XP) und schießt meinen K6 II 300 (auch Via MPV3 Board, XP) ab.

Hmm, ich kann mich an ein Tool wie CPU-Z erinnern (sah auch so aus), das auf einem der Reiter die komplette Geschichte der 80x86 Prozessoren hatte - weiß zufellig noch jemand wie das hieß? (sah ich afair das letzte mal vor dem Jahr 2000)
elianda
DOS-Übermensch
Beiträge: 1144
Registriert: Mi 31. Jan 2007, 19:04
Wohnort: Halle
Kontaktdaten:

Beitragvon elianda » So 30. Sep 2007, 20:12

bttr hat geschrieben:@elianda
Warum tust dir XPx64 an? Weil's bei Geeks "in" ist? Wenn du nicht mehr als 4 GiB RAM im PC hast, ist das vollkommen überflüssig.


Ich habe 4 GB RAM im System und das PCI Remapping im 64 Bit Modus macht schon bei weniger Speicher Sinn, sobald die Karten den Speicher ueberdecken.
Wobei ich schon darueber nachgedacht habe, ob man da nicht so aehnlich wie QEMM die ROMs + Adapter RAMs stealthed das auch mit dem mapped memory der PCI-Karten unter 4 GB machen koennte.
Benutzeravatar
Sir Ivanheart
Norton Commander
Beiträge: 111
Registriert: Mi 6. Dez 2006, 20:35
Kontaktdaten:

Beitragvon Sir Ivanheart » So 30. Sep 2007, 20:24

Ja, ich habe es irgendwo. Muss mal suchen...

EDIT: TestCPU heißt das Programm.

http://download.freenet.de/archiv_t/testcpu_726.html
Nur, weil man vor sich eine CPU hat, muß man das Denken nicht
einstellen.
Benutzeravatar
Dosenware
DOS-Gott
Beiträge: 3667
Registriert: Mi 24. Mai 2006, 20:29

Beitragvon Dosenware » So 30. Sep 2007, 21:39

Jupp, das wars, danke ;-)
Benutzeravatar
SharpClaw
DOS-Kenner
Beiträge: 409
Registriert: So 23. Jul 2006, 19:09

Beitragvon SharpClaw » So 30. Sep 2007, 21:51

hawooo!! ^^

@ elianda: Vizawrite & Co. > klar kenn ich die noch :D Ich glaube sogar die habe ich noch in meiner Sammlung irgendwo. Bei über 4000 Disketten habe ich langsam den Überblick verloren :roll:

@ Sir Ivanheart: Timetunnel-Rechner > Ich glaube das hing mit der Nasa zusammen und warum die keinen Flug mehr zum Mond wagen. Da meinte ein Wissenschaftler in einem Interview, daß die modernen Rechner zu ungenau seien in ihrem Berechnungen oder so in der Art, was mich doch sehr erstaunt hatte, weswegen ich mich auch noch an den Satz erinnern kann...
Doch bräucht' es ganze Scharen Von Zauberern, und Zeit
Das Schöne zu bewahren Und die Gerechtigkeit.

Nun will ich nicht mehr weinen. Komm, führ mich in dein Land!
Will mich mit ihr vereinen In deiner sanften Hand...

ASP - Zaubererbruder (Am Ende)
DOSferatu
DOS-Übermensch
Beiträge: 1161
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Beitragvon DOSferatu » So 30. Sep 2007, 23:18

Bin ab morgen weg, habe dann für ca. 1 bis 2 Wochen kein Internet. Werde danach ausführlicher antworten.

Zum Pascal-Code: Der Darstellungs-Fehler liegt an der Abfrage des Vertical Retrace. (Frame wird vom Screen aufgebaut, während es gezeichnet wird...)

Anmerkung: So langsam hat vieles des Inhalts hier gar nichts mehr mit dem eigentlichen Thema zu tun. Nicht schlimm. Wollts halt mal sagen.
DOSferatu
DOS-Übermensch
Beiträge: 1161
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Beitragvon DOSferatu » So 30. Sep 2007, 23:32

Bin ab morgen weg, habe dann für ca. 1 bis 2 Wochen kein Internet. Werde danach ausführlicher antworten.

Zum Pascal-Code: Der Darstellungs-Fehler liegt an der Abfrage des Vertical Retrace. (Frame wird vom Screen aufgebaut, während es gezeichnet wird...)

Anmerkung: So langsam hat vieles des Inhalts hier gar nichts mehr mit dem eigentlichen Thema zu tun. Nicht schlimm. Wollts halt mal sagen.

Habe übrigens rausgefunden, woran es liegt, daß bei mir kein fett und kursiv angezeigt wird.

Leider hat hier ein Künstler "kursiv" so umschrieben: <span style="font-style:italic"></span>
Warum? - Was stimmt nicht mit <i></i> ??? (Das andere Format hat keine Vorteile - es ist l„nger, macht im Prinzip auch nichts anderes, und das Format ist zu neu fr Arachne und andere alte Browser.)

(Und dasselbe gilt im Übrigen für Fettschrift.)

Eigentlich schade sowas - vor allem, weil das Seitendesign selbst auch mit <b> usw auskommt.
Und grad war noch das Thema, abw„rtskompatible Webseiten zu bauen... Wenn's den Betreibern nichts ausmacht, k”nnte man das ja fixen. (Aber will hier keineswegs nur wegen solcher Features nerven.)
elianda
DOS-Übermensch
Beiträge: 1144
Registriert: Mi 31. Jan 2007, 19:04
Wohnort: Halle
Kontaktdaten:

Beitragvon elianda » Mo 1. Okt 2007, 01:00

Das andre Format mit den styles gehoert zu den Cascading Style Sheets. Allgemein haben die den Vorteil, dass man mehr Freiheiten im Design bekommt, weil man mehr Moeglichkeiten hat.
Das <i> und <b> usw. gehoert zum HTML 3.2?!? Standard und momentan pusht das W3C die neuen Sachen.
Das heisst das alte wird als deprecated behandelt und es wird nicht empfohlen es noch einzusetzen.

Andererseits ist es natuerlich fuer Sachen mit festen Vorgaben, wie die Gestaltungsmoeglichkeiten hier innerhalb des Forums ausreichend. Da brauch man kein CSS.

Trotz der Moeglichkeiten mit CSS setzen dann viele der Medienfirmen (ich nenn die mal so) dann auf Flash. Obwohl die meisten Browser CSS zum Grossteil schon korrekt darstellen.
(CSS ist mehr als 10 Jahre alt: http://www.golem.de/0612/49570.html)
Aber um auch mal eine Seite mit CSS zu nennen: http://www.scenemusic.eu/

zum Pascal Source: Du meinst ich warte z.Z. bis nach dem Retrace, obwohl ich schon beim Start des Retrace anfangen sollte zu zeichnen?
Ich schaue da nochmal, ich vermute gerade das war auch andersherum auf meinem 386DX-25 damals etwas zu langsam, wegen der vielen Byte Transfers.
Ich denke heute wuerde ich das eher mit Backbuffer machen und dann REP STOSD.
Benutzeravatar
Locutus
Site Admin
Beiträge: 1533
Registriert: Mo 7. Mär 2005, 23:33
Wohnort: NRW
Kontaktdaten:

Beitragvon Locutus » Mo 1. Okt 2007, 02:40

@DOSferatu: Mir ist bewußt, daß phpBB nicht perfekt ist, aber dafür ist es kostenlos. Man könnte natürlich diese ganzen "Kleinigkeiten" fixen, aber im Grunde hat man dann nur wieder Migrationsärger (und d.h. viel Arbeit), wenn man mal auf eine neue phpBB-Version updated.

Gruß,
Christoph
bttr

Beitragvon bttr » Mo 1. Okt 2007, 09:53

aber im Grunde hat man dann nur wieder Migrationsärger


Dann macht man sich von jeder Änderung eine GNU diff-Datei und spielt die in die neue Version ein.
Benutzeravatar
Locutus
Site Admin
Beiträge: 1533
Registriert: Mo 7. Mär 2005, 23:33
Wohnort: NRW
Kontaktdaten:

Beitragvon Locutus » Mo 1. Okt 2007, 14:16

Dann macht man sich von jeder Änderung eine GNU diff-Datei und spielt die in die neue Version ein.


Ich bezweifle, daß das einwandfrei funktionieren wird, wenn sich die von mir gefixte Datei verändert hat in einer neuen phpBB-Version.
bttr

Beitragvon bttr » Mo 1. Okt 2007, 20:02

Dann hast du GNU diff nicht verstanden. ;) Natürlich klappt das nicht, wenn sich die Datei komplett ändert, aber wenn sie sich nur an einigen anderen Stellen ändert, die "drumherum" sind, funktioniert diff/patch sehr gut.
wobo
DOS-Guru
Beiträge: 595
Registriert: So 17. Okt 2010, 14:40

Re: Neuer User: DOSferatu

Beitragvon wobo » Di 9. Nov 2010, 22:33

Mensch, schreibst Du viel Text. Jetzt ist mein Kopf voller Gegenpositionen und Befürwortungen zu Deinen Ausführungen, dass ich fast gar nicht mehr weiß, was ich zu Deinem Game XPYDERZ schreiben wollte:

Eines vorweg: Ich konnte das Spiel nur ein paar Minuten antesten und so vielleicht einen ersten, oberflächlichen Eindruck bekommen. Wie schon geschrieben, gibt mein derzeit schnellster DOS-PC (p75) immer nach ca. 10 Min. den Geist auf.

1. Auf dem p75 scrollt Dein Game wirklich flüssig und mühelos in alle Richtungen, auch dann, wenn am Screen ordentlich was los ist (was eigentlich dauernd der Fall ist). DAß alles, wirklich alles selbt gemacht ist, ist auch noch extra Respekt wert. Ich denke, ich kann wirklich einschätzen, was es für Arbeit ist, wenn jemand Low-Level-Programmierung, Game-Programmierung, Grafiken und Game-/Leveldesign komplett selbst macht.

Außerdem ist die Top-Down / Bird's-Eye-Perspektive ohnehin ein Pluspunkt bei mir. Ich wollte selber immer mal ein Game aus dieser Perspektive schreiben.

Auch noch positiv ist, dass ich überhaupt keinen Fehler feststellen konnte. Ich denke da nur deswegen daran, weil selbst gemachte Software auf anderen Rechner gern abstürzt. Bei Dir konnte ich derartiges überhaupt bemerken. Dass das ganze PrePreRelease nur ganze 460 kb RAM verbraucht, hat mich auch noch ordentlich in Erstaunen verbracht.

2. Dennoch bin ich mit dem Game nicht so richtig "warm" geworden:

a) Das mag vielleicht schon daran liegen, dass ich eine natürliche Abneigung gegen Panzer habe und deswegen wohl auch noch nie ein Spiel mit Schwerpunkt Panzer gerne gespielt habe. Mir wäre es wohl lieber gewesen, Du hättest ein (wenn auch doof aussehendes) Männchen/Weibchen in TopDown gezeichnet...

b) Jedenfalls bin auch mit der Steuerung nicht so klar gekommen. Bei der Standard-Steuerung dreht sich der Panzer stufenlos in die letztlich gewünschte Himmelsrichtung. Das verwirrt mich aber immer, dass ich dann versuche, mit neuen Pfeiltastendrücken der Drehung nachzuhelfen. Mir wäre es lieber gewesen, die 8 Himmelsrichtung würden direkt, also ohne Drehung angesprungen.

Bei der Alternativsteuerung (MicroMachine) dagegen hätte ich mir mehr als die 8 Himmelsrichtungen zur Fortbewegung gewünscht. jetzt kann der Panzer in 45-Grad-Schritten fortbewegt werden. Hier hätte ich mir wohl 22.5-Grad-Schritte gewünscht.

Mein Wunsch also wäre eine Easy-8-Himmelsrichtungen-Direkt - Steuerung und eine fein aufgelöste Alternativ-Steuerung ...

Meine fehlenden Steuerungsfähigkeiten sind aber auch meiner fehlenden Game-Erfahrung geschuldet. Ich "game" allenfalls 2 Mal/Jahr...

c) Ansonsten noch: Ich habe mal versucht einen Mode 160x200x256 hardwaremäßig hinzubekommen, was fehlgeschlagen war. Bei Dir hab ich den Eindruck, dass Du den 160x200-Mode eher software-seitig einstellst/behandelst, da ja die sprites alle noch 320x200 sein dürften. Jedenfalls kann ich beim Umschalten von 320x200 auf 160x200 keinen Geschwindigkeitsvorteil feststellen: Beim p75 flutscht ohnehin alles, beim 486dx40vl ist beides (gefühlt) gleich langsam. Wäre es nicht möglich, dass Du für den Hintergrund 80x200 nimmst. Im ModeX könntest Du dann alle 4 Bitplanes (=4 pixel) auf einmal beschreiben und das quasi linear. Das wäre natürlich sehr Low-Res, aber das ist halt der Preis für langsame PCs (wie meine).

Wie gesagt, nimm' Dir meine Kritik bitte nicht zu sehr zu Herzen, da ich a) kein Gamer und b) ein furchtbar viel schlechterer Programmierer bin.

Grüße
wobo
DOSferatu
DOS-Übermensch
Beiträge: 1161
Registriert: Di 25. Sep 2007, 12:05
Kontaktdaten:

Re: Neuer User: DOSferatu

Beitragvon DOSferatu » Mi 10. Nov 2010, 16:57

wobo hat geschrieben:Mensch, schreibst Du viel Text. Jetzt ist mein Kopf voller Gegenpositionen und Befürwortungen zu Deinen Ausführungen, dass ich fast gar nicht mehr weiß, was ich zu Deinem Game XPYDERZ schreiben wollte:

Ja, ich bin bekannt dafür, viel und ausführlich zu schreiben, um zu vermeiden, falsch verstanden zu werden (was leider trotzdem oft noch passiert).

wobo hat geschrieben:Eines vorweg: Ich konnte das Spiel nur ein paar Minuten antesten und so vielleicht einen ersten, oberflächlichen Eindruck bekommen. Wie schon geschrieben, gibt mein derzeit schnellster DOS-PC (p75) immer nach ca. 10 Min. den Geist auf.

Normalerweise braucht man auch nur maximal 10 Minuten, um das Standardlevel durchzuspielen, wenn man etwas geübt hat...

wobo hat geschrieben:1. Auf dem p75 scrollt Dein Game wirklich flüssig und mühelos in alle Richtungen, auch dann, wenn am Screen ordentlich was los ist (was eigentlich dauernd der Fall ist). DAß alles, wirklich alles selbt gemacht ist, ist auch noch extra Respekt wert. Ich denke, ich kann wirklich einschätzen, was es für Arbeit ist, wenn jemand Low-Level-Programmierung, Game-Programmierung, Grafiken und Game-/Leveldesign komplett selbst macht.

Danke für die Blumen.

wobo hat geschrieben:Außerdem ist die Top-Down / Bird's-Eye-Perspektive ohnehin ein Pluspunkt bei mir. Ich wollte selber immer mal ein Game aus dieser Perspektive schreiben.

Und ich wäre froh, wenn ich mal jemanden hätte, der mit mir zusammen mal ein Spiel machen wollen würde. Der müßte nichtmal programmieren können - es gibt ja auch noch so Aufgaben wie Levels bauen, Grafiken erstellen, etc...
Übrigens sind 2D Vogelperspektive-Spiele leichter zu machen.
Bei Seitenansicht muß man für die Figuren auch noch die ganzen Dinge wie Springen und Herunterfallen berücksichtigen - und damit es nicht seltsam aussieht, eben auch mit Beschleunigung/Verzögerung arbeiten...

wobo hat geschrieben:Auch noch positiv ist, dass ich überhaupt keinen Fehler feststellen konnte. Ich denke da nur deswegen daran, weil selbst gemachte Software auf anderen Rechner gern abstürzt. Bei Dir konnte ich derartiges überhaupt bemerken. Dass das ganze PrePreRelease nur ganze 460 kb RAM verbraucht, hat mich auch noch ordentlich in Erstaunen verbracht.

Ja, leider braucht die Vollversion dann wirklich so um die 610 kB - was daran liegt, daß da dann der Leveleditor und der Multiplayer (vollständiger TCP/IP Stack) enthalten ist. Das hab ich in der PrePreRelease auskommentiert. Allerdings will ich die Vollversion dann in 4 Arten installierbar machen:
- Mini (ohne Leveleditor, ohne Multiplayer)
- Multiplayer (ohne Leveleditor, mit Multiplayer)
- Developer (mit Leveleditor, ohne Multiplayer)
- Complete (mit Leveleditor, mit Multiplayer)
Die Leute, die wenig Speicher haben, können dann z.B. zum Levels bauen die Developer nehmen und zum Multiplayer eben diese. Single Player geht natürlich in allen Versionen...

wobo hat geschrieben:2. Dennoch bin ich mit dem Game nicht so richtig "warm" geworden:

a) Das mag vielleicht schon daran liegen, dass ich eine natürliche Abneigung gegen Panzer habe und deswegen wohl auch noch nie ein Spiel mit Schwerpunkt Panzer gerne gespielt habe. Mir wäre es wohl lieber gewesen, Du hättest ein (wenn auch doof aussehendes) Männchen/Weibchen in TopDown gezeichnet...

Ich hatte schonmal erklärt, warum ich einen Panzer benutzt habe. Daß es nichts mit Kriegsspielen zu tun hat. Daß er eher wie ein Spielzeugpanzer aussieht. Und daß Figuren von oben eben irgendwie kaum noch als solche zu erkennen sind. Außerdem ist ne Figur mit 'ner Waffe - im Prinzip auch nichts anderes als 'n bewaffneter Panzer.
Es ist halt ein kleines doofes Ballerspiel und man sollte sich nicht über eine eventuelle "Story" dahinter soviel Gedanken machen.

wobo hat geschrieben:b) Jedenfalls bin auch mit der Steuerung nicht so klar gekommen. Bei der Standard-Steuerung dreht sich der Panzer stufenlos in die letztlich gewünschte Himmelsrichtung. Das verwirrt mich aber immer, dass ich dann versuche, mit neuen Pfeiltastendrücken der Drehung nachzuhelfen. Mir wäre es lieber gewesen, die 8 Himmelsrichtung würden direkt, also ohne Drehung angesprungen.

Bei der Alternativsteuerung (MicroMachine) dagegen hätte ich mir mehr als die 8 Himmelsrichtungen zur Fortbewegung gewünscht. jetzt kann der Panzer in 45-Grad-Schritten fortbewegt werden. Hier hätte ich mir wohl 22.5-Grad-Schritte gewünscht.

Du scheinst da irgendwas falsch verstanden zu haben:
ARCADE:
Die Standard-Steuerung ("Arcade") steuert so, daß man die 8 Himmelsrichtungen hat, je nachdem, welche Cursortasten man drückt (oben+links zusammen geht halt nach schräg oben links).
Außerdem fährt der Panzer SOFORT in die Richtung, in der man steuert, lediglich die Schußrichtung zieht dann noch nach (zusammen mit dem Panzersprite). Man kann sogar ALT gedrückt halten, dann kann man woanders hin fahren als man schießt.

CRUISE:
Die Alternativ-Steuerung ("Cruise") steuert so, daß man mit hoch/runter vor und zurück fährt und mit links/rechts den Panzer in 256 Stufen drehen kann. (Daß es bei Dir so aussieht, als wären es nur 22,5°, liegt wohl eher an der geringen Framerate.) Man fährt dann immer in die genaue Richtung, wohin man sich dreht. Wenn man hier ALT gedrückt hält, kann man statt sich zu drehen, nach links und rechts "gleiten" (in Doom nennt sich das "Strafe Mode").

wobo hat geschrieben:Mein Wunsch also wäre eine Easy-8-Himmelsrichtungen-Direkt - Steuerung und eine fein aufgelöste Alternativ-Steuerung ...

Also eigentlich ist das doch schon so... Die Direkt-Steurung hat 8 Himmelsrichtungen, nur daß sich wenn man die Richtung drückt, sich die Figur (Panzer) erst noch dahin dreht. Ich wollte so ein "dahinschnipsen" in die Richtung vermeiden, das fand ich zu doof.

wobo hat geschrieben:Meine fehlenden Steuerungsfähigkeiten sind aber auch meiner fehlenden Game-Erfahrung geschuldet. Ich "game" allenfalls 2 Mal/Jahr...

Ich spiele auch selbst recht selten mal irgend etwas. Bin auch ein wahnsinnig schlechter Spieler. (Mal abgesehen davon, daß ich ja auch alt bin.)

wobo hat geschrieben:c) Ansonsten noch: Ich habe mal versucht einen Mode 160x200x256 hardwaremäßig hinzubekommen, was fehlgeschlagen war. Bei Dir hab ich den Eindruck, dass Du den 160x200-Mode eher software-seitig einstellst/behandelst, da ja die sprites alle noch 320x200 sein dürften. Jedenfalls kann ich beim Umschalten von 320x200 auf 160x200 keinen Geschwindigkeitsvorteil feststellen: Beim p75 flutscht ohnehin alles, beim 486dx40vl ist beides (gefühlt) gleich langsam. Wäre es nicht möglich, dass Du für den Hintergrund 80x200 nimmst. Im ModeX könntest Du dann alle 4 Bitplanes (=4 pixel) auf einmal beschreiben und das quasi linear. Das wäre natürlich sehr Low-Res, aber das ist halt der Preis für langsame PCs (wie meine).

Also, das hast Du falsch verstanden.
Ich BENUTZE das HARDWAREMÄßIGE 160x200 für das Level! (d.h. mit verlinkten Planes 0+1 und 2+3) D.h. das Level braucht dann nur noch die halbe Zeit, um sich aufzubauen, weil es eben halb soviele Pixel sind. Ichbenutze also für den LowRes Mode jeweils 2 BitPlanes gleichzeitig. Mit 4 Bit Planes gleichzeitig wäre rein technisch auch möglich gewesen - aber das sah dann einfach schon zu häßlich aus.
Die Sprites dagegen werden weiterhin im 4-Plane Mode gezeichnet. (Level und Sprites werden ja von unterschiedlichen Subroutinen dargestellt).
Ich hätte es auch noch so machen können, daß die Spriteroutine ebenfalls auch noch den LowRes Mode unterstützt - wollte ich aber nicht, ebenfalls aus ästhetischen Gründen.
Manche verstehen diesen planebasierten Hardware-Lowres falsch. Man erzeugt damit keine Auflösung von 160x200, sondern man kann mehrere der Planes gleichzeitig mit einem einzigen Befehl ansprechen - was bei ModeX dazu führt, daß man mehrere nebeneinanderliegende Pixel mit nur einem Schreibzugriff setzt.
(Für die Figuren setze ich die Plane eben für jede Spalte neu. Das Level und die Figuren werden nicht gleichzeitig erzeugt - erst wird das Level geschrieben und dann die Figuren draufgesetzt. Würde man es wirklich so machen, daß man die Figuren während des Levelzeichnens gleich mitgeneriert, würde das zwar weniger Grafikkartenzugriffe erfordern (weil die Levelpixel "unter" den Figuren nicht mit übertragen werden würden - würde aber so eine komplexe Routine und einen derartigen Rechenaufwand erfordern, daß die durch die Wenigerbelastung der Grafikkarte freigewordene Rechenzeit von der CPU gleich wieder mehrfach aufgefressen werden würde.)
(Übrigens: Ich KANN auch auch einen echten 160x200 Pixel Mode erzeugen - technisch kein Problem- dann wäre aber ALLES 160x200 - auch die Schrift... - das muß ja nicht sein..)

Alternativ könnte man natürlich auch das Bild verkleinern. Meine Ausgaberoutine für die Levels/Sprites läßt das ohne weiteres zu. Also daß das Bild zwar in voller Auflösung ist, aber eben mit 160x100 Pixeln, in der Bildmitte dargestellt und die Sprites und Levelblöcke nur 1/4 so groß. Für den "lokal Multiplayer" wird das sowieso so gemacht - weil da nämlich mit Splitscreen gespielt werden kann.
Also quasi wäre das dann eine Option, wo man (wie bei Doom & Co) mit der +/- Taste (und/oder im Menü) die Bildgröße verkleinern kann. Allerdings habe ich die Darstellungsroutine auf "Stufen" beschränkt, also geht nur 1/2, 1/4, 1/8 usw. Der Grund dafür ist: Ich hatte die Routine schon so, daß es stufenlos ging - aber für Nicht-2er-Potenzen sieht so etwas einfach bescheiden aus, weil dann beim Scrollen die Pixel so flimmern (erscheinen/verschwinden etc.) und davon bekommt man ja irgendwann Augenkrebs.
Daß es übrigens auf einem 486er DX40 nicht so performt, liegt wohl weniger an der CPU als vielmehr an der langsamen Grafikkarte. Ich weiß - es ist eine steinkalte Schande, aber es ist eben so.

wobo hat geschrieben:Wie gesagt, nimm' Dir meine Kritik bitte nicht zu sehr zu Herzen, da ich a) kein Gamer und b) ein furchtbar viel schlechterer Programmierer bin.

Ich habe mit Kritik überhaupt kein Problem.
Und ich weiß, daß dieses Xpyderz nicht perfekt ist. Es war halt ein Versuch meinerseits, ein Fullscreen + scrollendes kleines Ballerspiel zu bauen. Es ist nicht der Weisheit letzter Schluß und sollte es auch nie sein.

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 3 Gäste