Files |  Tutorials |  Articles |  Links |  Home |  Team |  Forum |  Wiki |  Impressum

Aktuelle Zeit: Fr Jul 18, 2025 08:49

Foren-Übersicht » Programmierung » Einsteiger-Fragen
Unbeantwortete Themen | Aktive Themen



Ein neues Thema erstellen Auf das Thema antworten  [ 19 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Autor Nachricht
 Betreff des Beitrags: sehr viele bmp in Folge anzeigen
BeitragVerfasst: Do Jun 19, 2008 16:02 
Offline
DGL Member

Registriert: Do Jun 19, 2008 15:16
Beiträge: 6
Wohnort: Köln
Hallo zusammen,
ich möchte gerne eine große Anzahl (1M - 3M) von Bitmaps (VGA) anzeigen lassen. Und zwar in 40Hz, diese Frequenz möchte ich mit einem GenLock gewährleisten.

Nun fehlt mir ein wenig der Grundgedanke, wie ich das anstellen soll.
Soll ich eine Fläche nehmen und dann die Texture bei jedem Triggerimpuls ändern?
Oder kann ich direkt auf den Framebuffer schreiben?
Oder was gibt es da für Methoden ...

Meint ihr ein aktueller Rechner ist überhaupt in der Lage alle 25ms ein neues Bitmaps bereitzustellen?
Eine bmp ist ca 1,2 MB groß, dann währen das ca 48MB/s.


Vielen Dank Sleven


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 16:09 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2068
Programmiersprache: C++
Die Frage ist ob du sie schnell genug in den Speicher bekommst.
Und bei deinen Zahlen wird es etwas happig, da es in der Nähe der Festplattengeschwindigkeit kommt.
Müssen die Bilder so gross oder BMP sein?

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 16:14 
Offline
DGL Member

Registriert: Do Jun 19, 2008 15:16
Beiträge: 6
Wohnort: Köln
Das Format ist egal, wichtig ist dass die exakt in 24 Bit sind, und die Auflösung soll eigentlich egal sein aber erstmal 640x480.
Und das Bild darf sich nicht verändern (wie z.b. bei jpg).


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 16:28 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2068
Programmiersprache: C++
sleven hat geschrieben:
Das Format ist egal, wichtig ist dass die exakt in 24 Bit sind, und die Auflösung soll eigentlich egal sein aber erstmal 640x480.
Und das Bild darf sich nicht verändern (wie z.b. bei jpg).

Weshalb müssen es 24 Bit sein? Und weshalb darf die Auflösung verändert werden, aber keine Verluste auftreten? Das ist ein Widerspruch.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 17:27 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++
Wenn man es genauer nimmt tritt bei anderen auflösungen kein verlust auf bei kompression aber schon.
Du solltest eventuell dir mal BMP mit kompression angucken oder die BMP's alle mit zlib verpacken.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 17:44 
Offline
DGL Member

Registriert: Do Jun 19, 2008 15:16
Beiträge: 6
Wohnort: Köln
sorry, ich meinte die Auflösung ist bei mit erstmal 640x480 soll aber später beliebig sein. Und 24bpp ist wichtig, weil das Display genau so ein Bild braucht um das intern in 24 einzelne 1 Bit Bilder umzurechnen.

Ich habe mein Problem mit dem Gedanken wie ich das mit OpenGL am effektivsten Anzeige.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 18:45 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ich verstehe das glaube noch nicht ganz.
Aktuell würde ich sagen, versuchst du 24Bit BMP's zu laden, diese die einzelnen Bitebenen in jeweils eine Textur zu packen und die 24 Bilder dann nacheinander darzustellen. Also pro BMP 24frames und somit fast 2BMP's für 1Sekunde Spieldauer.
Also mit viel optimierung und Multithreading könnte das vieleicht sogar gut gehen aber wenn du 40Bilder pro Sekunde laden willst, dann diese zerlegen und verarbeiten hast du wohl kaum erfolgschancen.

Klingt für mich ein bischen nach Qualitätsskalierung von JPEG2000, also die hochwertigsten Bits zuerst laden und darstellen und die niederwertigen nachladen und somit die qualität mit jeden Bit weiter zu verbessern.

Wenn du wirklich die einzelnen Bitchannels als bilder aus den BMP's ziehen willst, dann macht das lieber vorher, das wird sonnst bei 24Bit ziemlich viel rechenaufwand. BMP kann meines wissens auch das Bild mit 1Bit tiefe und 24 slices speichern aber das wird meines wissens als totes feature nicht genutzt.

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 21:10 
Offline
DGL Member

Registriert: Do Jun 19, 2008 15:16
Beiträge: 6
Wohnort: Köln
Tut mir leid ich habe mich nicht ganz verständlich ausgedrückt.
Ich muss den ForthDD Microdisplay (http://www.forthdd.com) mit 40Hz füttern dieser zerlegt die Bilder so dass er Bilder in 2kHz ausgibt.

Ich muss 'nur' es schaffen die Bilder anzuzeigen, der GenLock von Nvidia bringt OpenGL Extensions mit. Wenn jemand schonmal damit gearbeitet hat, währe ich auch sehr froh um ein Feedback ;)

Kann ich nicht irgendwie so 100 Bildspeicher haben, die ich versuche immer voll zu haben?
Und dass ich bei jedem Bildaufbau zum nächsten Bild gehe.

Ich habe mir ein paar Tuturials angeschaut und die mal ausprobiert, aber bevor ich irgendein Mist mache, wollt ich euch lieber nach ein paar Ideen/Erfahrungen fragen.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 21:51 
Offline
Ernährungsberater
Benutzeravatar

Registriert: Sa Jan 01, 2005 17:11
Beiträge: 2068
Programmiersprache: C++
Was willst du den auf dem Bildschirm anzeigen?
40 FPS sind kein Problem.
Das Problem ist das Laden der Bilder in den Speicher.

_________________
Steppity,steppity,step,step,step! :twisted:
❆ ❄ ❄ ❄ ❅ ❄ ❆ ❄ ❅ ❄ ❅ ❄ ❅ ❄ ❄
❄ ❄ ❄ ❅ ❄ ❄ ❄ ❅ ❄ ❄ ❆ ❄ ❄


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 21:57 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
Hi,

ich verstehe nicht ganz was du erreichen willst leider... wenn ich es aber irgendwie richtig verstanden habe willst du alle 25ms ein neues bild laden und anzeigen, richtig?

Das wird mit BMP sehr schwer... ich hab in meinem Flipbook ja auch alle möglichen formate eingebunden zur wiedergabe und habe da sehr gute erfahrungen mit tif und iff gemacht was die abspielgeschwindigkeit angeht.

Also sowohl tif als auch iff kann man direkt von der festplatte aus flüssig angucken, jpeg auch in der regel.. aber die sind halt nicht verlustfrei.

Bei JPEG und TIF müßtest du allerdings auf die original libs zurückgreifen... der delphi eigene JPEG loader ist ziemlich langsam.

Aber alternativ kannst du auch einfach die bilder einfach in den arbeitsspeicher cachen, und von daaus dann flüssig abspielen... erfordert allerdings wesentlich mehr verwaltungs aufwand.

Aya~


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 21:58 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,

100 Bildspeicher sind etwas zu viel, du brauchst einfach nur einen doublebuffer.
Das aktuelle Bild wird in den backbuffer geschrieben und wenn das Bild fertig ist einfach geswappt.
Am schnellsten lassen sich meiner Meinung nach tga-Bilder laden.

Viele Grüße
dj3hut1


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 22:02 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 03, 2002 22:12
Beiträge: 2105
Wohnort: Vancouver, Canada
Programmiersprache: C++, Python
TGAs sind zu groß, da kommt u.U. die Festplatte wieder nichtmehr hinterher..

TIFF sind klein und extrem schnell beim dekomprimieren (natürlich vom compressor abhängig) = sehr schnell


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 23:33 
Offline
DGL Member
Benutzeravatar

Registriert: Di Mai 18, 2004 16:45
Beiträge: 2623
Wohnort: Berlin
Programmiersprache: Go, C/C++
Ohne Kompression bist du ziemlich erschossen, weil der Datenbus von HDD zu Speicher überlastet wird, zu langsame kompressionsysteme allerdings lassen es an der CPU hängen und deswegen sollte das kompressionsformat schnell im entpacken sein. zLib ist da der klassiker, einer der schnellsten entpacker algos den man bekommen kann. Wichtig ist hierbei, dass die Daten sofort nach dem entpacken nutzbar sind und nicht erst noch konvertiert werden müssen.
Ich persönlich würde gz.tar verwenden, also alle bmp's zippen und dann in eine tar rein(tar, damit du nur einen dateizugriff hast und somit die leserate wesentlich höher wird).
Alternativ kannst du auch ein anderes Format nehmen, welches schon packt und die bilder in eine tar packen aber unbeding alle files in eine file zusammenfassen(der unterschied ist sehr stark, dank großer caches).

_________________
"Wer die Freiheit aufgibt um Sicherheit zu gewinnen, der wird am Ende beides verlieren"
Benjamin Franklin

Projekte: https://github.com/tak2004


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Do Jun 19, 2008 23:51 
Offline
DGL Member

Registriert: Do Jun 19, 2008 15:16
Beiträge: 6
Wohnort: Köln
dj3hut1 hat geschrieben:
Hallo,

100 Bildspeicher sind etwas zu viel, du brauchst einfach nur einen doublebuffer.
Das aktuelle Bild wird in den backbuffer geschrieben und wenn das Bild fertig ist einfach geswappt.
Am schnellsten lassen sich meiner Meinung nach tga-Bilder laden.

Viele Grüße
dj3hut1


D.h. ich übergebe direkt die Bitmap in den BildBuffer ohne Texturen, Koordinaten etc.?
Wenn ihr ein Tutorial kennt welches sich mit ähnlichen beschäftigt, nur her damit.


Was die lese Geschwindigkeit angeht, gehen doch unkomprimierte Bitmaps bestimmt am schnellsten !?
Ich habe hier mal die erwähnte Formate ausprobiert
http://public.bombing-out.de/
PNG scheint recht gut abzuscheniden, was sag ihr dazu?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Jun 20, 2008 06:58 
Offline
DGL Member
Benutzeravatar

Registriert: Di Dez 27, 2005 12:44
Beiträge: 393
Wohnort: Berlin
Programmiersprache: Java, C++, Groovy
Hallo,

ja das ist theoretisch möglich, mit glDrawPixels ( man muss dabei noch einiges beachten : http://www.opengl.org/resources/faq/tec ... rmance.htm )
Könnte aber sein, das die Performance nicht ausreicht, und du dann doch mit Texturen arbeiten musst.

Für deinen Fall sollte glTexSubImage2D oder glCompressedTexSubImage besser geeignet sein.

Bei Nehe http://nehe.gamedev.net/data/lessons/lesson.asp?lesson=35 gibts eine Tutorial für ein ähnliches Problem, vielleicht hilft dir das weiter...

Viele Grüße
dj3hut1


Nach oben
 Profil  
Mit Zitat antworten  
Beiträge der letzten Zeit anzeigen:  Sortiere nach  
Ein neues Thema erstellen Auf das Thema antworten  [ 19 Beiträge ]  Gehe zu Seite 1, 2  Nächste
Foren-Übersicht » Programmierung » Einsteiger-Fragen


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 0 Gäste


Du darfst keine neuen Themen in diesem Forum erstellen.
Du darfst keine Antworten zu Themen in diesem Forum erstellen.
Du darfst deine Beiträge in diesem Forum nicht ändern.
Du darfst deine Beiträge in diesem Forum nicht löschen.
Du darfst keine Dateianhänge in diesem Forum erstellen.

Suche nach:
Gehe zu:  
  Powered by phpBB® Forum Software © phpBB Group
Deutsche Übersetzung durch phpBB.de
[ Time : 0.008s | 15 Queries | GZIP : On ]