Du bist nicht angemeldet.

Stilllegung des Forums
Das Forum wurde am 05.06.2023 nach über 20 Jahren stillgelegt (weitere Informationen und ein kleiner Rückblick).
Registrierungen, Anmeldungen und Postings sind nicht mehr möglich. Öffentliche Inhalte sind weiterhin zugänglich.
Das Team von spieleprogrammierer.de bedankt sich bei der Community für die vielen schönen Jahre.
Wenn du eine deutschsprachige Spieleentwickler-Community suchst, schau doch mal im Discord und auf ZFX vorbei!

Werbeanzeige

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

21

11.08.2009, 13:29

Zitat von »"PCShadow"«

Zitat von »"Das Gurke"«

@ PCShadow: Das klingt jetzt doof ... Hast du das Programm schonmal direkt nach diesem Absturz wieder gestartet? Ich hatte auch schon einen Rechner der sich beim ersten Start geweigert hat und dann plötzlich fehlerfrei lief.

volltreffer! jetz hab ich ca. 60FPS


Komisch ich hatte nachdems zwei oder dreimal gegangen is auch das selbe Problem. Nach Neustart gehts jetzt aber scheinbar immer...

@PCShadow: 60FPS mit oder ohne VSync? :p

22

11.08.2009, 13:31

Zitat von »"dot"«

@PCShadow: 60FPS mit oder ohne VSync? :p

mit - ohne sinds um die 100FPS

dot

Supermoderator

Beiträge: 9 757

Wohnort: Graz

  • Private Nachricht senden

23

11.08.2009, 14:13

Zitat von »"Das Gurke"«

Danke für den Hinweis, ich hatte das bisher schlichtweg nicht bedacht. Aber deswegen ist es ja auch mal ganz gut seine Programme zum Testen rauszugeben. Und ich dachte, dank .Net müsste ich mir da weniger Sorgen machen -_-


Hehe, ich hab mich selber lange genug mit exakt diesem Problem herumgeschlagen (kleiner Nebenjob -> C#, Managed DirectX -> ich Vista64 -> *kabumm* -> *kopfkratz*)...

Dank .Net musst du dir jedenfalls um sowas normal auch keine Sorgen machen. Wenn du ein .Net Programm auf Vista64 startest dann wird es im Normalfall auch ganz normal laufen, da die CLR es ja wie ein natives Programm ausführen wird und dich die zugrunde liegende Platform nicht zu kümmern braucht. Unter Vista32 wird es als 32bit und unter Vista64 als 64bit Programm laufen ("Any CPU" halt...).

Vista64 kann jetzt aber natürlich sowohl 32bit als auch 64bit Code ausführen, wunderbare Sache das, hat aber eine Einschränkung: Ein Prozess kann nur entweder 32bit oder 64bit sein. Ein 32bit Prozess kann nur 32bit Module laden und ein 64bit Prozess nur 64bit Module.
D.h. du kannst keine 32bit dlls in 64bit Prozesse laden und umgekehrt (irgendwie auch logisch. Das is übrigens auch der Grund warum es in Vista64 unter System32 diesen ominösen WOW64 Ordner gibt. In System32 sind die normalen System dlls drin (also die 64bit dlls) und in WOW64 (=Windows on Windows64) die 32bit Varianten die benötigt werden um 32bit Programme ausführen zu können).

Wenn du jetzt nun irgendwelche Abhängigkeiten hast wie z.B. deine dlls die als 32bit Module gekennzeichnet sind (vermutlich weil es Wrapper für irgendwelche nativen 32bit dlls sind) hast du ein Problem: Die CLR startet dein Programm als 64bit Prozess und dann willst du deine 32bit Abhängigkeiten reinladen. Einfachste Lösung wie gesagt: Im Header der exe (durch entsprechende Compilereinstellung, corflags sollte man dem normalen User wohl nicht zumuten ;) ) das 32bit Flag setzen das der CLR sagt dass sie, was auch immer passiert, das Teil als 32bit Prozess starten soll und dann laufts sowohl unter Win32 als auch unter Win64 (allerdings natürlich nur als 32bit Prozess. Wenn echte 64bit willst brauchst du deine dlls da als 64bit).
Wie gesagt brauchst du dir normal keine Sorgen machen, du hast nur grad das Pech dass dein Programm (dank seiner Abhängigkeiten) nicht normal ist ;)

FalkT

Treue Seele

Beiträge: 125

Wohnort: AC

  • Private Nachricht senden

24

11.08.2009, 17:03

Re: [Perfomancetest] GX.Tile - Spiele Framework für .Net

Zuerst Benchmark :

AMD Phenom II X4 @ 3.6 Ghz
Ati 3870
XP - SP3
Auflösung: 1920x1200
FPS: Konstant 255/256 (immer/überall, auch bei anderen Auflösungen)

Zitat von »"Das Gurke"«

Hallo Community!

Ich arbeite gerade an einem Spiele Framework für .Net, dass ich euch später nochmal vorstellen möchte. Momentan plagen mich aber vorallem relativ bizarre Performance Probleme. Mir ist bewusst, dass allgemein noch viel Raum für Optimierungen ist, aber auf einigen System sackt die Framerate unter 1 FPS. Da hilft dann auch keine Optimierung.



Ich würde spontan auf OpenGL 2.0 tippen.
D.h. die getesteten GrafikKarten mit wenig Performance können kein hardware-unterstütztes OpenGL 2.0, sondern nur per Software-Emulation.

Zumindest bei Pixelshader 1.0 -> Emulation auf 3.0 gabs identische Performance-Einbrüche.

25

11.08.2009, 17:15

350 fps

800x600 Fenstermodus

Windows Vista Home Premium 32bit SP2

Core2Quad Q8200
3.2GB Ram
Geforce 9500 GS

26

11.08.2009, 19:49

ich hab konstant 59 fps bei 1680*1050 mit und ohne rtt workaround

mein system:

Windows XP pro 32bit sp3
88er gts 320 mb
4 gig ram bzw 3 gig wegen 32 bit
am2 athlon 64 5200+ x2 @ ~2900 mhz

kiba

Alter Hase

Beiträge: 327

Wohnort: NRW

Beruf: Azubi: Fach-Info. Anw.

  • Private Nachricht senden

27

11.08.2009, 23:23

250 fps ,1280x1024 window modus

winxp 32 sp3

cpu: intel dou core 2.33 ghz
grafik: asus eah 3870
2gb ram

Wie groß is überhaupt ein Tile und die Groß ist die Map und wie viele Ebenen

Das Gurke

Community-Fossil

  • »Das Gurke« ist der Autor dieses Themas

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

28

12.08.2009, 09:56

Zitat von »"kiba"«

Wie groß is überhaupt ein Tile und die Groß ist die Map und wie viele Ebenen
Im Testprojekt hat ein Gebiets Tile 32x32 Pixel, das ist aber variabel. Die Größe der "Hauptmap" ist 35 * 30, wenn man über den Teleporter die "Miniwelt" betreten hat ist die 10 * 10 groß. Ebenen sind 7 vorgegeben, aber theoretisch beliebig viele im Integer Bereich möglich.

Zitat von »"FalkT"«

Ich würde spontan auf OpenGL 2.0 tippen.
D.h. die getesteten GrafikKarten mit wenig Performance können kein hardware-unterstütztes OpenGL 2.0, sondern nur per Software-Emulation.
Natürlich! *Facepalm* Na denn werd ich wohl mal schauen, wie ich ohne Frame Buffer auskomme.

Und nochmal Danke an alle für die Zahlen! Ich bin jetzt definitv schlauer als vorher.

TrommlBomml

Community-Fossil

Beiträge: 2 117

Wohnort: Berlin

Beruf: Software-Entwickler

  • Private Nachricht senden

29

12.08.2009, 10:26

aufn arbeitsrechner getestet:

fps: ~260

Intel Core 2 Duo E6850 1.97ghz @3ghz (32-bit)
2gb ram
ati radeon hd 2400

Das Gurke

Community-Fossil

  • »Das Gurke« ist der Autor dieses Themas

Beiträge: 1 996

Wohnort: Pinneberg

Beruf: Schüler

  • Private Nachricht senden

30

12.08.2009, 17:31

So, wie versprochen ein kleineres Update. Ich mach mal nen Pseudo Changelog:

- Das "Perfomanceproblem ansich" hab ich behoben. Es lag tatsächlich an der OpenGL 2.1 Emulation. Tausend Dank an FalkT!
- Auch auf X64 Systemen sollte das Programm nun ohne weiteres laufen. Danke an Dot für die ausführliche Beschreibung!
- Die Perfomance sollte allgemein besser geworden sein, hab jetzt zwei einfach zu behebende Bottlenecks mal etwas breiter gemacht.
- Der Spieler verfällt nun auch korrekt in die "Stand" Animation, wenn man sich nicht bewegt und kann nicht mehr aus der Welt hinauslaufen.

Diese neue Version gibts hier: http://tiles.redmine.fkrauthan.de/attachments/download/45/GX.Tile.App.r222.zip

Bei dieser zweiten Version braucht ihr mir keine FPS Statements mehr liefern, wenn das Programm schon vorher bei euch super lief. Ich würde mich jedoch freuen, wenn speziell die Leute bei denen das Ganze ohne RTT Workaround extrem lahm lief (zumindest bei Drakon war das ja der Fall) sich nochmal melden würden ob es jetzt besser ist. Und Leute mit 64 Bit OS würde ich auch bitten einmal zu schauen ob sie nun problemlos starten können, ich hab leider kein 64 Bit Windows in meiner Reichweite.

Werbeanzeige