Mode X und EGA Parrallax

Nachdem ich jetzt im grunde schon zu viele Texturen habe, habe ich eine einfache Variante zum wechseln der geladenen Textur Datei in den MAP's hinterlegt.

Testweise wurde immer alle 200 Texturen neu geldaden bei einem "Gebietswechsel", das dauert ca. 5 Sekunden auf dem 386DX40, denke das sind dennoch keine langen Ladezeiten, verglichen mit anderen Spielen.

Wenn ich das ganze jetzt in 50 Textur Blöcke unterteile, kann ich die Anzahl neu zu ladender Texturen auf 1/4 beschränken, wodurch beim betreten von Räumen nur das notwendigste geladen werden müsste.

Wird vermutlich 2 Sekunden dann dauern, das ist noch immer ziemlich Flott. Und man kann duch geschicktes auswählen der Texturen auch dafür sorgen das möglichst selten im speicher nach geladen werden muss.

Hinterm Busch verstecken hilft nicht wirklich, die immer mehr werdenden NPC's finden einen doch irgendwann.

Wenn man sie geschickt verteilt und ihnen Wege / Grenzen zuteilt, sind es immer genug das es nicht langweilig wird.

Aber der 386 wird dennoch meist zügig genug mit ihnen fertig, klingt für heutige verhältnisse verrückt.

Ab 10FPS sind die Bewegungen im Grunde bei diesem Grafik Aufbau schon spielbar flüssig, da das Spiel so angepasst ist das ab 10FPS die Bewegungen ohne einschränkungen abgearbeitet werden können.

Bei Ultima 7 verhält es sich ähnlich, nur das man leider die Bremse für zu schnelle Rechner vergessen hatte damals. Weshalb es auf 486 schon oft zu schnell läuft.

Ich habe einfach die FPS auf 73 limitiert und die Bewegungen werden ca. 10 pro Sekunde nur abgefragt.

Hoffe es bleibt genug Zeit / Leistung für Soundeffekte übrig... aber das kommt erst später.

Ich dachte mir, teste wie lange er für alle 200 braucht. Sind ca. 5 Sekunden.

Momentan werden 200 Texturen bei Spiel start geladen, später werden dann immer 50er Blöcke gewechselt wenn sich die Grafik so sehr ändert das es nicht mehr in die ersten 200 Texturen passt.

Also typischerweise dann in Dungeons oder in grösseren Gebäuden, wo jede Menge Proll herum steht und alles anders ausschaut wie draussen im freien.

Momentan teils sich das in etwas so auf.

-118 Texturen Aussenbereich davon sind 31 lediglich die Häuser von Aussen.

-31 Texturen Gebäude innen, Wände, Betten, Böden, Treppen ... alles was man soeht wenn man einen Raum betritt.

-33 Texturen "Dungeon"... das ist das Kellergewölbe der graue Dungeon, mit allem was dazu gehört. Feuer Fackeln Wände Böden Decken Gitter.

...wenn man 50 Testuren tauschen kann, wird man vermutlich bei extremeren bereichswechseln die wichtigsten teile tauschen können.

es gibt ja auch Dinge die immer gleich bleiben, ein Fass, Bett, Feuer, Truhe ... können / müssen auch oft geladen werden in unterschiedlichen Bereichen.

Haus Variante "erweitert"

Um bei den Häusern den Dachstuhl auch in diese Richtung gedreht darstellen zu können, sind ganze 24 zusätzliche Texturen erforderlich!

Hier die neune Texturen, es fehlern noch 5 weitere um auch an der anderen Seite das Dach so ineinander über gehen zu lassen ... macht dann 29 Texturen (200Limit komplett!).

bin am überlegen so ein rundes Fenster rein zu machen mit Sprossen. ...als zusätzliche Option.

jetzt gibt es erstmal einiges an Möglichkeiten Häuser zu gestalten.

Es sind insgesamt 48 Texturen, ich werde noch 2 Deko Texturen ergänzen für Häuser, dann ist es ein komplettes Grafik Set mit 50 Texturen.

Das entspricht einer Textur Datei. Passt also alles so ziemlich gut zusammen.

Anpassung der Textur Sets.

Heute habe ich mir mal die Zeit genommen die Texturen in Textur Sets auf zu teilen.

Leider mussten danach alle Maps neu erstellt werden, momentan existieren nur 3 Map Dateien zum testen.

folgende Sets gibt es momentan.

(Anzahl Texturen maximal 50 je Set)

9=Texturen Aussenbereich Set 1 (49)

8=Texturen Aussenbereich Set 2 (40)

10=Haus Aussen Set 1 (49)

11=Haus Innen Set 1 (37)

12=Duungeon Set 1 (34)

das Wechseln einer kompletten Map mit dem nachladen eines Textur Sets dauert ca. 2 Sekunden.

Wenn ein Texturset geladen wird, erscheint oben links ein kleiner gelber Ladebalken, eventuell passe ich das später noch an.

eine überlegung ist es weitere Textur Sets in den Ram zu laden EMS damit die nach dem ersten laden schneller nach geladen werden könnten.

Ich würde den speicher dann in Blöcke untereteilen in dessen ersten Byte die Nummer des Textur Sets hinterlegt wird um welches es sich handelt.

Man könnte dann einfach hin und her kopieren innerhalb des speichers.

Die Texturen werden in ein Array geladen, aus welchem sich alle Textur Funktionen bedienen.

//Array Texturen [X][Y]
//X= Nummer Textur 0-199 derzeit genutzt

//Y= Byte 1-1024 >>Pixel Farbwert | Byte 1025/1026 Ebene/Kolision

unsigned char huge MXsprite[200][1026];

Der Teil hier ladet die Texturen im speicher nach.

//Funktion Texturspeicher teilbereiche füllen.
//Nr=Nummer der Quelldatei 0-13 (.tex)
//TNr=Nr der ersten Textur im speicher welche neu geladen werden muss


char MapTex(unsigned char Nr,unsigned char TNr)
{
//Texturen Laden >>>>>
int os1;
int os2;
os1=0;
os2=0;
char rchar[1];
//char rchar;

ifstream ifs; //Eingabestream
if (Nr==0) ifs.open("0.tex",ios::binary);
if (Nr==1) ifs.open("1.tex",ios::binary);
if (Nr==2) ifs.open("2.tex",ios::binary);
if (Nr==3) ifs.open("3.tex",ios::binary);
if (Nr==4) ifs.open("4.tex",ios::binary);
if (Nr==5) ifs.open("5.tex",ios::binary);
if (Nr==6) ifs.open("6.tex",ios::binary);
if (Nr==7) ifs.open("7.tex",ios::binary);
if (Nr==8) ifs.open("8.tex",ios::binary);
if (Nr==9) ifs.open("9.tex",ios::binary);
if (Nr==10) ifs.open("10.tex",ios::binary);
if (Nr==11) ifs.open("11.tex",ios::binary);
if (Nr==12) ifs.open("12.tex",ios::binary);
if (Nr==13) ifs.open("13.tex",ios::binary);

if (! ifs) return(0);

//zeichnet einen einfachen ladebalken MXline ist eine Zeichenfunktion-Linie!
MXline(ODpx,ODpy+4+MXpage,ODpx+50,ODpy+4+MXpage,8);
MXline(ODpx,ODpy+4+MXpage+204,ODpx+50,ODpy+4+MXpage+204,8);
//<<<<<

do
{
ifs.read(rchar,1);
MXsprite[os2+TNr][os1]=rchar[0];
if(os1==1025)
{
os1=0;
os2++;

//Ladebalken MXpset ist eine Zeichenfunktion-Punkt!
MXpset(ODpx+os2,ODpy+4+MXpage,14);
MXpset(ODpx+os2,ODpy+4+MXpage+204,14);
//<<<<<
}
else
{
os1++;
}

}while(os2 <50);

ifs.close();

return(Nr);
}
//<<<<<

der Teil gefällt mir nicht wirklich, wird zwar keine Welt ausmachen. Aber das geht bestimmt eleganter oder?

if (Nr==0) ifs.open("0.tex",ios::binary);
if (Nr==1) ifs.open("1.tex",ios::binary);
if (Nr==2) ifs.open("2.tex",ios::binary);
if (Nr==3) ifs.open("3.tex",ios::binary);
if (Nr==4) ifs.open("4.tex",ios::binary);
if (Nr==5) ifs.open("5.tex",ios::binary);
if (Nr==6) ifs.open("6.tex",ios::binary);
if (Nr==7) ifs.open("7.tex",ios::binary);
if (Nr==8) ifs.open("8.tex",ios::binary);
if (Nr==9) ifs.open("9.tex",ios::binary);
if (Nr==10) ifs.open("10.tex",ios::binary);
if (Nr==11) ifs.open("11.tex",ios::binary);
if (Nr==12) ifs.open("12.tex",ios::binary);
if (Nr==13) ifs.open("13.tex",ios::binary);

wenn man das irgendwie schneller laden kann wäre nicht verkehrt.

Bin generell was auf am räumen im Programm:

manchmal zwar etwas unübersichtlicher aber es spart vermutlich wieder was rechnerei und variablen schieben für die CPU.

alt:

    tex=(px&15) + ((py&15)<<4);
    texBuX=(px>>4)&1;
    texBuY=(py>>4)&1;

    map= MapSp[texBuX][texBuY][tex];//Sprite Textur
    map= MXsprite[map][1025];//Sprite Eigenschaft

neu:

    map= MXsprite[MapSp[(px>>4)&1][(py>>4)&1][(px&15) + ((py&15)<<4)]][1025];//Sprite Eigenschaft

Zitat von mceric

Zitat von Markus

Bin generell was auf am räumen im Programm: ...

manchmal zwar etwas unübersichtlicher aber es spart vermutlich wieder was rechnerei und variablen schieben für die CPU.

Wenn der Compiler gut ist, müsste er eigentlich selbst merken, welche Variablen kurz genug benutzt werden, um sie gleich in CPU Register legen zu können. Daher finde ich die übersichtlichere Version besser, wenn die unübersichtlichere Version nicht tatsächlich merklich schneller läuft.

habe ich jetzt schon manuel alles immer so geändert wie ich es für schneller hielt.

Wurde die Variable mehrfach verwendet hatte ich die lange Variante genugtz, wurde die Variable nach jeder verwendung wieder geöändert, dann hatte ich das zusammen gelegt.

249 Zeilen konnte ich damit einsparen verteilt auf einige Funktionen. Sind jetzt noch 5559 Zeilen Code über (wenn man leere Zeilen für die übersicht abzieht vermutlich die hälfte)

bei dem Compiler funktioniert das irgendwie nicht richtig.

Irgendwie füllt der mir den speicher falsch. Ab und an sind fehler drin.

ifs.read(sprite[offset2 + startslot], 1026)

Im ersten Bild erkennt man das die erste Textur irgendwie falsche Werte hat.

zwischendurch sind immer wieder vereinzelt Texturen falsch.

Wenn ich die Pixel einzeln lade sind die Fehler nicht vorhanden.

ifs.read(sprite[offset2 + startslot][0], 1026) frisst der Compiler nicht

[0] muss ich entfernen.

das hier kann ich auch nicht machen weil ich [offset1] nicht in die Zeile packen darf, der Compiler akzeptiert das nicht.

offset1 = 0
remaining = 1026
do
  retval = ifs.read(sprite[offset2...][offset1], remaining)
  if retval <= 0
    fehlermeldung und abbruch
  else
    offset1 += retval
    remaining -= retval
  ende des else
while remaining > 0
done

Compiler zu alt oder zickig vermute ich.