[Sinti]

Potrzebuję klasy która będzie przechowywała Bitmapy. Czy muszę utworzyć obiekt tej klasy i go przekazywać każdej kolejnej klasie w której będę chciał skorzystać z bitmap, czy mogę to jakoś zrobić bez przekazywania obiektu tak jak mogę użyć metody statycznej bez obiektu klasy (idk robiąc poszczególne bitmapy statycznymi czy coś). No i jeśli drugi sposób jest możliwy to który jest lepszy?
#java #programowanie #pytanie #kiciochpyta

[63274682374]

@Sinti: Możesz. Pierwszy.

[Sinti]

@63274682374: Dzięki, jakby ci się chciało rozwinąć dlaczego pierwszy jest lepszy od drugiego to byłbym bardzo wdzięczny, chociaż już i tak jestem!

[MQs]

Potrzebuję klasy która będzie przechowywała Bitmapy.

@Sinti: Na razie tylko tak uważasz, ale załóżmy, że potrzebujesz.

Czy muszę utworzyć obiekt tej klasy i go przekazywać każdej kolejnej klasie w której będę chciał skorzystać z bitmap

Nie musisz, ale gdybyś chciał to kluczową kwestią jest ustalenie czy na danym poziomi abstrakcji rzeczywiście korzystasz z bitmap, bo bezpośrednia interakcja z bitmapą to dosyć niskopoziomowa warstwa. Tak jak baza danych, która schowana za kontekstowymi

[63274682374]

@Sinti: Bitmapa to "ciężki" obiekt. Domyślnie trzyma się to w plikach, ładuje w razie potrzeby do pamięci (o ile jest w ogóle w całości potrzebny), robi co trzeba robić i jak najszybciej wyrzuca. Umieszczenie tego jako pole statyczne powoduje, że będzie ten obiekt bardzo długo żył i zajmował pamięć.

[Sinti]

@MQs: Dzięki za odpowiedź, a ty który sposób byś wykorzystał jakbyś robił w miarę prostą grę? Powiedzmy ze ilość bitmap około 100.

[Saly]

@Sinti: pola statycznie są generalnie słabym pomysłem, bo psują reużywalność. Jeśli klasa ma normalne pole to możesz użyć jej w wielu kontekstach tj. dla różnych bitmap. W tym wypadku odpowiedzialność za wybór bitmapy spada na kod, który tworzy tą klasę (poprzez wepchanie bitmapy przez konstruktor lub setter). W modularnym designie tak właśnie robi się programy: małe, luźno powiązane klocki, z którym formowane są większe klocki.

[MQs]

@Sinti: Moja filozofia, jeśli chodzi o naukę, to robić najprostsze rzeczy w najpoprawniejszy sposób (taki taktyczny overengineering) tak, żeby przy robieniu trudniejszych się on już zasadniczo nie zmieniał. Jeśli celem jest jedynie skończony i ściśle określony projekt to nie ma sensu tracić czasu (co najwyżej się trochę od ścian poodbijasz i nauczysz czegoś w trakcie). Z drugiej strony sam sposób pozbywania się globalnych zależności warto ogarnąć, bo prędzej czy później cię

[PaaD]

@Sinti: Nawet jak będą pola to w rzeczywistości i tak będziesz przekazywać tylko referencję do bitmapy, która gdzieś tam sobie siedzi, więc to przepychanie statyków brzmi trochę jak przedwczesna optymalizacja (która niekoniecznie będzie trafna "globalnie") a może sporo utrudnić utrzymanie i rozwój kodu. Ergo, coś pomiędzy 1 a 2, bo obiekt bitmapy i tak już gdzieś będzie istnieć od momentu wczytania go do pamięci.

[Myzreal]

@Sinti: W miare prostych grach stosuje się atlasy tekstur, nie ładuje się każdego obrazka z osobna. W atlasie tekstur wszystkie "bitmapy" masz w jednym wielkim obrazie, ładujesz go całego do pamięci i potem tylko wyświetlasz jego odpowiednie fragmenty. To sprawia że nie wykonujesz mnóstwa kosztownych operacji przesyłania danych do GPU (przesyłasz tylko raz)

[Sinti]

@Myzreal: Jak mniemam chodzi o tzw "sprite" gdzie np masz wszystkie animacje danej postaci, czy o coś jeszcze innego?

[Myzreal]

@Sinti chodzi o to co napisałem: texture atlas