Mode X und EGA Parrallax

**root_42** · 7. September 2023

Nur wenns Mode X ist. Normaler mode 13 hat da keine Vorteile.

Markus · 7. September 2023

Man kann theoretisch mehrere Pixel gleichzeitig zeichnen, wenn man mehrere Planes mit dem selben Bit füllt, ja.

Das Problem ist es sind immer festgelegte 4 Pixel nebeneinander, um genauer zu sein halt alle 4 Pixel von Pixel 0 an und man muss auch noch die Bitmaske wechseln.

heisst es müsste dann bei jeder veränderung die Bitmaske geändert werden und geprüft werden wieviele Bits den selben Farbwert haben.

Das spart im endeffekt keine Leistung ein, schaut aber schlechter aus.

**root_42** · 7. September 2023

Und ab 486 und VLB hat man eh null Vorteil, da der 486 dann auf das VGA RAM in voller Breite in einem Speicherzugriff schreiben kann.

Markus · 7. September 2023

Ich würde es gerne auf 386 schnell genug zum laufen bringen, aber es kommen halt noch einige Sachen hinzu die Rechenleistung und Grafikkarte etwas beanspruchen.

Der Rechenaufwand wird ähnlich wie bei Ultima 7 sein, das scheint ähnlich strukturiert zu sein und es sind auch "Echtzeit" Kämpfe vorhanden, auf meinem 386 DX 40 auf modernem mit gut Cahce bestückten Board, bricht das manchmal richtig ein, wenn sich mehr auf dem Bildschirm bewegt.

Markus · 8. September 2023

Kann Borland c++ 3.1 irgendwie halbwegs brauchbar mit Strings umgehen?

Ich findet dazu nichts funktionierendes im Netz, mit den ganzen typischen Beispielen im Netz kann der Compiler irgendwie nichts anfangen.

also sowas in der Art?

DIM String XYZ;

XYZ="text1" & "text2"; & VariableXY2;

**root_42** · 8. September 2023

Zitat von Markus

Kann Borland c++ 3.1 irgendwie halbwegs brauchbar mit Strings umgehen?
Ich findet dazu nichts funktionierendes im Netz, mit den ganzen typischen Beispielen im Netz kann der Compiler irgendwie nichts anfangen.

also sowas in der Art?

DIM String XYZ;
XYZ="text1" & "text2"; & VariableXY2;

Alles anzeigen

Gibt zwei Möglichkeiten -- je nachdem wie alt der Compiler ist.

1. Pures C:

Code

const char* s1="Text1";
const char* s2="Text2";
size_t slen=strlen(s1)+strlen(s2)+1;
char* s_new=malloc(slen);
s_new=strncpy(s_new,s1,strlen(s1));
s_new=strncat(s_new,s2,slen);

(aus dem Kopf, kann Fehler enthalten) -- wie man sieht ist Stringhandling in C mühselig.

2. C++ wenn neu genug:

Code

#include <string>
std::string s1="Text1";
std::string s2="Text2";
std::string s_new = s1 + s2;

Deutlich einfacher, hm?

EDIT: Borland C++ scheint so alt zu sein, dass es keine gute Standard Library hat. Aber es gibt hier abhilfe:

GitHub - ViktorSlavkovic/bcc3.1_stl: STL Implementation for Borland C++ compiler from 1992

STL Implementation for Borland C++ compiler from 1992 - GitHub - ViktorSlavkovic/bcc3.1_stl: STL Implementation for Borland C++ compiler from 1992

github.com

EDIT2: Oh je, C++ mit BC3.1 ist glaube ich schon masochistisch Eventuell sollte man auf Watcom C++ oder djgpp umsteigen. Ja, dann hat man nicht mehr die Borland IDE, aber man muss halt abwägen was man haben will... modernes C++ oder die IDE.

Markus · 8. September 2023

Masochistisch und spartanisch umschreibt es eigentlich am besten.

hinzu kommt das man dank ModeX auch keine Funktionen mehr wie Cin / Cout verwenden kann, alles muss man irgendwie selber neu schreiben.

Und man hat nur Zeit für x oder Y.

Immerhin hatte ich heute genug Zeit um das Grundgerüst für die Map Darstellung so an zu passen, das errechnet wird welche Map Datei in welchen "Puffer" geladen werden muss.

Und es wird auch schon aus dem richtigen Puffer abgerufen zum Darstellen.

Alle Funktionen die in die Grafik eingriffen mussten also neue Datenbezüge bekommen, später muss ich testen ob der 386 das auch noch schnell genug macht.

Wenn nicht muss nochmal alles neu oder anders.

Das mit den Strings werde ich später testen, Danke für deine Hilfe!

Markus · 11. September 2023

wieder ein paar schritte voran gekommen.

Sprites werden aktuell auch noch nicht geladen.

es gibt testweise die Map Dateien 0000.txt - 0004.txt in jeder sind aktuell einfach nur irgendwelche bytes enthalten die dann Texturen laden... deshalb schaut die Map auch so sinlos aus. Aber es reicht um die Performance des Systems zu testen!

Und darum ging es zuerst einmal.

Der 386 kommt mit dem nachladen von Festplatte der einzelnen Mapabschnitte extrem gut zurecht, verbaut ist eine 1,? GB Fujitsu Festplatte. Auf einem 486 mit 500MB Festplatte lief es auch extrem schnell.

Selbst von Diskette war noch brauchbar, weil die Datenmengen sehr klein eingeteilt sind.

Ich könnte also einfach dazu übergehen die Daten einfach im hintergrund von Platte zu laden wärend das Spiel läuft ohne gross Ladezeiten und es würde die Menge des benötigten Speichers extrem reduzieren.

Testweise lief das ganz auch auf meinem neuzugang dem 486DX50 ...dem 50MHZ FSB Monster, der Horror für jede VLB Karte, aber es ist ein Eisa System. Über 200x in der Skunde kann er die Schleife mit Grafik und allem anderen durchlaufen und das mit einer Isa Otivga Grafikgurke!

Das bedeutet aber auch im umkehrschluss das der 386 vermutlich durch den langsameren RAM Speicherzugriff ausgebremmst wird!

Als 3. Testkaninchen musste der AMD586-133 auf dem PAT48PG VLB Board herhalten, ihm interressierte das ganze so wenig >800FPS, da merkt man dann zusätzlich noch die S3 VLB Karte.

Aktuell sollte die Minimum konfiguration also irgendwo bei kleineren 386DX (20-25) liegen auf dem DX 40MHZ läuft es meist recht flüssig. Es schwankt zwischen 10-50FPS. Wenn später noch Texturen nachgeladen werden sollen, kommt wohl eventuell doch ein ladebalken ins spiel...

Ich vermute ab einem 486DX33 läuft es absolut rund.

hier der komplette Code.

Alle Dateien ins Compiler Verzeichniss

Compiler Borland C++ 3.1

müsste als huge erstellt werden, wobei durch dei ganzen Änderungen kann auch sein das eine kleinere konfiguration schon reicht.

32PA0021.CPP 32.TXT 32s.TXT 0000.TXT 0002.TXT 0001.TXT 0003.TXT

Nicht wundern der Code läuft so zum testen halbwegs stabil! es gibt noch einige Dinge die nicht überprüft werden, fehlende Dateien und einige andere Dinge werden aktuell einfach ignoriert.

Später müssen da noch routinen rein. Beim experimentieren spare ich mir die schreibere aber, bis ich es final mache.

Wers testen möchte ich haffte für nicht! es ist noch alles in einer frühen testphase.

**root_42** · 11. September 2023

Meine Prophezeiung ist, dass das Spiel nochmal einen Schub bekommt, falls du dich entschließt es mal mit einem 32-Bit Compiler zu übersetzen. Wenn du eh meinst, dass es auf einem 286er nicht läuft, könntest du diesen Schritt wagen. Damit solltest du gerade bei Speicherzugriffen nochmal ordentlich zulegen können, solang du nicht einzelne Bytes, sondern direkt DWords lädst.

Markus · 11. September 2023

so heute gab es 2 neue Boards und eine Ati VGA Wonder. Dann habe ich gleich mal haufenweise tests gemacht mit den neuen und ein paar älteren Boards.

Der älteste Kandidat war ein 286, der Code war aber erst ab 386 lauffähig, die kleineren 386 sind auch im grunde schon zu langsam.

erstes Board, ein Neuzugang 386A mit 386DX25 bestückt. 10FPS schaffte das alte Board mit den vielen Chips, Chips!

es fühlte sich ein wenig wie Ultima 7 an das läuft auf keinem System wirklich rund.

der 2. neuzugang ein altes 486 Board mit Symphony Chipsatz und einem DX50. Machte mit 217FPS die beste Figur bei den heutigen Testboards.

386 Board mit Headland Chipsatz, ein sehr sehr sehr sehr schneller 386SX Board würde ich sagen. Es schaffte 9FPS

Mein urgestein in der Sammlung, das Originals 2. Board was ich jemals hatte. Es machte im Test wieder eine gute Figur. Der 386DX40 schaffte 37FPS.

noch ein richtig altes Baord ein 386/32 mit Sipp Ramm bänken, bestück mit einem Intel 386DX16 in der Ausführung noch ohne dem 386 "Logo". Er schaffte 6FPS

ein Highscreen 3486 Board mit Via Chipsatz, bestückt mit einem 486SX25 also der kleinste 486 im test, er schaffte 71FPS

TMC PAT48SA, das Board machte leider Probleme beim test mit der Ati Grafikkarte, diese ging nach ein paar minuten einfach aus und das Board bootete erstmal nicht mehr mit der Karte.

Die Stromversorgung war korrodiert nach einer reinigung lief wieder alles. In diesem etwas älteren 486 war eine Intel 486 DX 33 CPU, diese schaffte 123FPS

auch heute angekommen und gleich als Testgrafikkarte fungiert. eine Ati VGA Wonder.

der unterschied zwischen 386/486 ist ziemlich groß. Alle Systeme waren ohne VLB / PCI Grafik.

Beim test wurde in eine Richtung gelaufen und dann der durchschnitt ermittelt, Ladezeiten wurden nicht berücksichtigt, da das spiel von Diskette einfach viel länger lädt wie von einer Festplatte und dies das ergebniss verfälschen würde.

Bei einer Festplatte merkt man das Nachladen nicht, bei Diskette gibt es einen Rückler.

**Stefan307** · 11. September 2023

Der große Abstand ist schon erstaunlich, zumal das ja nicht unbedingt Highend 486er sind...

Markus · 12. September 2023

ich konnte es nicht lassen, habe noch ein paar Boards getestet. alles 386.

erster Kandidat PD386 mit 386DX33 machte 23FPS

dann ein minimal langsamerer Kandidat die bezeichnung fällt mir jetzt nicht ein, habe ich irgendwo notiert. Es ist ein Fullsize macht halt optisch was her das Board. CPU war ebenfalls eine Intel DX33, es war minimal langsamer immerhin 22FPS.

TK-82C491/386-4H-DO2C ...die kleine Rackete unter den 386 Boards. Kann auch mit der Cyrix 66MHZ CPU betrieben werden, wenn man eine bezahlbare findet. In unserem Kandidaten steckte der Texas DLC40MHZ

und er war mit 47FPS der schnellste 386 im test.

486 hatte ich jetzt absichtlich eher die kleineren genommen, alles über 50MHZ langweilt sich mit dem Programm sowieso nur.

Markus · 12. September 2023

Da ich im Editor Dateien öffnen muss und ja leider CIN nicht funktioniert wegen MODE-X ...habe ich jetzt noch eine Input funktion geschrieben.

MXinput(Position X, Position Y, Farbe schrift, Farbe Hintergrund, Variable für den Text, maximale eingabelänge)

eventuell werde ich später noch Text formatierungen integrieren Char / integer / String / decimal. oder spezielle Zeichen nur erlaubt. Das übliche zeugs halt.

es gibt einen Cursor den kann man mit Pos1 / Ende / Pfeil < / Pfeil > bewegen. Ich muss noch einstellen das Ende nur zum aktuellen String ende springt und nicht hinter alle "nuller" Chars.

Sonst gibt es chaos bei der übergabe in die Print Funktion (der Cout ersatz von mir).

Code

int MXinput(int MXx , int MXy,int MXcolor,int MXcolor2,char MXc[41],char MXmax){

unsigned char Zeichen;
unsigned char oZeichen;

unsigned char ch;

char MXc2[2]="  ";
MXc2[1]=0;
Zeichen=0;
oZeichen=0;
ch=0;

MXprint(MXx,MXy+MXpage+204,MXcolor,MXcolor2,MXc);
MXprint(MXx,MXy+MXpage,MXcolor,MXcolor2,MXc);

MXline((MXx<<2)+((Zeichen)<<3),MXy+8+MXpage+204,(MXx<<2)+((Zeichen)<<3)+6,MXy+8+MXpage+204,MXcolor);
MXline((MXx<<2)+((Zeichen)<<3),MXy+8+MXpage,(MXx<<2)+((Zeichen)<<3)+6,MXy+8+MXpage,MXcolor);

do
{
//tasteneingabe >>>>>
if (kbhit() )
{


    ch=getche();

    // Return > beenden
    if (ch==13) return(1);

    // Escape > beenden
    if (ch==27) return(1);

    // Zeichen Eingabe ASCII 32-175
    if (ch>=32 && ch<=175 &&  Zeichen<MXmax)
    {
    MXc[Zeichen]=ch;
    Zeichen++;
    }

    // <-
    if (ch ==8 && Zeichen>0)
    {
    Zeichen=Zeichen-1;
    MXc[Zeichen]=' ';
    MXprint(MXx,MXy+MXpage+204,MXcolor,MXcolor2,MXc);
    MXprint(MXx,MXy+MXpage,MXcolor,MXcolor2,MXc);

    MXc[Zeichen]=0;
    }

//Sonderzeichen folgt>>>>>
if (ch ==0)
{

    ch=getche();

    if (ch =='K' && Zeichen>0)
    {
    Zeichen=Zeichen-1;
    }

    if (ch =='M' && Zeichen<MXmax)
    {
    Zeichen=Zeichen+1;
    }

    if (ch ==71 && Zeichen>0)
    {
    Zeichen=0;
    }

    if (ch ==79 && Zeichen>0)
    {
    Zeichen=MXmax-1;
    }


}
//<<<<<

if (Zeichen>MXmax) Zeichen = MXmax;


MXprint(MXx,MXy+MXpage+204,MXcolor,MXcolor2,MXc,MXmax+1);
MXprint(MXx,MXy+MXpage,MXcolor,MXcolor2,MXc,MXmax+1);

if (Zeichen<MXmax)
{
MXline((MXx<<2)+((Zeichen)<<3),MXy+8+MXpage+204,(MXx<<2)+((Zeichen)<<3)+6,MXy+8+MXpage+204,MXcolor);
MXline((MXx<<2)+((Zeichen)<<3),MXy+8+MXpage,(MXx<<2)+((Zeichen)<<3)+6,MXy+8+MXpage,MXcolor);
}

if (oZeichen !=Zeichen && oZeichen < MXmax+1)
{
MXline((MXx<<2)+((oZeichen)<<3),MXy+8+MXpage+204,(MXx<<2)+((oZeichen)<<3)+6,MXy+8+MXpage+204,MXcolor2);
MXline((MXx<<2)+((oZeichen)<<3),MXy+8+MXpage,(MXx<<2)+((oZeichen)<<3)+6,MXy+8+MXpage,MXcolor2);
}
oZeichen=Zeichen;
}
MXprint(MXx,MXy-40+MXpage+204,MXcolor,MXcolor2,ch);
MXprint(MXx,MXy-40+MXpage,MXcolor,MXcolor2,ch);
} while(ch != '13');
}
//<<<<<

Alles anzeigen

Markus · 15. September 2023

Prototyp des Map Editors.

Im Grunde ein umgebauter Textur Editor.

Anstelle von Farben werden später Texturen angezeigt und unten rechts gibt es aktuell einen Ausschnitt als Vorschau.

die 16x16 Kachel Map Dateien können schon erzeugt und vom Hauptprogramm verarbeitet werden.

Texturen sind die oberen 16x16 Pixel

Sprites werden in der unteren Hälfte gezeichnet

Peter z80.eu · 15. September 2023

Markus - Schau Dir mal die Quelldatei(en) für "Mario" an, mit Sicherheit auch interessant wegen des Side-Scrollings. Die Quelldateien findest Du auf der Seite http://www.wieringsoftware.nl/mario/source.html , ist zwar Turbo Pascal, aber ich denke die Transferleistung bekommt man hin (Pascal ist ja i.A. lesbarer als C Sourcecode). Screenshot ist auf der Seite http://www.wieringsoftware.nl/mario/index.html zu finden.

Markus · 15. September 2023

die arbeiten doch bestimmt wieder mit "Parallax Scrolling" bei Mario.

Ich werde mir das mal anschauen, aber ich vermute der Aufbau kann wieder davon profitieren das es immer wieder die selben festen Blöcke nebeneinander gibt die verschoben (übersprungen) werden.

Meine Experimente am Anfang des Beitrags hier arbeiten noch nach dem Prinzip.

Ich bin aber davon weg gegangen, weil ich saubereres Scrollen und größere Texturen verarbeiten wollte.

Parallax kann man gut mit 16x16 oder 8x8 Pixel Blöcken machen, wobei hier nicht zu viele unterschiedliche Blöcke nebeneinander sein dürfen, sonst bricht die Grafikleistung komplett ein.

Bei mir fressen die Texturen schon mehr RAM wie die Grafikkarte VRam hat, daher fällt einiges an Möglichkeiten raus.

Ich orientiere mich eher an Ultima 7 beim Grafikaufbau und der MAP, auch wenn die perspektive etwas anders ist.

habe nochmal ein paar Stunden am Editor gearbeitet, der kann jetzt erstmal die wichtigsten dinge, damit ich weiter am eigentlich Programm arbeiten kann.

Markus · 17. September 2023

Es wird langsam.. weiter am Editor.

rechts im Bild kann man jetzt zwischen Vorschau und Texturauswahl wechseln.

Texturauswahl heisst einfach mit maus rechts oder links drauf drücken.

links wird entweder die Map oder die vorschau angezeigt / rechts wird die Vorschau oder die Texturauswahl angezeigt. wenn bei beiden Vorschau aktiv ist, wird nur eine grosse vorschau angezeigt.

entweder nahtlos oder als einzelkachel mit schwarzen "Fugen".

fast alles was man sieht kann man auch mit der Maus "anklicken" und verändern. es geht aber auch komplett über Tastatur.

später im spiel dann die geladene Map.

es frisst alles unmengen an Zeit, macht aber spaß zu schreiben und den fortschritt zu sehen. bzw dann später an den "alten" zu testen.

**Stefan307** · 17. September 2023

Die Bäume sind der Hammer...

**struuunz** · 17. September 2023

Ich muss auch ehrlich sagen: das sieht richtig gut aus! Klasse was du da schaffst! Da ziehe ich meinen virtuellen Hut.

Markus · 18. September 2023

schaut nach regen aus, langsam alle rein in die hütte. (Spiel / Map Editor / Txtur editor)

>2 Stunden an den texturen für die Hütte gezeichnet und die hat nichtmal ein dach, werden also doch wieder alle nass!

Mode X und EGA Parrallax

Jetzt mitmachen!

Benutzer online in diesem Thema