Strefa OMSI

Pełna wersja: Offset tekstur Kruger
Aktualnie przeglądasz uproszczoną wersję forum. Kliknij tutaj, by zobaczyć wersję z pełnym formatowaniem.
Dzień dobry:D

Ostatnio zacząłem prace nad HOFem dla Olsztyna, zawierającym wszystkie linie, przystanki i zapowiedzi... tak nudzi mi się. Nie miałem pojęcia jak zrobić polskie znaki, więc stwierdziłem że zrobię po prostu tekstury Kruger. Problem w tym, że mają one jakiś dziwny offset (patrz ss). Nie wiem czym jest to spowodowane i prosiłbym o pomoc, jeśli ktoś ma jakikolwiek pomysł co może być nie tak. Dodam iż jest to mój pierwszy projekt tego typu. Poza tym, offset jest tak mocny, że czasem nie można nawet odczytać numeru linii na tylnym (bądź w przypadku kartonów, bocznym) wyświetlaczu. Tak jest z N01 i N02, gdzie widać samo N0.

W logu nie ma żadnych errorów ani warnów.

Tak to wygląda na autobusach
[Obrazek: unknown.png]
[Obrazek: unknown.png]

Tutaj wyświetlacz boczny w SU12 III
[Obrazek: unknown.png]

A tukej pliki .bmp z ...Olsztyn\Kruger
[Obrazek: unknown.png]
[Obrazek: unknown.png]
[Obrazek: unknown.png]

No i ...Olsztyn\Kruger+
[Obrazek: unknown.png]
[Obrazek: unknown.png]
[Obrazek: unknown.png]


A tu screen z pliku .hof
[Obrazek: unknown.png]
Doszukiwałbym się winy w pojeździe. Wrzuciłem twoje bitmapy, zmniejszyłem je do 128x32 i odpaliłem na Mercedesie FL:

[Obrazek: BqPDtJM.png]
[Obrazek: cOd5H1z.png]
[Obrazek: IsMpppR.png]

Jak widać, wszystko działa, nie ma żadnych przesunięć. Niestety w kwestii Solarisa Urbino IV nie jestem w stanie pomóc, bo nie posiadam tego dodatku.
Problemy zauważyłem też w innych autobusach (np. Lubelski Mercedes i Solarisy z Polskiego packa). A więc to nie jest problem z pojazdem a samymi teksturami albo moją kopią gry... może coś źle zrobiłem z samymi teksturami. Robię je w paint.necie i zapisuję jako .bmp z głębokością koloru 32 bity. Jeżeli to nie w tym błąd to nie wiem w czym :/
Hmm... To może kwestia rozdzielczości. Z tego co wiem to Kruegery mają bitmapy o wymiarach 128x32, a Solarisy PL 128x64 (:?). Chociaż powinien być inny efekt złego wymiaru. Możesz jeszcze spróbować zapisać je w w zwykłym paincie. Spróbuj to wytestować na NL202 z podstawki, bo jest najbezpieczniej.
(27.09.2020 13:30)mati555 napisał(a): [ -> ]Z tego co wiem to Kruegery mają bitmapy o wymiarach 128x32, a Solarisy PL 128x64 (:?).

Kruegery mają rozdzielczość 128x32, a Kruegery+ 128x64. Jeśli grafika nie będzie o tej rozdzielczości, bitmapa może się wykrzaczyć. Zapisywać należy je jako pliki bitmap (bmp) 24-bitowe, by odpowiednio się wyświetlały.

Warto również dopilnować, by wszystkie czarne strefy były na pewno czarne najczarniejsze, a białe strefy białe najbielsze. Ty je rozciągnąłeś dziewięciokrotnie, co jest błędem krytycznym przy robieniu bitmap. Należy operować na grafice o jednym z podanych wyżej wymiarów, w zależności od typu wyświetlacza (wtedy jeden piksel na grafice to jeden piksel na wyświetlaczu). Możliwe, że również po takim rozciągnięciu źle je skalujesz do odpowiednich wymiarów (przy użyciu niepoprawnych ustawień), co powoduje artefakty widoczne na screenach.
(27.09.2020 13:39)KMSzczecin napisał(a): [ -> ]Możliwe, że również po takim rozciągnięciu źle je skalujesz do odpowiednich wymiarów (przy użyciu niepoprawnych ustawień), co powoduje artefakty widoczne na screenach.

Jak coś, rozciągnięte są tylko po to, aby wrzucić je tutaj... wsm nie wiem po co. Robię je w dobrych wymiarach. Popróbuję jeszcze i dam znać.

Problem rozwiązany!:D

A więc problemem było to, że zapisywałem .bmp 32-bitowe zamiast 24-bitowych... taka pierdoła a jak widać ma znaczenie. Teraz już nie ma żadnego offsetu, zostaje więc nadpisać każdy plik jako 24-bitowy i będzie można bawić się dalej:)
Przekierowanie