latajacaryba Temat założony przez niniejszego użytkownika |
» 2017-08-16 21:40:45 To może być trudne do implementacji, ale mam lepszy pomysł. Tworzę klasę, która zawiera tylko Sprite'a oraz wskaźnik do Pola.
Tworze sobie obiekt klasy pole o nazwie trawa, daje mu teksturę, ID, itd. i mam niezbyt zasobożernym sposobem pola. |
|
michal11 |
» 2017-08-16 22:16:06 Milion intów to raptem ok. 4MB, dla Ramu to żaden problem, zapisywanie tego do pliku w zasadzie tez, ale jeżeli się okaże, że tak, to można to zoptymalizować tak jak jankowalski25 napisał. |
|
latajacaryba Temat założony przez niniejszego użytkownika |
» 2017-08-16 23:07:45 Dobra, ten problem rozwiązany :) To pozostaje tylko kwestia tego co posiałem w przedostatnim poście; Czy jeśli mam klasę Pole i dziedziczącą po polu klase "PoleNaKtorymRosnieTrawa", to aby wywołać metodę "RośnijTrawo()" :D to koniecznie muszę zdefiniować tą metodę (jako np. czysto wirtualną) w klasie podstawowej? Nie da się np. sprawdzić typu obiektu i wywołać metodę, czyli coś w tym stylu: if( TypObiektu == Pole )
{
}
else if( TypObiektu == PoleNaKtorymRosnieTrawa )
{
Obiekt.RosnijTrawo();
}
|
|
jankowalski25 |
» 2017-08-17 17:54:12 A może lepiej zrobić odwrotnie? Niech pole pobiera sobie wzrost trawy i rysuje to, co trzeba. To, co proponujesz spowoduje, że będziesz trzymał wiele danych wewnątrz pól, a ich celem nie jest przecież sterowanie logiką programu (wzrost trawy, poruszanie się graczy, i tak dalej), tylko przygotowanie grafiki do wyświetlenia. Pomyśl również o podziale na warstwy, czyli najpierw rysuj same pola, a dopiero później to, co się na nich znajduje. Zakładając, że masz widok z góry, to najpierw tworzysz pole bez trawy, później rysujesz trawę, a na końcu ewentualnie wstawiasz kosiarkę, która ma po tym jeździć. |
|
mokrowski |
» 2017-08-17 20:34:43 No to może prościej..
Odpowiedzialnością klasy TextureManager jest wczytanie tekstury na podstawie podanego klucza z klasy która tego zażąda i zwrócenie jej (czy wskaźnik czy referencja to zależy od potrzeb) żeby się obiekt o który ją prosi "się narysował tam gdzie chce".
Odpowiedzialnością klasy Grass (trawa) jest poprosić o teksturę (o której wie że ma klucz "trawa") i narysowanie jej na ekranie.
Jeśli trawa ma rosnąć to wie jakie klucze do jakich tekstur etapów rośnięcia ma i prosi o to TextureManager'a. Np. trawa1, trawa2, trawa3... Za tę animację odpowiedzialny jest Grass a nie TekstureManager.
Teraz jak rozwiążesz cały trawnik to zależy od Ciebie.
1. Jeśli zrobisz wiele obiektów Grass z których każdy będzie samodzielnie zajmował jakąś przestrzeń na ekranie, to będziesz miał wiele obiektów w pamięci (ale może jest to do zaakceptowania na tym etapie). Zaletą będzie przejście po nich i wywołanie update() tak aby obsługiwały animację i każdy kawałek trawy będzie "samodzielny".
2. Jeśli będziesz przekazywał do 1 obiektu Grass (który odpowiada za cały trawnik) żądanie "umieść się teraz na ekranie w 5 polu 3 rzędzie", to obiekt Grass (jeśli ma wykonywać rośnięcie trawy), powinien wiedzieć jaki jest stan wzrostu w danej przestrzeni czyli powinien trzymać gdzieś informacje jaka tekstura jest w danej przestrzeni w danym momencie.
3. Możesz także decydować się na wzorzec Flyweight który prosisz o zrobienie na żądanie obiektu Grass który opiekuje się daną przestrzenią. Normalnie go nie ma i jest kreowany dla danej przestrzeni dopiero na żądanie po ściągnięciu danych jak go zrobić z jakiegoś kontenera.
Wybieraj :-) Każde rozwiązanie ma wady i zalety. |
|
latajacaryba Temat założony przez niniejszego użytkownika |
» 2017-08-18 15:42:14 No dobra, może jakoś mi to wyjdzie. Jeśli ktoś grał kiedyś w Terrarie, to właśnie o taką trawę mi chodzi, bo właśnie uproszczoną wersję tej gry próbuje zrobić (bardzo uproszczoną ;) )
Co do pól to zrobiłem coś takiego jak klasa pole, która posiada ID, teksture itd, oraz klasę Frame, która posiada Sprite'a i wskaźnik na pole. Frame pobiera sobie wszystko co mu potrzebne, czyli teksturę itd.
Uwaga - w dalszej części posta pisząc "pole" mam na myśli nie wspomnianą klasę, a po prostu obiekt na mapie
To jeszcze ostatnie pytanie. Prócz pól będę miał struktury, takie jak np. pomnik, ale również takie z którymi można wejść w interakcję, czyli np. drzwi.
Jak mam sprawdzić, czy dane pole jest zwykłym polem, czy też strukturą, z którą można wejść w interakcję? Myślałem, by taka struktura dziedziczyła po klasie Pole (w końcu też można wejść z nią w kolizję, ma teksturę), ale oczywiście taka struktura posiada konkretne stany (otwarte/zamknięte drzwi, studnia pusta/pełna). Nie wiem jak sprawdzać, czy przed graczem jest studnia, kamień czy drzwi (otwarte/zamknięte). Może fajnym pomysłem byłaby metoda, która zwałaby się "bool CzyJestKolizyjna()" i zwracała true/false w zależności od struktury/bloku/stanu ? |
|
mokrowski |
» 2017-08-18 17:28:15 Polimorfizm.. łopatologicznie byś zrozumiał... #include <iostream>
#include <vector>
#include <string>
struct R {
virtual std::string info() const = 0;
virtual ~R() { }
};
struct X
: public R
{
std::string info() const override {
return "X";
}
};
struct Y
: public R
{
std::string info() const override {
return "Y";
}
};
int main() {
std::vector < R *> objects;
for( auto i = 0U; i < 3; ++i ) {
objects.push_back( new X() );
}
for( auto i = 0U; i < 5; ++i ) {
objects.push_back( new Y() );
}
for( auto & o: objects ) {
std::cout << "Is " << o->info() << " class\n";
}
for( auto & o: objects ) {
delete o;
}
}
Oczywiście docelowo nie powinno być "gołych new/delete". |
|
michal11 |
» 2017-08-18 18:50:47 Poczytaj sobie o systemie komponentów z ue4, być może takie podejście ci się spodoba i zrobisz jakąś uproszczoną implementację u siebie, bo twój problem brzmi właśnie jak byś potrzebował kilku komponentów które musisz dodać do swojej klasy (np. komponent kolizji do zrobienia interakcji). |
|
| 1 « 2 » 3 4 |