Mode X und EGA Parrallax

die Figur habe ich der einfach heit halber von einer grossen einfach aufs format geschrumpft und mit meinem geschriebenen 32x32Pixel 256Farben umwandler auf texturformat umgewandelt. War eine Open Source sache wo ich die abgegriffen habe.

Ich werde später aber selber komplette Figuren dazu erstellen, gefällt mir besser wenn möglichst alles eigen ist.

Und es macht auch irgendwie spaß das alles zu erstellen.

Bisher habe ich nur Final Fantasy Mods für 3D Drucke gemacht. Und ein paar komplette Figuren zum drucken ohne Texturen.

Da sollte iso mit nur 32x32 Pixel doch einfacher sein.

alle im trockenen... naja fast Loch im dach reparieren wir morgen!

Die letzten Tage nicht so die Zeit gehabt, aber immerhin etwas den Code aufgeräumt.

PA0X0001.CPP

wenn sich 4 charaktere überm Bildschirm bewegen, bricht die Geschwindigkeit ordentlich weg bei kleineren Rechnern.

Erst ab einem 486 DX2-66 komme ich auf konstannte 20FPS. Der 486 DX50 ist spürbar langsamer trotz des 50MHZ FSB.

Also denkte ich wird vermutlich doch die CPU so stark ausgelastet???

Auf einem 133MHZ System mit Isa Grafikkarte schafft er deutlich mehr FPS, also ist nicht der ISA Bus am Bremsen.

Ich denke die "Ebenen" Prüfung Vordergrund / Hintergrund mit seinen sehr vielen RAM zugriffen und vergleichen bremmst sehr stark ab.

Muss mal schauen wo ich Rechenleistung einsparen kann.

welche gescheiten gibt es denn da unter DOS.

Watcom und DJGPP sind das beide für DOS lauffähige?

DJGPP hatte ich schonmal runter geladen über links auf der Seite die du verlinkt hattest, da funktionieren aber nicht mehr alle Links. Und er meckerte immer das Dateien fehlen.

gibt es da keinen kompletten Download in nur einer Datei der zusammen passt.

Wenn ich da nicht alles extrem ändern muss im Code würde ich das mal versuchen.

Die Grafik ist ähnlich wie Ultima 7 vom Aufbau, sowohl der Map Aufbau als auch die Kachelgrösse ist vermutlich ähnlich / gleich.

Auf einem 386DX40 läuft Ultima eigentlich ganz gut, wobei ich schätze das das auch nicht über 10FPS sind im schnitt.

Wenn auf dem Bildschirm ein Rudel Wölfe auftaucht scheint es auch ganz gut ein zu brechen unter der Grafiklast.

Generell waren die spiele früher alle ziemlich "leer" da liefen nicht so extrem viele Charaktere gleichzeitig über die Map.

Heute sind >30FPS und kurze Ladezeiten ja schon selbstverständlich, in den 80/90er Jahren waren es selten 30FPS und Ladezeiten waren oft extrem lang.

ich hatte jetzt zum vergleichen mehrere DX50 und DX2-66 Boards genommen, wenn der DX50 jetzt schneller gewesen wäre, hätte ich darauf schließen können das die bremse irgendwo auf dem Board Eventuel RAM gewesen wäre. Da der DX2-66 aber schon spürbar schneller war, gehe ich davon aus das wirklich die CPU so viel Rechnen muss das sie am ende ist.

Ich kann noch ein paar Prüf Routinen versuchen ein zu sparen. Wenn ich vor dem darstellen der Kreaturen prüfe ob es überhaupt überlagernde Texturen irgendwo gibt, dann braucht die CPU nicht jeden Pixel prüfen.

Im Grunde muss ich hierzu ja nur an den 4 äußeren ecken prüfen ob es eine überlagernde Textur gibt, ist da keine, was sehr häufig der fall sein wird, dann könnte ich in eine andere Funktion für das Zeichnen erstellen die geladen wird, die sämtliche Prüfungen weg lässt.

Die "Pixelweise" Prüfung liegt in einer separaten Funktion aktuell, frage ist halt ob es schneller wird wenn nicht ständig zwischen den Funktionen gesprungen wird?

//############################ Scrolling Charakter32x32 #########################
void DCtex32c    (int DCx,int DCy,int DCc) //DCx/DCy X/Y Koordinate Kreatur Char etc. DCc textur
{
unsigned char MXc=0;
int MXs=0;
unsigned char temp=0;
unsigned char temp2=0;
DCy=DCy+MXframe;//MXframe drauf rechnen

//VGA Mode-X Plane wird gewechselt
//Bankwechsel >>>>> 
asm  {
     mov    ax, DCx //[X Position
     mov    cx, ax
     shr    ax, 2
     add    bx, ax
     and    cx, 00000011b
     mov    ah, 1
     shl    ah, cl

     mov    dx, 3c4h                  //{ Sequencer Register    }
     mov    al, 2                     //{ Map Mask Index        }
     out    dx, ax
}
//<<<<<

do
{
do
{
//PSET >>>>>

MXc=MXsprite2[DCc][MXs];//in MXsprite2 sind die Texturen geladen DCc= Texturnummer | MXs = der Pixel 0-1023

if (MXc != 201 && DCx>-1+ODpx && DCx<320+ODpx && DCy>=MXframe+ODpy && DCy < MXframe+200+ODpy) //prüfen ob Pixel im Darstellungsbereich


//text(x,y)Unterfunktion prüfen ob es eine Textur gibt auf der Map die den Char überlagert auf dem Pinkt x/y, wenn ja wird der Pixel nicht gezeichnet
if (test(DCx,DCy-MXframe)==0){ 

{
asm  {
     mov    ax,DCy   //[y] Position
     xor    bx,bx
     mov    bl,40 //[size] Breite in Pixel / 8
     imul   bx
     shl    ax,1
     mov    bx,ax
     mov    ax, DCx //[X Position
     mov    cx, ax
     shr    ax, 2
     add    bx, ax
     and    cx, 00000011b
     mov    ah, 1
     shl    ah, cl
    //ohne Bankwechsel
    //     mov    dx, 3c4h   //Sequencer Register
    //     mov    al, 2      //Map Mask Index
    //     out    dx, ax
     mov    ax, 0a000h
     mov    es, ax
     mov    al, MXc //[col] Farbe
     mov    es: [bx], al
}
}
}


MXs++;
DCy++;

temp++;

} while(temp<32);

temp=0;
temp2=temp2+1;
DCy=DCy-32;
DCx=DCx+1;

//Bankwechsel >>>>>
asm  {
     mov    ax, DCx //[X Position
     mov    cx, ax
     shr    ax, 2
     add    bx, ax
     and    cx, 00000011b
     mov    ah, 1
     shl    ah, cl
     mov    dx, 3c4h                  //{ Sequencer Register    }
     mov    al, 2                     //{ Map Mask Index        }
     out    dx, ax
}
//<<<<<

} while(temp2<32);

}
//<<<<<





//---------------------------------------------


//Unterfunktion Ebenen Prüfung X/Y = Sprite Pixel Return(1) >>>>>
char test(int rx,int ry)
{
//korrektur zur bildschirm Mitte
rx=rx-144;
ry=ry-84;

int px;
int py;
px=((rx)>>5);// Kachel Nummer
py=(ry>>5);// Kachel Nummer
int tex;
int texBuX;
int texBuY;

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


unsigned char map;
map= MapSp[texBuX][texBuY][tex];//Sprite im Bereich //MapSp ist der zwischenspeicher für Kartenabschnitte, diese werden in der Open World alle 16 Kacheln neu geladen


if (map==0)return(0);


int posx;
int posy;
posx=rx-((rx>>5)<<5);//Position Pixel innerhalb der aktuellen Kachel
posy=ry-((ry>>5)<<5);//Position Pixel innerhalb der aktuellen Kachel

if (MXsprite[map][posy+posx*32]==201) return(0);

return(1);

}
//<<<<<

kann grad auf der Simulation DOSbox was arbeiten.

um das ganze etwas zu übertreiben habe ich dem System 150 Figuren zeichnen lassen und ich habe jetzt eine abfrage die prüft ob an einem der 4 Eckpunkte eine überlagernde textur ist vorhanden ist, wenn ja wird pixelweise geprüft und dann gezeichnet.

Wenn keine überlagernde Textur vorhanden ist, wird sofort gezeichnet.

bei 150 Figuren in der Dosbox sind es 6 zu 9 FPS... mal schauen eventuell kann ich das heute Abend noch was verfeinern und auf dem "kleinen" testen.

...besser so?

Da das spiel so gut es geht open world sein soll, habe ich natürlich ein speicher problem wenn es zu viele texturen werden und wenn die Map zu gross ist.

Daher habe ich die komplette Welt in Kartenausschnitte von 16x16 Kacheln unterteilt, welche in einzelnen dateien abgelegt werden XXYY.txt.

Der Texturspeicher für die umgebung ist aktuell auf 200 Texturen reserviert. hinzu kommen 200 texturen für Kreaturen/Chars, alle sind 32x32Pixel gross 1024byte, somit bleibt nicht mehr so extrem viel von den 640kb über.

Der Texturspeicher wird später in Textur Sets unterteilt welche ich überlege auf ca. 20 Stück zu setzen, somit sind immer 10Sets a 20 Texturen geladen.

in der Kartenausschnittdatei wird hinterlegt welches texturen "Set" benötigt wird.

Ändert sich die Lanschaft können nicht mehr benötigte Sets ersetzt werden durch andere Textursets, somit kann ich im grunde unbegrenzt Texturen für die gesamte Welt nutzen und auf einen Bereich von einem Kartenausschnitt 16x16 Kacheln aber maximal 200 verschiedene.

Es muss halt nur immer sichergestellt sein das für die angrenzenden Kartenabschnitten immer alle texturen richtig geladen sind.

Bisher ist es teilweise nur theorie, technisch lässt es sich so definitiv umsetzen...frage ist nur wie lange die Ladezeiten sind beim Setwechsel.