Bitte um Speed und crash test von meiner Lupen Funktion !!!!
Übersicht
BlitzBasic BlitzPlus
SilbersurferBetreff: Bitte um Speed und crash test von meiner Lupen Funktion !!!! |
 Do, Apr 17, 2014 23:48Antworten mit Zitat 
|
|
|---|---|---|
|
Hallo liebe Community
Ich bitte euch um mithilfe, es geht darum die Geschwindikeit Der Lupenfunktion auf anderen System zu Testen da ich Leider nur 2 verschiedene Systeme Daheim zu verfügung habe.... In Moment ist nur das Grundgerüst sowie die Lupe fertig, aber das war auch das wichtigste. Das Proggy Ist in BlitzPlus Geschrieben Um das Programm zu Testen müßt ihr ein Bild über das Menu einladen  Lupe anschalten mit der kleinen Taste L
auf dem Nummerblock die Tasten + und - für den Zommfactor
Rechte Mausteste im Übersichtsfenster zum Grabben der Lupe
Linke Maustaste in der Lupe um zu Malen
farben auswählen im farbregister mit der linken Maustaste
FPS anzeige in der Statusanzeige mit Spacetaste auf vollspeed umschalten und dann
Mit der maus aus dem Imagebreich rausgehen.... wegen der eventgeschichte Es würde Mich sehr freuen wenn ihr mitmachen würdet 
hier der Download zum testen http://home.arcor.de/silbersur...intneu.zip 
|
||
|
RallimenSieger des 30-EUR-Wettbewerbs |
Fr, Apr 18, 2014 11:12 Antworten mit Zitat
|
|---|---|---|
|
22 FPS
Win 7 Prof 64 bit 4GB Ram Ahtlon 64 X2 6400+ Geforce GT 240 |
||
|
[BB2D | BB3D | BB+]
|
||
PhillipK |
Fr, Apr 18, 2014 12:23 Antworten mit Zitat
|
|
|---|---|---|
|
59 FPS bei niedrigstem Zoom;
31-41 FPS bei höchstem Zoom Das sagt mir, das du keinen Check drin hast, was überhaupt sichtbar ist, da es bei höherem Zoom bei deiner Technik MEHR fps geben müsste( weniger rects, weniger zu zeichnen - mehr fps) Tipp 1: Bau einen Bounds check ein. Du weißt schon, wo der zoombereich ist (die vorschau im rechten bild) - zusammen mit den koordinaten kannst du die pixel abklappern die sichtbar sind. zum zweiten: Der Sichtbare krams wechselst wesentlich seltener als 20-60x die sekunde. Schau dir doch mal https://www.blitzforum.de/help/ImageBuffer an. Eventuell kannst du den "gezoomten" bereich vorrendern? Das würde nur bei userinteraktion (zoom bereich verschieben, zoomstufe ändern) einen redraw nach sich ziehen, was bedeutet, das du dauerhaft mit guter performance laufen kannst 
Mein System: Win 7 64bit Amd Phenom II x4 955 (3,2 ghz quadcore) Nvidia Geforce GTX 550 TI 12gb ram |
||
|
DAK |
Fr, Apr 18, 2014 18:33 Antworten mit Zitat
|
|---|---|---|
|
Das Programm verwundert mich schwer. Ich habe in meinem Laptop zwei Grafikkarten, eine Intel HD 4000 und eine Nvidia Geforce 635M. Die Nvidia ist üblicherweise deutlich schneller. Bei deinem Programm ist es umgekehrt, und das auch noch deutlich.
Nvidia Geforce 635M: 530 FPS ohne Zoom, 160 FPS mit (+-10%) Intel HD 4000: 2000-3000 FPS ohne Zoom, 200 FPS mit (+-10%) Kann mir das nur dadurch erklären, dass BlitzPlus alles auf der CPU rendert und dann nur mehr das fertige Bild an die Grafikkarte zum Zeichnen schickt. Das würde bei der HD 4000 deutlich schneller sein, da sie direkt im Prozessor eingebaut ist, und nicht wie die Geforce ein halbes Mainboard weit weg liegt. Windows 7 64bit i7-3632QM, 2.2 GHz x8 Nvidia Geforce 635M / Intel HD 4000 8 GB RAM Edit: Chrome flaggt das File übrigens nicht als "könnte bedrohlich sein", sondern ist als "ist schädlich". Habe es noch auf Virustotal.com gegengecheckt, wo es von 2/50 Virenscannern als bösartig eingestuft wird. Nur zur Info, vielleicht kannst du ja was dagegen machen. |
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
|
BtbN |
Fr, Apr 18, 2014 19:09 Antworten mit Zitat
|
|---|---|---|
|
Das ist nur das übliche "jemand hat nen virus mit BlitzBasic gebaut" phänomen.
Dagegen machen kann man nix, außer sich bei den Virenprogrammen beschweren. |
||
|
|
DAK |
Fr, Apr 18, 2014 19:12 Antworten mit Zitat
|
|---|---|---|
| Einen Virus mit BlitzBasic schreiben stell ich mir übel anstrengend vor... Aber ja, daran wirds wohl liegen. War nur so zur Info. Ich hab schon länger nichts Ernstes mehr in BB gemacht, bin also nicht mehr ganz am Laufenden. | ||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
Silbersurfer |
Fr, Apr 18, 2014 19:39 Antworten mit Zitat
|
|
|---|---|---|
|
Hallo leute vorab erstmal danke für den Test
Dak Zitat: Das Programm verwundert mich schwer
das habe Ich auch gemerkt, das es bei Nvidia zu Performence einbrüchen Kommt warum kann Ich in moment mir nicht erklären 
Zitat: Kann mir das nur dadurch erklären, dass BlitzPlus alles auf der CPU rendert und dann nur mehr das fertige Bild an die Grafikkarte zum Zeichnen schickt.
Die Grafiken liegen im VRAM Bei meinen laptop ist es das gleiche wie bei dir Nvidia GT620M: 480 ohne zoom, 120 mit Intel HD 4000 : 2500 ohne Zoom,180 mit ausser bei ATI Ati HD6950 ohne zoon 11500, 330 mit PhillipK Zitat: Das sagt mir, das du keinen Check drin hast
die Lupe ist mit Read/writefastpixel und im locket Buffer geschrieben wenn dort mehr gelesen oder geschrieben würde gäbe es ein Mav und Absturz Ich denke es liegt an den For Next schleifen, die ich verschachtelt habe, vielleicht kann Ich hier noch etwas nachbessern. Auf jedenfall schon mal gut das es bei euch zu keinen MAV oder Absturz des Proggy kam BlitzBasic: [AUSKLAPPEN] For ly=posy To y Edit wie meinst du das jetzt mein Programm soll bedrohlich sein Hmm. Ich greife nur auf die API zu, zum einsetzen des Icon im Fenster Und anschließend nutze ich Resoucen Hacker damit mein Progamm
die Windows 7 Gui nutz das ist alles. Mein Programm ist auf keinen Fall ein Virus nur zur Info Aber Danke DAK für die Info |
||
|
Thunder |
Fr, Apr 18, 2014 22:06 Antworten mit Zitat
|
|---|---|---|
|
Hab es Mal auf nem Netbook getestet, das schon etwas älter ist.
Nervig ist auf dem Ding vor allem, dass das Programmfenster teilweise außerhalb des Bildschirms liegt (Y-Koordinate der Titelleiste kleiner als 0). Glücklicherweise springt die Titelleiste nach unten, wenn man das Fenster skaliert. Das zweite ist, dass ich auf diesem PC keinen Nummernblock habe, also konnte ich nicht hinaus- oder hineinzoomen, wie du es beschrieben hast. Also funktioniert hat es, ich hatte so 14-18 FPS. Windows 8.1 32bit 2 GB RAM Intel Atom N280 1,666 GHz x1
Intel GMA950 |
||
|
BladeRunnerModerator |
Fr, Apr 18, 2014 22:09 Antworten mit Zitat
|
|---|---|---|
|
Zitat: PhillipK
Zitat: Das sagt mir, das du keinen Check drin hast die Lupe ist mit Read/writefastpixel und im locket Buffer geschrieben wenn dort mehr gelesen oder geschrieben würde gäbe es ein Mav und Absturz Ich denke es liegt an den For Next schleifen, die ich verschachtelt habe, vielleicht kann Ich hier noch etwas nachbessern. Auf jedenfall schon mal gut das es bei euch zu keinen MAV oder Absturz des Proggy kam Ich glaube3 Du hast Phillip nicht ganz verstanden. Er zeit Dir ja einen Weg wie Du deine performance maximieren kannst, indem Du eben nur updatest wenn es nötig wird. |
||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
|
|
DAK |
Fr, Apr 18, 2014 22:11 Antworten mit Zitat
|
|---|---|---|
|
Der API-Call ist ziemlich sicher nicht das Problem. Das Resouce Hacker gebastel aber eventuell schon. Hab schon gelesen, dass das Probleme mit Virenscannern machen kann. Kann aber auch sein, dass alle Blitz-Programme geflaggt werden.
ReadPixelFast/WritePixelFast sind Befehle, die direkt von der CPU ausgeführt werden. Da ist es recht wurscht, ob die Bilder im VRAM liegen oder nicht, wenn jedes Pixel einzeln von der CPU auf den VRAM geschrieben wird. Ich bin mir nicht sicher ob du das nicht eh schon machst, aber bei ReadPixelFast/WritePixelFast ist es fast immer zu empfehlen nicht jedes Frame alles neu zeichnen zu lassen, sondern bei jeder Änderung alles in ein Bild zu rendern und das dann jedes Frame zu zeichnen. Die einzige Ausnahme, wo das nichts bringt, ist wenn sich das Bild (fast) jedes Frame groß ändert (wie es z.B. bei einem Partikelsystem oder so der Fall ist). Warum zeichnest du die Bilder im Zoom eigentlich so gerastert? Soweit ich sehe hast du für ein Pixel im Original auch im Zoom nur ein Pixel, und der Rest wird mit Grau aufgefüllt. Wäre es hier nicht sinnvoller einfach jedes Pixel zu vergrößern? (So dass z.B. bei einem 2x Zoom aus einem Pixel 2x2 Pixel werden) Ich hoffe, du zeichnest mit dem WritePixelFast wirklich nur die Pixel, die sich im sichtbaren Bereich befinden, oder? |
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
PhillipK |
Sa, Apr 19, 2014 1:57 Antworten mit Zitat
|
|
|---|---|---|
|
Silbersurfer hat Folgendes geschrieben: die Lupe ist mit Read/writefastpixel und im locket Buffer geschrieben wenn dort mehr gelesen oder geschrieben würde gäbe es ein Mav und Absturz Ich denke es liegt an den For Next schleifen, die ich verschachtelt habe, vielleicht kann Ich hier noch etwas nachbessern. Auf jedenfall schon mal gut das es bei euch zu keinen MAV oder Absturz des Proggy kam BlitzBasic: [AUSKLAPPEN] For ly=posy To y Leider stehen für uns dort nur kryptische variablen^^ lx zb klingt nach lupe-x. Aber was ist dann x? Etwa das maximum des sichtbaren bereiches?
Wie auch immer. Der code hilft wohl nur dir am meisten ^^ Mich wundert es halt, das bei kleinerer Zoomstufe MEHR fps erreicht werden. folgender denkansatz wars: Du zeichnest jeden pixel mit Rect() oder ähnlichem; vorher hast du Color() ausgeführt. Je größer ein pixel (ergo das rect) wird, desto mehr fläche belegt das GESAMTE bild gezoomt. Wenn nun alles gezeichnet wird, werden wesentlich mehr pixeln zum rendern angefragt, als bei einem begrenzten bereich. Aber da du mit WritePixelFast arbeitest (und "pixel" scheinbar die farbe ist), ist diese überlegung hinfällig. Dennoch - würde mich mal intressieren ob das anderen auch so geht - wie liegen die FPS unterschieden zwischenn maximalzoom und minimalzoom? Wenn überhaupt müssten die FPS gleichbleiben, wenn jeder pixel des "zoombildes" jedesmal neu gezeichnet wird^^ Zum zweiten, kann ich bladerunner nur beipflichten: Ich konnte feststellen, das die fps varrieren, obwohl nix groß gemacht wurde. Da dies nur einsetzt, wenn der zoom offen ist, gibt es hier eventuell eine fette optimierungsmöglichkeit: Render den gesamten Zoombereich in ein eigenes bild und update dieses nur, wenn sich etwas daran ändern. Die pixel-platzierungsvorschau zum malen kannst du ja weiterhin so zeichnen wie bisher; Die gezoomten daten ändern sich meines sehens nach nur: 1) Der benutzer schiebt einen slider oder klickt im eigentlichen bild -> Zoombereich wechselt, gezoomtes bild ändert sich 2) Der benutzer hat aktiv einen pixel platziert, eine pixelfarbe wechselt 3) Der benutzer hat die zoomstufe geändert. Das sind aktionen die ein mensch durchführt, dh es ist schon rein physisch nicht möglich das diese öfters als 20x die sekunde auftreten - von der logik mal abgesehen. Eine fette optimierungsmöglichkeit ist also: Vorrendern. Dann ist es auch egal, ob deine Zoomfunktion mal 10ms braucht (was sie bisher ja kaum tut - alle 16,666ms muss gerendert werden, dann gibts 60 fps) - und du kannst hinterher noch mehr einbauen. Selbst wenn die funktion dann 30 ms braucht, es stört keinen mehr
Aber scheinbar bin ich der einzige mit schlechterer hardware ^^" 400+ fps? Leute, ganz ehrlich, das ist gemein  ^^
|
||
Silbersurfer |
Sa, Apr 19, 2014 10:12 Antworten mit Zitat
|
|
|---|---|---|
|
PhillipK
Zitat: Mich wundert es halt, das bei kleinerer Zoomstufe MEHR fps erreicht werden
Das hatte mich auch gewundert Phillip, es scheint wie ich schon sagte an der Schleife zu liegen denn zum anfang ist der scheifen durchgang 1 zu 2 damit meine ich, das die erste schleife 1 mal und die innere Schleife 2 mal durchläuft. beim zoom erhöhen wird es dann 1:3 1:4 1:5 1:6 ..... 1:20 u.s.w wie du sehen kannst erhöht sich der scheifen durchlauf drastisch Zitat: Leider stehen für uns dort nur kryptische variablen
hier nochmal die schleife mit ausagekärftigen Variabeln Namen BlitzBasic: [AUSKLAPPEN] For ready=lupey To lupenendey Zitat: folgender denkansatz wars: Du zeichnest jeden pixel mit Rect()
Aber da du mit WritePixelFast arbeitest (und "pixel" scheinbar die farbe ist) Mit rect writex,writey,lupenfactor,lupenfactor hatte ich das auch schon getestet, nur ist das erst ab einen zoomfactor 18 gleichschnell und dann schneller. Zitat: Zum zweiten, kann ich bladerunner nur beipflichten:
Eine fette optimierungsmöglichkeit ist also: Vorrendern Es ging mir hier darum wie schnell die Lupe in Realtime bei anderen System läuft. Die Lupe wird in einen Imagebuffer vorgerendert und nach bedarf angezeigt, und natürlch wird sie dann nur geändert wenn der Benutzer z.b am Bild was ändert oder wie du schon sagtest, der Lupenbereich verschoben wird u.s.w Das alles nutzt nur dann was, wenn die lupe halbwegs ordentliche FPS bringt. Aber ansonsten hast du bei allem recht Phillip und dort werde ich noch mehr nachbessern Danke für guten Tipps Thunder ich werde die Tasten + und - auch auf der normalen Tastur berücksichtigen Zitat: Nervig ist auf dem Ding vor allem, dass das Programmfenster teilweise außerhalb des Bildschirms liegt
Daran hatte Ich bei diesen Test garnicht gedacht, also werde ich eine überprüfung der Destop() größe vornehmen und demensprechend die größe des Fensters ändern danke Thunder |
||
|
-------------------------------------------------------
XP 2000+ 512DDR Radeon 9800 XL 340GB HD Hompage : http://home.arcor.de/silbersurfer01/ Is Bob engine http://home.arcor.de/silbersur.../Isbob.zip |
||
|
|
DAK |
Sa, Apr 19, 2014 12:39 Antworten mit Zitat
|
|---|---|---|
|
Zum Code: Der sollte (sofern lupenendex und lupenendey sich passend mitskalieren) eigentlich immer konstant viele Durchläufe haben.
So weit ich es verstehe gehst du ja jedes auszulesende Pixel aus dem Lupenbild durch und schreibst dann ein factor*factor Rect mit WritePixelFast in den Output, oder? Dabei sollten die Breite und Höhe der Lupe ja um den Faktor verkleinert werden. Das gibt dann folgenden Aufwand: BlitzBasic: [AUSKLAPPEN] For ready=lupey To lupenendey ;Lupengrundhöhe / Faktor Alles zusammen (fürs Schreiben) hat also folgenden Aufwand: (Lupengrundhöhe/Faktor) * (Lupengrundbreite/Faktor) * Faktor * Faktor. Faktor kürzt sich komplett raus, übrig bleibt nur mehr Lupengrundhöhe*Lupengrundbreite Für's Lesen fallen die beiden innersten Schleifen weg, der Aufwand ist also: Lupengrundhöhe*Lupengrundbreite / Faktor² Alles zusammen sollte es bei höherer Zoomstufe bis zu doppelt so schnell werden, wie ohne Zoom (gegeben dass Lesen und Schreiben ungefähr gleich lang braucht). Kann es sein, dass du lupenendx und lupenendy nicht mit anpasst? Wenn dem so ist, dann solltest du sie in den For-Schleifen noch mal durch den Faktor dividieren. Silbersurfer hat Folgendes geschrieben: Daran hatte Ich bei diesen Test garnicht gedacht, also werde ich eine überprüfung der Destop() größe vornehmen und demensprechend die größe des Fensters ändern danke Thunder
Ich habe hier einen Laptop in der doch recht üblichen Auflösung von 1366x768. Bei mir ginge sich das Fenster aus, wenn da nicht die Taskleiste wäre. Habe für die Tests die Taskleiste an den linken Bildschirmrand verschieben müssen. Wenn man Office-Artige-Anwendungen entwickelt, dann sollten sich diese entweder automatisch an die Auflösung anpassen, oder so klein starten, dass sie sich auf einem 1024x768er Bildschirm ausgehen (und die fette Windows 7/8-Taskleiste nicht vergessen  ). Größer skalieren geht leicht, kleiner nur dann, wenn die dafür benötigten Bedienelemente auch wirklich am Schirm sind.
|
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
Silbersurfer |
Sa, Apr 19, 2014 14:37 Antworten mit Zitat
|
|
|---|---|---|
|
Dak
Zitat: Lupengrundhöhe*Lupengrundbreite
Für's Lesen fallen die beiden innersten Schleifen weg, der Aufwand ist also: Lupengrundhöhe*Lupengrundbreite / Faktor² Das stimmt Dak genauso mache ich das ja auch, der Lesebereich wird durch den Factor Dividiert und der Schreibbereich mit dem Factor Multipliziert. Darum ja auch die Verschachtelung der Schleifen 1 Punk einlesen und dann 4 Punkte schreiben bei factor 2 genau das macht die Lupen schleife so 
Dak Zitat: Alles zusammen sollte es bei höherer Zoomstufe bis zu doppelt so schnell werden, wie ohne Zoom (gegeben dass Lesen und Schreiben ungefähr gleich lang braucht).
und das auch der Grund warum mich das wundert. Bei einen auschitt von 10x10=100 Pixel Lesen wären dann bei factor 2 20x20=400 Pixel schreiben Bei einen auschitt von 5 x 5= 25 Pixel Lesen wären dann bei factor 4 20x20=400 Pixel schreiben also schreiben würde sich nicht ändern und lesen würde sich veringern oder habe ich da jetzt einen Denkfehler ? Ich schaue nochmal alles gründlich durch Danke Dak für deinen Rat hier |
||
|
-------------------------------------------------------
XP 2000+ 512DDR Radeon 9800 XL 340GB HD Hompage : http://home.arcor.de/silbersurfer01/ Is Bob engine http://home.arcor.de/silbersur.../Isbob.zip |
||
|
|
DAK |
Sa, Apr 19, 2014 16:16 Antworten mit Zitat
|
|---|---|---|
| Jo, das war was ich gemeint habe. Lass dir doch mal die Variablen ausgeben, ob die alle auch wirklich so sind, wie du es denkst. Kann sein, dass du dich irgendwo verrechnet hast, und eine von den Variablen nicht mitskaliert. | ||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
Silbersurfer |
So, Apr 20, 2014 11:17 Antworten mit Zitat
|
|
|---|---|---|
|
Dak
Zitat: Jo, das war was ich gemeint habe. Lass dir doch mal die Variablen ausgeben
Ich habe jetzt rausgefunden warum es beim zoom die Fps nach unten zieht und nicht nach oben. Zitat: Warum zeichnest du die Bilder im Zoom eigentlich so gerastert? Soweit ich sehe hast du für ein Pixel im Original auch im Zoom nur ein Pixel, und der Rest wird mit Grau aufgefüllt. Wäre es hier nicht sinnvoller einfach jedes Pixel zu vergrößern? (So dass z.B. bei einem 2x Zoom aus einem Pixel 2x2 Pixel werden)
Mit der lupenfuktion und deren Variabeln ist alles in Ordnung. Ich habe nur völlig ausser acht gelassen das Lupe ja mit einen Raster wie du schon bemerkt hattest Gezeichnet wird, welches man mit der Taste g an/aus Schalten kann. Dieses ist auch der grund das die FPS in höheren Zoom ruter und nicht rauf geht, weil es bei factor 2 1:1 und nicht 1:2 ist. Je höher der Zoom desto weniger kommen dier weggelassenen zu schreibenden Punkte gewicht,weil es ja immer weniger weggelassen Punkte sind die Geschrieben werden Ist das Raster ausgeschaltet verhält sich die lupe wie erwartet, sie wird schneller Dak Zitat: ReadPixelFast/WritePixelFast sind Befehle, die direkt von der CPU ausgeführt werden. Da ist es recht wurscht, ob die Bilder im VRAM liegen oder nicht
stimmt nicht ganz, bei Blitzpus habe Ich die möglichkeit die Grafik im VRAM oder im RAM zu halten. Und da Read/Wirtepixel auf den buffer zugreifen, werden schreiben/lesen Actionen direkt auf dem Buffer ausgeführt, der Befehl wird zwar von der CPU ausgeführt, aber wenn der Buffer in VRAM liegt dann wird dort auch direkt Manipuliert. was bei mir 20% mehr schub bedeutet, vieleicht ist das auch das Problem mit den Nvidia Karten weil sie damit nicht so gut klar kommen. Ich habe jetzt mal ein das Proggy hochgeladen welches nur im RAM arbeitet würden mich freuen wenn die User mit den Nvidia karten diese nochmal für micht testen würden. hier der link:http://home.arcor.de/silbersur...intneu.zip |
||
|
-------------------------------------------------------
XP 2000+ 512DDR Radeon 9800 XL 340GB HD Hompage : http://home.arcor.de/silbersurfer01/ Is Bob engine http://home.arcor.de/silbersur.../Isbob.zip |
||
|
|
DAK |
So, Apr 20, 2014 14:00 Antworten mit Zitat
|
|---|---|---|
|
Intel-Karte: 1650-2000 FPS ohne Lupe, 250 FPS mit Lupe
Nvidia-Karte: 350 FPS ohne Lupe, 110 FPS mit Lupe |
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
Silbersurfer |
So, Apr 20, 2014 15:24 Antworten mit Zitat
|
|
|---|---|---|
| Hmm also daran liegt es auch nicht echt merkwürdig, aber danke Dak für dein Test | ||
|
-------------------------------------------------------
XP 2000+ 512DDR Radeon 9800 XL 340GB HD Hompage : http://home.arcor.de/silbersurfer01/ Is Bob engine http://home.arcor.de/silbersur.../Isbob.zip |
||
|
|
DAK |
So, Apr 20, 2014 18:59 Antworten mit Zitat
|
|---|---|---|
|
Ich glaub immer noch, dass dein Bottleneck ist, dass du die CPU zum Rendern verwendest. Wenn die Grafik im VRAM liegt, und dann nur noch von dort gezeichnet werden muss (DrawImage) ist es natürlich um Welten schneller als wenn du jedes Pixel einzeln von der CPU in den VRAM schreibst (WritePixelFast). Am besten wäre es wohl (wenn du nicht gleich mit der Graka zeichnen kannst), dass du alles auf der CPU renderst und gemeinsam hochlädst. Kann man in BB Bilder von Banks als Ganzes in den VRAM schreiben? Also dass du statt WritePixelFast einfach die Pixel in eine Bank schreibst und davon hochlädst.
Damit umgehst du die hohen Latenzzeiten die beim Übertragen von Millionen von winzigen Datensätzen ins Gewicht fallen. Ich denke, die Intel-Karten sind so viel schneller, weil sie direkt in der CPU sind, und somit sehr kleine Latenzzeiten auf dem Weg von der CPU zur GPU haben. |
||
| Gewinner der 6. und der 68. BlitzCodeCompo | ||
|
|
BladeRunnerModerator |
So, Apr 20, 2014 19:57 Antworten mit Zitat
|
|---|---|---|
| Seh ich genauso. | ||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
Übersicht
BlitzBasic BlitzPlus
Powered by phpBB © 2001 - 2006, phpBB Group