Dual Core & Co.

[Hajo]

Kommt darauf an was "sinnvoll" ist.

Performanter wäre es zweifellos. Ich habe das damals aber nicht gemacht, weil das nicht portabel genug erschien. Die rein Software-basierte Lösung war/ist klar langsamer, läuft aber mit fast jeder erdenklichen Grafik-Hardware.

OpenGL könnte eine Lösung sein, funktioniert aber auch nicht überall.

Es kommt darauf an was für Ziele man sich setzt. Portabilität war für mich wichtig, OpenGL wurde damals (1997) auf PCs nur wenig unterstützt, DirectX existierte gar nicht (erste nicht-Linux Simutrans Versionen waren für DOS, nicht Windows) und so wählte ich die Lösung, welche größte Portabilität mit erträglichem Aufwand für die Programmierung verband.

[hellmade]

hallo,

die Grafikkarte selbst als "Kopiersklaven" zu verwenden würde bei 3D-Systemen sicher was bringen. Wäre halt eine alternative Anzeige, weshalb man ja die Hauptprozessor-Gesteuerte Anzeige nicht ausbauen müsste.

Aber wenn SDL eh schon über einen Extrathread geht, dann bringt ein DualCore also schon etwas für simutrans *g*

prissi:

OK, wenn man tatsächlich die Breiten von Integers auf 64Bit schiebt, dann werden die Strukturen größer. Das müsste aber nicht unbedingt sein. OK, ist ein Heidenaufwand für alles Mögliche und unmögliche eigene Typen zu erzeugen und diese zusätzlich auch noch je nach Prozessorarchitektur umzubiegen. Ob sich das lohnt weiss ich auch nicht.

Was die 2048*2048'er karte betrifft, so fällt mir auf, dass es auf die Größe der Karte nicht so sehr ankommt, sondern mehr auf die "Bebauung". Ich lösche beispielsweise oft genug Wälder von meinen karten damit das Spiel schneller läuft *g*
Bei großen Städten sieht es ähnlich aus.

[Hajo]

Original von hellmade
die Grafikkarte selbst als "Kopiersklaven" zu verwenden würde bei 3D-Systemen sicher was bringen. Wäre halt eine alternative Anzeige, weshalb man ja die Hauptprozessor-Gesteuerte Anzeige nicht ausbauen müsste.

Ich habe letzte Woche versucht, für Sonnheim eine OpenGL basierte Anzeige zu bauen. Eie Ergebnisse waren mit modernen PCs/Grafikkarten recht ermutigend. Sonnheim ist allerdings Java, aber prinzipiell müsste es auch in Simutrans etwas bringen, die Grafikdaten hardwareunterstützt hin- und her zu kopieren.

Aber wenn SDL eh schon über einen Extrathread geht, dann bringt ein DualCore also schon etwas für simutrans *g*

Ein bischen. Zum anderen auch weil alle Windows Services und so auf dem jeweils anderen Core ausgeführt werden können, so dass ein Core ganz alleine für Simutrans da ist, und der andere das Grundrauschen abarbeitet. Mann müsste das mal messen wie sich die Last über zwei Cores verteilt.

OK, ist ein Heidenaufwand für alles Mögliche und unmögliche eigene Typen zu erzeugen und diese zusätzlich auch noch je nach Prozessorarchitektur umzubiegen.

Prinzipiell hat Simutrans solche Typen (uintX/sintX mit X in [8, 16, 32, 64]) aber es wurden an vielen Stellen auch einfach "int" verwendet wenn keine Not für eine bestimmte Variablengröße vorhanden war.

[Alexander Brose]

Original von hellmade
Was die 2048*2048'er karte betrifft, so fällt mir auf, dass es auf die Größe der Karte nicht so sehr ankommt, sondern mehr auf die "Bebauung". Ich lösche beispielsweise oft genug Wälder von meinen karten damit das Spiel schneller läuft *g*
Bei großen Städten sieht es ähnlich aus.

Bei großen Metropolen spielt natürlich der Verkehr eine Rolle. Eine Großstadt ohne Verkehr und Fußgänger läuft bei mir auch problemlos.
Bei Wäldern bin ich mir nicht so sicher. Absehen vom Jahreszeitenwechsel, der dann bei etwa 1.000.000 Bäumen doch etwas Rechenzeit in Anspruch nimmt.

Hoffentlich gibt es bald kein Simutrans in 3d. Also mit Polygonen.

[gpmfuchs]

@schnelle Hardwareberechnung, ich verwende dafür ClanLib.
Das basiert auf SDL. oder alternativ auf OpenGL. Sie haben ihre Engine recht hochoptimiert.
Aber ka ob das für Simutrans geeignet wäre, da meine Spiele nur wenig Drawoperationen haben.

[hellmade]

Hoffentlich gibt es bald kein Simutrans in 3d. Also mit Polygonen.

ich denke mal, Du meinst "eine" ???

ich weiss nicht, ob ein simutrans in Poligongrafik so viele Objekte haben könnte wie Spiele sie heute haben?

[prissi]

Die Strukturen mit 64Bit werden wegen dem "Alignment" aufgeblasen. Zur Zeit ist ein Koord3d 5 Bytes, dann kommt ein flag und ein 16Bit int. Zusammen 8 Byte.

Mit 64Bit macht der Compiler aber daraus 16 Byte, weil der die Struktur stur in einem 8 Byte record alingned. Und man kann dem Compiler nicht sagen, er soll alle Strukturen packen, weil sonst die Routinen aus der Standardbibliothek nicht mehr funktionieren (zumindest nicht mit dem GCC).

Schau dir z.B. planquadrat_t und grund_t und baum_t an, die sich bei einer 1x1 Millionen Karte 5 Millionen mal vorhanden.

Die Texturen in einer Grafikkarte zu packen und dort zu rendern ist sicher eine gute Idee. Allerdings ist die Dokumentation, schlecht (jedenfalls als ich das letzte mal nachsah). Und wie gesagt, es ist wenig protabel und eigentlich auch nicht das Problem. Das Kopieren geht fix, da dort fast keine Cache-misses auftreten und die jump-prediction fast immer richtig liegt. (Und außerdem ist es so fast einfacher, was Skalierung und transparenz angeht. Portabler ist es eh.)

[gpmfuchs]

btw. wenn wir schon über Geschwindigkeit reden wäre es möglich, das simutrans nicht alles frisst was an Rechenleistung da ist? (so als option)
mein laptop schmiert dann nämlich wegen zu grosser Hitze ab.
bei 1.0x geschwindigkeit scheint das zumindest ein bischen zu klappen, aber wenn man die Spielgeschwindigkeit reduziert erhöht sich die Rechenleistung.

@prissi existiert das alignment Problem tatsächlich?
bzw lässt es sich nicht dadurch umgehen das du erst den 16Bit int dann die Koord und dann das flag hast?

[Alexander Brose]

Original von hellmade
ich denke mal, Du meinst "eine" ???

Nein, ich meine ausdrücklich "kein".

[prissi]

Das "Alignment" macht jeder Compiler anders. Ich habe die Strukturen per try und error für 32 Bit optimiert. Jede Struktur muss by 32 Bit eine Länge von ((x+3)/4)*4 haben. Bei 64 Bit ist es ((x+7)/8 )*8, der Verschnitt ist unvermeidbar. Auch haben viele Pointer in den Strukturen nun 8 Byte statt 4 Byte, dass mach auch nochmal deutlich mehr. Irgendwo müssen die Extrabits am Ende untergebracht werden.

Und Simutrans ruf durchaus pause(10) auf. Es kommt darauf an, was SDL oder Windows daraus machen. Das bei anderen Multiplikatoeren andere Pausenverhältniss auftreten ist prinzipbedingt nicht zu lösen, da die Pause bei pause(2) MAXIMAL 2ms dauert, tatsächlich aber häufiger auch 0ms dauert.