Spiele-/Grafikprogrammierung

• ?

  2D - JnR Techniken
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  915
  Aufrufe

  N

  Der Geschwindigkeitsvektor ist der Richtungsvektor der Geschwindigkeit. Ob nun der Geschwindigkeitsvektor bereits eine gegebene Länge hat (z.B. bei konstanter Framerate), oder ob er wirklich nur ein Richtungsvektor ist und jeweils mit der Geschwindigkeit skaliert wird, spielt eigentlich gar keine Rolle. Normalerweise hat deine Figur 2 Vektoren: Position und Geschwindigkeit (= Positionsänderung pro Zeit), eventuell noch eine Beschleunigung. Für gegnerische Figuren und Kanonenschüsse gilt das auch. Mit all diesen Informationen kannst du herausfinden, ob Mario von der Seite angeschossen wurde. Je nachdem reichen auch schon die Positionen.
• W

  exe startet nach kompilieren nicht (OGRE_SDK)
  • Wenjo  

  6
  0
  Stimmen
  6
  Beiträge
  1243
  Aufrufe

  V

  kauf dir halt ein Buch zu Ogre - oder such ein Tutorial, das funktioniert und arbeite das nach
• ?

  OpenGL Light
  • Gast  

  1
  0
  Stimmen
  1
  Beiträge
  1183
  Aufrufe

  ?

  Hallo, ich rendere eine Scene und repositioniere je nach Camera (matrix) das Licht in der Scene entsprechend neu. Seit eh' her habe ich dabei das Problem, das das Licht immer in Blickrichtung die Scene erhellt, ähnlich einer Lampe auf dem Kopf. Hier ein Beispiel mit zwei verschiedenen Blikwinkeln auf die Scene: http://kahnsoft.cwsurf.de/Image1.jpg http://kahnsoft.cwsurf.de/Image2.jpg Man sieht, desto steiler der Blickwinkel desto heller wird die ganze Scene in dieser Richtung. //Spread Factors glLightf(GL_LIGHT0+m_lnum, GL_CONSTANT_ATTENUATION ,0); glLightf(GL_LIGHT0+m_lnum, GL_LINEAR_ATTENUATION,m_hotspot); glLightf(GL_LIGHT0+m_lnum, GL_QUADRATIC_ATTENUATION ,1); //Öffnungswinkel Lower for more focus //m_hotspot m_falloff glLightf(GL_LIGHT0+m_lnum, GL_SPOT_CUTOFF,m_hotspot); //Ausbreitungsintensität 0-128 glLighti(GL_LIGHT0+m_lnum, GL_SPOT_EXPONENT,1); glLightfv(GL_LIGHT0+m_lnum, GL_POSITION,m_LightPos); glLightfv(GL_LIGHT0+m_lnum, GL_SPOT_DIRECTION,m_LightDir); Der Scene entsprechend ist das ein SpotLight, dies wird so parameteriesiert das es wie eine Tischlampe von oben nach unten auf die scene scheint/scheinen sollte. Ist das Problem das, daß ich das Licht mit der CameraMatrix projektioniere anstatt es mit der Modelmatrix zu versuchen ? Danke für Hinweise gruß Karsten
• S

  Programmierung Sicherung
  • Sorvage  

  3
  0
  Stimmen
  3
  Beiträge
  1223
  Aufrufe

  S

  ja hab ich zwar. ich wollte da wissen welches gut ist, ich bakam aber andere antworten desswegen hab ich noch eins geschrieben
• S

  Neu Programmierung
  • Sorvage  

  6
  0
  Stimmen
  6
  Beiträge
  1048
  Aufrufe

  S

  okay danke für information. Ich werde es mal versuchen.
• ?

  [openGL] Zwei Flächen nah beieinander
  • Gast  

  17
  0
  Stimmen
  17
  Beiträge
  2339
  Aufrufe

  R

  wenn du genau weisst was du zeichnen willst, und was worauf erscheinen soll, dann kannst du den zbuffer ausschalten und einfach in der gewuenschten reihenfolge zeichnen, dann sollte es auch gehen
• V

  Cg 3 vs. D3D11 HLSL
  • Vertexwahn  

  7
  0
  Stimmen
  7
  Beiträge
  2610
  Aufrufe

  V

  Bleibt die Frage offen ob HLSL und Cg nun tatsächlich zu divergieren beginnen oder ob es sich dabei nur um eine alternative Syntax handelt die Cg erlaubt ist. Genau das sind die Fragen zu denen mich Antworten interessieren würden! Ich habe bisher mit Cg und in letzter Zeit mit D3D10 HLSL + Effektframework gearbeitet - ich kann halt damit Shader schreiben und hab auch schon einige Effekte damit programmiert, aber jedes Syntaxelement kenne ich da auch nicht Nun fange ich gerade ein neues Projekt mit Tesselierung an mit dem Hitergedanken irgendwann vielleicht auch mal einfach das ganze auf OpenGL poritieren zu können - die unteschiede zwischen D3D11 HLSL ohne Effektframework und GLSL 4.1 sind schon groß: Hier etwas das man in D3D11 als Domain-Shader bezeichnen würde: #version 410 core // Declare all the semantics #define ATTR_POSITION 0 #define ATTR_COLOR 3 #define FRAG_COLOR 0 layout(quads, equal_spacing, ccw) in; in vec4 ContColor[]; out vec4 EvalColor; in gl_PerVertex { vec4 gl_Position; float gl_PointSize; float gl_ClipDistance[]; } gl_in[]; out gl_PerVertex { vec4 gl_Position; float gl_PointSize; float gl_ClipDistance[]; }; vec4 interpolate(in vec4 v0, in vec4 v1, in vec4 v2, in vec4 v3) { vec4 a = mix(v0, v1, gl_TessCoord.x); vec4 b = mix(v3, v2, gl_TessCoord.x); return mix(a, b, gl_TessCoord.y); } void main() { gl_Position = interpolate(gl_in[0].gl_Position, gl_in[1].gl_Position, gl_in[2].gl_Position, gl_in[3].gl_Position); EvalColor = interpolate(ContColor[0], ContColor[1], ContColor[2], ContColor[3]); } und da wollte ich jetzt Cg nutzen mit dem Hintergedanken das ganze portabel zu halten - habe aber leider festgestellt, dass es da anscheinend auch unterschiede gibt - hätte halt gerne so wie frührer mit HLSL programmiert und gerne Cg benutzt um auch OpenGL zu haben... mmmh....
• X

  Aufgabenaufteilung
  • X.DarkForce.X  

  14
  0
  Stimmen
  14
  Beiträge
  2685
  Aufrufe

  P

  X.DarkForce.X schrieb: Also OK! Ich habe eine 3D-Anwendung die zuerst mit 0,... Bilder in der Sekunde lief. Nach Occlusion-, Frustum- und Detailcullling lief das ganze mit 50 bis 150 Bildern in der Sekunde. Das Ergebnis ist gut, ich habe aber einen schnellen Vierkerner und habs mal auf 'nem langsamen Zweikerner getesten. Fatal! Nach langen Ladezeiten liefs nur sehr ruckelig. Das klingt (trotz Culling, aber das ist ja auch nicht alles) eher danach, als ob die Anwendung insgesamt einfach noch ineffizient programmiert etc ist. Langsame oder falsch benutzte Algorithmen, überflüssige oder zu häufige Berechnungen, zu detaillierte Objekte, etc. Dass mein Prozessor mehr Leistung hat, ist kein Grund dazu mit Leistung verschwenderischer umzugehen. Was ist denn ein "langsamer Zweikerner"? Da jetzt mit Threads mühsam versuchen, irgendwas rauszuholen, obwohl das Problem erstmal woanders liegt, macht mir keinen Sinn. Und wenn doch Threads, dann sollte man, wie schon erwähnt wurde, erstmal herausfinden, was eigentlich die größten Leistungsfresser sind. Und dann kann man überlegen, wie sich das überhaupt gut in Threads aufteilen lässt. Wenn der eine Thread dauernd auf einen anderen warten muss, weil beide in irgendwelche selben Objekte schreiben, dann ist der Sinn auch fraglich. Das Einzige, was sich fast immer relativ problemlos und sinnvoll in einen Tread auslagern lässt, ist das bloße Laden von Objekten, Texturen und sonstigen Informationen..
• ?

  TicTacToe in C
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  4161
  Aufrufe

  ?

  TGGC schrieb: Passt irgendwie zur Wirtschaftskrise... "Glueckwunsch. Der Computer hat gewonnen!"
• ?

  Welches OS/Hardware für MMO Server?
  • Gast  

  4
  0
  Stimmen
  4
  Beiträge
  1583
  Aufrufe

  N

  Hallo, ich denke das kommt ganz auf das MMO drauf an und besonders die Definition von Massively !!! 100 Player würde ich nicht als massiv definieren. Die prinzipielle Grenze ist doch an der Stelle, wo jeder Computer an seine physikalischen Grenzen stößt. Dann braucht man ein Spiel das auch über Rechner-Grenzen hinweg skaliert. Da reicht es nicht einfach nur Threads zu starten, die einzelnen Nodes müssen auch untereinander kommunizieren. An dieser Stelle verweise ich immer gerne auf WoW. Da läuft als skalierbare Architektur eine Oracle-Datenbank im Hintergrund. Das bedeutet pro "Welt" hat man im Backend ca. 20 Quad-Core Nodes als Datenbank-Cluster zusammengeschaltet. Pro DB-Node kommen dann wieder X - User Server als Front-End. Pro User-Server hängen dann wieder Y Player dran. Setze ein für X = 20 und Y = 500; 20 * 20 * 500 = 200.000 User pro DB-Cluster. Ich denke hier wird deutlich, das weder WinAPI noch PCs das Problem darstellen. Sondern das Verständnis von skalierbarer Software-Architektur. PS: BSDs sind Linux überlegen, weil sie einen besseren Kernel-Scheduler haben. Ab einem Verhältnis von Threads / CPUs > 50, 100 macht sich das bemerkbar.
• P

  OpenGL: Koordinaten eines Punktes nach der Rotation?
  • PunkyDuck  

  6
  0
  Stimmen
  6
  Beiträge
  3305
  Aufrufe

  ?

  Hey, habe ähnliches Problem. Wie hast du es denn nun am Ende gelöst??? Danke.
• ?

  Denkproblem mit IDirect3DDevice9
  • Gast  

  24
  0
  Stimmen
  24
  Beiträge
  3582
  Aufrufe

  ?

  Habe deinen Quellcode jetzt nicht gelesen, doch wenn das ganze im Fenstermodus klappt, im Vollbildmodus jedoch nicht, könnte das an der Auflösung liegen die du einstellst. Im Vollbildmodus musst du eine gültige Auflösung verwenden die von deiner Graphikkarte unterstützt wird, irgendwelche exotischen Dinge woe 500x500 könnten da zum Absturz führen.
• ?

  Einen 2D-Artist programmieren
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  1125
  Aufrufe

  T

  tl;dr Aber der Titel klingt lustig.
• ?

  DirectX11 Bibliotheken, API's ?
  • Gast  

  5
  0
  Stimmen
  5
  Beiträge
  1262
  Aufrufe

  ?

  Ah habs ... Interessant nur, das die DX11 Dokumentation in nem DX9 Ordner ist ... Auf die Idee sollte man dann doch erstmal kommen ... Dank dir
• O

  OpenGl Texturen
  • otze  

  17
  0
  Stimmen
  17
  Beiträge
  4432
  Aufrufe

  O

  Juhu, es laeuft danke fuer eure Hilfe!
• *

  [OpenGL] Indices kommen mit Stride; was tun?
  • *rant*  

  13
  0
  Stimmen
  13
  Beiträge
  1929
  Aufrufe

  

  Dann sollte die Lösung ja mehr oder weniger offensichtlich sein
• X

  [OpenGL]Vergeichen, ob zwei Texturen gleich sind
  • X.DarkForce.X  

  12
  0
  Stimmen
  12
  Beiträge
  2579
  Aufrufe

  O

  Ich würde ein FBO verwenden: -Das FBO mit dem Mittelwert füllen. (Also 0.5f bzw. 127 aus Byte Sicht) -Dann das erste Bild einblenden. Dabei die Deckkraft halbieren (So dass aus dem max. Wert 255 ein 127 wird, z.B. mit einem blend Wert von 0.5f) -Nun das zweite Bild negativ in das FBO blenden (Siehe: http://wiki.delphigl.com/index.php/glBlendFunc, das ist zwar eine Delphi Seite, aber die haben sehr gut veranschaulicht was die ganzen Modi machen) Deckkraft natürlich auch halbieren. -dann aus dem FBO eine Textur machen und die Mipmap von OpenGL erstellen lassen. (glGenerateMipmap <-- ist so schön schnell ) -die Textur jetzt in klein (Je nach dem wie genau du Unterschiede erkennen willst versus wie schnell du es später auslesen willst) in ein FBO rendern. -Dann diesen FBO-Inhalt in den Ram kopieren und zusammenzählen wie weit jeder Pixelwerte von 127 abweicht. Wie größer dieser Wert ist, um so Ungleicher sind die Bilder. Und bei 0 handelt es sich um gleiche oder nahezu gleiche Bilder. PS: Wenn ich es richtig verstanden habe, kann man mittels eines PBO beim auslesen der Textur->Ram nochmal einiges an Geschwindigkeit raus holen. Aber damit habe ich noch nicht gearbeitet. Es wäre auch einen Versuch wert zu schauen ob man das ganze mit einem floating point FBO machen kann. Dann sollten es relativ genaue Resultate gäben, ohne dass man ein sehr großes Bild von der GPU zum Ram kopieren muss. Das unterstützen aber erst "neuere" Grafikkarten. Wohingegen die anderen Funktionen auch von relativ alten Grafikkarten unterstützt werden. Das ganze lohnt sich aber nur wenn die Texturen ohnehin in OpenGL herumliegen. Sie dafür extra zur GPU zu senden könnte ohne PBO teurer sein als sie nur auf der CPU zu vergleichen. Ja, ich habe auch ein kleineres Projekt geplantes wo ich so etwas gebrauchen könnte.
• C

  Effiziente Verwaltung von vielen Instanzen / Klick auf eine Iso Karte
  • Cloppy  

  8
  0
  Stimmen
  8
  Beiträge
  1244
  Aufrufe

  O

  In diesem Fall würde ich sogar fast sagen, das durchiterieren mit das schnellste ist, was du machen kannst. Zumindest sofern deine Objekte halbwegs sinnvoll definiert sind und hintereinander im Speicher liegen. Die größte Bremse ist nämlich in 99% der Fälle der RAM, und die umgeht man am Besten, indem man die Caches so gut wie möglich ausnutzt. Also: nicht wild im Speicher rum springen. Mal davon ab: 300 ist keine Problemgröße. ob du da jetzt Faktor 2 raus holst ist im Vergleich zu einem einzigen Grafikcall so uninteressant...
• 

  Der 1. sppro-Spiele-Contest
  • TGGC  

  7
  0
  Stimmen
  7
  Beiträge
  1632
  Aufrufe

  

  Der Contest ist nun beendet. Die oeffentliche Abstimmung zu den Ergebnissen findet ihr hier: http://www.spieleprogrammierer.de/index.php?page=Thread&threadID=14773 Eine Liste mit allen Spielen gibt es hier: http://contest.spieleprogrammierer.de/game-01/ Sie koennen alle live im Browser gespielt werden, solange er das canvas Element unterstuetzt. Das sollte mit Firefox, Opera, Safari, Chrome und dem allerneusten IE funktionieren. Viel Spass beim probespielen!
• I

  Anfängerfrage: SDL fürs Menü und OpenGL fürs Spiel?
  • isam2k  

  5
  0
  Stimmen
  5
  Beiträge
  2087
  Aufrufe

  ?

  Entweder das oder du renderst wie ich hier, einfach den Font. Ich mach folgendes: Ich render dne Font mit FTGL und berechne eine BoundingBox. Die nehme ich dann als indikaor für "kollissionen" mit der Maus, sprich MouseOver-Effekte und klicks etc. Das war einfacher als ich dachte, bin da nämlich auch nicht grade nen profi :D. Die Font-Klasse findest Du hier: http://code.google.com/p/nightlighttv/source/browse/NightLight/trunk/NightLightDLL/NLFont.cpp Die Menü-Klassen: http://code.google.com/p/nightlighttv/source/browse/NightLight/trunk/NightLightDLL/NLMenuController.cpp http://code.google.com/p/nightlighttv/source/browse/NightLight/trunk/NightLightDLL/NLMenuItem.cpp Kannst ja mal anschauen wenn Du magt. Das ganze Projekt baut auf OpenGL, libsgic++, FTGL, boost und SDL auf. Es ist nicht der beste Code der Welt, aber es funktioniert und man kann einfach Spiele damit machen. rya.