Beiträge von Markus

    Wenn sich das Programm aufhänge ab und an, dann wird das Problem vor dem Verstärcker liegen.

    Ich würde mal die Chips in den Sockel was bewegen, eventuell schlechter Kontakt beim OPL2 ..der FM1312


    Wenn eine Seite beim OPL2 leiser ist, kann das ja nur hinter dem OPL2 sein, weil der Chip Mono ist müsste die Ausgabe eigentlich an beiden Seiten gleich sein.


    Der TEA2025 ist der Verstärcker, dieser ist Stereo!


    pasted-from-clipboard.png

    ...du känntest an den Pins Prüfen ob das Signalö bei beiden Kanälken gleich ist.

    36 neue Texturen unter dem Motto "Castle" um die Städte was aus zubauen.



    Turm nochmal was tiefer gemacht, weil sonst bei der Ansicht das ganze zu hoch wird... die typische 2 1/2D ? RPG Perspektive ist halt etwas speziell.

    Zu hohe Gebäude verdecken einfach zu viel vom Gelände, das ist zwar realistischer... aber total unpraktisch.


    23:45 ...Details machen den Unterschied, verfeindern und kleine Fenster Sprites zum drauf pappen.


    kleines update... Texturen nochmals angepasst, war nicht ganz zufrieden mit den Kopfstein Texturen. Die kleinen wirken besser und es passt eher vom grössenverhältniss.

    Bisher hat jeder IBM Post Codes ausgeworfen der bei mir auch dem Tisch lag.


    hier gibt es eine übersicht der Postcodes des AT.

    minuszerodegrees.net



    bin meinen auch am bearbeitetn, die Rampage scheint probleme zu machen in dem Rechner. hängt ständig irgendwo wenn der Rechner mit 4,5 MB beladen ist.

    Defekte Tantals sind so der klassiker, können auch in anbaukarten probleme machen.

    wobei dann eigentlich das Netzteil aus geht oder es einen Knall gibt.


    Passiert halt auch gerne wenn so ein Rechner ewig gelegen hatte das dann erst nach Stunden / Tage einer einen kurzschluss bekommt.

    Bei den PC/XT/AT hatte ich das häufiger.


    Sonst halt mal durch messen was die Signale drum herum so machen.

    minuszerodegrees.net

    optimieren schadet nicht, ich werde die Tage aber erstmal aufräumen.

    Es gibt noch ein paar Datenleichen durch den Umbau, ungenutzte Variable und auch ganze Funktionen die weg können, weil unnötig.

    Im Map Editor will ich auch endlich die Textur Funktionen vom Spiel übernehmen, die hatten wir ja schonmal überarbeitet.

    Die Mode-X Grafik routinen sollen auch endlich in eine eigene Datei ausgelagert werden.




    Als Static funktioniert es.

    Ansonsten tut der Assembler teil so als ob das Array nicht existiert, weder lesen noch schreiben, aber auch keine Fehler Meldung.




    Ich habe Spiel und Editor jetzt so weit das ich 1000 Texturen verwenden kann, je nach Speicher kann ich auch noch ca. 64000 Texturen verwenden.

    Der Rechner ladet immer nur einzelne Texturen in den unteren speicher nach wenn diese auch benötigt werden.



    rum gammeln mit 37FPS und mit Kevin und Berta im Bild bei Bewegung noch 14FPS.


    ...wobei ich hier noch das Frame restaurieren über latch copy umsetzen möchte später, spart sehr viel Rechenleistung und ich habe jetzt genug speicher frei dafür.


    ich habe auch angefangen für "funktions" Pakete einzelne Dateien zu verwenden im Projekt.

    So kann ich die XMS Funktionen z.B. in allen Programmen verwenden in denen ich XMS benötige.

    ...hat wieder Stunden gedauert...


    den code von mceric konnte ich leider so nicht übernehmen, die Daten landen warum auch immer scheinbar nicht über das Struct bei SI...habe wieder Stunden damit verbracht das zu testen.



    ich hoffe ich habe nicht neue Fehler eingebaut, korrigiert mich gerne.

    Es scheint nur zu funktionieren wenn ich nach der Zuteilung des Pointers, die Daten danach erst wie gewohnt rein schiebe.


    Ich hatte etliche versuche gemacht es anders zu machen, mit Stuct und mit Arrays... nichts funktionierte, leider.

    Code
    mov si,offset XMSsi //<<< Pointer zu einem Array welches gross genug für di Daten ist unsigned int[10]!

    SI ist ein Zeiger Register ich denke ich habe das jetzt richtig begriffen... meine Assembler Kenntnisse sind halt leider was sehr dürftig und das ist verdammt lange her.


    Nun zum Spiel...

    im Bild wird oben Links der Inhalt des Arrays angezeigt, der Assembler Code füttert das Array brav mit den Werten. Korrigiert mich wenn ich falsch liege, ich gehe davon aus das durch den Pointer jetzt alles Werte richtig abgelegt werden müssen.


    hier der Code der Funktion.


    push pop habe ich brav eingebaut und einen Pointer zu einem Array welches die korrekte grösse hat es sind im Grunde 10x 16bit!


    Ich würde dir sehr empfehlen, den ganzen Zirkus rund um die EMM Structure in den C-Anteil von XMScopy zu verschieben. Also ganz gemütlich die komplette EMM Structure in C produzieren und dann dem asm-Block nur noch die Adresse der EMM Structure übergeben statt der vielen kleinen Variablen die du jetzt alle einzeln in Assembler dort rein bastelst. Das in C zu machen spart eine Menge Stress und potentieller Bugs.

    ...ich versuche das mal um zu setzen. Damit es später keine Probleme gibt.

    Das sind die kompletten XMS Funktionen...

    XMShandle ist eine Globale Variable in der jedes mal ein Wert hinterlegt wird wenn ein XMS handle reserviert wird.

    ...Das Programm verselbständigte sich aber irgendwo und hat dort ab und an einfach den Handle 1 in andere Werte geändert.

    Wenn man DOSBOX startet wird der erste Handle immer als 1 angelegt. zu testzwecken hatte ich deshalb einfach sturr gegen XMShandle !=1 geprüft um die Quelle des Fehlers zu finden.


    Beim starten des Spiels kommt noch ohne Grafik ein Info Fenster

    hier sieht man ob der XMS korrekt initialisiert wurde.

    Wenn es zu fehlern kommt wird das Programm auch sofort beendet mit einer Rückmeldung.


    Hier nochmal alle XMS Funktionen ...bis auf die Spiel spezifischen wo dann Texturen und Pixel abgefragt werden.

    Variablen am Anfang sind Global da werden beim initialisieren Informationen über Fehler hinterlegt.

    zusätzlich geben die Funktionen eine 1 zurück wenn alles korrekt funktioniert hat.


    Der Fehler welcher Auftrat war für mich nicht reproduzierbar, ich hatte Zeitweise alle Grafik Funktionen und alles drumherum was schon seit Monaten läuft deaktiviert und trotzdem wurde die Globale Variable XMShandle einfach von 1 auf was anderes geändert.

    Ich habe jetzt Einstellungen im compiler geändert, seitdem scheint ruhe zu sein.

    Jetzt werden alle Texturen korrekt kopiert und ich konnte auch die ziemlich vermurksten Test Funktionen durch die Funktionen aus dem MAP Editor ersetzen.


    Ich hatte zwischendurch auch sturr die Adressen mitm Rechner ausgerechnet und als Zahl in der Funktion eingetragen, dann schredderter der mir trotzdem den Wert aus der XMShandle Variabel, das war schon sehr kurios.


    Es läuft jetzt und alle Texturen werden korrekt angezeigt, also wurden die Adressen vorher auch eigentlich schon richtig hinterlegt.


    Register Variables auf none gesetzt und der Code funktionierte wieder.


    Merkwürdig ist nur das der Map Editor die selbe XMS Datei includiert und dabei lief alles mit den selben compiler einstellungen wobei das Spiel nicht läuft.


    Mitlerweile läuft es ja zum Glück.

    auf dem 386 habe ich noch ca. 13FPS wenn ich das Spiel zwinge bei jeder Textur anfrage diese aus dem XMS rüber zu kopieren.


    Ich habe aber einen Textur Puffer für 62 Texturen erstellt, wo angefragte Texturen rein geladen werden vom XMS.


    Bei einer Textur Anfrage wird geprüft ob eine Textur im Puffer ist oder nicht. Hierzu wird jeder Textur Nummer eine Speicherplatz Nummer hinterlegt 0 heisst nicht gepuffert.

    Dann wird sie neu in den Puffer geladen bei einer Anfrage.

    Der Puffer wechselt einfach beim laden immer einen Speicherplatz weiter.

    Dadurch können zwar benötigte Texturen überschrieben werden, aber bei 62 Texturen kommt das dennoch selten genug vor so das eigentlich immer permanent die Sichtbaren Texturen sich im Puffer ansammeln und von dort aus verwendet werden.


    Ich muss nur noch die Textur Speicherplätze von 8 bit auf 16bit ändern damit 65536 anstelle der bisherigen 256 (tatsächlich nur 200) Texturen verwendet werden können, der Rest ist schon im editor und im Spiel Funktioniert schon.


    Somit kann man zu jeder Zeit jede Textur überall für verwenden.

    Wenn ich jetzt noch den Char Speicher anpasse und den Chars noch 60 Plätze zum Puffern gebe dann habe ich im unteren Speicher auf einmal wieder ca. 348kb mehr zur verfügung. >420KB sind dann noch frei, das sollte dann für den Rest noch locker reichen.

    Und ich kann mir 100 Charaktere basteln wenn ich lust und Laune habe sind 2,052MB im Speicher 2000 Texturen. Das sollte reichen.