Sinuskurve berechnen

Alles, was nicht direkt mit Python-Problemen zu tun hat. Dies ist auch der perfekte Platz für Jobangebote.
deets

es heisst blitten. blittern gibt's nicht. und ich wuerde mal sagen frag halt einfach, aber ich bin auch kein forumsregelkenner.
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

ok, ich frag mal ;)

meine Hauptroutine sieht so aus:

Code: Alles auswählen

if __name__ == '__main__':
	myLogo = Logo (WIDTH/2, 0, 1, "data/image.png")
	
	myStars = []
	for starfield in range ( 0, HEIGHT ):
		myStars.append (Stars (starfield, 255, 255, 255))
	
	pygame.init()
	screen = pygame.display.set_mode((WIDTH, HEIGHT),
                                     pygame.DOUBLEBUF
                                        | pygame.FULLSCREEN
                                        | pygame.HWSURFACE,
									 16)                     
	clock = pygame.time.Clock()               
	while True:
		for event in pygame.event.get():
			if (event.type == pygame.QUIT
				or (event.type == pygame.KEYDOWN
					and event.key == pygame.K_ESCAPE)):
                
					pygame.quit()
		screen.fill (BLACK)
		
		
		for starfield in range (0, HEIGHT):
			myStars [starfield].draw (screen)
			myStars [starfield].calc ()
		
		myLogo.calc ()
		myLogo.draw (screen)
		pygame.display.update()
		clock.tick(FPS)
Ich habe zwar den DoubleBuffer eingestellt, doch blitte ich immer gleich auf das HauptSurface. Und das scheint alles bischen zu ruckeln. Damals hatte ich mal unter Allegro nen Demo programmiert und nen TribleBuffer eingestellt, also zwischen 3 Surfaces geblittert. Allerdings war auch das echt ruckelig. Im Netz fand ich die Sache mit der Clock ( den ich auch hier verwende ), nur viel bringen tut das irgendwie nichts.
Würde nur mal gerne wissen, wie man das besser lösen kann?
BlackJack

@The Hit-Man: Ob `screen` wirklich direkt der angezeigte „Framebuffer” ist, kann selbst ohne DOUBLEBUF nicht garantiert werden, mit DOUBLEBUF ist es er das dann aber ganz sicher nicht. Dafür sorgt SDL schon.

Beim ruckeln ist die Frage wo das herkommt. Sind die FPS zu gross gewählt und der Code kommt manchmal nicht hinterher, oder ist der Puffer/Anzeigewechsel nicht synchron zum Bildaufbau? Oder beides? Und der gleiche Code kann auf einem anderen Rechner mit anderer Hardware, anderen Treibern, und einem anderen Monitor ganz anders aussehen. Und natürlich auch andersherum: Wenn es bei Dir perfekt aussieht, ruckelt es vielleicht bei jemand anderem. Die Zeiten das jeder den gleichen Videochip und einen Röhrenmonitor mit 50Hz hat und die Hardware es erlaubt sogar genauer als eine Rasterzeile synchronisiert etwas in die Videochip-Register zu schreiben, sind schon etwas länger vorbei.

Das war damals für mich schon eine herbe Enttäuschung als ich auf dem PC feststellen durfte, dass man bei VGA-Karten nur abfragen kann wann der Rasterstrahl nach dem Bildaufbau von unten wieder nach oben abgelenkt wird. Und das man sich darüber nicht mal per Interrupt informieren lassen kann, sondern tatsächlich in einer Schleife auf ein Bit in einem Register warten muss. Das war man vom C64 mehr Komfort gewohnt. :-)

Die Namensgebung ist teilweise übrigens irreführend. `starfield` heisst Sternenfeld und Du bindest da kein Sternenfeld dran, sondern einen Index. Der in der zweiten Schleife über die Sterne zudem noch unnötig ist, man kann *direkt* über die Elemente von `myStars` iterieren. Und eine Klasse die `Stars` heisst, aber nur *einen* Stern repräsentiert, ist auch komisch.
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

Die Namensgebung ist teilweise übrigens irreführend. `starfield` heisst Sternenfeld und Du bindest da kein Sternenfeld dran, sondern einen Index. Der in der zweiten Schleife über die Sterne zudem noch unnötig ist, man kann *direkt* über die Elemente von `myStars` iterieren. Und eine Klasse die `Stars` heisst, aber nur *einen* Stern repräsentiert, ist auch komisch.
Naja, ich arbeite ja noch dran ;) Ich verstehe schon was du meint, mit dem Rasterstrahl. Aber es muß doch eine Lösung geben, alles weich hin zu bekommen. Wenn ich mir WC3 unter meinem Wine anschaue, läuft das ja auch flüssig, auch wenn das Game schon echt alt ist. Wenn ein Rechner zu langsam ist um irgendetwas flüssig wieder zugeben, ist das natürlich verständlich. Allerdings auf dem Rechner, auf dem ich das Programmiere, ist mein GFX-Treiber ( Debian/Wheezy ) 1400MHz, 1,2GB RAM, 3D Beschleunig. Ein Freund sagte mir, er benutze OpenGL und dort hätte man einen V-Sync. Obwohl er sich im Moment mit dem gleichen Problem unter OpenGL rumschlägt. Es muß doch was transparentes geben, irgendwie. Irgenwelche Shooter und sonstige Sachen machen das doch auch?

Hatte mal selbstgemachte Demos auf der PS1 gesehen, die auch auf SDL aufsetzen ( gibts ja fast auf jedem System ) und dort ruckelte auch nichts.
BlackJack

WC3 ist jetzt Wing Commander oder Warcraft? Ist ja beides älter. :-) Rechnergeschwindigkeit, Grafikkarte, und RAM können noch so toll sein, wenn der Flaschenhals die Übertragung der Daten vom Rechner in die Grafikkarte ist, kann das trotzdem zu langsam sein. Hardwarebedingt. Irgendwelche Shooter und sonstige Sachen haben teilweise genau das gleiche Problem. Wenn Du mehr Kontrolle haben möchtest, zum Beispiel bei den Sachen die im Arbeitsspeicher passieren vs. was im Speicher der Grafikkarte passiert, musst Du auf den relativen Komfort von SDL verzichten und OpenGL verwenden.

Ein allgemeiner PC und SDL ist nicht mit einer PS1 und SDL vergleichbar, weil SDL auf dem PC mit allen möglichen Hardwarekombinationen klar kommen muss, und bei der PS1 ziemlich fix ist, auf welches Backend SDL zugeschnitten und optimiert werden kann. Was immer da drunter liegt *muss* VSYNC bieten, denn alles andere wäre bei einer Spielkonsole unsinnig.

Was für ein Ruckeln hast Du denn eigentlich? Tearing, also dass das Bild im Aufbau deutlich in zwei oder mehr horizontale Streifen geteilt ist, die nicht ganz zusammen passen? Oder stockt die ansonsten flüssige Animation manchmal einen Frame lang? Bei letzterem kann es an *vorhandenem* VSYNC liegen, nämlich dann wenn Deine gewünschte FPS nicht mit dem übereinstimmt was der Monitor an FPS vorgibt. Also das übliche Problem was man mit C64-Emulatoren hat, weil die wenn sie auf 100% laufen 50 FPS erzeugen, dass aber kaum ein Monitor als Refresh-Rate anbietet. Bei Röhrenmonitoren möchte man das ja auch gar nicht — da könnte man sich noch mit 100 Hz behelfen, wenn es der Monitor kann, aber bei LCDs besteht in der Regel ja nicht einmal die Möglichkeit etwas zu wählen. Da muss man nehmen was der Monitor bietet.
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

Was für ein Ruckeln hast Du denn eigentlich? Tearing, also dass das Bild im Aufbau deutlich in zwei oder mehr horizontale Streifen geteilt ist, die nicht ganz zusammen passen? Oder stockt die ansonsten flüssige Animation manchmal einen Frame lang?
Ich würde sagen beides. Du kannst hin und wieder leichte Verschiebungen am Logo sehen. Hin und wieder Stockt es mal kurz und du siehst die Festplatte auf leuchten ( was ich jetzt noch akzeptieren könnte. Kann ja immer mal was dazsichen kommen IRQ/DMA ).
OpenGL habe ich mich noch nie mit befaßt :( Wüßte nich mal ob damit 2D Anwendungen gemacht werden können *rot werd*
deets

OpenGL schmeisst Pixel auf den Bildschirm - ergo: klar kann man damit 2D machen. ZB ist PyGlet dafuer gedacht.

Tearing ist halt fehlende Sync, da muss man dann schauen, ob das mit OpenGL besser wird. Und wenn die Kiste richtig "haengt" bei Festplattenaktivitaet - da kann man nicht wirklich was machen (ausser das System irgendwie tunen, aber nicht programmatisch)
BlackJack

@The Hit-Man: Mit OpenGL kann man auch 2D-Anwendungen schreiben. SDL bietet OpenGL ja auch selber an.

Du könntest mit einem `pygame.display.Info` auch mal nachsehen was bei dem Video-Modus beschleunigt ist und was nicht.

Wichtig wäre auch, dass Du eine Pixeltiefe wählst, die für den Modus/Treiber am besten ist und dass Du alle Surfaces in diesem Modus erstellst oder sie dort hin umwandelst. Wenn das Logo-Surface zum Beispiel in einem anderen Format ist, kann das blitten auf das Display-Surface sehr wahrscheinlich nicht hardwarebeschleunigt erfolgen, weil es ja vorher erst in das passende Format umgewandelt werden muss. Und das für jedes blitten.
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

gibts da irgendwelche Beispiele?
deets

Wenn du OpenGL machen willst, solltest eher pyglet statt pygame nutzen.
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

pygame nutze ich ja gerade ...
deets

Ich weiß. Lies nochmal was ich geschrieben habe..,,
The Hit-Man
User
Beiträge: 435
Registriert: Montag 20. Februar 2006, 18:11
Wohnort: Menden / Sauerland
Kontaktdaten:

ups ... hast recht ( fußball ist doch dran ) ...
Antworten