Konrad-GM

Gdybyś pokazał w jaki sposób tworzysz bloki. Możliwe że tworzysz dwa naraz.

W GM, jak i w innych silnikach 3D, jest ograniczona liczba źródeł światła. A światło włączasz poprzez funkcję d3d_light_enable. Możesz zrobić dynamiczne przypisywanie świateł obiektom, które są relatywnie widoczne (np. przez różnicę distance pomiędzy graczem a pochodnią). W create pochodni np zmienna "lightId = 0;" i "enabled = false;", która określa ID światła i czy jest aktywne. Zaś w step można sprawdzać odległość np: GML if(!enabled && distance_to_object(objPochodnia) <= 100) { d3d_light_enable(lightId, true); // inne ustawienia swiatla jak kolor, range etc. enabled = true; } else if (enabled && distance_to_object(objPochodnia) > 100) { enabled = false; } W romie przy creation code pojedynczego obiektu można ustalać różne ID świateł do których pochodnie są przypisane. Dla optymalizacji można powielać ID świateł, ale które są daleko od siebie.

Czyżby coś się zmieniło w GMS? :P Szybki test: Jak widać obiekty z większym depth rysują się na początku ;p

No coś nie halo ;D Najpierw rysować należy kamerę (ustawia projekcje itd. z depth = 1000), później obiekty i świat (depth < 1000), a na końcu ponownie ustawić projekcję ale na ortho i rysować hud (depth < depth-świata). To tak dla ścisłości :)

Za dużo "nocy" ;p A tak to projekt prezentuje się bardzo dobrze. Borek musi się streszczać bo na Almorę popyt spadnie :borek: sarkazm kolego, borek porzucil almore

Nie zaprzeczę, jednak parę błędów posiada, no i oczywiście rozwinąć to do użytku wypadałoby ;)

Pracuję nad dodatkiem do Unity3D, a konkretnie nad budową sceny opartej na voxelach (w edytorze unity) z minkraftową teksturą Całość pisana w C# ;)

Można serializować dane z ds_map/grid etc. i np. zapisać do ini jako string.

Spróbuj manualnie pobierać znaki z klawiatury np. przez getchar aby rozpoznawać pojedyncze znaki.

Bodajże input stream również rozdzielany jest poprzez spacje, tj. int a, b, c; cin>> a >> b >> c; cout<<"a = "<< a<< "\n"<<"b = "<< b<< "\n"<<"c = "<< c<< "\n"; // #>10 20 30 // a = 10 // b = 20 // c = 30

Zrób webowego GameMakera ;D

N00b xD

Sterowanie odstrasza, strasznie niewygodne :/ Szkoda, Contra mimo limitu daje radę ;)

Jak na niby-NESa, dość sporo kolorów ;)

Jest to możliwe, jeżeli umiejętnie posłużyłbyś się np. funkcjami grupy http_* i skorzystał z web API

Na tym polega "fenomen" Draw GUI - żaden event Draw GUI nie uwzględnia przesunięć view_x/yview, to tak jakby rysować przy projekcji ortho o współrzędnych 0,0 na ekranie

Zatem jest ich więcej :P

Poza paroma błędami, a jest ich sporo (głównie dziury w mapie, łamanie nadgarstków), gra jak na alphe jest ok. Wymaga duużo poprawek, nieraz wypadłem poza mapę przez ścianę trzymając skrzynię czy beczkę. Screen o jakie dziury mi konkretnie chodzi (nie wiem czy tak miało być):

Można też zastosować 'cover'a http://www.w3schools.com/cssref/css3_pr_background-size.asp

Jakby kogoś interesowało rozwiązanie: ; void __fastcall__ pal_fill(const byte* colors); _pal_fill:; A - low-bytes pointer, X - hi-bytes pointer STA ptr2 ; store data address into zeropage - 2bytes STX ptr2+1 LDA $2002; hi/low seek reset LDA #$3F ; seek PPU address to $[3F]00 - hi-byte STA $2006 LDA #$00 ; seek PPU address to $3F[00] - low-byte STA $2006 LDY #$00 ; start indexing @1: LDA (ptr2), Y; read data STA $2007 INY CPY #$10 BNE @1; loop limit RTS Argument funkcji pal_fill to wskaźnik 2 bajtowy na dane 1-bajtowe, przy wywoływaniu funkcji zachowany jest w dwóch rejestrach 1-bajtowych - A i X. ptr2 to po prostu adres na pamięć 2-bajtową w sekcji tzw. zeropage. Delkaracja ptr2 znajduje się w pliku ASM zeropage.inc od cc65.

Cześć i czołem bracia i rodacy, mam do was pytanie moi mili, otóż prosiłbym by ktoś kto zna ASM mógł mi wytłumaczyć parę spraw. Otóż chodzi o adres (wskaźnik) jaki otrzymuje funkcja w ASM wywoływana z poziomu kodu C. Nie jest to "zwykły" ASM pod procesory x86, tylko zająłem się dość "starą" technologią NES z procesorem MOS 6502. Różnice to oczywiście rejestry i 8bitowa pamięć. Korzystam z kompilatora CC65 pod Win8. W języku C mam zamiar zawrzeć logikę gry, zaś w ASM wszystkie pozostałe rzeczy jak zarządzanie kontrolerami, dźwiękiem (APU) czy grafiką (PPU). Do rzeczy: W celu wywołania funkcji napisanej w ASM korzystam z trywialnego kodu: void __fastcall__ pal_fill(const byte *data); // import pal_fill(palPaleta); // wywolanie Dla optymalizacji, poprzez __fastcall__ ładuje wskaźnik *data do rejestru. Jednakże z racji iż jest to 8bitowy procesor, a wskaźnik 16bitowy, rozkładany jest na partie 8bitowe w rejestrach tj. A i X. Teraz problem pojawia się iż chciałbym wczytać zawartość znajdującą pod wskaźnikiem, jednak nie mam za bardzo pojęcia jak się za to zabrać. Co prawda kompilator C przekształca źródła z C na plik ASM, jednak jest to mało optymalizowane i wygląda jak śmietnik. Pętla w ASM: _pal_fill: LDY $2002; reset PPU states LDY #$F3 STY $2006; hi-byte of $[3F]00 - PPU seek address LDY #$00 STY $2006; low-byte of $3F[00] - PPU seek address LDX #$00; start indeXing from 0 @1: ;??? LDY A, X; load colour from address A + X into Y reg !!! tutaj następouje "syntax error", jak wspomniałem, rejestry są 8 bitowe ;??? STY $2007; put colour from Y reg into PPU pallete INX; X = X + 1 CPX #$10; if X == 16 BNE @1; above cmp is true -> continue RTS; return to C Zastanawiam się czy nie należy tutaj użyć "stack"a, (sp), coś a'la: STA (sp) STX (sp)+1 ... LDY (sp), X Pozdrawiam, Konrad

Zapomniałeś o jednym. "w+" flag - write/update: Create an empty file and open it for update (both for input and output). If a file with the same name already exists its contents are discarded and the file is treated as a new empty file.

Uśmiałem się, +1

W GM:Studio działają surface'y w trybie 3D z tego co kojarzę. Rysuj ten kwadrat na oddzielnym surface nawet o mniejszej rozdzielczości (pixel-perfect zaznaczanie chyba nie jest Ci aż tak potrzebne :) ), i na nim stosuj funkcję: surface_getpixel

Nawet GameMaker ma własny "mainloop". Bo chyba o to chodzi w Game Engine'ach. Modding a'la Unity czy UDK jest ok... :P