Themabewertung:
  • 0 Bewertung(en) - 0 im Durchschnitt
  • 1
  • 2
  • 3
  • 4
  • 5
0.99.14.1 - 1336: Fahrzeuge/Industrierauch/SlopeTrans
#1
Simutrans-Version: 0.99.14.1. - 1336 Win SDL

PAK-Set (+zusätzliche PAK-Dateien): pak.german

Betriebssystem: Win XP Pro


Fehler (möglichst genaue Beschreibung):

1.) Die Fahrzeuge hoppeln merklich.

2.) der Industrierauch ist nicht mehr da wo er sein soll. Bei der Normal-Perspektive ist er beim KKW gut 1/3 zu tief. Bei den anderen Perspektiven (Shift + R) ist er irgendwo nur nicht da wo er sein sollte.

3.) Die SlopeTrans-Übergänge haben grafische Störungen. Sehr deutlich zu sehen beim Übergang Wüste-Gemäßigt.

Verhalten (Absturz, Einfrieren, ...):
Zitieren
#2
Zitat:Original von FrankP
Simutrans-Version: 0.99.14.1. - 1336 Win SDL

PAK-Set (+zusätzliche PAK-Dateien): pak.german

Betriebssystem: Win XP Pro


Fehler (möglichst genaue Beschreibung):

1.) Die Fahrzeuge hoppeln merklich.

Prissi hat im englischen Forum - das jetzt gerade nicht zugänglich ist - unter Pak 192 dargestellt, dass die Fahrzeugbewegungen in größeren Darstellungen ruckeliger werden. Daher hat er versucht, für Pak 128 schon mal gleitendere Bewegungen hinzubekommen, was aber auf Kosten von Pak 64 gegangen sei.

In der Nightly 1331, in der sich seine Versuche erstmals niedergeschlagen haben, kamen die 128er-Fahrzeuge kaum noch über die halbe Spitzengeschwindigkeit hinweg, das ist in der 1336 aber behoben. Es scheint indes so, als wenn die Züge etwas mühsamer anfahren und der Rauch anfangs flackert. Aber die Bewegungen sehen unter Pak 128 jetzt wirklich deutlich flüssiger aus!

Bin gespannt, ob Prissi einen Kompromiss zwischen den Anforderungen für große und kleine Darstellungen findet, ob da irgendetwas mit simuconf-Optionen zu machen ist oder ob es zukünftig zwei Versionen gibt ...

EDIT: Auch für das 128-Set gibt es einen Nachteil: Wenn ich eine Stufe verkleinere, hoppeln die Fahrzeuge, was sie früher erst in der zweiten Stufe getan haben. Damit könnte ich allerdings gut leben.
Zitieren
#3
Zitat:Original von michelstadt
...
Bin gespannt, ob Prissi einen Kompromiss zwischen den Anforderungen für große und kleine Darstellungen findet, ob da irgendetwas mit simuconf-Optionen zu machen ist oder ob es zukünftig zwei Versionen gibt ...
...

Zwei Versionen gibs bestimmt nicht. Jetzt schon Blickt kaum einer noch durch, was soll dann bei 2 verschiedenen Programm-Versionen erst noch werden.
Gerade was Anfänger angeht. Keiner liest erst einen halben Roman und sucht sich dann alles zusammen. Windows-User sind jetzt schon von SDL und GDI verwirrt. Was soll werden wenns davon dann auch noch je 2 Versionen gibt.

Entweder eine Größenangabe irgendwo vorgeben oder die tatsächliche Größe ermitteln. Das Ermitteln der Größe sollte an Hand der Klima-Texturgrafiken möglich sein, da die ja in Vollfläche vorliegen.
Zitieren
#4
Simutrans sollte intern eine Variable haben die das aktuelle Tile-Raster speichert (also 64 oder 128 oder ...). Zumindest hatte es das in den Versionen die ich betreut habe.

Das Problem muss woanders liegen, die Raster-Größe ist bekannt.

PS:

Der kleinste Bewegungsvektor der funktioniert ist (2,1) ... wenn man den halbiert dann ergibt das (1, 0) da die Werte Integer sind, aber (1,0)+(1,0) != (2,1). Vielleicht ist das ein Grund für das seltsame verhalten?
Blogger blog blog
Zitieren
#5
Ich habe versucht, die Zahl der Schritte von 16 auf 32 pro Kachel zu erhöhen. Das führt aber bei kleineren Größen als pak128 zu Schritten in der Diagonale von 1,0/1,1 was zum ruckeln führt und deshalb so sicher nicht in die endgültige Version kommt. Daher rühren vermutlich auch die Störungen an Übergängen her, weil dort der Renderalgorithmus versagt.
Zitieren
#6
Ok, da hatten wir in der selben Minute die selbe Idee Big Grin

Ich hatte vor langer Zeit mal vor die Vektoren durch Bewegungstabellen abzulösen. D.h. statt deltas aufzusummieren für alle Schritte die x und y positionen in Tabellen zu hinterlegen, und dann die Werte aus Fahrtrichtung und Schritt mit der Tabelle zu ermitteln:

xoff = path.x[direction][step]
yoff = path.y[direction][step]
view = path.view[direction][step]

(View ist die Ansicht für das Fahrzeug, also eine der 8 Richtungen in der das Fahrzeug dargestallt werden kann.)

Damit könnte man sogar "rundere" Kurven fahren lassen da man jetzt nicht mehr von fixen Vektoren abhängig ist sondern Punkte zu jedem Step angeben kann.

Edit: Linksschreibung.
Blogger blog blog
Zitieren
#7
Warum nicht immer einen Schritt von 2:1 nehmen und die Anzahl aus der Kachelgröße ableiten?

Größe = Schritte
32 = 8
64 = 16
96 = 24
128 = 32
160 = 40
Zitieren
#8
Weil die Routinen dann alles ausgeben, mit variablen statt mit festen Werten arbeiten müssen. Da es sich um wirklich sehr viele Routinen handelt, würde ich das nach möglichkeit vermeiden wollen. Eventuell hilft es ja, in x-Richtung nur ein 2er Raster zuzulassen.
Zitieren
#9
Der Textur-Übergang (SlopeTrans) scheint in Rel. 1349 wieder in Ordnung zu sein.

Nur ist jetzt nach dem Laden auf der Startkarte vom pak.german alles weis. (23.März 1930) Allerdings nur die Bodentextur und Stadtstraßen.

Bei einem Spielstand vom pakHAJO wars beim Laden direkt nach dem Start auch so. Das Datum war mitten im Sommer.
Zitieren
#10
Die Schnee-Routine selber scheint etwas aus dem Takt zu sein.

Zumindest was das pakHajo (bits_per_month = 18 ) betrifft.
Da beginnt die Schnee-Ausbreitung bereits Ende August und hat Anfang Dezember die ganze Karte bedeckt.
Zitieren


Gehe zu:


Benutzer, die gerade dieses Thema anschauen: 3 Gast/Gäste