Beiträge von Markus

    an den Map Details am arbeiten.

    es gibt jetzt nicht nur hinter dem Baum... die charaktere können jetzt auch vor oder hinter dem Stamm stehen.


    die ganzen "Kreaturen" und teile der Landschaft werden jetzt immerhin schon mit 16bit texturiert, das führt aktuell zu grafikfehlern im linken rand werden im ungünstigsten Fall 4 fehlgeleitete Pixel Spalten angezeigt wie im ersten Bild zu sehen, was rechts werden 4 Pixel zu viel gezeichnet ausserhalb des Bildschirms, diese landen dann ganz links im Bild als die ersten 4 ...so ist der Grafikspeicher nunmal zugewiesen.

    Da muss noch eine überprüfung rein und ggf muss der Pixel dann halt weg gelassen werden, es frisst dann wieder etwas von der gewonnenen Rechenleistung weg.

    Übung beim löten kann nie schaden, man wird irgendwann auf mal irgendwo was reparieren müssen an einem alten Rechner und da ist es besser man hat vorher schonmal ein paar übungsläufe mit "billigen neuen" Platinen durch gemacht, dann ist man auch sicherer wenn man dann mal an einem alten Board was reparieren muss.

    neuen Einbauheizkörper für PC's XT's AT's ...tinyhouse?


    und ein Adlib Clone... aber einer der schon retro ist. So ein teil hatte ich Ende der 90er selber auch schonmal,freue mich darum um so mehr den zu testen... und später darauf was zu programmieren, wenn ich mit der Grafik geschichte durch bin.

    !

    haha, das das triggert!!! Davon stehen dann 2 nebeneinander, das triggert noch mehr.

    Aber die sind so schön stabil und übersichtlich, weil eben das Netzteil unten liegt.

    Man sieht sofort das Board ähnlich wie bei einem Desktop, aber es nimmt weniger Platz weg und der Monitor stehr nicht darauf.



    1x Glasreiniger und Breff...Netzteil riecht natürlich immer noch wie eine Kneipe, aber er ist drumherum erstmal sauber.

    CD-Rom war ein 1994 Mitsumi 2x ...später mal testen.


    Die Grafikkarte muss ich auch nochmal bearbeiten.

    auch neu bekommen, es kommt aber kein Bild. keine Ahnung was es hat leider habe ich auch keine Ahnung was die Jumper machen.

    Hoffe ich bekomme die noch hin, eine Eisa Karte für mein Eisa System wäre schon ganz nett.

    hatten wir schonmal so ähnlich,

    erst vor kurzem so einen Rechner mit einem 486 Eisa drin bekommen.

    Sobald man den sehr massiven Deckel öffnet hat man direkt oben das Mainboard mit den Karten, das Netzteil ist unten auf dem Boden.

    Auf jeden Fall konnte ich an ein 2. Gehäuse mit CD-Rom und Netzteil kommen, habe nicht lange überlegt und zugeschlagen... leider stinkt das teil wie 10Jahre Kettenraucher.

    Wird deshalb erstmal komplett zerlegt und desinfiziert!

    Ansonsten gibt es keine Kratzer oder ähnliches.

    Hier kann bald ein 386 einziehen.

    würde mich jetzt schon fast wundern wenn die TASM Version dann 32bit kann... vermutlich werde ich mir dann irgendwo eine neuere besorgen müssen, im netz findet man ab und an Hinweise hierzu.

    wie funktioniert das denn mit den ASM Routinen per .obj? muss ich die mit einem anderen Programm erstellen oder? weil das wäre eine einfache Lösgung für das Problem und die direkten Grafik routinen sind aktuell ja sowieso assembler.



    was mir halt auch auffällt ist das solche if then blöcke sehr viel rechenleistung brauchen... kann man das irgendwie schneller machen?

    schaut beides gleich aus ...nur die FPS 43 zu 35...Code umbauen nur noch 4xPlane switch je Kachel, vorher waren es 32!

    Komplette System wird umgebaut alles soll voll erstmal 16Bit ausnutzen. 32bit ist der Borland zu blöde für...das nerft. kein EAXund Co.

    ob Mode X oder VGA schneller ist hängt viel vom System ab und davon was für Grafik dargestellt wird.

    Wenn man eine feste Map hat und diese auf dem Bildschirm verschiebt, dann braucht man mit Mode X nur einen bruchteil neu zu zeichnen, das ist viel schneller wie VGA, weil man bei VGA 64000 Pixel neu zeichnen müsste und bei Mode X 1280 Pixel, bei Mode X kann ich auch 32 bit ansteuern dann zeichnet man halt alle 4 pixel, da ich 32x32 Kachel habe ist das relativ egal ich muss 4x die bank wechseln im idealfall. wenn ich horizontal scrolle nutzt es mir aktuell nichts... aber man kann den Bildschirmbereich bei Mode X breiter machen, wenn ich diesen um 32 Pixel vergrösser kann ich mit 32bit immer komplette kacheln zeichnen und muss das dann auch nur noch alle 8 bewegungen in eine richtung wiederholen.


    Was dem ganzen die geschwindigkeit nimmt sind halt objekte auf der Map die sich bewegen, diese sind aber in den meisten spielen nicht in so extrem grosser Menge vorhanden. wenn ich hier wieder optimiere hat VGA aber auch selbst dort kaum vorteile, alles in allem müsste Mode X selbst wenn 50% des Bildes neu gezeichnet wird noch schneller sein wie VGA.


    Wenn der Rechner so schnell ist das es sich lohnt den kompletten Bildschirm neu zu zeichnen oder wenn die Grafik das erfordert, ab dann ist VGA im vorteil weil man keine Planes mehr wechseln muss, wobei man bei VGA einfach keinen Backbuffer hat und es fehlt halt auch der komplette Grafikspeicher, ist schon ein risen nachteil.


    Ab einem schnelleren Pentium kann man dann auf Vesa zurückgreifen, damit hat man endlich genug zugriff auf die Grafikkarte und kann auch problemlos mit mehreren Speicherseiten arbeiten.

    Hatte früher unter Turbo Pascal viel mit vesa gearbeitet., dagegen ist VGA egal wie immer quälerei.

    Doom und Heretic nutzen beide Mode X/Y 320x200 320x240 damit kann man im grunde 8 Pixel auf einmal in der selben Farbe einfärben (16Pixel mit 32bit), davon profitieren 3D Spiele noch am meisten. Zoomt man nahe an den kleinen Texturen heran, dann sind immer genug Pixel in der selben Farbe nebeneinander. Wolfenstein würde mit detailreicheren Texturen komplett einbrechen auf langsameren Rechnern.

    Der normale VGA Modus hat schon keine 2. Bildschirmseite, dann hätte man keinen Backbuffer und man kann auch nicht scrollen wie bei Mode X, was ja auch noch richtig Leistung bringt bei meiner Anwendung.

    Doom profitiert hauptsächlich von den vielen Bildschirmseiten und es wird auch wieder einiges an texturen für die Statusleiste direkt kopieren im vram, das geht immer am schnellsten, ist aber nur begrenzt verfügbar.


    ich müsste den Assembler Part 32bit hin bekommen, dann könnte ich noch was grösseres umbauen was mir einiges an Leistung bringen könnte eventuell.

    alles mögliche von 8bit auf 16 bit umgeschrieben... von 5-6FPS auf 9-10FPS konnte ich jetzt die Leistung steigern... es gibt allerdings noch einiges was nicht optimal ist beim umbau auf 16 bit.

    kann man Borland c++ nicht dazu nötigen den Assembler auch 32bit zu fressen?

    32bit würde schon noch mehr bringen denke ich und langsammer wie 386 macht hier sowieso keinen sinn dafür wird einfach zu viel geladen und verändert in der Grafik.

    aktuell wird alles 8bit gezeichnet im Programm... hängt auch mit dem verschachtelten aufbau von Mode X zusammen.

    Da ich fast immer nur 4 pixel nebeneinander zeichne und mehr nicht, wird es leider nicht schneller.


    Wenn ich mit 16 bit arbeite setzt die Grafikkate blöderweise Pixel 0 und 5 oder einfach gesagt X und X2 ist 4 pixel weiter daneben.

    wenn ich komplette bereiche nachzeichne, könnte ich das allerdings nutzen.

    in der Funktion wird lediglich eine Zeile ergänzt für den 2. Pixel.


    Normal VGA kann halt leider weder scrollen noch gescheit den Grafikspeicher nutzen, sonst wäre hier auch viel mehr mehrnutzen drinn.


    Die Prüfungen muss ich natürlich auch anpassen, aber das wäre der Anfang um den 2.Pixel mit zu setzen in der Assembler Routine.

    ins Bios kommt man fast immer mit der ENTF ..ernen taste beim booten. F1 genügt immer nur dann wenn das Bios selber meckert, was es für Datum Uhrzeit normalerweise nicht macht.

    das Mapdesign gibt vor wieviele texturen sich ändern, das bestimmt dann auch wie lange geladen wird auf einmal.

    Wenn man irgendwo einen schmalen durchgangh macht eine schlucht wo man nicht oft durch muss, kann man auch einmalig 5-10sekunden Laden verkraften denke ich.

    Bei kleineren veränderungen der Landschaft kann man einfach immer mal 20 texturen bei laden denke ich, das sind 20kb, sollte schnell genug gehen.

    Hier überlege ich wirklich auch später wie schon von root vorgeschlagen einfach die texturen in den EMS zu laden, das würde dann auch schnelleres laden bedeuten.

    Im endeffekt ist ausschlaggebend wie lange es direkt von Platte dauert, ist es schnell genug kann man es auf diesen kurzen weg machen und man benötigt kaum RAM, ladet es zu langsam kann man überlegen beim start alles in den RAM zu laden.

    alles hat sein für und wieder, packe ich direkt beim start alles in den speicher so habe ich bei spielstart irre lange Ladezeiten, sind die häppchen die man nachladet klein genug so kann es sein das es flüssig durch läuft und man kaum noch ladezeiten hat.


    Der 386/486 wird mir sagen was er davon hällt...


    Das Testen der 4 Eckpunkte um den grossen Pixeltest teilwiese zu umgehen bringt effektiv ein paar FPS, macht aber nicht den grossen sprung nach vorne.

    ich habe es dann gewagt den rest meines Grafikspeichers mit hilfe von Latch copy als backup für den hintergrund wo die Figur sich bewegt zu nutzen, weil hier auch viel neu gezeichnet werden muss immer, das brachte einiges an geschwindigkeit... ich muss jetzt nur prüfen wieviel speicher ich dort noch habe für wieviele Kreaturen... und ich bruache einen plan b wenn der Grafikspeicher überläuft, damit dann nicht alles crashed.


    Prost!