Will

Jeśli w takiej grze 2d musisz tak kombinować to robisz coś ee źle.. Może po prostu za bardzo utrudniasz sobie sprawę? Jeśli chcesz się na coś przesiąść to polecam jakąś zwykła bibliotekę 2d jak sfml, budujesz edytor choćby w c# w jakieś ~2tyg i praktycznie dostosowujesz go do własnych wymagań co bardzo ułatwia proces tworzenia. Dla gier 2d to najlepsze rozwiązania, budujesz sobie fabrykę przystosowaną do własnych wymagań.

Obecnie wyliczam tylko slip i koła dostają poślizgu w osi z lokalnej. Z tego co sprawdziłem to jest w porządku chociaż nie sprawdzałem dla wielu powierzchni więc możesz mieć racje jeśli level będzie na jakimś błocie. Chciałem połączyć model realistyczny z zręcznościowych i staram się całość odpowiednio wyważyć. Nie chciałem robić jak w flatout 2 gdzie prawię w każdym momencie poślizg wygląda tak samo. Czy całość jest grywalna tzn nie jest zbyt trudne do opanowania? Poślizg jest zależny od tego jak wejdziesz w zakręt. Jeśli wejdziesz na pełnym gazie przy sporej prędkości jest duża szansa, że zrobisz obrót. Restart robiłem na szybko bo to testowy level. To będzie coś raczej jak flatout 2 i podobne gry a nie czyste derby. Na dłuższą metę wydaje mi się to zbyt nudne. Co do zawieszenia to jest taki problem, że siła idzie na koła nie pojazd i przy normalnie ustawionym centrum masy przy bardziej bumpy zawieszeniu auto łatwo się przewraca na zakrętach. Nie wystarczy tylko trochę "lepsze" zawieszenie tak aby czuć start/hamowanie + zakręty?(tzn przenoszenie masy jest ale ustawianie są takie, że słabo widać). Dzięki wielkie za testy, jeśli ktoś ma jeszcze jakieś sugestie proszę pisać.

Witam. Potrzebuje aby kilka/naście osób przetestowało fizykę pojazdu nad, którą pracuje. Całość to maksymalnie uproszczony level tak aby ważył jak najmniej. Sterowanie jest standardowe a/w/s/d +ręczny spacja. Dodatkowo można zmienić typ napędu pojazdu: "B" -> zmiana na napęd tylni "F"-> napęd przedni "T"-> napęd 4x4 (zmiana napędu ma istotny wpływ na prowadzenie nie jest to tylko kosmetyka). Jeśli wypadnie się z trasy lub zablokuje wystarczy wcisnąć R. Zależy mi głównie na dopasowaniu parametrów tak aby całość była jak najbardziej grywalna. Model bazowany jest na prawach fizyki więc trzeba mieć na uwadze, że np: przy zbyt szybkim wejściu w zakręt w przypadku tylnego napędu może nas obrócić. Wszelkie sugestie co do sterowania/prędkości/skrętów/zawieszenia itd mile widziane jako, że chcę maksymalnie dopracować ten model. Tutaj wygląd sceny: http://imageshack.us/photo/my-images/818/test0606.jpg/ Tutaj jest link: http://dl.dropbox.com/u/5303770/test0.6.06.2011v2.rar (waga ~17mega) edit:link zamieniony na nową wersje.

Te procenty to czysta fantazja. Nie ma co takich rzeczy pisać bo testów co jest szybsze jest masa i wahają się od "C# jest szybszy" do "c++ jest 100% szybszy". Jak piszesz artykuł, który ma być wiarygodny to trzeba sprawdzić zebrane informacje i np: checknąć na stronie/forum unity jakie są opinie i co jest na +/-. Przez mało rzetelne i niesprawdzone informacje w różnych artykułach powstają różne bajki.

Skąd jest info co do szybkości c#+xna? Co do unity wyrzuciłbym: -"Darmowa wersja zawiera większość potrzebnych rzeczy" zawiera tyle aby się pobawić, żeby zrobić full grę brakuję masy rzeczy. -"Duża wydajność" co najwyżej całkiem niezła. a dorzuciłbym: +Obsługa sporej ilości formatów(tekstury/modele/audio) +Support dla wielu konfiguracji sprzętowych. edit: +bardzo dobra dokumentacja

Witam. Poszukuje grafika 2d do pomocy przy prostej grze 3d(wyścigi połączone z destrukcją coś ala flatout). Całość jest komercyjna więc jeśli nie stanie się coś tragicznego można coś tam zarobić choć wielkiej kasy nie obiecuje. Najważniejsza jest umiejętność tworzenia dobrych tekstur 2D(budynki/podłoże/przeszkody/ itp), przynajmniej godzina dziennie wolnego czasu i rzetelność. Tutaj przykładowe screeny przedstawiające obecny wygląd projektu(jak widać trzeba będzie też trochę popoprawiać też obecne tekstury): http://imageshack.us/f/196/beztytuuwie.jpg/ http://imageshack.us/f/859/screenshot2011051115093.jpg/ Jeśli ktoś jest zainteresowany można pisać na gg/ten temat/email/pw.

<ziew>... i co z twojego postu wynika? Chyba jasno stwierdziłem, że jeśli zacznie ostro pracować to da radę. To chyba logiczne, że jak będzie próbował wszystkiego to nic z tego nie wyjdzie. Mnie nie interesowało czy jest na 100% pewien, czy może najpierw chce polecieć na księżyc, zbudować własną planetę, przekopać się do Chin czy wyhodować kapustę giganta tylko odnosiłem się do jednej jasno przedstawionej sprawy. Równie dobrze mógłbyś napisać, że w poprzednim roku na polu u sąsiada krety zbudowały największą podobiznę Elvisa i wyszłoby na to samo.

A jak nie interesuje się tym od dawna i nie jest dobry w rysunku technicznym to nie? Może od razu niech zawód od przedszkola będzie wpajany bo potem już za późno. Jak będzie miał odpowiednie chęci i motywacje to da radę no problem.

Winapi to sobie można w większości przypadków odpuścić. Machaj jak najwięcej programów i staraj się w ramach możliwości finansowych korzystać z książek a nie tylko z tutoriali z neta bo w większości przypadków są kiepsko napisane, szczególnie dla początkujących. Jak dla mnie każdy początkujący powinien przeczytać symfonie + dodatki do tego z szablonami+ Effective C++ & More Effective C++(nie wiem czy są polskie wersje).

Ja nie piszę, że ma olać studia kompletnie, jeśli chcę niech idzie. Chodzi mi o to żeby wybrał sobie inny kierunek bo czysta informatyka jest głupim wyborem jeśli ktoś ma dobrych kilka lat doświadczenia z programowaniem(jeśli to jest właśnie to co chcę robić). Inny kierunek sprawi, że jego wiedza podczas studiów znacznie się poszerzy a nie tylko uzupełni. Zdecyduj co chcesz robić i zacznij już klepać jakieś projekty: -gry komputerowe -> ucz się c++ i bierz się to co najbardziej Ci pasuje gameplay/ai/programowanie grafiki - soft -> bierz się za c# i klep jakieś przydatne programy za 20 razem napiszesz coś sensownego i może nawet zarobisz. - www -> zabieraj się za odpowiednie technologie i klep ile wlezie. Dodatkowo tu najłatwiej o zarobek. - co tam jeszcze sobie chcesz robić.. Przede wszystkim trzeba zacząć coś robić i to codziennie choćby po kilkanaście minut. Może się okazać, że po roku i tak wszystko Ci się znudzi..

A jakie to ma znaczenie dla tego co napisałem(jeśli do tego się to odnosi)? 0.o

Jeżeli masz przed sobą dobrych kilka lat nauki programowania po co Ci studia informatyczne? Kompletna strata czasu. Dorzuć sobie do infy matme+fizykę i szukaj czegoś w innym kierunku, może jakaś robotyka, budowa maszyn czy jakiś inny kierunek, który w jakiś sposób Ci się spodoba.

Pisałem z pamięci.. daj GetCurrentThreadId. Jeśli nie zadziała to wpisz w google nazwę albo od razu na msdn'ie to kwestia 1min.

"edit: spróbuj w 4 dać current thread id -> getCurrentThreadId()"

Jak pisałem zostaw 3 parametr na null a na 4 daj id używanego wątku.

Tyle, że o ile pamiętam jeśli 3 i 4 jest null funkcja nie zadziała. Sprawdź jaki error wypluwa. edit: spróbuj w 4 dać current thread id -> getCurrentThreadId()

Nie działa bo trzeci parametr masz NULL?

Teoretycznie jako, że switch akceptuje tylko stałe dla danych case'ów w przypadku ich dużej liczby switch powinien być znacznie szybszy niż if/else if. Jak dobrze pamiętam kompilator tworzy sobie dla switch'a look up table tak, że choćbyś miał 1000 case'ów będzie wymagane tylko jedno porównanie aby odnaleźć właściwie. Problem jest taki, że switch nie działa dla złożonych warunków tylko dla prostych typów liczbowych. Dla bardziej złożonych i przy małej ilość if/else if np 4-5 można ustawić całość względem częstości występowania danego targetu i też będzie śmigać. Największy problem jest taki, że to co się stanie zależy od wielu elementów np: kompilatora/sprzętu/ustawień optymalizacji i wielu innych. W przypadku kodu, który wykonuje się rzadko tego typu sprawami w sumie nie ma co się za bardzo przejmować. Znacznie więcej czasu stracisz na alokowaniu pamięci ze sterty niż na takich pierdołach gdzie aby wykonać malloc mamy najpierw context switch z user mode do kernel mode a potem po wykonaniu request'a znowu context switch co jest bardzo kosztowne. Drogie są też porównania string'ów, nie pamiętam już jakie to były produkcje ale zdarzało się, że string'i były głównym bottleneck'iem całego projektu.

Mogę napisać ale to będzie raczej mało rzetelne jako, że nie mam takiej wiedzy żeby to dobrze opisać ale jeśli chcesz.. Dajmy na to, że masz jakąś instrukcje dla procka. Ona cała nie może się wykonać ot tak. Przypuśćmy, że na wykonanie danej instrukcji są 4 etapy: 1. Fetching bierzemy instrukcje z pamięci 2. Decoding Dekodujemy(czy raczej procek) instrukcje żeby wiedzieć co to jest 3. Execute wykonujemy instrukcje 4. Store zapisujemy wynik instrukcji do rejestru. Teraz niech każdy etap potrzebuje jeden "clock cycle" aby się wykonać. Teraz w przypadku przetwarzania instrukcji "pipelined" wykonywanie kolejnych instrukcji wygląda mniej więcej tak(bardzo mniej): http://imageshack.us/photo/my-images/121/pipelined.jpg/ Pipelined oznacza krótko pisząc tyle, że przetwarzanie kolejnych instrukcji jest podzielone na małe etapy tak, że jak instrukcja 1 przechodzi do 2 etapu procek może wrzucić do pierwszego etapu następną co jest oczywiście znacznie szybsze niż wersja procka nonpipelined, która wygląda tak: http://imageshack.us/photo/my-images/64/nonpipelined.jpg/ Jak widać pipelined jest znacznie szybszy. Całość można porównać do budowy samochodu w przypadku pipelined budowa auta jest podzielona na wiele oddzielnych etapów, które mogą się wykonywać niezależnie od siebie i kiedy pierwsze auto otrzyma silnik i idzie do montownia drzwi na jego miejsce do etapu montowania silnika daje się następny pojazd. W przypadku nonpipelined budowa kolejnego auta może się rozpocząć dopiero kiedy poprzednik jest w 100% ukończony. Instrukcje warunkowe nie są zbyt przyjazne dla tego typu rozwiązania. Kiedy natrafimy na jakieś if'a wykonywanie instrukcji na pierwszy rzut oka musi się zatrzymać dopóki cała instrukcja nie zostanie wykonana aby zdecydować gdzie "skoczyć" ale to jest nie bardzo do przyjęcia bo "montażownia" musi działać cały czas(jeśli jakieś maszyny z konkretnych etapów "stoją" to strata energii i czasu). Dlatego procek zgaduje jaki będzie wynik instrukcji warunkowej, bazuje tu na poprzednich wyborach dotyczących tego warunku(dzięki jakiemuś tam cache dla branching'u). Jeśli procek strzeli dobrze wszystko leci dalej jak trzeba. Jednak jeśli nie trafi to pipeline jest czyszczony(instrukcje, które się wykonały z źle wybranego bloku kodu) czyli jeśli pipeline podzielony jest na 20 etapów cofamy się o 20 instrukcji w tył co oczywiście sporo kosztuje. To jest bardzo uproszczone tłumaczenie i całość jest znacznie.. znacznie.. bardziej skomplikowana.

Uznam, że tego nie napisałeś bo nie chcę mi się znowu kłócić o tak podstawową sprawę. Poczytaj trochę.

array[16] = {{5, 8, 0xFF, 11,10, 4, 2, 0xFF,0xFF, 0, 6, 9,3, 7, 0xFF, 1}; +zmienna np: elemSize:int=4; teraz: getElement(x:int,y:int) { return array[y*elemSize+x]; }

Wszystko zależy od tego czym wypełniona jest kartka. Tzn dane są losowe nie można ich wyliczyć: -trzeba wyklepać jednowymiarową tablicę i po problemie lub dodać wczytanie danych do tablicy z pliku. Jeśli wielkość kartki jest dynamiczna można użyć pamięci z alokatora(jeśli tablica jest używana raz a potem jest nie potrzebna) lub jeśli jest potrzebna podczas dłuższego czasu stworzyć tablicę z pamięci z zwykłym new.

Dalej nie widzę sensu robienia wielowymiarowej tablicy... If'y są bardzooo wolneeee więc jeśli rzeczywiście tylko raz całość będzie użyta i jeśli dane znane są znane w czasie kompilacji to zrobić makro, które wyliczy co trzeba. Jak danych nie da się wyliczyć i trzeba wklepać ręcznie to nie ma sensu marnować pamięci/instrukcji.

Szybsza będzie druga wersja. Poza tym zrób jednowymiarową tablice a nie jakieś wielowymiarowe cuda. Całość zależy też w sumie jak będziesz to przetwarzał i jak często będziesz się "bawił" z tymi danymi.