Beiträge von Markus

    ....wenn ich beim initialisieren der Variable =0 weg lasse dann Funktioniert es ohne Fehler.



    wenn ich im Compiler Register Variables auf none stelle, dann funktioniert es auch.


    Ist das zufall oder hat hier der Compiler meine Variable geschreddert?

    momentan schaut es so aus.


    Texturen in den speicher laden


    Diese Funktion gibt die kopier anweisung



    Das ist die aufgerufene Funktion. ...es funktioniert halt irgendwie fast immer bei gewissen Adressen schreibt es aber den XMShandle um...


    was komisch ist, ich schreibe immer in die selben Ziel adressen, aber manchmal schreibt er scheinbar wo anders rein.


    Anscheinend tritt der Fehler ab Textur 139 bis 154 auf...danach 155 Funktioniert wieder...alles ziemlich merkwürdig. Ich verstehs nicht wirklich.

    das hatte ich gestern schon versucht, irgendwie reserviert er immer alles egal was ich da eingebe.



    Momentan ärgert mich auch der Code ein wenig, der umbau vom Map Editor funktioniert bisher reibungslos. Aber im Spiel wird der Inhalt der Variable XMShandle ab und an verändert obwohl es keinen befehlt gibt der das macht.

    Das Problem tritt immer bei kopieren auf, wenn die Quelladresse gewisse Werte hat.


    Wenn ich als Quelle den richtigen Handle wähle und als ersten Byte im Speicher 142614 >> müsste dann Offset 11542 / Segment 2 sein. Dann tritt der Fehler auf. Bei niedrigeren Adressen und teilweise bei höheren tritt der Fehler nicht auf.

    Merkwürdig das der Fehler auftritt wenn ich die Quelladresse ändere, die Zieladresse bleibt immer gleich. Also dürfte ja eigentlich nichts überschrieben werden, weil ich ja nur wo anders lese.


    der Reservierte XMS Speicher ist 1,5MB groß wovon lediglich 300kb belegt sind.


    Merkwürdig ist, wenn ich die Variable XMShandle später initialisiere (ein Array von 909 Chars habe ich jetzt einfach davor zuteilen lassen) dann tritt der Fehler nicht auf.

    Hierdurch ändert sich ja die Adresse der Variable... also scheint irgendwas die Adresse gezielt zu überschreiben.

    Jo Borland ist halt Borland.

    Die hatten immer eine brauchbare IDE und auch sonst läuft der compiler schön stabil.


    Wenn man XMS / EMS nutzen will, muss man vorm start einfach reservieren... wüsste jetzt nicht das man den compiler mit hausmitteln daran hindern kann einfach alles beim start zu reservieren was frei ist.

    Momentan bin ich glücklich mit dem Borland c++ 3.1... der läuft richtig schön stabil und ich wollte ja erstmal bei 16bit Code bleiben.

    Das ganz alte zeug halt nochmal durch gehen.

    Grössere Software Projekte für Dos denke ich sind eher selten.


    Bei Amiga / C64 wird vermutlich mehr los sein.


    Aber ich arbeite gerne mit den alten 16 bit compilern, Basic und die Borland compiler mag ich einfach.

    Es muss ja nicht schnell fertig werden und auf so alten Kisten macht das optimieren meist irgendwo Spaß.


    Bis auf das eine mal wo der compiler die Festplatte komplett zerlegt hatte war alles immer ok ...kann unter DOS passieren.

    Deshalb wird der 386DX40 Rechner nur zum entwickeln und testen verwendet. Zum spielen gibts nen andern 386.

    Ich bin dann mal so frei.


    Ich habe jetzt soweit alle wichtigen Routinen in diese Funktions Sammlung gesteckt.


    Damit kann man alles wichtige machen.


    Unten in der Main ist dann ein Beispielprogramm welches folgendes macht.


    XMS Treiber prüfen

    XMS Manager Adresse abfragen


    XMS Handle reservieren


    Die ersten 10 Byte des Char Array Text1 in den reservierten XMS Handle kopieren

    Die 10 byte vom reservierten XMS Handle kopieren in das Char Array Text2


    Den reservierten XMS handle wieder frei geben


    ENDE!


    Man kann das Programm so nicht von den meisten compilern starten, weil diese während der Ausführung meist selber den kompletten speicher reservieren!


    ...ich umgehe das Problem indem ich vor dem Ausführen XMS reserviere und dann vom compiler aus den Handler mit einem toll wieder frei gebe, dann kann man auch vom compiler aus den Code ausführen.

    ...testen und experimentieren auf eigene Gefahr.

    habe ich noch nicht gemacht... c++ ist halt ziemliches Neuland für mich.


    ...hatte gestern 6 Stunden an dem Code gebastelt und am ende dann festgestellt das der Compiler sich irgendwo was verstellt hatte und deshalb immer alles abstürzte.


    Wenn du ein Beispiel hast immer gerne her damit.. sonst muss ich wieder suchen.

    Der Compiler ärgert mich mal wieder wo er nur kann.


    ich muss einer Funktion eine Variable übergeben damit die Funktion auf dessen Adresse zugreift.


    Wenn ich das über Pointer versuche, wird die Adresse der Pointer übergeben.

    Kann machen was ich will es Funktioniert nicht.


    Ich bin jetzt so weit das ich den Adresswert als HEX oder dezimal übergebe, weil es anders komplett unmöglich erscheint.


    Nur finde ich bei der Lösung keinen Wert die Adresse einer Variable in einer anderen Variable als unsigned long Wert zu übergeben.




    mir fällt einfach keine Lösung ein und ich finde im Netzt absolut garnichts wie man an die Adresse als zahlen Wert kommen kann.

    Ich werde jetzt wohl erstmal eine Funktionssammlung zusammen stellen, welche ich dann Programmübergreifend nutzen kann.

    Danach muss ich dann schauen das ich den MAP Editor anpasse damit ich dann Texturen frei wählen kann nach lust und laune.

    Und dan brauche ich noch Funktionen die den Speicher verwalten in dem Texturen innerhalb der unteren 640kb abgelegt werden die ständig genutzt werden.


    Mir wird nicht langweilig...

    ich habe heute einen ersten Teslauf auf dem 386 gemacht mit einem Testprogramm.


    Das Testprogramm ist das Spiel ...wobei bei jedem Frame zusätzlich noch 2 Texturen 2048 Byte vom XMS in den unteren Speicher bereich kopiert werden. Ich hätte hier jetzt eigentlich mit frame einbrüchen gerechnet zumal das Programm normalerweise 36-37 FPS macht wenn kein NPC durchs Bild läuft und der Char steht... was soll ich sagen, wenn ich bei jedem Frame die 2 Texturen im XMS verschiebe verliere ich KEIN FPS!!!

    Also können locker 36-37 Aufrufe an den XMS Manager gesendet werden zum kopieren von jeweils 2 Texturen = 74 Texturen innerhalb einer Sekunde ohne das das System merklich an geschwindigkeit verliert.

    Testrechner war wie fast immer der 386DX40 mit 8MB Ram wovon 1MB mit XMS genutz werden!


    Ich hätte hier schon erwartet das die geschwindigkeit irgendwo einbricht... dem ist nicht so!

    ...genau mein Programm schnappt einen Handle und reserviert einfach einen 4MB Block.

    Dann starte ich Borland, das schnappt sich alles was zu bekommen ist.

    Jetzt muss man nur noch mit dem 1. Programm was man startet den speicher Handle wieder frei geben und ich habe 4MB XMS wieder frei.

    Mein Problem ist das Borland beim starten einfach den kompletten speicher reserviert. Es sind 0KB über.


    Im grunde braucht man ja nur einen Handler für sein Programm.

    XMS Handler können ja extrem gross sein, da gibts keine 64kb Grenze.

    ...ich habe das Problem umgangen indem ich es nicht in Assembler sondern schon davor im Code angepasst hatte.

    Ich werde da noch einiges umstricken müssen.


    Immerhin konnte ich erste änderungen durchführen. Beim laden Wird geprüft ob XMS verfügbar ist.

    Dann werden 1,5MB reserviert in einem Handle!


    danach werden alle Texturen aus 20 Dateien in den Handle geschoben.


    Beim laden der Textur werden dann die alt bekannten Textur datenbanken vom XMS in die 4 Arrays geschoben.


    Das ganze funktioniert schonmal ganz gut.

    ...Kevin läuft auch wieder fröhlich durchs Bild. Dabei fällt mir auf Kevin frisst 15FPS beim 386... der ist ganz schön hungrig!



    ....jetzt muss ich BC nur noch dazu bewegen mir nicht den ganzen XMS zu klauen vor dem Start! das wäre ziemlich praktisch!


    Habe ein kleines tool welches XMS reserviert mit handler 1 bei Dosbox, anschliessend starte ich Borlande C++.

    Dann starte ich ein tool welches handle 1 frei gibt im compiler und anschliessend habe ich 4 MB frei ...geht so auf jeden fall schonmal!



    Edit ... die XMS Handler beim 386 sind auch komisch, der erste ist 2701, der Treiber sollte nur 32 Handle zur verfügung stellen wie kommt der da auf 2701?

    Bei Dosbox fängt der erste brav mit 1 an.

    Ich brauche nochmal eure Hilfe.... bin mit Assembler noch nicht so fit und mir qualmt der Kopf vom ganzen Code umbauen.



    was ich machen möchte ...MXsp ist ein Pointer

    Code
    MXsp=&MXspriteT1[0][0];


    wenn ich den Code wie folgt schreibe wird scheinbar die Adresse des Pointers übergeben und nicht die Adresse der Variable worauf der Pointer zeigt.


    Wie kann ich die Adresse einer Variable über einen Pointer im Assembler Code übergeben?

    Code
    //    mov word ptr 12[si],offset MXsp;
    //    mov word ptr  14[si],seg MXsp;