SQT wersja angielska dociera do wiekszej liczby osob, kapujesz ?

ekrany z pierwszego  LEVEL'a do Rick Dangerous 1 mam zrzucone z C64 dzieki uprzejmosci pewnej osoby tworzacej mapy do gier, komplecik

Chcecie zrobic konkurencje Abbuc'owi ;)? Jak dotad tylko ABBUC potrafi motywowac. Tylko co z tego skoro wiekszosc produkcji jest marnej jakosci, wyjatkiem jest Dynablaster :)

Jakis grafik stworzy animacje ludzika i chce aby z tego powstala cala gra.

Brakuje grupy osob, ktore opracowalyby scenariusz gry (jesli to konwersja to scenariusz juz jest), grafike, muze. Bo na nowego Richarda Munnsa czy innego "czlowieka orkiestre" nie mamy co liczyc.

Chcialbym wiedziec przed napisaniem czegokolwiek, o co chodzi w grze, jak porusza sie glowny bochater, kim sa jego przeciwnicy, za co sa punkty, jak moze zginac, jak moga zginac przeciwnicy, jak zorganizowany jest ekran, czy to scrol pionowy, poziomy czy pojedyncze ekrany-komnaty, ile ma byc tych komnat, poziomow gry. Jak juz wszystkiego tego sie dowiem mozna zaczynac pisac bez obawy ze nagle kod programu bedzie musial zostac zmieniony o 180 st.

jest tutaj http://www.romnation.net/srv

to moze juz lepiej przesiadziecie sie na atari 8-bit i nie bedziecie sie tak nudzic :)

p.s.
srednio 8bitowiec, tu na forum jest lepszy o 50% od 16-32bitowca :)

dzieki Stryker za JagPad'a sprawuje sie znakomicie, a kasy nie oddam ;)

kolory wystepujace w obrazku sa sortowane od najczesciej do najmniej wystepujacych i po kolei, przypisywane sa im kolory, czyli najczesciej wystepujacy bedzie tlem

osobiscie jestem za jednym taskiem (procesem), gdzie cala moc CPU przydzielana jest wlasnie temu jednemu procesowi

wyobrazcie sobie obsluge myszki w multi-taskingu, przy kilku procesach, opoznienia wplyna na plynnosc ruchow myszki ktora jest zalezna wlasnie od czestotliwosci odczytywanie jej koordynat

najlepiej gdyby bylo sprzetowe wsparcie mychy, inaczej najlepszym manipulatorem staje sie JOY odswiezany na VBL'u

oczywiscie na C64 istnieje juz taki psudo-multitaskowy system (do 30 procesow) zwie sie Lunix

ciekawe jak oni sie do tego zabierali ze zdolali cos zrobic :)

z ta emulacja Konop ma racje, moze zbyt doslownie go zrozumieliscie, piszac aplikacje nalezaloby zrezygnowac ze wszystkich rozkazow odwolujacych sie do stosu i strony zerowej, przerwania wylaczone koniecznie

czysto teoretycznie wygladaloby to tak: wywolujemy task, jako parametry podajemy mu nowy adres stosu i strony zerowej, odpowiednie procedury modyfikuja procedury emulujace stos i strone zerowa, task rusza

wlasciwie ze strony zerowej moglibysmy zrezygnowac i emulowac tylko stos, MADS udostepnia stos programowy (malej poprawki dotyczyloby tylko wywolanie procedury w MADS), np.

; wywolanie procedury w MADS po nazwie procedury

 nazwa_procki

; MADS wymusza:
;
; JSR NAZWA_PROCKI
;
; a wiec juz korzystamy ze stosu sprzetowego $0100-$01FF
; teraz wystarczy poprawic MADS tak aby wykonywal tutaj makro,
; ktorego parametrem bedzie nazwa procedury (a wiec jej adres),
; np. na takie:
;
; .macro @EXECUTE
;    ldx @stack_pointer
;    lda >:1
;    sta stack,x
;    lda <:1
;    sta stack-1,x
;   
;    txa
;    sec
;    sbc #2
;    sta @stack_pointer
;
;     jmp :1    ; a najlepiej BRA :1 dla 65816 i bedzie relokowalne
;
;  .endm
;

.proc nazwa_procki

.endp

makro @CALL odkladajace parametry procedur na stos programowy moze zostac, natomiast makro @EXITPROC musi zostac poprawione, na np.:

.macro @EXITPROC

 ldx @stack_pointer
 lda stack,x
 sta _jump+1
 lda stack+1,x
 sta _jump+2

 txa
 clc
 adc #2
 sta @stack_pointer

_jump jmp $FFFF

.endm

tak wiec narzedzie jest, do tego konfigurowalne, oprocz nowego sposobu tworzenia aplikacji, musi istniec system udostepniajacy podstawowe komponenty, posredniczacy w komunikacji miedzy sprzetem a aplikacja

niewatpliwie najmilszy jest 65816, zaczalem pisac takie srodowisko wlasnie dla niego, latwiejszy relokowalny kod (skok bezwarunkowy BRA), stos programowy o rozmiarze wiekszym niz 256B, ktory latwo adresowac dzieki rejestrom 16-bitowym