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.
Opcjonalna stara smuga (oldsmudge yes).W kwestii formalnej :) jesli nazwy parametrow maja byc po angielsku, to powinno byc to raczej "oldlightbeam" albo "oldbeam". Smudge to po ichniemu smuga w sensie "plama", a nie "promien swiatla".
Zgadza sie, trzeba bedzie troche te fizyke przerobic, bo nie do tego byla stworzona i mimo ze ma ponad 50 parametrow to raczej nie da sie ustawic wypchniecia 'czastek' na pewna wysokosc, ale jescze pokombinuje.To co jest powinno w zasadzie wystarczyc -- czastki wedruja "w gore" zgodnie ze zdefiniowanym parametrem, a dodatkowo powinny byc (ewentualnie) popychane zgodnie z kierunkiem wiatru podanym w scenerii, a nie w emiterze. W przypadku dymu z lokomotywy itp "luk" bierze sie z tego, ze czastka po wyemitowaniu nie podaza dalej za zrodlem ale "wisi" w powietrzu podczas gdy lokomotywa leci dalej do przodu.
No ale wlasnie, wiekszosc exampli ktore mam bazuje na bibliotekach opengl, ktore nie sa dostepne dla borlandowskiego srodowiska, a nawet jesli sa to w starszych wersjach gdzie brakuje niektorych funkcji.Biblioteki sa z reguly tylko wrapperem do tworzenia/obslugi okien, ladowania danych itp, wiec nie sa tak naprawde konieczne. Chyba duzo wiekszy problem to brak obslugi shaderow w kodzie EU. Gdyby byla to kupe rzeczy moglbys zrobic w 10 minut metoda google/skopiuj/wklej. A tak to trzeba sie bawic w szukanie kodu sprzed 10+ lat. Tutaj jest cos co moze dzialac: http://www.paulsprojects.net/opengl/shadowmap/shadowmap.html (z naciskiem na 'moze')
MaSZyne sie kompiluje na Borland C++ Builder 5.02 z 2001r :-)No to faktycznie, kamieni kupa. Tak sie zastanawiam, jesli te kawalki w Pascalu tak wszystko blokuja, to moze sprobowac automatycznej konwersji na poczatek i potem to ewentualnie doszlifowac? Jakies narzedzia sa: http://www.garret.ru/lang.html i dokumentacja na http://www.garret.ru/ptoc/Readme.htm chociaz nie wiem na ile skuteczne.
To jest zgodne z C99? Bo mnie sie wydaje, ze to moze byc C++11...Auto jest c++11 ale to tylko moje lenistwo, zawsze mozna podac typ recznie. Inicjalizacja listy, nie jestem pewien; VS2012 chyba tego nie przelknie, 2013 kompiluje bez problemu (podobnie z reszta jak auto) i jest darmowa wersja Express z MS, wiec to tez raczej nie tragedia..?
zrobilbym nawet we wpisie podawanie nazwy typu wyliczeniowego, ale w c++ konwersja typow na string i odwrotnie nie jest userfriendly.Oj tam oj tam, technika poszla do przodu:
W pascalu to jest jedna linijka kodu, przyklady dla c++ sa na internetach ale jest to przerost formy nad trescia.
std::unordered_map<std::string, int> values = { { "triangle", 1 }, { "polygon", 2 }, { "line", 3 }, { "point", 4 } };
auto lookup = values.find( "polygon" );
auto value = lookup == values.end() ? 0 : lookup->second; // zamiast 0 mozna podac wartosc default
Jak dla mnie we wpisie ini podajesz typ jako string (zgodnie z tym co napisałeś) a w parserze próbujesz odczytać int. Czegoś nie rozumiem?Na moje to typ jest podany jako liczba w zakresie 1-4. Parser wywiedziony jest z std::basic_stringstream i jako taki przeprowadza automatyczna konwersje takiego "tekstu" do podstawowych typow numerycznych (w tym wypadku int) poprzez operator>> Podobnie jak robi to z reszta parametrow.
parser.getTokens(7);Tu jest chyba blad -- parser pobiera 7 parametrow, ale przekazuje dalej 6. Potem odczytuje 3 ale probuje przekazac 4. Problem w tym ze getTokens() kasuje poprzednia zawartosc bufora, wiec snow_color dostanie zawartosc snow_tex itd, a snow_blend nie dostanie nic.
parser >> QGlobal::snow_area >> QGlobal::snow_size >> QGlobal::snow_srcf >> QGlobal::snow_srct >> QGlobal::snow_sraf >> QGlobal::snow_srat;
parser.getTokens(3);
parser >> QGlobal::snow_color >> QGlobal::snow_tex >> QGlobal::snow_light >> QGlobal::snow_blend;