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

Aktuelle Zeit: Mo Jul 14, 2025 21:33

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



Ein neues Thema erstellen Auf das Thema antworten  [ 33 Beiträge ]  Gehe zu Seite 1, 2, 3  Nächste
Autor Nachricht
 Betreff des Beitrags: fragen über fragen
BeitragVerfasst: Fr Feb 18, 2005 14:33 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
hi dgler,

da ich ein einsteiger in opengl programmierung bin, versuche ich mich gerade durch die ganzen tutorials zu schlagen, die ihr zusammengestellt habt. finde es klasse, das ihr euch soviel mühe gegeben habt aber teilweise gehen die tutorials nicht so tief in die materie, das alle meine fragen damit beantwortet werden..deswegen hoffe ich nun etwas klarheit zu bekommen.

also, mein plan ist es, ein spiel namens "push over" (wer es nicht kennt, kann es sich auf unserer abandonseite runterladen *schleichwerbungmach* *G* http://www.tfr.de.tp) neu aufzusetzen (mit neuen steinen, leveln etc.) und das ganze in opengl zu gestalten.
damit ihr wisst worum es geht : auf einem spielfeld stehen viele dominosteine, die alle verschiedene funktionen haben (teiler, explodierer, brückenbauer etc.). zeil ist es, eben diese steine im level so umzustellen, das eine kettenreaktion in gang gesetzt wird, welche den speziellen endstein als letzten umfallen lässt. dann ist das level geschafft und man kommt ins nächste (klingt von meiner beschreibung her sehr langweilig, aber das game war früher der HAMMER!).

so weit so gut. habe natürlich erstmal nachgegrübelt ob ich mich nun wirklich mit der api rumschlagen soll, oder direkt die vcl variante nehme - bin aber zu dem schluss gekommen, das api wahrscheinlich besser wäre, da ich das vom studium her ein bissel auf die reihe kriegen muss *G*.
naja, habe mir zumindest sowohl das api als auch das vcl template von eurer seite gezogen und erstmal den ganzen unnützen kram da raus geworfen. dann ging es los mit den tutorials und schon fingen die probleme an:

1.) ich weiss mittlerweile, wie man einfache objekte mit opengl auf den bildschirm zaubert, diese einfärbt, verschiebt und drehen kann. selbst die rotation per tastendruck um die jeweiligen achsen stellen nicht sooo die grossen probleme dar. ich habe nun testweise einmal zwei dominosteine hintereinander in meine worldmatrix gerendert und so si gedreht, das man sie von der seite sieht. allerdings verstehe ich nun folgendes nicht:
ich sehe doch richtig, das man nicht die objekte selbst dreht, sondern einfach die komplette worldmatrix an sich und dann die objekte in diese matrix neu zeichnet. doch wie kann man nun bewerkstelligen, das ich z.b. per tastendruck nur EINEN stein umfallen lasse, dieser dann den nächsten den er trifft anstösst und dieser mit umfällt? wie kann man objekte (meine dominosteine bestehen übrigens aus insgesamt 6 einzelnen glQuads - geht das nicht auch einfacher?) einzeln komplett rotieren und verschieben lassen? (ich weiss nicht ob ich da einen denkfehler habe, aber aufgrund den tutorials habe ich es jetzt so verstanden das ich die beiden objekte zeichnen lasse, die matrix pushe, meinen blickwinkel ändere, nur den stein der umfallen soll in ner schleife ständig neu zeichne, die matrix poppe und damit den zweiten stein wieder so erscheinen lasse usw.) das prinzip was ich mir da denke is doch SEHR aufwendig - das muss doch auch einfacher gehen. nur wie?

2.) diese "einheitenrechnung" von den euch bennanten "weltkoordinaten" verstehe ich nicht. wenn ich ein fenster von der grösse 800x600 habe...wieviele WK's muss ich ein Objekt dann verschieben, damit es z.B. genau am rande des bildschrims steht. und wenn ich objekte über den screen sausen lasse - wie kann ich abfragen, das sie an den bildschirmrand stossen und dann wieder umdrehen? so wie ich es jetzt habe fliegen sie immer weiter und weiter nach links oder rechts. und wie lassen sich diese "WK"'s z.b. in pixeleinheiten transformieren?

3.) auf einzelne konstanten die ihr verwendet, geht ich gar nicht ein. was genau macht denn z.b. "SwapBuffers(h_DC)"? der kommentar daneben ist mir einfach zun wenig. swapbuffers kriegt das handle auf unsern device kontext übergeben richtig? und was macht diese funktion dann damit? wenn ich es nicht drinhabe oder per tastendrück woanders aufrufe passiert in dem fenster auch erstmal gar nichts. kann ich dieses "SwapBuffers" auch für OnIdle-Events benutzen? Wenn ja, wie kann ich mir das mit den "Double Buffer" vorstellen? Gibt es dann ein zweites Fenster im Hintergrund, welches die gleiche Szene nochmal zeigt? Und wo genau liegt der Unterschied zwischen dem h_DC (Device Kontext), h_RC (Rendering Context) und unserem Fenster (h_Wnd) ? Ist das alles nur für windows intern? was genau machen die einzelnen matrix modes (projection,modelview) und wofür ist der pixelformatdeskriptor?

4.) wenn ich die api vorlage benutze, seh ich in der main message loop immer folgendes:
glDraw();
SwapBuffers(h_DC);
ProcessKeys;
das windows ein event gesteuertes bs ist, is mir schon klar, aber ist es, gerade für spiele, wo sich einzelne objekte verschieden bewegen und reagieren sollen, überhaupt sinnvoll, das glDraw() in die main message loop zu packen? weil irgendwie rendert der die gleiche szene (was in gldraw steht) doch dann immer und immer wieder neu und man hat doch gar keine möglichkeit, da mal was geschehen(erscheinen) zu lassen (ausser ganz normalen rotationen und bewegungen) oder? muss das swapbuffers auch zwingend in die main message loop? oder muss man für spiele den ganzen kram sowieso woanders himpacken? wenn ja, wo am besten? wenn nein: wie kann man das denn alles am geschicktesten verarbeiten?

5.) auch ein sehr seltsames phänomen: sobald ich per opengl auch nur EIN simples objekt in mein fenster rendere, steigt die temperatur meiner graka soweit an, als wäre sie unter vollast wie bei NFSU2(ca. 53°C - idle is ca 32°C). ist das normal? denn sooo aufwendig ist das, was ich da rendere ja nun auch wieder nicht - oder liegt es eben daran, das der die gleiche szene immer und immer wieder rendert, da das gldraw ja in der main message loop steht? das führt ja dann wieder auf die frage von 4 zurück? wie und wo dann? :)

6.) was ist denn vorteilhafter und schneller? meine dominosteine per glquads und einer funktion direkt auf den screen zu rendern oder ein model zu entwerfen und da ne textur draufzupacken? wäre es damit auch einfacher die sachen einzeln auf dem bildschirm zu bewegen (da man ja nur das model irgendwie verschieben bzw. drehen muss, während man bei den glquads ja den ganzen mist ja immer und in jeder position neu zeichnen muss oder?)

ich glaube das war es erstmal, aber ich glaube das reicht auch erstmal für meinen ersten post :D
sorry, wenn ich soviele fragen auf einmal stelle, aber das ist halt alles so unklar und wo kann ich sonst fragen wenn nicht hier? ansonsten schonmal danke im vorraus und für die ganze arbeit mit den tutorials. weiter so

p.s. die fragen stelle ich übrigens an die ganze community - auch wenn es so klingt das ich nur die "tutorialschreiber" meine :wink:


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 14:56 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Jul 17, 2002 12:07
Beiträge: 976
Wohnort: Tübingen
Wow, das sind ja eine Menge Fragen, aber das werden wir schon alles klären.

zu 1.) Um Objekte zu verschieben/rotieren/skalieren, fallen mit spontan nur zwei Möglichkeiten ein. Entweder jedes Quad weis genau, wo es hinsoll, als so, wie es zum Beispiel von einem 3D-Modeller exportiert wird, oder du zeichnest immer das gleiche Quad, nur hald versetzt/verschoben/skaliert. Ersteres würde ich speziell für deine Anforderungen nicht empfehlen, da deine Dominos natürlich dynamisch sind, und sich fest zum Level gehören. Für einen Würfel sind 6 Quads schon fast optimal, einfacher lässt sich ja ein Würfel nicht beschreiben. Ich würde aber stattdessen 12 Triangles verwenden, da die GPU zwei Tris schneller berechnet als ein Quad.

zu 2.) Die Weltkoordinaten in Pixeleinheiten zu konvertieren dürfte schwierig werden, da sich natürlich mit wechselnder Entfernung zum Betrachter auch die Einheiten verändern. Es sei denn du arbeitest nur auf einer Ebene.

zu 3.) Da hab ich ned so richtig Ahnung 8)

zu 4.) Also im glDraw(); wird hald einfach alles gezeichnet, was gezeichnet werden soll. Du schreibst hier alles Matrixtransformationen (zB glTranslatef(...)), Polygone (glBegin(...)) und halt alles, was mit gl... beginnt, rein, was halt in jedem Frame auch wieder neu gesetzt werden muss.

zu 5.) Das ist ja der optimale Zeichen dafür, dass der Computer zeigt, was er kann. Natürlich würden bei einem simplen Quad ein Bild pro Sekunden reichen, aber bei mehr Objekten wirst du für jedes Quäntchen investierter Leistung froh sein. Und OpenGL kennt hald (bildlich gesprochen) nicht, wieviel sich in der Szene befindet, also fordert es einfach alle Power, die es kriegen kann. Es fragen oft Leute, ob es normal ist, dass die CPU-Auslastung bei OpenGL-Anwendungen immer bei 100 % liegt, das ist genau das gleiche. Es würde mich eher stören/wundern, wenn es anders wäre.

zu 6.) Ob Model oder in OpenGL berechnen, kommt eigentlich aufs selbe raus, das Model würde ja auch mit den gleichen Funktionen gerendert werden, mit denen es du per Hand machen würdest. Models setzt man hald generell bei komplexeren Objekten ein, eine Dominostein ist da ja noch ned das Maximum :)

_________________
"Du musst ein Schwein sein in dieser Welt, sangen die Prinzen, das ist so 1.0. Du musst auf YouTube zeigen, dass dir dein Schweinsein gefällt, das ist leuchtendes, echtes Web 2.0."
- Hal Faber

Meine Homepage: http://laboda.delphigl.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 15:17 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
danke für die schnelle antwort!

liegt wahrscheinlich an mir,aber wiklich schlauer bin ich jetzt leider immer noch nicht :wink:

also, das ganze sieht in meinem testprog so aus: (drehen und wenden kann man die per tastendruck - is ja aber auch egal)

Bild

der relevante code dafür is folgender:

Code:
  1. procedure glDominoe();        
  2. begin
  3.   glBegin(GL_QUADS);
  4.     glColor3f(1,1,0);
  5.     glVertex3f(-1.0,-2.0, 0.0);
  6.     glVertex3f(-1.0, 2.0, 0.0);
  7.     glVertex3f(1.0,2.0, 0.0);
  8.     glVertex3f(1.0,-2.0, 0.0);
  9.  
  10.   glColor3f(1,1,0);
  11.     glVertex3f(-1.0,-2.0, -0.5);
  12.     glVertex3f(-1.0, 2.0, -0.5);
  13.     glVertex3f(1.0,2.0, -0.5);
  14.     glVertex3f(1.0,-2.0, -0.5);
  15.  
  16.   glRotatef(90,1,0,0);
  17.   glColor3f(1,1,0);
  18.   glVertex3f(1.0,-2.0, 0.0);
  19.     glVertex3f(1.0, 2.0, 0.0);
  20.     glVertex3f(1.0,2.0, -0.5);
  21.     glVertex3f(1.0,-2.0, -0.5);
  22.  
  23.   glColor3f(0.8,0.8,0.2);
  24.   glVertex3f(-1.0,-2.0, 0.0);
  25.     glVertex3f(-1.0, 2.0, 0.0);
  26.     glVertex3f(-1.0,2.0, -0.5);
  27.     glVertex3f(-1.0,-2.0, -0.5);
  28.  
  29.   glRotatef(90,0,1,0);
  30.   glColor3f(0.8,0.8,0.2);
  31.   glVertex3f(-1.0,2.0, 0.0);
  32.     glVertex3f(-1.0, 2.0, -0.5);
  33.     glVertex3f(1.0,2.0, -0.5);
  34.     glVertex3f(1.0,2.0, 0.0);
  35.  
  36.   glColor3f(1,1,0);
  37.   glVertex3f(-1.0,-2.0, 0.0);
  38.     glVertex3f(-1.0, -2.0, -0.5);
  39.     glVertex3f(1.0,-2.0, -0.5);
  40.     glVertex3f(1.0,-2.0, 0.0);
  41.   glEnd();
  42. end;
  43.  
  44. procedure glDominoe2();          
  45. begin
  46.   glBegin(GL_QUADS);
  47.  
  48.     glColor3f(1,1,0);
  49.     glVertex3f(-1.0,-2.0, 0.0);
  50.     glVertex3f(-1.0, -0.25, 0.0);
  51.     glVertex3f(1.0,-0.25, 0.0);
  52.     glVertex3f(1.0,-2.0, 0.0);
  53.  
  54.   glColor3f(1,0,0);
  55.     glVertex3f(-1.0,-0.25, 0.0);
  56.     glVertex3f(-1.0, 0.25, 0.0);
  57.     glVertex3f(1.0,0.25, 0.0);
  58.     glVertex3f(1.0,-0.25, 0.0);
  59.  
  60.   glColor3f(1,1,0);
  61.     glVertex3f(-1.0,0.25, 0.0);
  62.     glVertex3f(-1.0, 2.0, 0.0);
  63.     glVertex3f(1.0,2.0, 0.0);
  64.     glVertex3f(1.0,0.25, 0.0);
  65.  
  66.  
  67.  
  68.  
  69.   glColor3f(1,1,0);
  70.     glVertex3f(-1.0,-2.0, -0.5);
  71.     glVertex3f(-1.0, -0.25, -0.5);
  72.     glVertex3f(1.0,-0.25, -0.5);
  73.     glVertex3f(1.0,-2.0, -0.5);
  74.  
  75.   glColor3f(1,0,0);
  76.     glVertex3f(-1.0,-0.25, -0.5);
  77.     glVertex3f(-1.0, 0.25, -0.5);
  78.     glVertex3f(1.0,0.25, -0.5);
  79.     glVertex3f(1.0,-0.25, -0.5);
  80.  
  81.   glColor3f(1,1,0);
  82.     glVertex3f(-1.0,0.25, -0.5);
  83.     glVertex3f(-1.0, 2.0, -0.5);
  84.     glVertex3f(1.0,2.0, -0.5);
  85.     glVertex3f(1.0,0.25, -0.5);
  86.  
  87.  
  88.  
  89.   glRotatef(90,1,0,0);
  90.   glColor3f(1,1,0);
  91.   glVertex3f(1.0,-2.0, 0.0);
  92.     glVertex3f(1.0, -0.25, 0.0);
  93.     glVertex3f(1.0,-0.25, -0.5);
  94.     glVertex3f(1.0,-2.0, -0.5);
  95.  
  96.   glColor3f(1,0,0);
  97.   glVertex3f(1.0,-0.25, 0.0);
  98.     glVertex3f(1.0, 0.25, 0.0);
  99.     glVertex3f(1.0,0.25, -0.5);
  100.     glVertex3f(1.0,-0.25, -0.5);
  101.  
  102.   glColor3f(1,1,0);
  103.   glVertex3f(1.0,0.25, 0.0);
  104.     glVertex3f(1.0, 2.0, 0.0);
  105.     glVertex3f(1.0,2.0, -0.5);
  106.     glVertex3f(1.0,0.25, -0.5);
  107.  
  108.  
  109.  
  110.   glColor3f(0.8,0.8,0.2);
  111.   glVertex3f(-1.0,-2.0, 0.0);
  112.     glVertex3f(-1.0, -0.25, 0.0);
  113.     glVertex3f(-1.0,-0.25, -0.5);
  114.     glVertex3f(-1.0,-2.0, -0.5);
  115.  
  116.   glColor3f(0.8,0.0,0.2);
  117.   glVertex3f(-1.0,-0.25, 0.0);
  118.     glVertex3f(-1.0, 0.25, 0.0);
  119.     glVertex3f(-1.0,0.25, -0.5);
  120.     glVertex3f(-1.0,-0.25, -0.5);
  121.  
  122.   glColor3f(0.8,0.8,0.2);
  123.   glVertex3f(-1.0,0.25, 0.0);
  124.     glVertex3f(-1.0, 2.0, 0.0);
  125.     glVertex3f(-1.0,2.0, -0.5);
  126.     glVertex3f(-1.0,0.25, -0.5);
  127.  
  128.  
  129.  
  130.   glRotatef(90,0,1,0);
  131.   glColor3f(0.8,0.8,0.2);
  132.   glVertex3f(-1.0,2.0, 0.0);
  133.     glVertex3f(-1.0, 2.0, -0.5);
  134.     glVertex3f(1.0,2.0, -0.5);
  135.     glVertex3f(1.0,2.0, 0.0);
  136.  
  137.   glColor3f(1,1,0);
  138.   glVertex3f(-1.0,-2.0, 0.0);
  139.     glVertex3f(-1.0, -2.0, -0.5);
  140.     glVertex3f(1.0,-2.0, -0.5);
  141.     glVertex3f(1.0,-2.0, 0.0);
  142.   glEnd();
  143. end;
  144.  
  145. procedure glDraw;
  146. begin
  147.   glClearColor(0,0,0,0);
  148.   glClear(GL_COLOR_BUFFER_BIT or GL_DEPTH_BUFFER_BIT);
  149.   glloadidentity;
  150.   gltranslatef(posvect[0],posvect[1],viewwidth);
  151.   glRotatef(RotateX, 1, 0, 0);
  152.   glRotatef(RotateY, 0, 1, 0);
  153.   glRotatef(RotateZ, 0, 0, 1);
  154.   glscalef(0.3,0.3,0.3);
  155.   glDominoe2;
  156.   gltranslatef(0,0,2);
  157.   gldominoe;
  158. end;
  159.  
  160. while not finished do
  161.   begin
  162.     if (PeekMessage(msg, 0, 0, 0, PM_REMOVE)) then
  163.     begin
  164.       if (msg.message = WM_QUIT) then    
  165.         finished := True
  166.       else
  167.       begin                              
  168.         TranslateMessage(msg);
  169.         DispatchMessage(msg);
  170.       end;
  171.     end
  172.     else
  173.     begin
  174.       viewwidth:=-10;
  175.  
  176.       glDraw();                          
  177.       SwapBuffers(h_DC);                  
  178.       ProcessKeys;                      
  179.     end;
  180.   end;
  181.   glKillWnd(FALSE);
  182.   Result := msg.wParam;
  183. end;
  184.  


gerade, um diese frames und animation bzw. kollision usw. geht es mir! wie kann ich nun porgrammieren, das, wenn ich z.b. die space taste drücke der gelbe stein in einer FLÜSSIGEN bewegung umfällt, dabei den anderen stein anstösst (wenn sie kollidieren) dieser dann mit umfällt und beide dann liegen bleiben?
das kann doch gar nicht gehen, wenn der in der main message loop immer nur das selbe rendert oder? und wie kann man festlegen, das erst ein objekt umfällt, dann beide und das dann später auf ganz viele steine erweitern? das ist quasi mit mein hauptproblem :?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 16:05 
Offline
DGL Member
Benutzeravatar

Registriert: Mi Aug 28, 2002 19:27
Beiträge: 568
Wohnort: Chemnitz / Sachsen
hallo und guten morgen *g*

das klingt ja schon verdammt nach einem einsatz für newton !!!

doch noch kurz zum swapbuffers ... also das ganze macht im endeffekt nichts weiter als die virtuellen bildschirmseiten (es gibt 2 buffer, den angezeigten und den in dem du zeichnest) zu vertauschen, so das die dinge, die du gezeichnest hast auf dem bildschirm erscheinen ...



nun zu den dominos ... das ganze wäre ein wirklich wunderbares spiel für die newton game physics engine (schau mal dazu bissl hier im forum rum, gibts schon einiges zu und sascha hat einiges auf seiner eigenen seite). dabei bräuchtest du halt nur deine dominos als Körper an newton übergeben und wenn du die leertaste drückst lässt du einfach ne kraft auf den anfangsstein wirken und schon fällt der um und die anderen danach auch. um das fallen die kollision und so brauchst du dich selbst nicht kümmern, da newton dir nur eine matrix zurückgibt, mit der du dann dein objekt positionieren kannst. also alles viel einfacher als das was ich so von dir gelesen hab :-)

_________________
Aktuelles Projekt :
www.PicPlace.de


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 16:09 
Offline
DGL Member
Benutzeravatar

Registriert: Di Nov 26, 2002 22:12
Beiträge: 259
Wohnort: Dresden
Was die Einsteigertutorials angeht so gebe ich dir Recht, denn sie lassen einige Fragen offen. Deshalb werden diese Tutorials derzeit überarbeitet.

Wie wäre es, wenn du eine Prozedur erstellst in der du deinen Stein zeichnest. Am besten gleich eine ganze Klassefür die Steine. Für jeden Stein speicherst du eine Position, Ausrichtung, Funktion usw.

Es gibt keine feste Umrechnung von Weltkoordinaten, denn du kannst deine Welt so groß bzw. so klein Zeichnen wie es dir beliebt. Schließlich kannst du dich einem Objekt unendlich annähern und dich wiederum von ihm unendlich weit entfernen. Die eigentliche Größe entsteht durch die Geschwindigkeit mit der du dich bewegst. Bewegst du dich verhältnismäßig langsam so erscheint dir alles riesig, bewegst du dich schnell so erscheint dir alles viel kleiner (die korrekte Entfernung deiner Nearclippingplane vorausgesetzt).
Welche Skalierung deiner Welt dir also zusagt ist ganz allein dir überlassen.

SwapBuffers gibt dein Bild aus indem es den Front- und den Backbuffer austauscht und somit das gezeichnete Bild auf den Bildschirm bringt. Am Besten du liest dich diesbezüglich mal in unserem OpenGL-Wiki zum Thema Framebuffer schlau.
Bezüglich der anderen Fragen solltest du google bitten oder stöberst mal im Wiki. Dinge wie Handles und ein Device Kontext haben nichts mit OpenGL zu tun.

Wenn ich mir deinen bisherigen Code so anschaue empfehle ich dir dringend dir weitere Tutorials durchzulesen (z.B. das Bombermantutorial). Mit deinem bisherigen Code wirst du nicht weit kommen, denn es ist nur eine Frage der Zeit bis du die Übersicht komplett verloren hast. Mit Klassen könntest du dir zudem viel Arbeit ersparen.

Wenn du weitere Tutorials gelesen hast werden sich die meisten Fragen von selbst beantworten.

Zum Mitreißen der Steine:
Es gibt im Internet Unmengen an Tutorials zum Thema OBB (Oriented Bounding Boxes)-Kollision. Da deine Steine vermutlich immer Boxen sein werden könnten dir diese Artikel weiterhelfen. Um die Physik musst du ich jedoch selbst kümmern (wenn du weißt, wann eine Kollision statt findet ist es auch nicht mehr schwer den Stein umzustoßen, denn du kennst dann auch den Kollisionsstein (und somit die Informationen des anstoßenden Steines).

In letzter Zeit wird für solche Probleme auch immer öfter Newton empfohlen. Mit Newton kannst du ein komplexes Physikmodell in dein Programm einfach integrieren. Da es sich hier um kein besonders komplexes Thema handelt wird es sicher auch einige Tutorials/Beispielprogramme zu diesem Gebiet geben.

_________________
Nichts auf der Welt ist so gerecht verteilt wie der Verstand. Denn jederman ist überzeugt, dass er genug davon habe.
Rene Descartes, frz. Mathematiker u. Philosoph, 1596-1650


Zuletzt geändert von Magellan am Fr Feb 18, 2005 16:14, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 16:09 
Offline
DGL Member

Registriert: Fr Jan 10, 2003 20:18
Beiträge: 88
Nun ja... ich glaube dir fehlen noch logische Denkweisen eines OpenGL- bzw. 3D-Programmierer:
Es wird nicht immer die selbe Szene gezeichnet sondern nur das was du geschrieben hast, dein Probelm ist denke ich mal folgendes: Du kannst ja die Positionen und den neigungs-Winkel deiner Dominos in sogennate VARIABLEN speichern und diese dann zum Beispiel per Tasten Druck ändern zB: folgender Maßen:

Wenn die Leertaste gedrückt wird, setzt du die Variable eines Dominos( D1_faellt_um:Boolean) = TRUE;
dann überprüfst du in deiner Main Loop ob D1_faellt_um TRUE ist und ziehst der Variable D1_Winkel:GLfloat; etwas ab z.B: so:

D1_Winkel:=D1_Winkel-0.01;

Vor dem Zeichnen deines Dominos speicherst du dann die Matrix(glPushMatrix), drehst ihn um seine z-Achse(oder x,y je nachdem von wo wir drauf schaune) via glRotate(D1_WInkel,0,0,1) zeichenst ihn lädst wieder die Matirx in den zustand vorher(glPopMatrix) und zeichnes den anderen Domino, mit Kollision und allem, das muss auch alles in der Main Loop stehen.
Dadurch eintsteh dann eine Animation, da bei jedem Frame der Domino sich mehr und mehr neigt, je nachdem wie hoch deine FramesPerSecond Rate ist, ALSO NICHT IMMER DAS GLEICHE BILD :)

Ich hoffe ich konnte es einigermaßen erklären...


Peace ;)

[EDIT] Ach ja zu deiner Frage mit den Koordinaten. Du benutzt die Projektions Matirx, da ändert sich dein Frustum mit der Tiefe(z-Koordiante) deines Objekts, für Pixel Korrdinaten brauchst du den Ortho-Modus, nähers dazu findest du sicherlich in SoS 2D-Tutorial.


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 16:29 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
vielen dank für die vielen tipps - ich werd ma schauen was ich draus mache und dann nochmal das ergebnis posten :D

aber sehe ich richtig, das ich die main messageloop so lasse wie sie ist ja? also das müsste schon so gehen wie es da steht?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 16:42 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 14, 2004 18:56
Beiträge: 804
Wohnort: GER/OBB/TÖL-WOR/Greiling
schau dir mal auf Newton Game Dynamics den Neton Stress Test an(ziemlich weit unten auf der seite). du wirst newton dann bestimmt für dein thema interessant finden! :wink:

PS: wenn ichs noch drauf hab, kriegst nen schnellen screen.

_________________
Bild

"User Error. Replace User and hit Continue."


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 17:57 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
die newton engine is zwar cool aber leider komplett in vcpp :x

und ich habe keine lust das alles nach deplhi zu portieren....

also das mit dem einzelnen objektbewegen hab ich jetzt gerafft, aber wie kann man schwerpunkte von bestimmten objekten festlegen um die dann rotiert werden. eine fallbewegung mit dem ganz normalen glrotatef sieht nicht so prickelnd aus :D

und wie bestimmte ich kollisionen? gibt es irgendeine opengl funktion die mir die koordinaten von bestimmten punkten, linien, polygonen o.ä. zurückliefert?


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 18:06 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 14, 2004 18:56
Beiträge: 804
Wohnort: GER/OBB/TÖL-WOR/Greiling
überrraschung! :D

http://newton.delphigl.de

netterweise hat Sascha Willems einen Header für Delphi geschrieben.

Kollisionen usw. musst du normalerweise alles selbst machen.

opengl macht NUR die grafik, d.h. es nimmt von dir daten und zeichnet. zumindest prinzipiell.

EDIT: Öha! war doch .de! link korrigiert.

_________________
Bild

"User Error. Replace User and hit Continue."


Zuletzt geändert von luketheduke am Fr Feb 18, 2005 18:15, insgesamt 3-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 18:10 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
das mit der kollision war auch eher ne allgemeine frage :wink:

aber wenns das auch für delphi gibt, das is ja schomal was...thx für den link :)

edit: ööhmmm...der link funzt aber ned :(


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 18:16 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 14, 2004 18:56
Beiträge: 804
Wohnort: GER/OBB/TÖL-WOR/Greiling
sry, link korrigiert.

EDIT: bei euch auf der seite steht übrigens, dass "PushOver" noch nicht bei euch auf dem mirror ist.

_________________
Bild

"User Error. Replace User and hit Continue."


Zuletzt geändert von luketheduke am Fr Feb 18, 2005 18:29, insgesamt 1-mal geändert.

Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 18:21 
Offline
Guitar Hero
Benutzeravatar

Registriert: Do Sep 25, 2003 15:56
Beiträge: 7810
Wohnort: Sachsen - ERZ / C
Programmiersprache: Java (, Pascal)
Sascha hat den Newton Header bereits nach Delphi portiert. Es gibt hier ja schon einige die das mit Delphi nutzen. Du musst das also net selber amchen ;) .

Das mit dem Mainloop is so ne Sache. Schönender in Sachen CPU Last und wie du schon gesagt hast auch GRAKA, wäre es, wenn der Mainloop nicht ganz so oft ausgeführt wird. z.B. könntest du mit einem Timer das Zeichnen auslösen. Dann könnte auch jeder Nutzer einstellen wieviel Frames er haben möchte. Bei vielen Programmen wird hier auf dem Board im OnIdle gerendert. Dadurch kommt natürlich die höchste Framerate aber auch die höchste CPU last zu stande (was vorallem bei Laptops negativ ist). Du solltest aber daran Denken, dass bei einer Variablen Framerate auch die Dominostein bewegung Timbased(und nicht Framebased) sein muss.
Das sind alles Sachen die dir wahrscheinlich noch nichts sagen aber es gibt hilfe im Wiki:

http://wiki.delphigl.com/index.php/Timebased_Movement
http://wiki.delphigl.com/index.php/Doppelpufferung
http://wiki.delphigl.com/index.php/SwapBuffers

_________________
Blog: kevin-fleischer.de und fbaingermany.com


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 18:50 
Offline
DGL Member

Registriert: Fr Feb 18, 2005 13:35
Beiträge: 11
luketheduke hat geschrieben:

EDIT: bei euch auf der seite steht übrigens, dass "PushOver" noch nicht bei euch auf dem mirror ist.


hoppla..das kann sein. meld dich einfach per pm oder so - dann schick ichs dir per mail. is ja ned so riesig. aber vorsicht - du brauchst entweder dos oder n bs mit dos kernel (z.b. win 95/98).
oder halt n tux system mit dem dosemu :D


Nach oben
 Profil  
Mit Zitat antworten  
 Betreff des Beitrags:
BeitragVerfasst: Fr Feb 18, 2005 19:39 
Offline
DGL Member
Benutzeravatar

Registriert: Fr Mai 14, 2004 18:56
Beiträge: 804
Wohnort: GER/OBB/TÖL-WOR/Greiling
ja hab ich, ist aber net in benutzung - wart ich lieber auf deine opengl-umsetzung.

PS: wann immer du fragen hast, ich helf dir gerne.

_________________
Bild

"User Error. Replace User and hit Continue."


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


Wer ist online?

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