Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - Lerhes

Strony: [1] 2 3 4 5 ... 25
1
Projekty zaawansowane / Odp: [Libgdx] TAnima - MMO Rogue-like
« dnia: Czerwiec 01, 2018, 01:04:03 »
Cześć,

Ja jestem bardzo na tak - chętnie poczytam / dowiem się co to za podejście.

Trochę czytałem o DDD i te tematy zdecydowanie mnie ciekawią :)

Trzymam kciuki za projekt i za powstanie artykułu ! :)

Pozdrawiam,
Lerhes

2
Szkółka / Odp: [C++]Problem z string i nowym Visual Studio
« dnia: Luty 10, 2018, 17:47:31 »
Cześć MofC,

Hehe, zerowanie tablicy struktur jeszcze nie jest takie złe - ale biorąc pod uwagę co masz w tej strukturze (OBIEKT klasy std::string) to nie był najlepszy pomysł. Tym zerowaniem "popsułeś" wewnętrzny stan std::string. Aż dziwne, że Ci się nie wywalało wcześniej (vs2015). W każdym razie - dobrze, że udało się rozwiązać problem.

Pozdrawiam,
Lerhes

3
Szkółka / Odp: [C++]Problem z string i nowym Visual Studio
« dnia: Luty 10, 2018, 01:23:25 »
Cześć MofC,

Ciekawy przypadek tutaj masz. Jakoś nic oczywistego mi nie przychodzi do głowy co mogło  by wyjaśnić twoje wyniki.

Na razie mam dwa strzały: Wielowątkowość oraz błąd debugera.

Aby wykluczyć błąd debugera: Rozumiem, że gra przestała Ci działać na VS2017 i to właśnie przez to, że IDname ma niepoprawnie skopiowanego stringa? Pytam, bo już widziałem przypadek w którym debuger pokazywał nieprawdziwe informacje o stanie zmienych. Albo najlepiej dodaj przed "SDL_Delay(0);" kod:
std::cout << GraphContainer[i].IDname << std::endl;
Aby wykluczyć błąd z wielowątkowością, na wszelki wypadek spróbuj użyć takiego kodu w funkcji LoadGraph:
static SDL_mutex *mutex = 0;

if (mutex == 0)
{
mutex = SDL_CreateMutex();
if (!mutex) {
  fprintf(stderr, "Couldn't create mutex\n");
  return;
}
}

if (SDL_LockMutex(mutex) == 0) {


//Tutaj skopiuj kod z obecnej wersji metody LoadGraph.


  SDL_UnlockMutex(mutex);
} else {
  fprintf(stderr, "Couldn't lock mutex\n");
}



Pozdrawiam,
Lerhes

4
Szkółka / Odp: [C++]Problem z string i nowym Visual Studio
« dnia: Luty 09, 2018, 14:31:11 »
Cześć MofC,

Mógłbyś podać trochę więcej informacji ?

Może jestem niedowiarkiem, ale mógłbyś pokazać dokładnie jak zadeklarowane jest pole: IDname ?

Cytuj
Po operacji ilość znaków w ciągu IDname jest taka sama jak name ale znaki są od razu całkiem inne.
Możesz sprecyzować co to znaczy, że znaki są całkiem inne? Podaj jakiś przykład jak na przykład mój poniższy:
name jest: "To String"
po przepisaniu w IDname jest: "Je Jablko"
To jest coś w tym rodzaju? Czy może chodzi tylko o Polskie znaki? Jak sprawdzasz, że znaki są całkiem inne? Wypisujesz je? Czy to już w debugerze widać? Co konkretnie widać? Możesz zrobić screen z Visual Studio (w trybie debug) na którym widać zawartość IDname po przepisaniu?

Pozdrawiam,
Lerhes

5
SDL / Odp: DestroyRenderer problem z użyciem
« dnia: Styczeń 20, 2018, 01:30:19 »
Cześć Mentaris,

"Okazało się że używałem delete na wskaźniku który nie stworzyłem operacją new."
Ok, to na pewno był błąd i dobrze, że to poprawiłeś. Jeżeli to na co pokazywał wskaźnik to obiekt utworzony na stosie - to zdecydowanie było to coś co trzeba naprawić.

"Poduczyłem się o wskaźnikach i zmodyfikowałem wszystko po kolei. "
Martwi mnie co to znaczy.. mam nadzieję, że nie przesadziłeś.

"Jeśli chodzi o te inicjalizowanie wskaźników. To jakoś tak średnio wiem jak to zrobić. Jest funkcja która pobiera wszystkie wskaźniki, ona jest uruchamiana tuż po stworzeniu obiektu. To nie wystarczy?"
Nie do końca rozumiem o czym tutaj piszesz. Zgadzam się z tym, że wskaźniki trzeba inicjalizować przed użyciem. O co chodzi z funkcją która pobiera wszystkie wskaźniki ? Wiem, że dałeś link do kodu ale mógłbyś skopiować dokładnie fragment który nie działa / którego nie rozumiesz ?


"Żeby inicjalizować wskaźnik, trzeba mieć albo zmienną pod którą się podebnie albo tworzyć miejsce w pamięci za pomocą new. "
Ok, to jest napisane plus / minus poprawnie.

"To znaczy by wszystkie wskaźniki tworzyć za pomocą new, przepisywać im wartość zerową, a potem w destruktorach usuwać je i nadawać im nullptr?"
Rozumiem, że mówimy o wskaźnikach które są "polami" klasy ? W tym przypadku tak, należy je utworzyć za pomocą new (najczęściej tego właśnie chcemy ale są też inne przypadki). Nie "przepisujemy" (albo raczej przypisujemy) im wartości zerowej tuż po utworzeniu operatorem new, bo wtedy nie będą pokazywały na nic sensownego i w przypadku gdy ich użyjesz wyskoczy błąd: "Access violation". Znowu najlepiej gdybyś podał przykład (nie cały kod) w którym zobrazujesz problem.
W destruktorze warto usunąć to na co pokazują wskaźniki (żeby nie było wycieku pamięci) i przypisać im nullptr - co będzie też oznaczać, że już na nic sensownego nie pokazują. (Ktoś może Ci zarzucić, że to nie ma sensu bo i tak skoro destruktor właśnie się wykonuje, to i tak obiekt przestaje istnieć - nie ma co "tracić czasu" na przypisywanie nullptr do wskaźnika - ale to taka uwaga na boku).

Napiszę inaczej, z perspektywy twojego projektu: porozmawiajmy o klasie "Game" w pliku "GameLoop.h".
Klasa Game ma pole: "target_texture" którego typ to: "wskaźnik do SDL_Texture".
Widzę, że w destruktorze: "Game::~Game()" usuwasz to na co pokazuje ten wskaźnik przy pomocy metody z SDL: "SDL_DestroyTexture(target_texture);". To znaczy, że było by dobrze ustawić ten wskaźnik na jakiś obiekt typu "SDL_Texture" w przeciwnym razie funkcja "SDL_DestroyTexture" może zadziałać niepoprawnie. Przypuszczam, że programiści SDL sprawdzili przed zniszczeniem tego na co pokazuje wskaźnik "target_texture" czy "target_texture" nie jest null ale niestety w twoim przypadku im to nie pomoże. Dlaczego? Zaraz o tym porozmawiamy. Jeszcze jedna uwaga: Było by dobrze trzymać się zasady: Gdy wskaźnik "pokazuje" na coś sensowego to jego wartość je inna niż null. Jeżeli nie pokazuje na żaden obiekt (lub pokazywał, ale ten obiekt usunęliśmy) to przypisujemy pod każdy wskaźnik nullptr. Gdybyś tej zasady się trzymał i obawiał się że programiści SDL nie są ostrożni, mógłbyś napisać taki kod:
if(target_texture) { SDL_DestroyTexture(target_texture); target_texture = nullptr;}
Wtedy sam sprawdzasz czy na pewno wskaźnik pokazuje na coś sensownego zanim każesz zadziałać funkcji SDL_DestroyTexture.

Dlaczego piszę "Było by dobrze" oraz "Gdybyś"? Bo ty tej zasady nie przestrzegasz. Aby to poprawić powinieneś w konstruktorze Game::Game wpisać nullptr do target_texture o tak: target_texture = nullptr; I tak dla każdego innego wskaźnika! W przeciwnym razie,  target_texture będzie pokazywał na coś losowego.
Jeżeli chcesz powiedzieć, że i tak ustawiasz ten wskaźnik w funkcji: "int Game::startLoop(SDL_Window* window)" - ok zgadzam się. O ile funkcja ta zostanie wywołana jako pierwsza przed funkcją "void Game::render()" gdzie używasz target_texture. W twojej aplikacji tak właśnie jest - ale zasady to zasady.

Przestrzegając powyższej zasady możesz uniknąć innych pułapek. Co by było gdyby ktoś wywołał "startLoop" przez przypadek dwa razy? W twojej obecnej implementacji na razie nic bardzo złego - wyciek pamięci. Ale można by temu zapobiec:
if (target_texture )  { WypiszBlad("Ponownie tworzysz teksture, to jest jakis blad!"); } else { RenderTarget = SDL_CreateRenderer(window, -1, SDL_RENDERER_ACCELERATED | SDL_RENDERER_TARGETTEXTURE); }

Jeżeli chcesz napisać: "Ale ja tak nie zrobię! Jestem ostrożny!" To się możesz bardzo szybko przekonać, że takie rzeczy się każdemu zdarzają - pytanie czy potrafimy to wykryć i szybko naprawić czy szukamy błędu przez tydzień.

Poza tymi ogólnymi uwagami, używasz "target_texture" w miarę poprawnie. Pytanie czy wszystkie wskaźniki tak są używane? To praca dla Ciebie!

Jeżeli wiesz dokładnie z którym wskaźnikiem jest problem (w której klasie) to napisz i zobaczę jak jest używany / inicjalizowany.

Pozdrawiam,
Lerhes

6
SDL / Odp: DestroyRenderer problem z użyciem
« dnia: Styczeń 11, 2018, 13:47:22 »
Cześć Mentaris,

Tak w Visualu jest dostępny debugger.
Jeżeli problem pojawia się w trybie "Release" to po prostu zrób debugowanie w trybie Release.
Ostrzeżenie: W trybie Debug jeden krok przenosi Cię najczęściej do kolejnej instrukcji. W trybie Release (z powodu optymalizacji) jeden krok może Cię przenieść parę linii do przodu, a czasami nawet do tyłu!
Spróbuj i daj znać czy udało Ci się rozwiązać problem.

Pozdrawiam,
Lerhes

7
Warsztat Summer of Code 2017 / Odp: Warsztat Summer of Code 2017
« dnia: Październik 08, 2017, 21:00:33 »
Wielkie gratulacje dla wszystkich którzy wzięli udział w konkursie. Gratuluję osobom którym udało się ukończyć prace jak i tym którzy walczyli do ostatniej chwili.

Pozwoliłem sobie napisać dwa zdania o zgłoszonych tytułach (nie głosuję bo nie mam do tego prawa):
RoboP - Boski - niestety pułapki są jak dla mnie za trudne - a ponieważ każde zderzenie sprawia że postać na chwilę się zatrzymuje, bardzo często kończy się to śmiercią, bo nie da się "wyjść" z perma stuna. Szkoda bo wystarczyło po prostu zabierać życie i gra mogłaby być naprawdę fajna.
kkazmier - pong - fajnie się grało. Jak na mój gust lepiej by było gdyby więcej kulek pojawiało się do odbijania. Było też parę gliczy - jak na przykład uciekające "z tuby" kulki. Jak na pierwszą grę w Unity - jest OK.
Beem - Pivotris - brak DLL uniemożliwia odpalenie gry.
Lorek - Coloris - bardzo ładna oprawa graficzna i porządnie przetestowana - za to duży plus. Gameplay trochę nudny - może szybsze poruszanie węża by pomogło? (zapewne na komórce gra się lepiej(?)).
Wezu - Flipper - Fajna grafika i projekt maszyn. Zamiast punktów za rzucanie, wolałbym niszczenie jakichś przeszkód - ale i tak grało się spoko. Trochę toporne przerzucanie "rzeczy" z platformy ala Answer.com do katapulty.
Cremmy - tragedia - i to w trzech aktach. A tak poważnie - bardzo mi się gra podobała. Ciekawa grafika i fabuła. Jak dla mnie najlepsza gra.

Pozdrawiam,
Lerhes



8
Grafika 2D / Odp: One-Man Gamedev! Rozwijajmy się razem!
« dnia: Luty 25, 2017, 02:57:15 »
Cześć Filip,

Trzymam za ciebie kciuki! (Zgaduję: Trzydziestka to idealny moment, żeby w końcu zrobić to co zawsze chciałeś).

Zgadzam się z tym co powiedział Joker. Na twoim miejscu skupiłbym się na kodzie a grafikę załatwiłbym w inny sposób. O na ten przykład możesz tworzyć gry razem z dziewczyną/żoną - ona grafikę a ty kod. Piękny tandem :) Niemożliwe? O! Nic bardziej mylnego! Na warsztacie mamy właśnie takie rodzynki:
http://warsztat.gd/user/Isabell

<Prywata>: Izabela i (chyba) Jakub- śledzę wasze projekty i trzymam za was kciuki. </Prywata>

Nawet jak chcesz był One-man-army - spoko :) Trzymam kciuki tym bardziej.
Będziesz też tworzył grafikę 3G, czy skupiasz się na grach 2D?

Pozdrawiam,
Lerhes

9
OpenGL / Odp: Plik nagłówkowy glut.h
« dnia: Luty 24, 2017, 23:11:47 »
Cześć,

Daj linka do tego "przykładu".

Na tej stronie:
https://www.opengl.org/resources/libraries/glut/spec3/node113.html
widzę, że funkcje:
glutReshapeFunc
glutKeyboardFunc

znajdują się w spisie, natomiast brak tam funkcji:
glutInitDisplayFunc

Natomiast jest inna:
glutDisplayFunc

Może o tę chodziło?

Pozdrawiam,
Lerhes

10
Ślepy strzał: Pacman?

11
Nie chce mi się ustawiać SMFL, żeby potwierdzić gdzie i dlaczego jest problem. Dlatego trochę zgadując, spróbuj dodać na początek pliku:
#include <ContextSettings.hpp>
I daj znać co z tego wyszło.

Pozdrawiam,
Lerhes

12
Cześć,

Daj linka do tego przykładu i powiedz na której konkretnie linijce się wysypuje to pomożemy.

Żeby post miał jakąś wartość dodatnią (edukacyjną): błąd który podałeś występuje na etapie kompilacji, nie linkowania.

Pozdrawiam,
Lerhes

13
Projektowanie kodu / Odp: kompozycja, agregacja ich odpowiednik w c++
« dnia: Styczeń 15, 2017, 22:21:05 »
Cześć,

Odpowiem jak ja rozumiem te pojęcia - mam nadzieję, że niczego nie pomieszam.
Żeby od czegoś zacząć, to zacznijmy od opisu na:
https://pl.wikipedia.org/wiki/Agregacja_(programowanie_obiektowe)

Dla mnie agregacja, to zawieranie. Czyli jedna klasa zawiera inną. Np:
class Okladka{
string tytul;
string autor;
bool czyGruba;
Color kolorOkladki;
void spal() {}
};

class Ksiązka {
Okladka okladka;
int liczbaStron;
};

W przypadku powyżej, z agregacją mamy do czynienia w klasie Okladka i w klasie Ksiazka. Klasa Okladka agreguje (zawiera) dwa obiekty klasy string i jeden obiekt klasy Color . Można powiedzieć także, (parafrazując Wikipedię) że klasa Okladka składa się z obiektów string i Color.
Podobna sytuacja jest z klasą Ksiazka - zawiera ona klasę Okladka (czyli mamy agregację).

Dodane: Na marginesie: Czy relacja która występuję między Ksiazka a Okladka to mogła by być kompozycja (specjalny przypadek agregacji) - oczywiście że tak. To zależy czy dopuszczamy możliwość tworzenia obiektów okładka bez obiektu książka.... -> proszę czytać dalej.

Teraz jeżeli chodzi o kompozycję - to jest to agregacja ale obiekty agregowane nie mogą istnieć bez obiektu głównego. Przykładów można wymyślić dużo - jak dla mnie tutaj bardziej zależy od kontekstu.
Np:
class KanalTelewizyjny
{
string nazwa;
};
class Telewizor{
vector<KanalTelewizyjny> kanaly;
};

W tym przypadku mamy do czynienia z agregacją ale i kompozycją. Klasa KanalTelewizyjny jest stworzona z obiektu klasy string - agregacja. Klasa Telewizor zawiera wiele obiektów klasy KanalTelewizyjny - agregacja. Natomiast ta druga agregacja jest też kompozycją - Telewizor posiada obiekty klasy KanalTelewizyjny - ale obiekty KanalTelewizyjny  nie mogą istnieć poza klasą Telewizor.

Tutaj ważna jest sprawa twojego konkretnego przypadku. Jeżeli obiekty klasy KanalTelewizyjny mogą być tylko agregowane przez klasę Telewizor - a bez niej nie ma sensu tworzyć obiektów klasy KanalTelewizyjny   - wtedy mamy kompozycję. Gdyby w twojej aplikacji miało to sens - wtedy miałbyś zwykłą agregację - nie kompozycję.
Jak dla mnie to trzeba najbardziej podkreślić - agregacja, kompozycja i inne relacje - służą do określenia właśnie relacji między obiektami - jeżeli projektujesz swoją aplikację i chcesz zaznaczyć, że jedna klasa zawiera inną klasę - rysujesz pusty romb - wszyscy wiedzą, że to agregacja i że jedna klasa będzie zawierać obiekty drugiej klasy. Gdybyś do tego chciał podkreślić, że obiekty tej drugiej klasy nie mogą istnieć bez obiektów tej pierwszej klasy (bo nie miało by to większego sensu) - to rysujesz romb wypełniony.
Inny przykład na kompozycję ze świata GUI (Graficznego Interfejsu Użytkownika), który wydaje mi się równie dobry: Relacja która łączy przycisk i okno to właśnie kompozycja. Czyli okno zawiera w sobie przyciski. Czy przycisk może istnieć bez okna? - Nie. Czy okno może istnieć bez przycisków - tak. Ja taką relację oznaczyłbym właśnie wypełnionym rombem (kompozycją).
Uwaga: Gdyby w twoim konkretnym przypadku było możliwe istnienie przycisku bez okna - ok u Ciebie mogła by być to agregacja. W moim przypadku użyłbym kompozycji bo wykluczam istnienie przycisku bez okna. Żeby to podkreślić używam właśnie relacji która się nazywa kompozycja.

Natomiast nie podoba mi się twoje rozumowanie:
Cytuj
Wiem (jestem pewien), że referencja i wskaźnik: Klasa&, Klasa* to asocjacja (bez strzałek - linia ciągła).
Relacje między obiektami to jak dla mnie jedna sprawa, a czy to będą wskaźniki czy referencje to zupełnie coś innego. Nie dostrzegam tutaj związku - że wskaźnik to na pewno asocjacja - skąd taki tok rozumowania?
Dodane: Może doprecyzuję - ok, jak masz referencję na klasę czy wskaźnik na klasę - to faktycznie jedna klasa będzie zawierać inną - trudno żeby mieć tu coś innego. Więc zgodzę się, że to będzie wtedy agregacja (a nie na przykład relacja dziedziczenia - rodzic - potomek). Ale równie dobrze mogła by to być kompozycja. Wydaje mi się, że są to dwa zupełnie inne światy - jak rozmawiamy o agregacji czy kompozycji - rozmawiamy w kontekście relacji między obiektami - a nie czy będziemy używać wskaźników czy referencji...

Na koniec pytanie o szablon: "template<class T> class ..." co to jest? Ja bym odpowiedział, zależy co ten szablon robi. 

Tak ja rozumiem temat - jeżeli coś pokręciłem to proszę o sprostowanie. Przykłady były wymyślane na kolanie i nie do końca mogą być trafione :P

Pozdrawiam,
Lerhes

14
C++ / Odp: Tajemnicze zachowanie new
« dnia: Wrzesień 28, 2016, 13:33:34 »
Cześć,

Dzięki za odpowiedzi. Szczególne podziękowanie dla Karola - wydaje mi się, że właśnie z tym mam do czynienia w przypadku mojego programu.
Tak właśnie mi się wydawało, że ma to coś wspólnego z pobieraniem pamięci od OS, ale dziwne mi się wydawało, żeby przy okazji OS zerował tę pamięć. Ale fakt - gdyby tego nie robił, to programy mogłyby analizować otrzymaną pamięć i próbować na tej podstawie jakiejś formy ataku.

Jeszcze raz dziękuję za pomoc.

Pozdrawiam,
Lerhes

15
C++ / Tajemnicze zachowanie new
« dnia: Wrzesień 28, 2016, 00:32:51 »
Cześć,

Trafiłem na "trochę dziwne" zachowanie operatora new i bardzo proszę o wyjaśnienie poniższych obserwacji. Sprawdziłem w standardzie języka C++, że pamięć zaalokowana operatorem new nie jest zerowana (no chyba że użyjemy nawiasów). Czyli:
int * tab1 = new[100]; //Nie mamy zerowania
int* tab2 = new[100](); //Mamy zerowanie
Nic w tym dziwnego. Zróbmy mały eksperyment:
http://ideone.com/fblet5
Wynik nie jest specjalnie zaskakujący - zaalokowałem 200 intów. Ustawiłem w tym obszarze same -1 i potem zwolniłem pamięć. Ponowna alokacja takiej samej tablicy dała mi ten sam adres (tutaj może być czasami inny adres, ale akurat to nieistotne) i mam te same wartości (-1) co też nie jest jakieś dziwne (bo niby kiedy miała się zmienić). Kompilator dołączony do Visual Studio daje troszkę inne wyniki, ale generalnie jest podobnie.

Ok, teraz meritum sprawy, podciągnijmy znacznie rozmiar alokowanej tablicy, z 200 elementów do 2000000.
http://ideone.com/W3mLvH
I teraz psikus którego nie rozumiem. Dlaczego przy alokacji dużego obszaru pamięci, ten obszar jest zerowany?
Jeszcze raz wyjaśnię o co mi chodzi. Najpierw alokuję duży obszar pamięci i ustawiam w nim -1. Potem usuwam ten obszar i alokuję ponownie równie duży. Dostaję ten sam adres. Ale dlaczego "gratis" zostały w nim ustawione zera?
Taki sam wynik jest z Visual Studio.

Wiem że nie mogę polegać na takim zachowaniu kompilatora, bo jest niezgodne ze standardem. Natomiast ciekawi mnie, dlaczego duży obszar zaalokowanej pamięci jest zerowany, a mały nie. Wydaje mi się, że przecież takie zerowanie dużego obszaru tylko spowolni program (a wydajność jest przecież najważniejsza w C++ :) ).

Update: W sumie to można pytanie "uprościć" do pytania o malloc - bo przecież new woła malloc (plus trochę magii). Stosowanie samego malloc daje te same wyniki.

Pozdrawiam,
Lerhes

Strony: [1] 2 3 4 5 ... 25