Mode X und EGA Parrallax

  • Was heisst Kollision in deinem Spiel?

    Es gibt davon mehrere Arten.


    Was heisst bei dir 386 , wieviel MHZ ist erforderlich?


    Was ist bei diesem Spiel das Konzept bitte? Wann ist man Sieger ...Was ist das Spieleziel?


    Danke.

    2 Mal editiert, zuletzt von funkheld ()

  • Kollisionen so wie man es halt auch aus der 3D Welt kennt, halt etwas einfacher. Dafür hat man aber kaum Rechenleistung.


    Bei jedem Schritt muss z.B. geprüft werden ob der Spieler sich gegen ein Hinderniss bewegt.

    Jedes umherfliegende Objekt Pfeile / Projektile / Eis / Feuer, bei allem muss geprüft werden ob es irgendwo gegen prall.

    Kollisionen mit anderen Spielern / Kollisionen mit der Umgebung / Kollisionen mit anderen Kreaturen.


    Momentan wird getestet und teilweise entwickelt auf einem 386DX40 mit Cache, das stellt aber auch schon das Leistungs Minimum da um es vernünftig spielen zu können.


    Das Spiel soll sich irgendwo an Ultima7 / Final Fantasy 3 / Diablo orientieren. Also typische RPG ...aber etwas Actionlastiger.

  • Das ist die Kollisions Abfrage.... durch die OpenWorld etwas komplexer.


    Art der Kollision


    //Kollision +-

    //0=nix

    //1=Geröll /Berge

    //2=Objekte / Wände

    //3=ganze Blöcke nicht zugänglich harte 32x32 Grenze




    Es funktioniert immer gleich:

    Ermitteln beider Positionen

    Ermitteln der zuständigen Map Datei Zwischenspeichers

    Ermitteln der Textur im Map Datei Zwischenspeicher

    Auslesen der Textur eigenschaften aus dem Textur speicher.


    Da alles bis auf der Texturspeicher permanent sich verändert, ist es halt etwas aufwändiger.



    Die erste Abfrage prüft ob es ein Objekt gibt mit dem eine Kollision entstehen könnte welches der Klasse1 entspricht.

    Klasse 1 ist eine Kollision wo sich 2 blöcke mindestens >50% überschneiden.

    Code
    //(16,16-16,16) bis Textur Mitter ..Ger”ll..
    px=((rx+16)>>5);// Kachel Nummer
    py=(ry+16>>5);// Kachel Nummer
        tex=(px&15) + ((py&15)<<4);    
    texBuX=(px>>4)&1;    
    texBuY=(py>>4)&1;
    //    map= MapEv[texBuX][texBuY][tex];//Sprite im bereich
    
        map= MapSp[texBuX][texBuY][tex];//Sprite im bereich    map= MXsprite[map][1025];//Sprite im bereich    if ((map&3)==1)return(1);
    //<<<<<


    hier die Funktion im gesamten, es werden also 4 Kollsionstypen unterschieden.

    die meisten prüfen an 4 Eckpunkten.

  • Mit Screenshots kann man es nicht gut festhalten, das Feuer hat jetzt einen Paletten Effekt. welcher Random die Werte einzelner Farben ändert. darüber hinaus gibt es noch 2 dunkle graun töne die "flackern" um den effekt in der Umgebung auch noch etwas zu verstärken.

      


    Kollisionen und ebenen sind soweit richtig in den Texturen, dadurch geht das Map erstellen später ziemlich schnell.


    Die Dungeon Karte besteht aus 20neuen Texturen die gestern und heute entstanden.


    Heute ist leider der letzte Urlaubstag, danach geht es alles wieder etwas langsamer.

    Bin momentan ganz zufrieden wie es sich entwickelt.

  • Es macht auch riesen Spaß, aber es ist auch eine grosse herausvorderung. Die kleinen Rechner zeigen einem doch jeden kleinen fehler und jeden Leistungsfresser.


    ...wo wir wieder bein Thema sind.


    Problem gefunden. der 386 schafft jetzt sagenhafte 6FPS, weil ich mehr Paletteneffekte habe und diese fürs feuer schneller takte.


    Die Palette wird über einen interupt aufruf geändert, dieser scheint zu langsam zu sein. geht das auch schneller ohne interrupt?

  • Was war der Trick für die 6 FPS? :) Ich zitiere mal Brackeen.com wegen schneller VGA Palette:


    Code
    outp(0x03c8, 0);
    for(i=0;i<256;i++)
    {
      outp(0x03c9, palette_red[i]);
      outp(0x03c9, palette_green[i]);
      outp(0x03c9, palette_blue[i];
    }

    Man gibt zuerst auf Port 3c8 die Startfarbe aus und dann 1 oder mehr Bündel von jeweils 3 Bytes auf Port 3c9, um 1 oder mehr RGB Paletten-Einträge zu aktualisieren :)

  • Wenn du sagen wir mal 42 Farben der Palette ab Farbe 23 animieren willst, ginge das in Assembler schnell:

    Code
    mov al,23
    mov dx,3c8h
    out dx,al
    inc dx
    mov cx, 126
    mov si, offset von RGBRGBRGB... farbdaten im datensegment
    rep outsb

    String I/O gibt es seit 186 CPU, also auf jedem 286 und 386 unterstützt.

  • Ich schieb nochmal eine Testversion hier rein.

    Darin sind die relativ wenigen neuen test maps enthalten.


    Über das obere Haus gelangt man über die Treppe in den Dungeon.

    Kolisionen innerhalb des Dungeons stimmen schon grösstenteils.


    Treppen benutzt man in dem man sich direkt neben dem Abgang/Aufgang stellt und dann wieder Enter drückt.


    Über die Tasten -+ ist ein wechsel der Ebenen auch möglich, wenn da nichts ist landet man halt im schwarzen.


    Angriffe sind teils schon korrekt belegt, es gibt aber auch noch ein paar unfertige. Taste 1 / 2

    Char wechseln Taste F1 F2 F3 F4 sind belegt.


    k=Kolision abschalten

    f=FPS Anzeige

    ESC=beenden

    r=Grafik Reset.


    Wenn man die Kolision abschaltet und zu weit nach links läuft, rennt man im Achswerte unter 0 dann gibt es massiv Grafikfehler, kann später nicht passieren weil alle Maps eigentlich ab X/Y 0 anfangen.


    Spiel starten SP0005.exe

  • Konzept Geschichte, da bin ich noch nicht ganz so weit mit.

    Ich habe ein paar Ideen, aber bin da auch unschlüssig.



    Momentan versuche ich erstmal das Grundgerüst auf zu bauen.

    Da gibt es noch genug Probleme zu lösen.


    Das erste was mich beschäftigt ist das der "bequeme" untere Speicherbereich bald voll ist.


    Es werden halt immer mehr Texturen.


    30x Umgebung

    5x Wasser/Ufer da kommen noch ca. 12 Texturen hinzu.

    53x Haus Gebäude

    33x für den "Dungeon"

    -----

    121 (+12) von maximal 200, also wird das bald schon voll sein.


    Im Speicher für die Kreaturen sind momentan 160 Texturen vor reserviert für die ersten 8 Kreaturen, davon sind 100 Texturen fertig. Limit hier auch wieder die 200.


    Der 3. Speicherbereich ist für Objekte, hier sind flexiblen texturen 0-32x0-32 Pixel hinterlegt, dort sind 7kb belegt, mit Effekt Texturen.


    Das sind insgesamt dann ca. 450kb speicher, mehr kann ich davon nicht abzweigen. Den rest benötige ich noch für andere Dinge.



    Ich werde hier also bald mal nach EMS oder XMS ausschau halten müssen.


    Und ich muss mir gedanken machen, wie ich die ganzen Kreaturen über den Bildschirm bewege, die müssen ja irgendwelche Laufwege oder Bewegungsbereiche zugeordnet bekommen.

    In der Dosbox ist das immer alles ganz einfach machbar, der 386 zeigt einem dann schon seine Grenzen.

  • Ich denke ein Texturcache würde auch Sinn ergeben. Du wirst ja keine 200 Texturen auf einem Bildschirm brauchen. Also einen Cache mit LRU Strategie und Nachladen von Platte. Smartdrive beschleunigt das dann von alleine mit XMS. :)

    root42 auf YouTube


    80486DX@33 MHz, 16 MiB RAM, Tseng ET4000 1 MiB, GUSar Lite & TNDY & SnarkBarker, PC MIDI Card + SC55 + MT-32, XT CF Lite, OSSC 1.6

  • Ich bin grad am überlegen wie ich die Gegner "bewege" ich denke ich lege Laufwege in der Map an die die dann einfach abgrasen und je nach Kreatur reagieren die dann halt auf den Spieler ab einer gewissen Reichweite.

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!