Eine Frage der Auflösung...

Andreas, welche Auflösung habt ihr bei den DOS Robot Spielen verwendet? Bin mir da nämlich nicht so wirklich sicher, ich weiß das 640x350 eine mögliche Auflösung unter DOS war...
Da streiten sich nämlich gerade ein paar Leute mit mir warum ich ein Fenster 640x348 haben will, das mittels Alt+Tab zu Vollbild 640x480 wechselt... (Ich befürchte ja, denen geht es momentan eher darum, das Tobor auch unter DOS laufen soll 😃

Die Auflösung basiert primär aus Kompatibilitätsüberlegungen zwischen damals existierenden EGA- (Farbe) und Hercules- (Monochrom) Adaptern.
Die Hercules-Adapter waren im Grafik-Modus fest auf 720x348 eingestellt, die EGA-Adapter stellten verschiedene Modi zur Verfügung. Wir wählten bei EGA die höchste, verfügbare Auflösung, und das war der Modus 10h mit 640x350 Punkten.
Als Schnittmenge ergibt sich daraus die Auflösung im Spiel von 640x348 Punkten, was bei Hercules an den Seiten für dunkle Streifen sorgte. Die fehlenden zwei Pixelreihen bei EGA (und VGA) fiel nicht weiter auf.
Dämlicherweise entspricht das Pixel-Seitenverhältnis von fast 2:1 nicht dem für Monitore üblichen Seitenverhältnis von 4:3, wodurch die Pixel nicht quadratisch sind.
Um ein quadratisches Grid zu bekommen, verwendet Robot ein ebenfalls unübliches Grid-Format von 16x12 Pixel, was letztendlich ein Spielgrid von 640/16=40 x 348/12=29 ergibt (eine Grid-Zeile geht für den Status drauf).
Tja, und wenn man nun die Original-Shapes auf einem Monitor verwendet, der quadratische Pixel erwartet, wird das ganze ziemlich flach, wie eben im Fenster-Modus.
Eigentlich müsste man daher für die Darstellung auf heute üblichen Systemen mit quadratischen Pixeln die Shapes auf 16x16 umrechnen, aber bei den paar Pixeln sieht das eben teilweise ziemlich übel aus, wie man das bei der aktuellen Beta schon unschwer erkennen kann.
Da würde nur ein Neuzeichnen der Shapes helfen, aber das wird mit ziemlicher Sicherheit nicht passieren (weil eben auch reichlich interne Routinen von 16x12-Shapes ausgehen).

Hm, das "flache" Erscheinungsbild im Fenstermodus stört nicht einmal 😃 Nein, es gefällt mir sogar 😃
Also, das vergrößern der Tiles machst du aber nur im erzwungenen 640x480 Modus, richtig? In dem anderen sieht es eigentlich ziemlich normal aus.
Tja, woher nehmen, wenn nicht stehlen? (Die vier fehlenden Pixelreihen, meine ich natürlich 😃
So wie es aussieht, benutzt du das gleiche Verfahren, das ich für ne Raycasterversuchsreihe zum Texturieren der Wände genommen habe:
(orig_hoehe / zoom_hoehe) * akt_zeile
um für die aktuell zu zeichnende Tilezeile (bei 16x16) die Zeile zu errechnen, die du aus dem original Bild nimmst. Ich weiß, dämlich erklärt, aber du weißt was ich meine 😃
Wie wäre es, wenn du für jeden zu zeichnenden Punkt einer Zeile Farbanteile verwenden würdest? Dann gäbe es zwar einen leichten Blureffekt (dürfte aber bei nur 4 zusätzlichen Pixeln nicht auffallen) aber im Endeffekt, dürftest du dann Bilder haben, die viel weicher aussehen?
Also, wie man sowas beim verdoppeln von Bildern macht, weiß ich, aber beim vergrößern eines Bildes in nur einer Achse auf 125%, hm, da muss ich noch ein bisschen drüber nachdenken 😃

So, habe es mal ausprobiert und voila 😃
[externes Bild: http://www.coreloop.com/games/robot/fausti/zoom1.PNG][externes Bild: http://www.coreloop.com/games/robot/fausti/zoom2.PNG]
Von oben gesehen:
- das erste Bild ist das original 16x12,
- darunter in etwa das welches du momentan erreichst 16x16,
- darunter meine Vergrößerung
( deren Farbinformationen man noch mit 1,25 multiplizieren muss, damit die original Helligkeit erreicht wird, habe ich aber beim nehmen der Screenshots vergessen *autsch* )
Ok, wie habe ich das gemacht?
Als erstes habe ich jeden der 12 Pixel einer Spalte in 25% Farbanteile aufgeteilt (jeweils 25% von Rot, Grün und Blau). Diese habe ich der einfachheit halber in ein Array ( genannt "row()" )der Größe 12 * 4 = 48 gespeichert. Also 4 Einträge pro Pixel.
Dann beim zusammenbasteln der Pixel einer 16 Pixel langen Spalte:
i = 0For y = 0 To 15 ' In der Variable "farbe" ist dann die gewünschte Farbe für das Pixel farbe.r = (row(i).r + row(i+1).r + row(i+2).r) * 1.25 farbe.g = (row(i).g + row(i+1).g + row(i+2).g) * 1.25 farbe.b = (row(i).b + row(i+1).b + row(i+2).b) * 1.25 i = i + 3 ' Hier setzt du dann den Pixel...Next
Somit bekommst du immer die 75% Stückchen an Farbinformationen die du beim umwandeln von 12 in 16 Pixel benötigst. Der Multiplikator 1,25 dient wie gesagt nur, um wieder 100% Farbinformationen zu erhalten (was ich ja wie gesagt bei den Screenshots vergessen habe...)
Vielleicht ist das ganze ja nicht perfekt, aber es sieht um einiges besser aus (soweit ich das bei den paar testbildchen die ich gemacht habe, sehen konnte.) Und, vielleicht bringt es dich ja auf eine bessere Idee?

Das mit der Skalierung ist ja alles schön und gut, aber wenn man da die Performance berücksichtigen muss, dann dauert eine solche Interpolation natürlich viel zu lange.
Hinzu kommt, dass ich auf der letzten Ebene und insbesondere im Fenstermodus auch nur mit einem indizierten Farbmodus arbeite, um nicht unnötig Performance zu verlieren. Und da kommt man nicht einfach so mit Farben rumrechnen (zumal ich ja ohnehin nur 16 verschiedene zur Verfügung habe...).
Trotzdem: Guter Lösungsansatz! Und wenn Du die Farbwerte nicht mit 25% sondern 33% in dem Array ablegst, sparst Du am Ende noch die Multiplikation mit 1,25... 😉

Ah, an die indizierten Farbmodi habe ich überhaupt nicht gedacht 😃
Naja, weil ich denen auch immer ziemlich aus dem Weg gehe. Ich nutze entweder 24bit wenn ich ohne Antialiasing arbeite oder eh alle Farbberechnungen von Hand mache, ansonsten 32bit.