Skocz do zawartości

novo

Stały użytkownik
  • Liczba zawartości

    13
  • Rejestracja

  • Ostatnia wizyta

novo's Achievements

Newbie

Newbie (1/14)

0

Reputacja

  1. novo

    Problem Z E4300

    NB sie grzeje az parzy, to fakt. Sprzedawca mowil ze to norma na nforce'ach. Pozatym na domyslnylch ustawieniach plyta powinna chyba dzialac na domyslnym chlodzeniu. Bo to troche lipa, jak nawet nie wykrecajac potrzebuje chlodzenie dodatkowe na NB.
  2. Witam, Zrobilem ostatnio upgrade kompa no i oczywiscie cos musialo sie sypnac. Config to p5n-e, e4300, tagan U15 430W, Geil 2x512 DDR2 800 4-4-4-12, GF 7600gs, na procu siedzi infinity. Wiem ze karta jest sprawna, bo sprawdzalem u brata. Plyte glowna wymienilem dzisiaj w sklepie, ale problem jest nadal(watpie zebym 2 razy trafil padnieta). Zasilka jest ok, zostaje wiec proc i ram. Na poczatku komp chodzil przez jakies 40min w stresie(standardowe taktowanie) i bylo ok(temp max 32*), pozniej musialem wyjsc, wiec komp odpoczywal. Po powrocie odpalilem css no i po ok godzinie gry zaczely sie restarty. Teraz komp sie wiesza jakies 15-20s po wejsciu do windy(caly czas standardowe taktowanie). Probowalem odpalic memtesta, ale tez sie wiesza. Do 10% dojechal bez bledow, a potem zwiecha. Za malo ogarniam sprzet, zeby dojsc co jest nie tak. Jutro bede musial sie wybrac do serwisu, ale caly czas nie wiem co jest problemem, ten ram czy procesor. Jest ktos wstanie wywrozyc na podstawie tych objawow co sie stalo? Pozdr. novo.
  3. novo

    Engine

    Przy starszych grach(bez T&L) ta roznica moze byc widoczna, bo vertexy szly na CPU a nie GPU i to api bylo odpowiedzialne za ich wyswietlanie. Ale przy dzisiejszych GPU i tak wszystko sie na nich liczy(albo fixed czyli nie masz za bardzo na to wplywu, albo shadery), wiec API juz takiej roznicy nie robi. Pozdr! novo.
  4. novo

    Engine

    Cos krecisz. OGL I DX i tak sa implementowane w driverze i to on decyduje o wygladzie sceny. Wyglad jest totalnie niezalezny od api. Zawsze da sie skonfigurowac tak zeby na obu api widok byl ten sam.
  5. novo

    6ghz To Max Na Procesor?

    Kiedys ktos na warsztacie zarzucil takim linkiem, ja sie na tym nie znam, ale przekazuje dalej do oceny :) http://atomchip.com/_wsn/page3.html
  6. novo

    Engine

    :D Na razie mam sam kernel(bez VFS). Teraz zabieram sie za pisanie renderera. W chwili obecnej nie mam za duzo czasu bo maturke poprawiam(nie starczylo punkciorow na UW na infe a Fizyka na UW suxx :)). Po maturach prace zostana wznowione :) Pozdr! novo.
  7. novo

    Engine

    Moim zdaniem sa to tak niskopoziomowe API, ze kazde funkcjonuje na innej zasadzie. Chodzi mi o to, ze to jakie funkcje sie wywoluje nie ma wiekszego znaczenia. Wazne jest zeby wiedziec do dana f-cja robi. I tak przy d3d wymagana jest znajomosc dzialania karty graficznej(nie jakos super niskopoziomowo, ale potok renderowania powinno sie znac), tak samo przy dsound trzeba wiedziec jak drivery/karta ten dzwiek odgrywa. DInput jest na tyle prosty, ze nawet nie warto o nim wspominac. Mi napisanie wrappera na dinput przy kompletnej nieznajomosci DX zajelo 2h(wszelkie info z dokumentacji), a bylo to juz ze 3 lata temu(duuuuzo slabiej wtedy kodzilem :)). Wiadomo ze oba API sa oparte o COM, ale tak naprawde jest to tylko kwestia wywolywania f-cji ktorych nazwy, parametry i zwracane wartosci wyczytamy z dokumentacji. Co do wyzszosci DX nad OGL to jak pisalem raczej nie ma roznicy, bo to tak naprawde tylko nakladka na driver/karte graf. Potok renderowania jest ten sam, tylko kod ma troche inna strukture. Poznanie jednego API najczesciej polega na nauczeniu sie generowania grafiki 3D, poznawanie drugiego API to juz tylko nauka odpowiednich f-cji z dokumentacji. Z OGL'em sa problemy przy pisaniu efektow na jak najstarsze karty graficzne ze wzgledu na brak PS1.x niezaleznego od producenta karty. Wszystko trzeba robic na rozszerzeniach ATI lub NV. Przy DXie nie ma problemow. Ja tylko osobiscie uwazam ze na poczatek OGL jest latwiejszy i z tego co czytalem wiekszosc tak uwaza. Ale to jest kwestia gustu, a o gustach jak wiadomo sie nie dyskutuje :). Najlepiej sprobowac popisac w jednym i drugim API i sprawdzic jak jest nam wygodniej. Pozdr! novo.
  8. novo

    Engine

    Do obslugi ogre'a nie musisz znac dx'a bo ogre calkowicie go zaslania. Na pewno jak dx'a poznasz, bedzie Ci duzo latwiej. Nie chodzi tu o poznanie samego API, ale raczej sposobow generowania grafiki 3D. Np. nVidia podaje ze najlepiej jest do karty wysylac po 3-4k vertexow na raz, bo wtedy uzyskuje sie maxymalna wydajnosc. Dobrze jest ogolnie wiedziec co ile czasu sie wykonuje. Osobiscie z ogre'a nie korzystalem, tylko czytam sobie zrodla, wiec za duzo ci w tym temacie nie pomoge. Jakiekolwiek pytania dotyczace silnika proponuje kierowac na forum ogre, tam na pewno uzyskasz odpowiedz. Pozdr! novo.
  9. novo

    Engine

    Przy prostych grach, mozesz spokojnie wszystko rysowac recznie w dx'ie. Przy bardziej zaawansowanych musisz juz miec jakis silnik, albo swoj, albo gotowy. Druga sprawa: jak zaczniesz pisac engine, to szanse ze napiszesz jakakolwiek gre spadaja prawie do 0 :). Nie dla tego ze nie masz szans na napisanie go, wrecz przeciwnie. Po prostu zawsze bedzie cos co bedziesz chcial do niego dodac :). To jest glowny problem programistow-amatorow. Przy profesjonalnych projektach, przed napisaniem silnika robi sie zalozenia co bedzie obslugiwal i potem sie pisze az sie skonczy. Jak juz programisci zaczna pisac kod, to zadko sie zdaza zeby cos bylo dodawane. Silnik mozna pisac w nieskonczonosc. Najlepszym tego przykladem jest Duke Nukem: Forever. Chlopaki chca zrobic gre idealna, silnik zmieniali juz z 5 razy a gry nie widac. Co do ksiazki: Slyszalem ze dobra. Jezeli chcesz oszczedzic kase, to polecam pouczyc sie z tutkow z netu. Po polsku masz dimmension3.spine.pl. Z angielskojezycznych polecam www.gamedev.net(Ogolnie game dev), (OpenGL) i www.ultimategameprogramming.com(DX i OGL). Na poczatek polecalbym OpenGL. Dla mnie jest latwiejszy od dx'a a oferuja ta sama funkcjonalnosc(pod wzglem grafiki 3D, bo dx ma jeszcze dinput, dsound, ale i tak najczesciej nawet piszac pod OGL'a ich sie uzywa wiec tak czy siak bedziesz musial sie tego nauczyc). Argument, ze lepiej uzyc dx'a bo ma od razu nie tylko 3d, ale wlasnie pozostale komponenty jest raczej nie trafiony. Nauka Direct3D nie ulatwi ci wcale nauki dsound(mimo ze tez COM, to zupelnie co innego bo dotyczy dzwieku) czy dinput(bardzo proste API, napiszesz sobie raz wrapper i na najblizsze 5lat ci starczy. D3D i OGL oferuja ta sama funkcjonalnosc(jedyne ograniczenie to karta graficzna), wiec klotnie nad wyzszoscia jednego nad drugim sa bez sensu. Ja uwazam ze OGL jest na start latwiejszy i raczej wiekszosc wypowiedzi ktore czytalem byla podobna, chociaz zdazali sie ludzie ktorym API D3D bardziej pasowalo. Jak nauczysz sie jednego API to w zasadzie nauka drugiego pojdzie ci bez problemow bo to praktycznie to samo, tylko inaczej przedstawione :). Kolejnym problemem jest zblizajacy sie DX10. Microsoft zapowiedzial totalna przebudowe tego API i odejscie od COM'ow. Nowa wersja bedzie niekompatybilna wstecz. DX9 i starsze bedzie po prostu emulowane przez DX10, co umozliwi odpalanie starszych gier, ale samo API ma sie zmienic. Dokladnych informacji nie podam, bo DX'em nie bawie sie juz od ok roku i skupilem sie na razie na OGL(przenosnosc), chociaz planuje renderer tak, zeby zaimplementowac obsluge i D3D i OGLa. Pozdr! novo.
  10. Ten post zostawie na przyszlosc. Dzialo sie tak prawdopodobnie dla tego, ze 1/i nie musi dawac poprawnych wynikow. Tzn 1/2 nie oznacza koniecznie 0.5, moze byc np 0.4999999999999999. Wynika to z faktu iz obliczenia zmiennoprzecinkowe sa zawsze podawane z pewna dokladnoscia. Aby sprawdzic ile ta dokladnosc wynosi(zalezy od typu) mozna uzyc std::numeric_limits<T>::epsilon(). Dla float bedzie to: std::numeric_limits<float>::epsilon(). Wiecej info jest tu. Pozdr! novo.
  11. novo

    Engine

    Tak, wspiera. Jest nawet niezalezny od graficznego API, wiec mozesz wyswietlac za pomoca DX9, albo OpenGL. Napisz jaki kompilator/IDE i jaki dokladnie blad, bo tak ciezko pomoc :) Pozdr! novo.
  12. novo

    Engine

    Nie polecam. Dlaczego? 1. Silnik jest stary(2000r). Nie bylo wtedy jeszcze shaderow(90% obecnych efektow sie na nich opiera). Ogre jest rozwijany caly czas i mysle ze mozna grafike przez niego generowana spokojnie porownac do far cry(czego o q3 raczej powiedziec nie mozna). 2. Ogre jest projektem open source. Co za tym idzie kod jest duzo czytelniejszy i bardziej elegancko napisany. Q3 powstawal w jednej firmie i w takim przypadku mozna sobie pozwolic na mniej czytelny kod. Jezeli sie czegos nie rozumie to idzie sie do kolegi obok i tlumaczy co napisal :). 3. Ogre jest napisany w C++ z wrecz podrecznikowym designem OO. Q3 jest strukturalny i napisany w C. Dla niektorych moze to byc zaleta, ale jednak i tak niewiele to q3 pomaga. 4. Ogre jest caly czas rozwijany, a q3 nie. 5. Brak dokumentacji do q3. Wypuszczony zostal tylko kod zrodlowy na GPLu. Do Ogra jest sporo tutoriali i wielkie community. Jakiekolwiek problemy i watpliwosci sa najczesciej rozwiazywane w ciagu 24h od wyslania posta. 6. Ogre jest na LGPLu a co za tym idzie mozna go wykorzystywac w komercyjnych projektach bez wymogu umieszczania zrodel(GPL na to nie pozwala). Ogolnie silnik q3 mozna 'przerobic' jezeli jestesmy ciekawi jak to panowie z ID zakodzili. Ogre pod wzgledem technologicznym stoi na poziomie wspolczesnych komercyjnych silnikow. Dodatkowa zaleta q3 jest to ze dostajemy kompletny silnik(nie tylko renderer jak ogre), ale brak dokumentacji w zasadzie uniemozliwia poznanie go w rozsadnym czasie. Analizowanie calego kodu moze byc troche pracochlonne biorac pod uwage jego ilosc. // EDIT: Jeszcze co do pytania z poczatku watku. Dobrze napisany silnik zajmuje sie cala techniczna otoczka pisania gry. Programiscie zostaje tylko skodzenie mechaniki gry, a nie wyswietlania grafiki, odczytywania klawiatury/myszki czy odgrywania dzwiekow. Majac silnik jedyne czym sie zajmujesz to gra sama w sobie, czyli pisanie obiektow reprezentujacych postacie, przedmioty, NPC i interakcje miedzy nimi. W silniku masz zaimplementowane wszystkie efekty(cienie, realistyczna woda, oswietlenie, ladowanie mapy i zarzadzanie geometria, kolizje, podstawa do napisania AI, obsluga dzwieku itp.). Nie musisz znac nawet OpenGL/DirectX zeby sie zabrac za pisanie gry(jednak wiedza o tym jak silnik dziala i jak jest zbudowany bardzo pomaga, szczegolnie przy optymalizacji). Silnik tworzy API w ktorym piszesz gre. Bez silnika musisz wszystko robic recznie(w zasadzie kazda gra posiada silnik, mniej lub bardziej profesjonalny). Pozdr! novo.
  13. novo

    Engine

    Witam, Z darmowych polecam Ogre3D. Nie jest to co prawda kompletny silnik, glownie renderer. Ale mozna podpiac pod niego np ODE i juz mamy fizyke. Dzwiek i input do prostych gier to jest kwestia paru tysiecy linijek wiec to tez raczej problemu nie robi. Pisanie silnika to dosc duze przedsiewziecie. Ja swoj pisze juz 2lata i na razie prawie nic nie ma. Zawsze przychodzil moment kiedy sie okazywalo ze cos zle zalozylem i kod byl juz na tyle zagmatwany ze musialem wszystko od nowa pisac. Jezeli chcesz sie za to zabrac to i tak polecam sciagnac zrodelka ogre3d i przestudiowac. Kod jest bardzo elegancko napisany. A co do warsztatu, to nadal istnieje., tylko juz dawno nie pod adresem warsztat.pac.pl. Oficjalna strona jest na www.gamedev.pl, ale nie polecam bo jest to eksperyment paru osob z java/cocoonem i srednio sie prezentuje. Jeden z warsztatowiczow zrobil samemu gotowy serwis i on glownie jest teraz uaktualniany: Warsztat2b. Od wczoraj wieczorem sa jakies problemy, ale serwis na pewno nie umarl, tylko jakies problemy techniczne. Polecam przejrzec artykuly na stronie glownej. I przed zadaniem pytania na forum koniecznie uzyc f-cji szukaj, bo inaczej duza szansa ze topic poleci. Pozdr! novo.
×
×
  • Dodaj nową pozycję...