To już lepiej zrób na zamówienie dla siebie. Lepiej byś spędził ten czas choćby na nauce c#. A jak będziesz miał rok doświadczenia i trochę talentu to znajdziesz robotę gdzie nie będzie kasa na końcu, tylko jako comiesięczna pensja ;]
Zobaczyłem wymagania->ee malutkie..->zobaczyłem produkcje->atak śmiechu..
@Marmot Zastanów się.. to jest chyba tylko dowcip albo ta grupa nie jest zbyt inteligentna.
Możesz podać jakieś źródła do tego "wzorca" ?
Chodziło mi po prostu o popularną grę kółko vs krzyżyk w ostateczności jakieś statki.. Niby proste a wielu "pro" nie potrafi nawet tego. Z doświadczenia wiem, że na pewno rozjaśni to wiele wątpliwości.
Dzięki za poprawę humoru.
Co do tematu. Każda gra jest na swój sposób inna i jak to zostanie poskładane w głównej mierze zależy od Ciebie. Spróbuj napisać coś w konsoli jakieś
KvK. Zastanów się co program ma robić, jakie akcje wykonywać, kiedy i w jaki sposób. Rozpisz sobie wszystko a następnie zastanów się jak to zrealizować. Co do budowy większych gier nie masz na razie co się przejmować z czasem i doświadczeniem dojdziesz i do tego.
inline stosuje się do jak najkrótszych funkcji(kilka linii). Wszystkie długie funkcje(kilkanaście linii), którym dałeś inline i tak prawdopodobnie nie zostaną rozwinięte przez kompilator(dzięki Bogu). A nawet te krótkie właściwie też nie zawsze, wszystko zależy od kompilatora. Więc jak już coś to dla VC stosować __forceinline.
Jeśli to jest 3d: Dostałeś za pokutę pisać to w gm?
Skoro wiesz jak to ma wyglądać teoretycznie napisz od nowa w dx, nauka api max miesiąc a możliwości nieograniczone. Na pewno jest znacznie trudniej ale efekty znacznie ciekawsze wyjdą.
To nie patrz na kod tylko na tekst. Prosta metoda wykrywania kolizji, dla czworokątów banalna do zaimplementowania. Odpowiednie wzory fizyczne są, tylko zastosować.
"GML, Will. Ale C++ z kolei pozwala nam wiele "rzeczy" sobie skrócic, a i oferuje o wiele więcej ciekawych rozwiązań."
Przykro mi, że nie potrafisz tego zrozumieć ;/ Wymień te "rzeczy" , które można sobie skrócić dzięki c++...
"Will, argumenty? Bo na prawdę, nie wiem o co ci chodzi..."
Zobacz na kod źródłowy gry w języku obiektowym w porównaniu do gm.
Jeśli skorzystasz z 2 pierwszych wzrośnie jeszcze szybciej. Testy na kolejnych węzłach będą bardzo szybkie a odpadnie w cholerę geometrii. Powinno się obejść bez dodatkowego wątku, który przyda się dla zasobów.
"Myślę, że o wiele łatwiej dla ciebie by było napisac tą grę w C++ niż w GMie, nawet kombinowania będzie o wiele mniej "
Źle myslisz..
"czyli po prostu napisać grę w C++?"
to jedna z opcji... Można też pokombinować z optymalizacją (frustrum culling na jakiś AABB+octree ) i wtedy powinno być Ok mimo użycia gm.
Nie wiem jak to jest z gm. Wygląda to mniej więcej tak: Obliczasz wektor kamera a obiekt(np: jego środek), następnie możesz obliczyć kąt między poprzednim kierunkiem obiektu a tym nowym obliczonym i obrócić o dany kąt obiekt.
p.s nie wiem jakie tam są funkcje wspierające tego typu działania. Jak będę wieczorem napisze Ci jakiś pseudo kod.
Genialny temat ;D Wszyscy prześcigają się w kolejnych pomysłach jak napisać to samo. Nawet jeśli jest int program sam automatycznie zwróci odpowiednią wartość. "\n" nie służy do opuszczenia linijki tylko przejścia do następnej tak łopatologicznie. Moim zdaniem niech się trzyma deva, bardziej rozwinięte ide na takim poziomie tylko przeszkadza.