-
Postów
4 891 -
Dołączył
-
Ostatnia wizyta
-
Wygrane w rankingu
53
Typ zawartości
Profile
Forum
Wydarzenia
Treść opublikowana przez I am Lord
-
To zależy czy w biosie masz jeszcze ją włączoną. Ale możesz sprawdzić bo prawdopodobnie wystarczy podłączyć do niej monitor tym:
-
Kartę sieciową to ty masz zintegrowaną, muzyczną/dźwiękową i grafikę także masz zintegrowaną. A to w tym porcie pcie x16 jest zapewnie 2 kartą graficzną, której za pewne nie używasz bo monitor masz wpięty w wejście od zintegrowanej ( to niebieskie takie pod różowym szeregowym wejściem )
-
No więc jaki masz problem bo ja tu żadnego nie widzę. Masz pcie x16 i tam wpinasz nową kartę.
-
Karty zintegrowanej nie da się wyjmować bo jest wbudowana w płytę główną. Czy z Płyty głównej wystaje ci wejscie od monitora? Jeżeli tak to masz zintegrowaną. Powiedziałeś jeszcze że masz wpięte coś pod Pcie x16 i ma to coś wejście HDMI więc wnioskuję z tego że to też jest k. graficzna. EDIT: Czy to jest twoja płyta główna?
-
Ciekawe że mi się takie cosie nie robią może AA miałeś włączone w opcjach?
-
Co wy z nim za problemy macie? : O
-
Wow dla mnie jest super. Miałem wcześniej powiedzieć ale zapomniałem że trochę zbyt duży spectacular jest na ludzikach.
-
postaw wielgachnego tilesa o szerkoości i wysokości twojego tła, tilesom możesz zmieniać depth na dowolny
-
To jest karta graficzna, a wejście to nazywa się HDMI do podłączania nowoczesnych monitorów HD.
-
takie wejście jak tutaj? http://pcarena.pl/uploads/images/nowak/lea...500-gt-hdmi.jpg
-
ustawianie room_persistent z innego pokoju
I am Lord odpowiedział(a) na Nirvan temat w Pytania początkujących
GML room_set_persistent(ind,val) Taka mała notatka: nie wolno używać tej funkcji na roomie który jest aktywny. -
Nie możesz otworzyć i zrobić np zdjęcia?
-
image_angle = point_direction( x, y, drugiobiekt.x, drugiobiekt.y );
-
To czarne obok jest PCIe x16 tam ją wepniesz.
-
Source Newton Pong
I am Lord opublikował(a) temat w Gotowe Skrypty, przykłady, dodatki, silniki 3D dla GM
Udostępniam wam souce gry Newton Pong w celach tylko i wyłącznie EDUKACYJCH We większości skryptów i obiektów jest komentarz ( polski ) mam nadzieję że w miarę jasny. 1. Gra jest stworzona w GM8 ( nie w GM8.X ) powód jest taki że GMogre został zportowany z użyciem GMAPI od Snake z naszego GMC a jego GMAPI nie wspiera najnowszego GMa, efekt jest taki że gra się na nim zfreezuje. 2. Aby source się odpalił trzeba mieć zainstalowanego GEXa GMogre w GM8, tegoż GEXa znajdziecie tutaj 3. Pliki sourca są tutaj. 4. Dodatkowo dorzucam source plików zasobów ( gdyby ktoś chciał sprawdzić jak zostały zrobione ) są to modele Blendera, pliki pdn z PaintNet oraz pliki XML ( stworzone przez plugin Ogre do blendera 2.49b ) z których narzędzie konwertujące Ogre tworzy pliki .mesh Krótko opiszę jakich systemów GMogre używałem a więc co można się z sourca nauczyć: - customowe wpisy do loga - menu stworzone za pomocą nieintuicyjnej i niewygodnej metody CreateText oraz CreateSprite - menu podczas gameplay ( pauza i okienko zwycięzcy ) stworzone za pomocą Overlays ( dużo wygodniejsze i lepsze od tego wyżej ) - tworzenie sceny [ statyczne swiato kierunkowe, statyczne Entity ( instancja posiadająca model ) ], kamery ( statyczna oraz mouselook ) - implementacja fizyki GMnewton 2.0 ( który wchodzi w skład GMogre ) Dodatkowo nie powiązane z GMogre: - wykrywanie systemu operacyjnego - 3 poziomowe AI oparte na czystej matematyce - bardzo prosty Sound Menadżer, który zapobiega wykrzaczaniu się dźwięków, co jest typowe dla gier robionych w GMie - zapis i load opcji z pliku ini - światła dynamiczne ( te podpięte pod piłki ) - korzystanie z event_user 1. Analizowanie kodu zaczynamy od obiektu oLoading, który to inicjuje GMogre, inicjuje zasoby, zmienne globalne ( w większości używane w opcjach ), inicjuje silnik fizyczny oraz ustawienia z ini. 2. Potem gra przechodzi do oMenu, tutaj jest tworzony view port, kamera, interface menu. 3. Głównym obiektem gameplayu jest obiekt oEngine, który to resetuje punkty graczy, renderuje klatkę gry, zarządza pauzą, zwycięstwem, zapisywaniem screenShotów, debugerem GMnewtona, zwalnia pamięć po powrocie do menu. tworzy pozostałe obiekty: - oCam ( zadaniem tego obiektu jest przełączanie kamery statycznej w mouselook F12 ) - oEnvironment ( tworzy scenę ) - oPlayersControler ( tworzy paletki, tutaj wykonywane jest AI oraz poruszanie paletek przez graczy ) - oTextControler ( HUD ) - oSoundsManager ( odtwarza dźwieki, kontroluje je tak by każdy typ dźwięku mógł być odtwarzany tylko 1 w tym samym czasie ) - oBall ( tworzy piłki, tyczki w debug mode, dynamiczne swiatla ) -
A no tak zupełnie zapomniałem, podopisuję komentarze i wrzucam.
-
Mój kumpel na studiach ma taką poważną dysleksję że nie potrafi dobrze czytać. Myli często podobne litery, m z n, b z d. Czyta masakrycznie wolno bo stara się czytać poprawnie ale i tak często robi pomyłki.
-
Tak one wyglądają. Karty graficzne się podłącza na PCIe 16, kiedyś jeszcze były karty na PCIe 8 ( mam taką w 10 letnim kompie ) a te mniejsze to prawdopodobnie są na rzeczy typu tunner TV, k dźwiękowa itp.
-
Nirvan ściągaj nestopię i gramy w contre przez neta w coopa xD Tylko trzeba mieć 2 takie same kopie romów
-
@up W Die By The Sword był zrobiony taki system podobny do mojego, tyle że w 3D, bardziej precyzyjny i bardziej skomplikowany, tam prędkość machania mieczem była zależna nie tylko od szybkości ruchu myszką ale także od masy miecza i siły bohatera. Nazwali ten system Vsim i do orginału tej gry dołączali specjalną myszkę którą dało się wykonywać ruchy 3D :D ( szybko to wycofali ) Edit: Myszka oczywiście się nie przyjęła a o grze słyszało mało ludzi. Bardzo fajne uczucie jak się skrzyżują miecze, ta gra to jest bardziej symulator walki mieczem i się bardzo fajnie w to grało.
-
Ciekawe chyba mam konkurencję :P , ja przeszedłem ten poziom za około 20 razem, a całą contre na nesie mogę przejść z utratą 4-5 żyć ( po drodze jakieś 15 żytek zdobywam za score ) edit: No patrz nawet nie wiedziałem, dawno nie przekraczałem tej liczby a na ekranie continue nic nie pisze o ilości.
-
Mój trochę bardziej skomplikowany pomysł ale i też bardziej realistyczny. Taki rysunek poglądowy co gdzie i jak :D O co mi chodzi, można by było wyliczać prędkość uderzenia wybranych punktów na mieczu z jaką trafiło w ciało przeciwnika i na tej podstawie obliczyć zadany dmg. I teraz jak by miało się już tych 8 zmiennych wyliczone ( 2 punkty na mieczu w poprzednim stepie i obecnym ) to prędkość tych punktów wyliczyli byśmy o tak: GML speed1 = sqrt( sqr(x-xprevious) + sqr(y-yprevious) ); speed2 = sqrt( sqr(x2-x2previous) + sqr(y2-y2previous) ); No i zadany dmg przy kolizji tych punktów GML potworekID1 = collision_point(x,y, potworek, 0, 1 ); potworekID2 = collision_point(x2,y2, potworek, 0, 1 ); if ( potworekID1 != noone ) potworekID1.HP -= speed1 * (STRbohatera + atrybutAtakuMiecza ) if ( potworekID2 != noone ) potworekID2.HP -= speed2 * (STRbohatera + atrybutAtakuMiecza ) oczwiście to tylko teoria, którą teraz na szybko wymyśliłem i da się to ulepszyć oraz zoptymaliować pozatym nie wiem czy jest w 100% poprawna + jest jeden bug - za szybkie machnięcie może spowodować niewykrycie kolizji przez collision_pointy więc trzeba byłoby znaleźć jeszcze na to jakiś sposób ale na chwilę obecną nic nie wymyślę :P