Re: [Widelands-public] Optimierungen

[<Si...@gm...>]

> > if (tp == texture->get_w())
> >    tp = 0;
> > ushort *texp = texture->get_pixels() + (y %
> > texture->get_h())*texture->get_w(); diese probleme koennen wir vermeiden,
> > indem wir die texturen auf eine bestimmte groesse bringen, entweder 32 oder
> > 64 pixel. Die modulus und die multiplikationen sind dann einfache binaere
> > unds bzw. bit shifts.
> 
> Stimmt. Ich wuerde eher 64 verwenden - dann wiederholt sich die Grafik nicht 
> ganz so oft.
> 
Ja, das findet meine zustimmung.

> 
> Das Hauptproblem mit bright_up_clr2 ist ja, das man sich gegen Over- bzw. 
> Underflows schuetzen muss, zusammen mit dem auseinander- und wieder 
> zusammenbauen der 16Bit-Werte. Gibt's nicht irgendwelche Assemblermagie, mit 
> der man das umgehen koennte?
ich denke nach. auf jeden fall schreibe ich die funktion jetzt mal in
assembler und schaus mir an. auch, wie der gcc die baut,wenn er sie
nicht inlined

> Ein Ansatz waere vielleicht MMX, wobei MMX nur bei 8 Bit pro Farbkanal 
> sinnvoll ist. Man koennte zumindest einmal ausprobieren, die Texturen als 24 
> Bit RGB zu speichern, mit MMX aufzuhellen/abzudunkeln und dann in 16 Bit zu 
> packen.
mmh... eine moeglichkeit. ich denke nur immer an S2. die haben das ja
auch hingekriegt, ohne MMX. allerdings sieht man bei denen auch deutlich
die abstufungen der pixelhelligkeiten. ich denke, dort funktioniert das
mit nem palettenindex switch (was eine addition waere). Ein bleistiel:
die texturen haben 16 effektive farben und ne palette von 256 farben.
Dann koennte man jede verwendetet farbe folgendermassen packen:
<hoehe-7><hoehe-6><hoehe-5>...<farbe><hoehe+1><hoehe+2>..<hoehe+7><hoehe+8>  --> naechste farbe
dann koennte man die hoehenunterschiede zum nachbar einfach zum
farbindex hinzuzaehlen. man muesste immer noch jeden pixel einzeln
behandeln, aber die aktion waere viel weniger kompliziert. Allerdings
wird es dann schwer, schoene texturen zu kreieren.

> Wenn man dann einen simpleren Algorithmus ueber LUT oder so hat sollte man 
> sich ueberlegen, das ganze per Assembler und Hand zu tunen, z.B. um immer 
> zwei Pixel gleichzeitig zu bearbeiten.
Ja, das auf jeden fall.

> 
> Uebrigens stimmen die Groessen der Felder und/oder der HEIGHT_FACTOR nicht. 
> In Siedler 2 gibt es keine ueberhaengenden Steigungen, d.h. jedes Dreieck ist 
> sichtbar. Auf eden.swd ist aber der Hang oberhalb des Vulkans so steil, dass 
> die Dreiecke verschwinden. Ich wuede entweder FIELD_HEIGHT auf 64 erhoehen 
> oder HEIGHT_FACTOR auf 5 verringern. Ansonsten kommt es auf Dauer zu 
> verwirrenden Artefakten.
ich hab da ewig rumgemacht und mit S2 verglichen. Ich denke, realistisch
ist HEIGHT_FACTOR auf 5 zu verringern.

cya 
Holger