| Vorheriges Thema anzeigen :: Nächstes Thema anzeigen |
| Autor |
Nachricht |
0oFreako0
Anmeldungsdatum: 17.12.2011
Beiträge: 114
|
 Verfasst am: 11.08.2012, 08:46 Titel: Setzen von Pixeln per Asm oder Poke probleme :( |
 |
|
Hi ich brauche für meine Plasma Routine eine schnellere Pixelsetzung.
Da ich im 32 Bit Modus arbeite bekomme ich immer eine Falsche Position
der Pixel angezeigt ? Woran könnte dies liegen. Und hat jemand vielleicht noch eine Idee wie ich dies in Asm noch schneller setzen könnte?
| Code: | ScreenRes 320,240,32
Dim framebuffer AS BYTE PTR
framebuffer = SCREENPTR
Dim As Integer x,y,pitch
ScreenInfo ,,,,pitch
x = 100
y = 100
ScreenLock
POKE UInteger, framebuffer + 32 + (y * pitch) + (x * 24), &hFF0000FF
ScreenUnLock
Sleep |
|
|
| Nach oben |
|
 |
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 11.08.2012, 10:15 Titel: |
|
|
Hi,
deine Adressenberechnung für den Pixel ist falsch,
hier findest du eine ASM Anweisung zum setzen des Pixels:
| Code: | ScreenRes 320,240,32
Dim As Integer x, y, pitch
Dim As Byte Ptr pt
ScreenInfo ,,,,pitch 'Anzahl Byte pro Zeile
x = 100
y = 100
pt = ScreenPtr + (y * pitch) + (x * 4) '4Byte pro Pixel
ScreenLock
'PSET (x, y), &hFFFFFFFF
'Poke UInteger, pt , &hFFFFFFFF
Asm
mov eax, [pt] 'Adresse nach eax
mov DWord Ptr[eax], &hFFFFFFFF 'Farbe auf den Pixel
End Asm
ScreenUnLock
Sleep |
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Cherry
Anmeldungsdatum: 20.06.2007
Beiträge: 249
|
| Verfasst am: 12.08.2012, 18:30 Titel: |
|
|
| Zitat: | | Code: | 'Poke UInteger, pt , &hFFFFFFFF
Asm
mov eax, [pt] 'Adresse nach eax
mov DWord Ptr[eax], &hFFFFFFFF 'Farbe auf den Pixel
End Asm |
|
Warum nicht einfach...
| Code: | Dim pt As UInteger Ptr
' ... und nachher...
*pt = &hFFFFFFFF |
...? oO
Wenn man unbedingt Byte Ptr haben will, geht ja sogar *CPtr(UInteger Ptr, pt) = &hFFFFFFFF |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 12.08.2012, 21:03 Titel: |
|
|
Hi,
| Code: | | *CPtr(UInteger Ptr, pt) = &hFFFFFFFF |
wird vom fbc zu
| Code: | mov eax, dword ptr [ebp-20] 'ebp-20 ist pt
mov dwrd ptr [eax], -1 |
umgesezt 
Ist also identisch mit der ASM Version.
Die Konvertierung im Basic Quellcode verhindert nur einen Warnhinweis.
(ja, der fbc setzt in vielen Fällen schon sehr gut in Asm um  )
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Cherry
Anmeldungsdatum: 20.06.2007
Beiträge: 249
|
| Verfasst am: 13.08.2012, 00:21 Titel: |
|
|
| Eben deshalb mein Posting. Wozu Assembler reinschreiben, wenn es auch mit (besser verständlichem und kürzerem) FB-Code geht? |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 13.08.2012, 10:22 Titel: |
|
|
Wer sich Assembler wünscht will doch keine Pointerakrobatik, oder?
Besser veständlich ist in diesem Fall ansichtssache!
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
Cherry
Anmeldungsdatum: 20.06.2007
Beiträge: 249
|
| Verfasst am: 13.08.2012, 21:47 Titel: |
|
|
| Hatte das mit dem Asm-Wunsch irgendwie überlesen. Sorry. |
|
| Nach oben |
|
|
0oFreako0
Anmeldungsdatum: 17.12.2011
Beiträge: 114
|
| Verfasst am: 01.10.2012, 13:34 Titel: |
|
|
Hi habe nochmal eine kleine Frage...
Kann ich mit dieser Funktion auch schnell in einen mit Imagecreate() erzeugtem Grafik Buffer schneller pixel setzen und auslesen? |
|
| Nach oben |
|
|
volta
Anmeldungsdatum: 04.05.2005
Beiträge: 1876
Wohnort: D59192
|
| Verfasst am: 01.10.2012, 14:10 Titel: |
|
|
Hi,
die Adressenberechnung für den Pixel im Image ist natürlich anzupassen.
siehe: http://www.freebasic-portal.de/befehlsreferenz/imageinfo-596.html
| Code: | | pt = Pixdata + (Höhe * Pitch) + (Breite * bpp) |
_________________
Warnung an Choleriker:
Dieser Beitrag kann Spuren von Ironie & Sarkasmus enthalten.
Zu Risiken & Nebenwirkungen fragen Sie Ihren Therapeuten oder Psychiater. |
|
| Nach oben |
|
|
0oFreako0
Anmeldungsdatum: 17.12.2011
Beiträge: 114
|
| Verfasst am: 01.10.2012, 15:19 Titel: |
|
|
Thx Volta.
Ich hatte noch keine Zeit es bisher zu testen , kann man damit schnellere Ergebnisse erzielen als mit point und pset? |
|
| Nach oben |
|
|
nemored
Anmeldungsdatum: 22.02.2007
Beiträge: 4702
Wohnort: ~/
|
| Verfasst am: 01.10.2012, 16:38 Titel: |
|
|
Mit direktem Speicherzugriff kann man viel schneller arbeiten - wenn man es richtig optimiert (nicht mehrmals dasselbe berechnet usw.). Andererseits kann man natürlich auch viel mehr falsch machen.
_________________
Deine Chance beträgt 1:1000. Also musst du folgendes tun: Vergiss die 1000 und konzentriere dich auf die 1. |
|
| Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008
Beiträge: 1917
|
| Verfasst am: 01.10.2012, 18:00 Titel: |
|
|
| 0oFreako0 hat Folgendes geschrieben: | Thx Volta.
Ich hatte noch keine Zeit es bisher zu testen , kann man damit schnellere Ergebnisse erzielen als mit point und pset? |
Kurze Antwort: Nein.
Lange Antwort: Ja, aber weder du noch ich. Und praktisch niemand in einem Bereich, der über Messrauschen hinausgeht.
Andere Optimierungen wären sehr viel effizienter. Beispielsweise die CPU nicht für Dinge benutzen, die sie nicht gut kann (Bildbearbeitung, Blitting, ...), sondern einen dedizierten Prozessor, der nur das gut kann. Namentlich: OpenGL, DirectX. |
|
| Nach oben |
|
|
St_W
Anmeldungsdatum: 22.07.2007
Beiträge: 956
Wohnort: Austria
|
| Verfasst am: 01.10.2012, 18:55 Titel: |
|
|
Da bin ich nicht ganz der Meinung von 28398 - ich bin davon überzeugt, dass sich schon allein durch direkten Speicherzugriff ein merkbarer bzw. messbarer Geschwindigkeitsvorteil gegenüber PSET ergibt.
Dies ruht darin, dass PSET
- eine Funktion ist und somit den üblichen Call-Overhead mit einigen Stack Operationen usw. besitzt
- PSET zusätzliche Überprüfungen beinhaltet, ob die Koordinaten gültig sind, etc.
Natürlich wirst du hier bei wenigen PSETs auch keinen Unterschied bemerken - das ist nur sinnvoll, wenn du größere Mengen an Pixeln setzten willst.
Nutzt FB nicht ohnehin DirectX (bzw. OpenGL auf Wunsch) für seine Grafikausgabe?
Aber ich dementiere nicht, dass es effizientere Möglichkeiten gäbe.
_________________
Aktuelle FreeBasic Builds, Projekte, Code-Snippets unter http://users.freebasic-portal.de/stw/
http://www.mv-lacken.at Musikverein Lacken (MV Lacken) |
|
| Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008
Beiträge: 1917
|
| Verfasst am: 01.10.2012, 20:01 Titel: |
|
|
| St_W hat Folgendes geschrieben: | Da bin ich nicht ganz der Meinung von 28398 - ich bin davon überzeugt, dass sich schon allein durch direkten Speicherzugriff ein merkbarer bzw. messbarer Geschwindigkeitsvorteil gegenüber PSET ergibt.
Dies ruht darin, dass PSET
- eine Funktion ist und somit den üblichen Call-Overhead mit einigen Stack Operationen usw. besitzt
- PSET zusätzliche Überprüfungen beinhaltet, ob die Koordinaten gültig sind, etc.
Natürlich wirst du hier bei wenigen PSETs auch keinen Unterschied bemerken - das ist nur sinnvoll, wenn du größere Mengen an Pixeln setzten willst. |
Oh, Augenblick, ich dachte es ginge um Blitten (PUT usw.), einzelne Pixel setzen ist sowieso wahnsinnig langsam und nicht notwendig.
| St_W hat Folgendes geschrieben: | | Nutzt FB nicht ohnehin DirectX (bzw. OpenGL auf Wunsch) für seine Grafikausgabe? |
Nein. |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 01.10.2012, 20:17 Titel: |
|
|
| 28398 hat Folgendes geschrieben: | | St_W hat Folgendes geschrieben: | | Nutzt FB nicht ohnehin DirectX (bzw. OpenGL auf Wunsch) für seine Grafikausgabe? |
Nein. |
DirectX-Treiber werden vorrangig geladen. |
|
| Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008
Beiträge: 1917
|
| Verfasst am: 01.10.2012, 23:04 Titel: |
|
|
| Dir ist klar, dass zwischen DirectDraw und D3D/OGL ein nicht ganz unbedeutender technologischer und perfomancemäßiger Unterschied liegt...? |
|
| Nach oben |
|
|
ThePuppetMaster
Anmeldungsdatum: 18.02.2007
Beiträge: 1839
Wohnort: [JN58JR]
|
| Verfasst am: 02.10.2012, 00:21 Titel: |
|
|
DirectDraw = 2d
Direct2D = 3d
directx = directdraw / direct3d
OGL 2d/3d
is nur ne spezifikationssache. keine performance sache 
MfG
TPM
_________________
[ WebFBC ][ OPS ][ ToOFlo ][ Wiemann.TV ] |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 02.10.2012, 17:40 Titel: |
|
|
| Die Frage war, ob FB DirectX für die Grafikausgabe verwendet und die Antwort lautet eindeutig "ja". Performanceunterschiede und Versionsgeschichten waren gar nicht Teil der Frage, also lass deine Kommentare bitte. Ich habe die Antwort nur richtig gestellt. |
|
| Nach oben |
|
|
28398
Anmeldungsdatum: 25.04.2008
Beiträge: 1917
|
| Verfasst am: 02.10.2012, 18:17 Titel: |
|
|
| MOD hat Folgendes geschrieben: | | Die Frage war, ob FB DirectX für die Grafikausgabe verwendet und die Antwort lautet eindeutig "ja". Performanceunterschiede und Versionsgeschichten waren gar nicht Teil der Frage, also lass deine Kommentare bitte. Ich habe die Antwort nur richtig gestellt. |
DirectDraw ist seit über zehn Jahren nicht mehr in DirectX enthalten und gehört noch zu DirectX sieben. (Hint: Das wurde im letzten Jahrtausend veröffentlicht und schon im letzten Jahrtausend war es deprecated.)
Wenn du dir die Datei gfx_driver_ddraw.c (und vielleicht noch gfx_win32.c zum Verständnis) anschaust (insbesondere die Zeichenfunktionen um directx_paint()), dann wirst du feststellen, dass mit DirectDraw ausschließlich ein von der eigentlichen libgfx2 bereitgestellter Puffer in ein DDS geblittet wird und dieses dann auf dem Bildschirm gepackt wird.
Aber vielleicht wusstest du das auch schon und hast mit Absicht dich ausdrücklich nur auf die Grafikausgabe bezogen?
(Wenn du mir den Mund verbieten möchtest, solltest du dich eher an die Forenleitung wenden, denn auf dich werde ich aus nahe liegenden Gründen natürlich nicht hören.)
| ThePuppetMaster hat Folgendes geschrieben: | DirectDraw = 2d
Direct2D = 3d
directx = directdraw / direct3d
OGL 2d/3d
is nur ne spezifikationssache. keine performance sache |
Uh-uh, TPM, es ist ja echt selten, dass du was falsches von dir gibst, aber das ist leider falsch.
Treiberentwickler optimieren seit Ewigkeiten den ddraw-Pfad nicht mehr (wurde da je was optimiert? Wahrscheinlich nicht), dass es diesen Baustein überhaupt noch gibt, ist eine reine Gefälligkeit von Microsoft ggü. veralteten Anwendungen (s.o.).
So kommts, dass ich sowohl mit DirectX (besonders mit DirectX unter Windows) als auch mit OpenGL heutzutage wesentlich schneller unterwegs bin was 2D-Operationen betrifft. Naja und natürlich flexibler und mit etwas, was besser dokumentiert ist und unterstützt wird.
Zuletzt bearbeitet von 28398 am 02.10.2012, 18:23, insgesamt einmal bearbeitet |
|
| Nach oben |
|
|
MOD
Fleißiger Referenzredakteur
Anmeldungsdatum: 10.09.2007
Beiträge: 1003
|
| Verfasst am: 02.10.2012, 18:22 Titel: |
|
|
| MOD hat Folgendes geschrieben: | | ...Versionsgeschichten... |
| 28398 hat Folgendes geschrieben: | | gehört noch zu DirectX sieben |
Wer lesen kann, ist klar im Vorteil. |
|
| Nach oben |
|
|
|
FAQ
Suchen
Mitgliederliste
Benutzergruppen
Registrieren
Profil
Einloggen, um private Nachrichten zu lesen
Login
