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

Aktuelle Zeit: Fr Jul 11, 2025 07:03

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



Ein neues Thema erstellen Auf das Thema antworten  [ 28 Beiträge ]  Gehe zu Seite Vorherige  1, 2
Autor Nachricht
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 13:41 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
Da mein Spiel ein Adventure wird, ist meine 'Zielgruppe' meistens nicht so gut bestückt wie die 3D-Shooter-Fraktion. Insofern kann ich nicht unbedingt mit einer GeForce- oder Radeon-Karte planen. Da ich mich bei schwächeren System auch mit 16bit zufrieden gebe, habe ich wieder Hoffnung. Unter Umständen muss ich eben wirklich eine Hardware-Anforderung aussprechen, ein 10fps-Spiel kommt nicht in Frage.

Ich habe jetzt auch ein paar Tests auf dem 800Mhz/Geforce256-System gemacht:
(VSync abgestellt)

Renderpass.exe:
32bit: ~125fps
16bit: ~250fps

GLTestApp.exe:
32bit: ~45fps
16bit: KEINE ANZEIGE, sehr ruckelig.
Hier das Log:
Code:
  1.  
  2. Vendor:
  3. NVIDIA Corporation
  4.  
  5. Renderer:
  6. GeForce 256/AGP/SSE
  7.  
  8. Version:
  9. 1.3.1
  10.  
  11. Extensions:
  12. GL_ARB_imaging GL_ARB_multitexture GL_ARB_texture_compression GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_texture_env_combine GL_ARB_texture_env_dot3 GL_ARB_transpose_matrix GL_S3_s3tc GL_EXT_abgr GL_EXT_bgra GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_clip_volume_hint GL_EXT_compiled_vertex_array GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_multi_draw_arrays GL_EXT_packed_pixels GL_EXT_paletted_texture GL_EXT_point_parameters GL_EXT_rescale_normal GL_EXT_secondary_color GL_EXT_separate_specular_color GL_EXT_shared_texture_palette GL_EXT_stencil_wrap GL_EXT_texture_compression_s3tc GL_EXT_texture_edge_clamp GL_EXT_texture_env_add GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_EXT_texture_cube_map GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod GL_EXT_texture_lod_bias GL_EXT_texture_object GL_EXT_vertex_array GL_EXT_vertex_weighting GL_IBM_texture_mirrored_repeat GL_KTX_buffer_region GL_NV_blend_square GL_NV_evaluators GL_NV_fence GL_NV_fog_distance GL_NV_light_max_exponent GL_NV_packed_depth_stencil GL_NV_register_combiners GL_NV_texgen_emboss GL_NV_texgen_reflection GL_NV_texture_env_combine4 GL_NV_texture_rectangle GL_NV_vertex_array_range GL_NV_vertex_array_range2 GL_NV_vertex_program GL_NV_vertex_program1_1 GL_SGIS_generate_mipmap GL_SGIS_multitexture GL_SGIS_texture_lod GL_WIN_swap_hint WGL_EXT_swap_control
  13.  


Mit diesen Framezahlen bin ich durchaus zufrieden. Kann man denn im Code das VSync ein/ausschalten?

So, ich werde also mal versuchen ein paar Stunden lang irgendein Template dahingehend zu verändern, dass es meiner Vorstellung entspricht. Irgendeine Empfehlung für eine 2D-Basis?

Vielen Dank schonmal im voraus!
:D


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 14:00 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Jan 04, 2003 21:23
Beiträge: 674
Wohnort: Köln
für ein 2D-Spiel solltest du dir den Ortho-Modus (glOrtho)
mal genauer ansehen...

VSync kann man zwar per Software ausschalten, wobei es aber de facto nichts bringt, wenn man mehr FPS hat, als der Monitor anzeigen kann, weil man ja eigentlich doch nur die Monitor-Herzzahl Frames pro Sekunde sieht :D

(den Code dazu gabs irgendwann mal auf der PAge (DelphiGl.com), ich kann ihn aber leider grad nicht finden...

_________________
. . .


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 14:06 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
VSync ausschalten bringt unter Umständen schon etwas. Ich hatte bei einer Tutorialanwendung nach Ausschalten einen Sprung von 30 auf 60fps. Und das ist schon ein Unterschied. 30fps ist genau an der Schmerzgrenze. Wahrscheinlich lässt sich dieses Phänomen durch geschickteres Programmieren umgehen, oder doch nicht?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 14:13 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Jan 04, 2003 21:23
Beiträge: 674
Wohnort: Köln
was hast du denn für einen Monitor??
wenn der bei dir bei eingeschaltetem VSync nur 30 FPS hat, dann ist entweder der Treiber kaputt, der Bildschirm gibt eine falsche HErzzahl zurück oder dein Bildschirm läuft wirklich unter 30Hz...
in diesem Fall, hat es aber wie eben schon beschrieben keinen Sinn das Programm unter 60FPS laufen zu lassen, weil es für den BEnutzer visuell NULL Unterschied ist, ob das Programm mit der Anzahl der Hz-Anzahl des Monitors läuft oder mit mehr FPS...
das Bildschirmergebnis wird eher noch schlechter.... :-/

_________________
. . .


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 14:28 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 05, 2002 10:35
Beiträge: 4234
Wohnort: Dortmund
Mit der Extension WGL_EXT_swap_control kannst du das einstellen. Aber ob es übernommen wird hängt vom Treiber ab. Wenn du dort eingestellt hast "Immer an" (oder aus) dann wird die Extension da auch nichts dran ändern.

Und zum Thema VSync. Es ist eine reine Geschmackssache. Wenn du es an hast dann werden die bilder nur dann gezeichnet wenn der Monitor gerade nicht zeichnet. Wenn du es ausmachst kann es sein, dass der Monitor das Bild zeichnet und mittendrin ihm das Bild ausgetauscht wird. Du hättest sozusagen 2 unterschiedliche Bilder zur Hälfte auf dem Monitor gezeichnet. Aber da das menschliche Auge eh ein wenig langsam ist fällt es nicht so stark auf. Unter idealen Bedingungen kann es aber schon auffalen. Das passiert aber eher selten.
Es hat beides Vor und Nachteile. Und im Endeffekt wählt der Benutzer schon die für ihn gewollte Einstellung. Oder der Treiber. ;-)

Zu deinen 30 FPS mit vysnc. Da wirst du beim Zeichnen ein ganz wenig über dem Sync gelegen haben. Und 30 sind nicht so schlecht. Ein Trickfilm hat nur 24 und er läuft flüssig.
Nebenbei kannst du bei den 30 fast das doppelte an Dingen rendern ohne das sich die FPS großartig verändern würde (theoretisch jedenfalls). Er hat ja momentan recht viel Zeit mit dem Warten verbracht und die würdest du so dann zum Rendern benutzen.

Fiji: Flachbildschirme laufen in der Regel nur mit 60 Hz. Die Flackern aber auch nicht.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 16:02 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
Ja, stimmt normale Filme laufen mit 24/25fps. Und allgemein wird das als flüssig bezeichnet. Ich glaube aber, dass jeder hier eine höhere Framezahl als angenehmer bezeichnet. Ich wage zu behaupten, dass man optisch druchaus erkennen kann, ob 30,40 oder 50fps dargestellt werden. (Das wäre doch mal eine geile Idee für 'Wetten dass...' 8) )

Ich arbeite nur noch mit TFTs, die haben alle 60Hz.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 22:30 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
Wahrscheinlich hast du auf der Geforce 256 im 16 Bit Modus kein passendes Pixelformat mit Stencilbuffer (wegen dem Schatten benötigt). Ab Geforce sind 32 Bit Modi ohnehin schneller.

Immerhin hast du in beiden Fällen (Vanta und Geforce 256) hardwarebeschleunigte Videomodi, wobei dein Treiber für Geforce 256 relativ alt ist, da sämtliche NVidia Treiber (ab TNT) schon relativ lange OpenGL 1.4 unterstützen.

Für deine Zwecke ist OpenGL bereits so wie es jetzt ist locker schnell genug: in GLTest werden die 3D Objekte in jedem Frame neu berechnet und in Bildschirm, Z-Buffer und Stencilbuffer gezeichnet.
Für deine Anwendung langen ein paar texturierte Quads mit Alphakanal aus (für die Sprites), den Hintergrund kannst du entweder als Textur realisieren oder mittels DrawPixels direkt zur Grafikkarte schaufeln. Du brauchst an sich weder Beleuchtung und Nebel.
Ich glaube dir versprechen zu können, dass das sogar auf einer normalen TNT in 800x600 mit weit über hundert FpS laufen wird - selbst wenn du größere Wasserflächen oder so animieren möchtest, wenn du nicht exzessiv Texturen schiebst, was jedoch, so wie es zur Zeit aussieht, leicht vermieden werden kann (du kannst z.B. alle für eine Szene benötigten Sprites und Animationssequenzen im Voraus als Texturobjekte definieren, dann kannst du damit sehr schnell arbeiten - du brauchst auch nicht mehrere skalierte Versionen eines Sprites, da du z.B. texturierte Quads in jeder beliebigen Größe zeichnen kannst).

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 23:06 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
Ja, bis jetzt sind erste Tests recht erfolgreich. Ich habe jetzt aber noch keine Ahnung wie ich die Vielzahl von Sprites/Animationen speichermässig verwalten soll. Zahlreiche Animationen (Laufen/Sprechen) brauche ich ständig und andere werden dynamisch dazu geladen. Ok, bei den Laufanimationen kann ich über Textur-Offsets gehen. Wie sieht's mit der Konvertierung System <-> Grafikkarte aus? Kümmert sich OpenGL darum, dass die gerade benötigten Texturen in den Grafikspeicher kommen, oder wie? Ich brauche schon einige MBs für die Animationen...


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Dez 12, 2003 23:43 
Offline
DGL Member
Benutzeravatar

Registriert: Sa Dez 28, 2002 11:13
Beiträge: 2244
Der OpenGL Treiber verwaltet die Texturen automatisch. Wenn man mehr Texturen benutzt, als in den Grafikkartenspeicher passen, werden sie ausgelagert. Das Programm wird natürlich dadurch dann langsamer, aber mit 128 MB Standard braucht man sich da eigentlich keine Sorgen machen.
Wenn du allerdings ungefähr weißt, welche Texturen benötigt werden, dann ist es besser nicht immer alle zu laden, sondern da schon vorher eine Auswahl zu treffen.
Falls der Speicher insgesammt nicht ausreichen sollte:
Die Aktualisierung von Texturen über gltex[sub]image ist je nach Texture Größe von der Geschwindigkeit her noch akzeptabel. Demnächst gibt es noch eine neue Extension (arb_pbo) mit der man einen besseren Zugriff auf die Texturedaten hat und sogar Videos streamen kann.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Dez 13, 2003 19:25 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
Gut, gut, gut. OpenGL beginnt mir zu gefallen. Grosse Texturen sind auch kein Problem, aber müssen die Dinger wirklich 2^n und quadratisch sein? Wenn ich auf OpenGL umsteige, muss ich jetzt alle Grafik-Resourcen entsprechend anpassen? Was mache ich denn bei Grafiken mit den Ausmassen 1500*13? Für Animationen sind solche Dinger ganz praktisch. TexSubImages helfen mir glaub ich wenig weiter, denn ich brauch noch AlphaChannelMaps und das geht damit nicht (oder doch)?

(Sorry, wenn dieses Problem irgendwo schon breitgetreten wurde. Ich hab's nicht gefunden.)


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Dez 13, 2003 19:43 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Dez 13, 2002 12:18
Beiträge: 1063
TexSubImages unterstützen Alpha Channel

Es zwingt dich ohnehin niemand, gar alles mit Texturen zu realisieren (die übrigens nur Zweierpotenzen als Begrenzungen haben müssen, quadratisch müssen sie normalerweise nicht sein). Schau die doch mal die Dokumentation zu glDrawPixels und glCopyPixels an - für 2D Operationen können die auch praktisch sein.

_________________
Viel Spaß beim Programmieren,
Mars
http://www.basegraph.com/


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Sa Dez 13, 2003 19:53 
Offline
DGL Member
Benutzeravatar

Registriert: Do Dez 11, 2003 20:57
Beiträge: 11
Wohnort: Düsseldorf
ok, schau ich mal. Aber auf Pixel-Ebene wollte ich eigentlich nicht runter, kommt natürlich drauf an, ob ich AlphaChannels und eine vernünftige Geschwindigkeit dann noch habe. Mal sehen... thanks


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: So Dez 14, 2003 15:23 
Offline
DGL Member
Benutzeravatar

Registriert: Mo Sep 23, 2002 19:27
Beiträge: 5812
Programmiersprache: C++
Also eigentlich kann die die 2^n-Begrenzung recht egal sein, denn gluBuildMipMaps ver- bzw. entzerrt beim erstellen der MipMaps deine Texturen so, das sie genau in diese Begrenzungen passen. Wenn du diese Methode zur Übergabe deiner Texturdaten an OpenGL nutzt, dann können deine Texturen eigentlich jede von dir gewünschte Größe besitzen. Allerdings ists halt fraglich ob man für ein pures 2D-Spiel auch wirklich MipMaps braucht, da deine Objekte ja eigentlich immer auf der gleichen "Tiefe" liegen und so immernur eine MipMap-Stufe genutzt wird. Somit belagern die nichtgenutzten MipMap-Stufen also nur zusätzlichen Speicher im VRAM, aber wie gesagt hast du dann die Sache mit den 2^n-Texturdimensionen nicht mehr.

gluManPages zu gluBuildMipMap2D hat geschrieben:
Initially, the width and height of data are checked to see if they are a power of two. If not, a copy of data (not data), is scaled up or down to the nearest power of two.
This copy will be used for subsequent mipmapping operations described below. (If width or height is exactly between powers of 2, then the copy of data will scale upwards.) For example, if width is 57 and height is 23 then a copy of data will scale up to 64 and down to 16, respectively, before
mipmapping takes place.

_________________
www.SaschaWillems.de | GitHub | Twitter | GPU Datenbanken (Vulkan, GL, GLES)


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


Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 7 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.009s | 14 Queries | GZIP : On ]