Nochmal zu const speed
Übersicht
BlitzBasic AllgemeinGehe zu Seite 1, 2, 3, 4 Weiter
X0rBetreff: Nochmal zu const speed |
 Mo, Jun 12, 2006 22:54Antworten mit Zitat 
|
|
|---|---|---|
|
Ok. Ich wollte hier nochmal das mit dem speed von Programmen besprechen. Bitte diesen Thread nicht schließen oder löschen. Es ist wichtig.
Nun denn: GTA San Andreas z.B läuft doch auch flüssig, obwohl da mehrere meshes geladen sind. Das muss man doch irgendwie programmieren können. Ich hatte das mal in irgendeinem anderen Forum gelesen, weiß aber nicht mehr welches. Also zu meinem Problem: Konstante Geschwindigkeit. Beispiel: Ladet 20 cube meshes auf rnd(1,20) u.s.w. Ihr merkt, der speed des Programms wird langsamer. So, nun will ich wissen, wie der speed konstant bleibt, also sich auch bei 30 meshes nicht ändert. Ist das nicht mit einem kleinen Trick zu machen? Weil bei meinem momentanen Spiel wird die Stadt langsam so groß, dass das Spiel langsamer läuft. |
||
|
5k41 |
Mo, Jun 12, 2006 23:01 Antworten mit Zitat
|
|---|---|---|
|
erstmal alle objekte ausserhalb des sichtbereiches verstecken, dann einfach mal bei google oder hier im forum nach frameunabhäniger programmierung suchen!
MfG |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
Dreamora |
Mo, Jun 12, 2006 23:04 Antworten mit Zitat
|
|
|---|---|---|
|
Hinzu kommt, das Konsolenprogrammierer nicht auf 100-300 FPS zielen sondern auf konstant 30 oder 60 (bzw. früher 25 - 50 da Pal mit 50hz arbeitet).
Sprich wenn du dein Programm so machst, das es millisecs abhängig nur alle 1000/60 ms ein bild rendert (mit flip 0), wirst du feststellen, das deine restliche Programmlogik auf einmal 10-1000 Mal soviel Zeit zur verfügung hat 
Die meisten vertreten jedoch die Meinung, das rendern mit flip 1 besser sei ohne das man nur alle XY millisecs rendert ... mag für einfache Programmierung so sein ... für Spiele die aber einiges an hintergrundlogik benötigen ist es der overkill. |
||
| Ihr findet die aktuellen Projekte unter Gayasoft und könnt mich unter @gayasoft auf Twitter erreichen. | ||
X0r |
Di, Jun 13, 2006 14:44 Antworten mit Zitat
|
|
|---|---|---|
|
Frameunabhängig ist aber was ganz anderes. Damit kann ich konstante Geschwindigkeit auf allen RECHNERN programmieren.
Aber ich meine was anderes. Konstante Geschwindigkeit der Kamera und der bewegenden Objekte. Mach folgendes: if mousehit(1) then cub.cub=new cub cub\c=createcube() positionentity cub\c,rand(1,20),rand(1,20),rand(1,20) endif in der Kopfschleife(Also repeat ..flip..until..) Du merkst, dass sich die Kamera langsamer bewegt. Kein Wunder, es ist ja auch viel mehr auf dem Ram Speicher. Und ich suche nach einer Lösung, dass sich die Kamera auch bei 20 cubes flüssig und schnell bewegt. |
||
X0r |
Di, Jun 13, 2006 14:50 Antworten mit Zitat
|
|
|---|---|---|
|
Oh Moment. Frameunabhängiges Programmieren nimmt ja speed * Schleifenzeit.
Umso mehr im Ram, desto größer die Schleifenzeit. Ok. Supi. Das Spiel ist jetzt schnell. Aber nochwas: Wer kann mir das jetzt flüssiger machen? Es ruckelt, ist ja klar. Und wie stell ich das mit dem FPS ein? Hä? Und dieses Frameunabhängig Tutorial ist auch nicht wirklich gut. Stell dir vor, dein Rechner ist sau langsam, dann würde das Rechteck "springen" und es würde keine Kollision herrschen. Und überhaupt, wie gesagt, ist es nicht flüssig. Ich habe auch GTA San Andreas auf PC. Und darauf läufts auch flüssig bei einer Auflösung von 1024*768. |
||
- Zuletzt bearbeitet von X0r am Di, Jun 13, 2006 14:59, insgesamt einmal bearbeitet
|
BladeRunnerModerator |
Di, Jun 13, 2006 14:52 Antworten mit Zitat
|
|---|---|---|
|
Frameunabhängiges Programmieren sorgt nicht nur dafür dass es auf verschiedenen Rechnern gleich schnell läuft, sondern auch dass - wie der Name es schon sagt - unabhängig von der Framerate auf einem Rechner alle Meshes dennoch konstante Geschwindigkeiten haben. Was Du gegen Framerateeinbrüche unternehmen kannst (culling, polyreduktion etc.) wurde schon in Deinem letzten Thread geklärt.
Eigentlich hätte ich mir das sparen können weil Du es wahrscheinlich eh nicht hören willst. Der effektive Speed Deiner Programme hängt davon ab wie effektiv Du das zu zeigende Material verwaltest. |
||
|
Zu Diensten, Bürger.
Intel T2300, 2.5GB DDR 533, Mobility Radeon X1600 Win XP Home SP3 Intel T8400, 4GB DDR3, Nvidia GF9700M GTS Win 7/64 B3D BMax MaxGUI Stolzer Gewinner des BAC#48, #52 & #92 |
||
|
BtbN |
Di, Jun 13, 2006 14:55 Antworten mit Zitat
|
|---|---|---|
|
Genau das macht Frameunabhängige Programmierung doch.
du multiplizierst jede Bewegung mit einem Faktor. Dieser Faktor ist die Render-Dauer des letzen Frames durch 1000(Für gewöhnlich). Durch die Multiplikation der Bewegungen mit dem Faktor gibst du die Bewegung nicht mehr in Einheiten pro Frame sondern in Einheiten pro Sekunde(Und das immer und überall, egal welche Framerate). Wenn die Framerate nun zu gering wird, fängts an zu ruckeln, aber der Speed bleibt konstant! |
||
X0r |
Di, Jun 13, 2006 15:49 Antworten mit Zitat
|
|
|---|---|---|
|
Ja genau. Hab ich doch oben schon gesagt.
Aber was ist jetzt mit dem Ruckeln? Es soll flüssig funktionieren und keine jumpings. @BladeRunner: Doch doch. Das wollte ich hören. Zeig mir das mal, was du da mit der Kollision meinst. |
||
|
|
5k41 |
Di, Jun 13, 2006 17:04 Antworten mit Zitat
|
|---|---|---|
|
ja, es ruckelt natürlich dann statt es einfach langsamer zu machen wenn du zuviel anzeigst! Poste doch bitte mal deinen code... ich hab das gefühl es macht keinen sinn dir nur theoretisch zu erklären wie das mit dem entfferntem rendering etc. funtzt!
MfG |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
X0r |
Di, Jun 13, 2006 17:12 Antworten mit Zitat
|
|
|---|---|---|
|
Ich schreibe mal jetzt den code, so wie ichs immer mache:
graphics3d 1024,768 setbuffer backbuffer() cam=createcamera() .... stime=millisecs() repeat if keydown(200) then a=1 else a=0 endif speed#=a*time moveentity cam,0,0,speed# if mousehit(1) then cub=createcube() positionentity cub,rand(1,20),rand(1,20),rand(1,20) endif renderworld updateworld flip 0 time=millisecs()-stime until keyhit(1) end Es R U C K E L T |
||
- Zuletzt bearbeitet von X0r am Di, Jun 13, 2006 17:20, insgesamt 3-mal bearbeitet
|
|
5k41 |
Di, Jun 13, 2006 17:16 Antworten mit Zitat
|
|---|---|---|
|
graphics3d 1024,768
setbuffer backbuffer() repeat stime=millisecs() time=stime-millisecs() flip 0 until keyhit(1) erstmal muss es so sein! und es geht mir hier nicht um diese routine, sondern um die anzeige deiner würfel etc. bei 20 würfeln a 8 verts und 20 surfaces darf es eigentlich noch garnicht ruckeln... musst irgendwo irgendwas falsch machen! MfG 5k41 |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
X0r |
Di, Jun 13, 2006 17:24 Antworten mit Zitat
|
|
|---|---|---|
|
Ähh ja. Ich habe das da oben falsch geschrieben. Na ok. In 30 Sekunden.
Ok. Mach mal das hier und drücke 1 Minute auf mouse 1 Taste. Siehst du. Es springt. Das ist Mist. Es soll flüssig werden: Graphics3D 1024,768 SetBuffer BackBuffer() cam=CreateCamera() Repeat stime=MilliSecs() If KeyDown(200) Then a#=-0.5 Else a#=0 EndIf MoveEntity cam,0,0,a#*time If MouseDown(1) Then cub=CreateCube() PositionEntity cub,Rand(-70,70),Rand(-70,70),Rand(-70,70) EndIf RenderWorld UpdateWorld Locate 1,1 Print time Flip 0 time=MilliSecs()-stime Until KeyHit(1) End P.s: Das ist nur ein Beispiel, natürlich nicht mein Ego-Shooter. So, jetzt zum flüssig. |
||
|
|
5k41 |
Di, Jun 13, 2006 17:35 Antworten mit Zitat
|
|---|---|---|
|
was springt da? sorry bei mir läufts nach einmal kurz klicken sehr flüssig!
MfG |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
X0r |
Di, Jun 13, 2006 17:37 Antworten mit Zitat
|
|
|---|---|---|
|
MANN. Waum versteht mich keiner?
Drück mal 1 Minute drauf. Bis dort 100+ von denen sind. Jetzt müsstest du es merken. |
||
X0r |
Di, Jun 13, 2006 17:42 Antworten mit Zitat
|
|
|---|---|---|
|
MANN. Waum versteht mich keiner?
Drück mal 1 Minute drauf. Bis dort 100+ von denen sind. Jetzt müsstest du es merken. Was da springt? Hmm, die Kamera, nich? Man, wenn da 100 cubes geladen sind, ist der Schleifendurchgang ja wohl langsamer, weil so viel auf dem Ram Speicher ist. Dadurch ist time ziemlich groß. 2 oder 7 z.B. Und wenn die Kamera sich mit speed 7 bewegt, dann ist das viel zu schnell und deswegen ist die Kamera auf einmal mit einem Schlag 100 Pixeln(oder was auch immer) weiter weg. Und das ist verdammt schlecht für ein Spiel. Hast du es jetzt kapiert? Und selbst wenn ich frameunabhängig Programmiere. Wenn diese cubes nicht mehr in view sind, dann bewegt sich die KAmera schneller. Dürft eigentlich nicht sein, oder? Kommt mir so vor. So, und wenn ein mesh jetzt zu weit springt, dann kann es nicht kollidieren und somit ist das Spiel futsch. |
||
|
|
5k41 |
Di, Jun 13, 2006 17:52 Antworten mit Zitat
|
|---|---|---|
|
Erstmal: REG DICH AB!
NAtürlich wird es sprunghaft! Das ist ja der Sinn von Frameunabhäniger programmierung! Wenn du beispielsweise ein netzwerk spiel programmierst ists doch wohl besser wenn jemand durch die welt hüpft als wenn er schleicht und damit viel langsamer ist! Zu deinem Problem: Das liegt an den Surfaces! 100 Sind einfach zuviel auf einmal und wirst du dank singlesurface technik, hiden von objekten und geschickter optimierung NIE brauchen und genau das wollte ich dir erklären... MfG 5k41 |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
X0r |
Di, Jun 13, 2006 18:07 Antworten mit Zitat
|
|
|---|---|---|
|
Ich bin nicht aufgeregt. Aber das heißt ja dann, dass ich das Programm garnicht schneller machen kann und das es dann nichts bringt.
Hä? Aber wie läuft das bei GTA San Andreas? Gut. Da werden meshes versteckt, aber die in der Nähe sind. Es funktioniert doch auch flüssig. Und ich will das auch so flüssig bekommen. Eine bitte: Programmier ein Programm wie meins, nur dass die Kamera nicht so blöde hüpft, sondern ganz normal mit gleichem speed weiterbewegt. Ist das zu schaffen? |
||
|
|
5k41 |
Di, Jun 13, 2006 18:17 Antworten mit Zitat
|
|---|---|---|
|
NEIN! Du willst es einfach nicht verstehen oder? Es wird überall getrickst bist zum gehtnichtmehr! Informier dich mal über SingleSurface, dann übers entityhiden, entferntes rendern clipping usw. und du wirst merken, dass selbst GTA nicht auf mehr als ca. 50 surfaces (in deinem beispiel 50 cubes) kommt!
MfG |
||
|
Projekte:
For a better World - Gesellschaftsspiel ( 100%) User posted image |
||
X0r |
Di, Jun 13, 2006 18:58 Antworten mit Zitat
|
|
|---|---|---|
|
Was hideentity ist weiß ich. Wird ja auch bei GTA so gemacht, man merkt es ja von weitem. Die Objekte werden wieder gezeigt. A
Aber beeinflusst das denn wirklich die Geschwindigkeit? Sie sind doch immernoch auf dem Ram Speicher, oder? Und was ist mit Blitz Game's Autospiel? Da wird, glaube ich, nichts vesteckt. Was ist aber rendern clipping? Kannst du mir das mal erklären? |
||
|
Hellfront |
Di, Jun 13, 2006 19:54 Antworten mit Zitat
|
|---|---|---|
|
Du solltest erst mal etwas elementares erklären:
Es ist unwichtig wie viel du auf deinem RAM hast (so lange er groß genug ist) Der RAM ist ja einfach nur dazu da, um nicht alles später viel langsamer von HD laden zu müssen. Wichtig ist, dass du so wenig rechnen musst wie möglich (oder eher dein PC ) Es oist doch egal wie viel auf dem RAM ist, sondern es ist wichtig wie viel der Prozesser zu tun hat.
|
||
Gehe zu Seite 1, 2, 3, 4 Weiter
Übersicht
BlitzBasic Allgemein
Powered by phpBB © 2001 - 2006, phpBB Group