Ostatnie wiadomości

Strony: [1] 2 3 4 5 ... 10
1
Programowanie grafiki / Odp: SFML - convex shape origin position points problem z ustawieniem.
« Ostatnia wiadomość wysłana przez Risist dnia Wczoraj o 23:57:04 »
ConvexShape sh;

Vector2f origin = coś tam;

sh.setPoint(0,p1);
...
sh.setPoint(n,pn);

sh.setOrigin(origin);
sh.setPosition(-origin);

Ogólnie rzeczywista pozycja wierzchołka to sh.getPosition() + sh.getOrigin() + point (obrócony przez transform)

W razie wątpliwości polecam zajrzeć do dokumentacji lub do źródeł sfml'a.
// Ps. piszę z pamięci więc w szczegółach coś może się różnić.

Edit
Dlatego obraca ci się wokoło początku układu współrzędnych bo pozycja sh jest równa 0, a pozycje punktów to jedynie offset od tej pozycji
2
SDL / Odp: DestroyRenderer problem z użyciem
« Ostatnia wiadomość wysłana przez Lerhes dnia Wczoraj o 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
3
Projekty zaawansowane / Odp: [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez hRs dnia Styczeń 19, 2018, 11:47:54 »
Wprowadzona została aktualizacja zawierająca:
- lepsze dostosowanie poziom trudności
- kamera zostałą przesunięta w dół umożliwiając większą kontrolę sterowania
- dodany do game over screen Twój najlepszy wynik punktowy
- poprawione zostały błędy
 
Zapraszam :)
4
Projekty zaawansowane / Odp: [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez hRs dnia Styczeń 18, 2018, 17:30:19 »
Dzisiaj zrobiliśmy kilka poprawek.
Poziom trudności na początku będzie niski (tak jak do tej pory do 300 punktów) i z biegiem czasu będzie znacznie wolniej rósł.
Do tego kamera została opuszczona w dół dzięki czemu nie będzie się statek chował pod palcami :)
Update przewidziany jest na jutro, aby obie platformy dostały go jednocześnie.
5
Projekty zaawansowane / Odp: [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez maro dnia Styczeń 18, 2018, 12:44:56 »
Cytuj
Mogę wiedzieć do ilu punktów maksymalnie doszedłeś?
Nie wiem, ale czas gry to ok 40sek-1min.
Odinstalowałem ją, bo jak pisałem nie dało się manewrować statkiem, gdy był przy krawędzi ekranu.
Może trzeba go podnieść trochę do góry...?
6
Projekty zaawansowane / Odp: [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez hRs dnia Styczeń 17, 2018, 23:49:57 »
Cześć,

dzięki za odpowiedź i za udzielenie swojej opinii. Jutro postaramy się dodać aktualizacje, która sprawi że na początku gra będzie łatwiejsza. Zatem gracz będzie mógł prędzej wdrożyć się w system sterowania.

Mogę wiedzieć do ilu punktów maksymalnie doszedłeś?
Ja w grę pograłem "trochę" i mój rekord to ponad 4000 punktów.
7
Projekty zaawansowane / Odp: [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez maro dnia Styczeń 17, 2018, 22:18:46 »
Grałem ok 20 minut, kilka luźnych spostrzeżeń.
Oprawa całkiem fajna, klimat jest ok, choć moim zdaniem ani to retro ani lata 80.
Reklamy ok, nie przeszkadzają, ani nie są nachalne.

Gra ma dosyć wysoki próg wejścia - trzeba się przyzwyczaić do dużej bezwładności sterowania. Ogarnięcie tego trwa zdecydowanie za długo.
Fajne jest odbijanie się od krawędzi.
I tutaj uwaga, gdy już opanujemy sterowanie i zrobimy te 200-300 punktów dystansu, gra robi się niegrywalna. Przy krawędziach nie da się manewrować, ponieważ statek chowa się pod kciukami. A wystarczy, że zgubimy go z oczu na ułamek sekundy, i jest już po grze.
8
Projekty zaawansowane / [iOS][ANDROID] Rocket Glow! by GamesTornado
« Ostatnia wiadomość wysłana przez hRs dnia Styczeń 17, 2018, 15:38:10 »


Uwielbiasz styl Retro lat 80, rakiety i gry Arcade? Rocket Glow! jest dla Ciebie!

Przenieś się do cyfrowego świata świecących figur geometrycznych, sterując niesamowicie szybkim, neonowym pojazdem. Omijaj pomarańczowe przeszkody i zbieraj bonusy. Im większy dystans pokonasz tym więcej punktów zdobędziesz. Zbierając bonusy otrzymasz dodatkowe punkty.

Gra oferuje nieskończony, proceduralnie generowany świat, którego pokonanie staje się coraz trudniejsze z każdą kolejną przeszkodą.

W tym cyfrowym świecie istnieje kilka dopalaczy, które ułatwią lub utrudnią Twoją podróż. Czasowe przyspieszenie, spowolnienie, nieśmiertelność oraz odwrócenie sterowania dadzą Ci wybór pomiędzy trasą łatwiejszą lub trudniejszą ale z większą liczbą bonusów.

Gra dostępna jest na platformach:
iOS https://itunes.apple.com/us/app/rocket-glow/id1273142947
Android http://play.google.com/store/apps/details?id=com.rocketglowgamestornado1

Inne linki:
GamesTornado http://gamestornado.com
YouTube Trailer https://www.youtube.com/watch?v=SEn2McP4Des

Screeny:



9
Programowanie grafiki / Odp: OpenGL vs DirectX
« Ostatnia wiadomość wysłana przez Kyroaku dnia Styczeń 12, 2018, 23:42:50 »
Cytuj
Za Vulkanem przemawia to, że będę zaczynał od początku nie znając ani OpennGL ani DirectX, a grafika jest po prostu niesamowita.
A ja się wciąz zastanawiałem co ma piernik do wiatraka i na cholere komu uczyć się Vulkana, chcąc zrobić grę w Unreal Engine.
10
Programowanie grafiki / Odp: OpenGL vs DirectX
« Ostatnia wiadomość wysłana przez Sarann dnia Styczeń 12, 2018, 20:40:17 »
Grafika może być niesamowita bez względu na silnik, modele nie wyglądają ładniej w zależności od niego :)
Strony: [1] 2 3 4 5 ... 10