Thema: Jump and Run programmieren

Quote:

Originally Posted by Psycho_Ente Versuche es mal mit Visual Basic Express 2010 Gravitation und Kollisionsabfragen lassen sich, gegebenenfalls mit einem Timer Lösen. Allerdings würde ich dir empfehlen, dich erst einmal mit den Grundlagen von Visual Basic zu befassen.

[Only registered and activated users can see links. Click Here To Register...]

Einen Timer :facepalm:

Nutz C# und XNA ;)

Quote:

Originally Posted by XxharCs Seit wann ? - Wär mir extrem neu ! Das zeigste mir bitte :awesome:

Seit XNA 4.0.

Quote:

Originally Posted by Headpuster [Only registered and activated users can see links. Click Here To Register...] Einen Timer :facepalm: Nutz C# und XNA ;) Seit XNA 4.0.

Wo liegt das Problem? Wie würdest du Gravitation, innerhalb Visual Basic umsetzen? Wenn du mich schon als dumm darstellen willst, könntest du auch gerne mal eine Erklärung abgeben, warum.
Bei mir hat es immer laggfrei und ordentlich mit einem Timer funktioniert.

Quote:

Originally Posted by Psycho_Ente Wo liegt das Problem? Wie würdest du Gravitation, innerhalb Visual Basic umsetzen? Wenn du mich schon als dumm darstellen willst, könntest du auch gerne mal eine Erklärung abgeben, warum. Bei mir hat es immer laggfrei und ordentlich mit einem Timer funktioniert.

Klar kein Problem.

Also, ich würde die Gravitation mit der Update Funktion, die von XNA overrided wird, verwenden, da sich diese so ziemlich alle 1 - 2 Millisekunden wiederholt.
Außerdem erstellt sie keinen neuen Thread, sondern used den GUI Thread, was wesentlich resourcenschonender ist.

Und nur weil es "ordentlich und laggfrei" funktioniert, heists nicht, das es richtig ist ;)

1. mit gdi macht man keine spiele
2. erst recht nicht mit einem timer
3. xna mit vb geht, ist aber nicht zu empfehlen

mein tipp:
verwende die opengl oder Direct X oder auch XNA, aber lass die finger von nicht hardware beschläunigten apis (wie gdi) und arbeite nicht mit timern sondern mit dem Idle Event der form (ka ob .Net forms das auch haben)

btw ich würd auch nicht mit einer .net sprache arbeiten, denn die sind um einen faktor 10-1000 langsamer als kompilierte sprachen

Quote:

Originally Posted by warfley 3. xna mit vb geht, ist aber nicht zu empfehlen

Gründe?

VB + XNA ist genau so schnell wie C# + XNA, da es vom selben Compiler in die ITL und dann vom Interpreter in Asm Code umgewandelt wird.

Warum nicht mit einer .Net Sprache arbeiten?
Terraria ist auch in C# und XNA programmiert und viel performanceschonender geschrieben als manche C++ mit Ultra 1337 Uber Direct X sind.

BTW benutzt XNA im Endeffekt auch nur Direct X.

Quote:

Originally Posted by warfley btw ich würd auch nicht mit einer .net sprache arbeiten, denn die sind um einen faktor 10-1000 langsamer als kompilierte sprachen

Quelle bitte, aber bezogen auf die neuste .net Version.

Quote:

Originally Posted by MoepMeep Quelle bitte, aber bezogen auf die neuste .net Version.

Da braucht man keine Quelle.
Schreib mal in C++ eine Console, welche dir 10k Hashes ausgibt, und dann eine in VB.
Sind locker 5 Sekunden unterschied.

Quote:

Originally Posted by Headpuster Da braucht man keine Quelle. Schreib mal in C++ eine Console, welche dir 10k Hashes ausgibt, und dann eine in VB. Sind locker 5 Sekunden unterschied.

Das interpretierte Sprachen langsamer sind ist klar, ich wollte die Quelle für den von ihm angegebenen Faktor sehen.

die quelle sind eine reihe von tests meiner seits mit diversen aufgaben wie arrays zu sortieren, oder daten verrechnen, das einzige wo .Net schneller war als Delphi war der zugriff auf die forms (.Net Forms halt), ich habe es mit .net 3.5 getestet mit 4, mit c# und vb und bei 30000 tests war das ergebnis eindeutig:
C# hat etwa 10-100 mal so lange gebraucht und vb etwa 10-1000 mal so lange

die kompilierte sprache war in diesem fall delphi, und der delphi compiler ist nicht mal auf hohe rechengeschwindigkeit optimiert.

natürlich sind 30000 tests wenig, aber allzuviel zeit hatte ich auch nicht dafür aufgewendet

Quote:

Gründe? VB + XNA ist genau so schnell wie C# + XNA, da es vom selben Compiler in die ITL und dann vom Interpreter in Asm Code umgewandelt wird.

nein eben nicht vb ist aus einem mir unbekannten grund langsamer
aber mein gedanke ist viel einfacher in vb xna zu verwenden ist viel weniger kompfortabel als in c#, in c# hat man das einfache Content system mit drag&drop, und vb macht alles nur mehr probleme (auch wenn es noch meilenweit kompfortabler ist als letztendlich OGL oder DX)

Quote:

Originally Posted by warfley die quelle sind eine reihe von tests meiner seits mit diversen aufgaben wie arrays zu sortieren, oder daten verrechnen, das einzige wo .Net schneller war als Delphi war der zugriff auf die forms (.Net Forms halt), ich habe es mit .net 3.5 getestet mit 4, mit c# und vb und bei 30000 tests war das ergebnis eindeutig: C# hat etwa 10-100 mal so lange gebraucht und vb etwa 10-1000 mal so lange die kompilierte sprache war in diesem fall delphi, und der delphi compiler ist nicht mal auf hohe rechengeschwindigkeit optimiert. natürlich sind 30000 tests wenig, aber allzuviel zeit hatte ich auch nicht dafür aufgewendet nein eben nicht vb ist aus einem mir unbekannten grund langsamer aber mein gedanke ist viel einfacher in vb xna zu verwenden ist viel weniger kompfortabel als in c#, in c# hat man das einfache Content system mit drag&drop, und vb macht alles nur mehr probleme (auch wenn es noch meilenweit kompfortabler ist als letztendlich OGL oder DX)

Hast du auch in allen fällen komplett optimierten code genommen?

Keine ahnung ob der code den msdn mir bietet auch optimiert ist, aber ich habe bewust nicht selbst geschrieben

Ausserdem andert sich am faktor ja nichts, da ich bei beiden programmiersprachen alles gleich gemacht habe

Wie gesagt, ich sage ja auch keinen festen faktor, sonndern einen faktoren bereich, der sehr gross ist

Quote:

Originally Posted by warfley Ausserdem andert sich am faktor ja nichts, da ich bei beiden programmiersprachen alles gleich gemacht habe

Und eine weitere Person die ich nicht mehr ernstnehmen muss, danke (:

darf ich fragen wiso? wenn ich in bei beiden sources zufällig eine schleife zu viel eingebaut habe dann ist es doch gleich viel mehr zu tuen->im faktor das selbe

[Only registered and activated users can see links. Click Here To Register...]
[Only registered and activated users can see links. Click Here To Register...]

Dein test hat übrigens noch ein paar weitere Schwachpunkte:
1. Dein Rechner läuft nicht immer exakt gleichschnell. Besser gesagt, irgendwas pfuscht dir bei Testumgebungen die du bereitstellen kannst immer dazwischen. Sei es irgendein updatecheck, ein gefundenes wlan netz, Mausbewegung oder auch Betriebssystem interne sachen, welche du nicht abstellen kannst.
2. Viel zu kleine Tests.
3. Wie du selbst schon gemerkt hast, gibt es bereiche wo C# 'schneller' ist. Davon wird es sicherlich noch mehrere geben.

Wie du vielleicht gemerkt hast, ist es nahezu unmöglich die Geschwindigkeit von 2 Sprachen zu vergleichen. Ich versuch dir mal näher zu bringen, was ich mit meiner Aussage vorhin meinte anhand eines Beispiels(welches keinen echten bezug zur realität dastellt, soll nur zur verdeutlichung dienen).
Nehmen wir irgendeine Funktion die in jeder gängigen Sprache vorhanden ist. Schauen wir uns diese Funktion nun auf Assembler ebene an(von jeder Sprache), wird diese nicht bei allen exakt gleich sein(auch compiler abhängig zum teil). Dadurch brauch Sprache A für Problem C möglicherweise länger als Sprache B, Sprache B ist allerdings bei Problem D schneller als Sprache A. Welche der beiden ist nun schneller? Ich hoffe du verstehst wodrauf ich hinauswill. Als Faktor würde ich eher 0.8-2.0 angeben, ohne dies auch nur im geringsten beweisen zu können. Ich habe auf diese Problematik auch schonmal einen meiner Professoren angesprochen und auch er wußte keine konkreten Zahlen(und ja, es war ein Professor aus dem entsprechendem Fachbereich :p ). Merkste was? Gescheite Zahlen dazu sind nahezu unmöglich :p

Ich verstehe was du meinst, und klar weiß ich das .Net sprachen in manchen dingen besser sind, und finde sie auch nicht so schlecht. nur wie gesagt, ich hatte mal eine reihe von tests aus langeweile gemacht, und da kam bei den doch sehr geringen testumfang ganz verscheidene werte raus, und mehr als 50% lagen etwa bei den von mir angegeben faktoren. womit das alles zu tun hat habe ich nicht weiter drüber nach gedacht. und soviel macht das auch nicht aus (am ende wartet man eh auf die graka... hab bei delphi ogl spielen die gleiche fps rate wie bei .net)