Seite 1 von 2
besseres dsa
Verfasst: 23.01.2010 23:38
von Conrad
gibt es eigentlich noch schnellere methoden als
Code: Alles auswählen
Repeat
ClearScreen(0)
...
StartDrawing(ScreenOutput())
Plot(0,0,0)
StopDrawing()
...
FlipBuffers()
Until quit=1
ich frage, weil das dsa-drawing so bei mir nicht annährend so schnell ist wie die sprite-darstellung.
Re: besseres dsa
Verfasst: 23.01.2010 23:55
von gnasen
schau einfach mal in der Help unter DrawingBuffer(). Es gibt auch ein Beispiel dazu, was ganz gut zu verstehen ist.
Das sollte die schnellste native Variante sein.
Generell braucht der Aufruf von StartDrawing() etwas, ist nicht der schnellste. Deswegen möglichst alle Zeichenoperationen in so wenig Drawing-Blöcken wie es gerade geht unterbringen.
Re: besseres dsa
Verfasst: 24.01.2010 00:07
von Conrad
danke für die schnelle antwort!
DrawingBuffer() hab ich schon versucht, habe ihn 2x am anfang vor der schleife aufgerufen und den wert gespeichert und dann
direkt in den mem geschrieben (immer abwechselnd für je einen flippbuffers()-mem). hat aber geflackert wie wild.
Re: besseres dsa
Verfasst: 24.01.2010 00:09
von Kaeru Gaman
je nachdem was du machen willst...
es ist meistens schneller, mehrere hundert sprites darzustellen, als was umfangreiches zu drawen.
"objekte" die du per drawing zusammensetzen willst, kannst du zu beginn auf ein Sprite drawen und später nur noch displayen...
Re: besseres dsa
Verfasst: 24.01.2010 00:16
von Conrad
das ist eine gute idee, die aber nur ein teilproble von mir löst, es muss nämlich auch noch gezoomt werden (alles was gedrawt wird) ...
Re: besseres dsa
Verfasst: 24.01.2010 00:21
von Conrad
hab mal getestet, wieviel punkte er jz wirklich drawt : ca. 70.000
mit entsprechenden performance-algos (keine pixel mit gleichen koordinaten 2x darstellen,etc...) komm ich vieleicht auf 30000,
aber mit allem was noch dazukommen wird, werden es sicher noch mal 2.5x so vieler.
Re: besseres dsa
Verfasst: 24.01.2010 00:59
von Kaeru Gaman
ach übrigens... soweit ich weiß, nutzt der PB-Befehl Plot nur DSA wenn du die Farbe mit angibst, ohne Farbe geht er über den DC, wie die anderen Draw befehle.
(deswegen ist es wichtig, Plots mit Farbangabe nicht mit anderen Drawings zu mischen, weil er sonst hin und her schalten muss, das verlangsamt das ganze extrem)
das galt jedenfalls für die alte Drawing-Lib, obs seit der 4.40 mit der neuen Lib noch zutrifft ist mir jetzt nicht bekannt.
zu dem gezoomten:
du könntest auch auf ein Sprite displayn, daraus ein Sprite3D machen und das zoomen.
das geht allerdings nur mit DX7 richtig.
alternativ könntest du noch einen WondowedScreen mit Autostretch benutzen,
wenn du einen 100x100 WindowedScreen mit Autostretch in ein 200x200 Fenster packst,
wird der automatisch 2x gezoomt, damit überläßt du es der Hardware, das ist das schnellste.
Re: besseres dsa
Verfasst: 24.01.2010 01:13
von Conrad
Kaeru Gaman hat geschrieben:ach übrigens... soweit ich weiß, nutzt der PB-Befehl Plot nur DSA wenn du die Farbe mit angibst, ohne Farbe geht er über den DC, wie die anderen Draw befehle.
(deswegen ist es wichtig, Plots mit Farbangabe nicht mit anderen Drawings zu mischen, weil er sonst hin und her schalten muss, das verlangsamt das ganze extrem)
plot hat bei mir praktisch immer eine farbangabe.
aber was macht den die sprite-engine(?) so groß anders als dsa?
Re: besseres dsa
Verfasst: 24.01.2010 04:41
von Kaeru Gaman
das sind nur noch reine textures, die sich direkt in der Grafikkarte tummeln.
du schiebst also nur noch die position für die ausgabe durch den port, alle daten sind im GraRam.
Re: besseres dsa
Verfasst: 24.01.2010 16:17
von Conrad
also ist es am schnelsten, die sich nicht ändernden obj. mit sprites(3d) anzuzeigen und den rest mit dsa zu drawen, oder?
eigentlich wollte ich ja keine sprites verwenden, sondern alles direkt aus der berechnung auf den screen bringen >.<