hehe laoo ;)
niezle, nawet bardzo, przy duzej ilosci punktow zysk bedzie znaczacy,
tylko trzeba by bylo aktualna procke mnozenia przerobic tak aby korzystala ze wskaznikow do tablic na stronie zerowej, ale to raczej nie problem

niezle ;)
jesli dobrze licze to mamy juz 107..118cykli ;)

przy mnozeniu 8x8 ten trick oczywiscie dziala i jest powszechnie uzywany, i dzieki czemu zyskujemy bardzo duzo cykli (dokladnie 19)
ale przy 16x8 niestety tego nie mozna zastosowac...

w rzeczywistosci to 106..120, bo oczywiscie nie bedziemy mnozyc stalych tylko zmienne ;)

dzieki Eru, wlasnie o taka optymalizacje mi chodzilo ;)

    lda (zch),y
    adc (zdh),y
    ldy #0
    cmp #$80
    bcc *+4
    ; A*Blo is negative
    dey
    clc
ial    adc tal,x

ten kod da sie jeszcze zoptymalizowac o 2 cykle, korzystajac z tricku z instruckja "bit":

ldy #0, cmp #$80,bcc*+4 => 7cykli
ldy #0, cmp #$80,bcc*+4,dey,clc => 10cykli

    lda (zch),y
    adc (zdh),y
    bpl skok
    ldy #$ff
    clc
    dta #{bit $1000}
skok    ldy #0
ial    adc tal,x

bpl skok,ldy #0 <- 5cykli (2 cykle zysku)
bpl skok,ldy #$ff,clc,bit XXXX <- 10 cykli

wiedz uzywjac tego tricku mamy wersje, ktora dziala w 104..120 cykli ;)

no jesli zalozyc ,ze zawsze po operacji mnozenia bedzie sie dodawac to zyskamy 2 cykle, jesli B jest ujemna, zawsze cos ;)

oczywiscie mnozenie bedzie uzywane do obrotow punktow:

X'=(M1*X + M2*Y + M3*Z) / 128

dzielnie liczby 24bitowej przez 128 to tylko 15cykli (niezaleznie od tego czy jest ujemna czy nie! - przy 16bitowej liczbie trzeba by bylo to sprawdzac...), jesli by olac ostatnie 8bitow to bysmy mieli dzielnie przez 256 i mniejsza dokladnosc (w wysokiej rozdzielczosci to tak nie przeszkadza ale w rozdzilczosci powiedzmy 80x48 cos takiego jest bardzo widoczne bo obiekt przy obrocie trzesie sie jak galareta)

troche zle policzyles cykle, bo zysk bedzie zerowy "sta adres" zjada 4cykle a nie 3(chyba ,ze procka by byla na stronie zerowej co raczej odpada bo trzeba by bylo korzystac z jsr/rts co zjada 12cykli ;>), "lda $8000,y" jest o jeden cykl szybsza niz "lda ($00),y" ale ten 1 cykl zysku traci sie po przez "sta adres16" zamiast "sta adres8"

z usunieciem eor #$80 / eor #$ff i zrobieniem dodatkowych tablic to dobry pomysl ;)
ale z "lda :1 eor #$80 tay" chyba juz nie bedzie tak latwo, aby to zastapic samym "ldy :1"

no tak tylko ,ze uwzgledniajac tyle mozliowsci te tablice beda juz zajmowac ~32k, zmiana bankow zajmuje tez troche cykli, wiedz moze byc to nie warte zachodzu...

dzieki za odpowiedz, zachwilke wysle przyklad na mail'a

klopot w tym ,ze w tych grach pobieranie danych od klienta (uzytkownika) nie jest tak rozwiazany jak w grach na atari...
np w Quake wyglada to mniej wiecej tak: jesli gracz wykona jakis ruch nastepuje wysylanie pakietu z ta informacja do servera, teraz server wysyla ta informacje do wszystkich graczy, teraz jak gracz otrzyma informacje ,ze on lub jakis inny gracz/obiekt wykonal ruch wykonuje go (wiedz w tym momecie sa pewne opoznienia), tylko ,ze teraz ten ruch bedzie sie wykonywal przez iles tam nastpenych klatek (poniewaz gracz tam nie przesuwa sie o wsporzedne rzedu -1/+1(tak jak to ma miejsce na atari) a o wartosci zmiennoprzecinkowe tzn. jesli gracz wykona ruch do przodu o vector np. [0.0, 2.0, 0.0] to w zaleznosci od szybkosci poruszania sie gracza (i ilosci klatek na sekunde na danym komputerze) co klatke ten gracz bedzie wykonywac ruch o np. [0.0, 0.2, 0.0] wiedz wykonanie calego ruchu zajmie mu 10klatek i to daje sporo czasu na wyslanie lub odbior nowych pakietow dzieki czemu mimo np. pingu 300 da sie uniknac "zabich skokow"

na atari jak by byl ping 300 to w ciagu sekundy byly by mozna wykonane max 3-4 ruchy gracza... w innych grach typu Quake itp tez ale jak juz wczesniej wspominalem tam te 3-4 ruchy starczyly by aby zajac 1sekunde na ich wykonanie dzieki czemu gracze caly czas by plynnie sie poruszali i nie bylo by zadnych przeskokow, na atari gracz by wykonal tylko 3-4 ruchy na 50 mozliwych (tzn przesunol by sie np. o 3-4pixele chociaz moglby w tym samym czasie przesunac sie o 50pixeli)

chodzi mi o to,ze gry na atari nie byly pisane pod katem gry sieciowej ;)

wezmy prosty przyklad: niech jeden gracz ma caly czas joy'a w prawo, w grze w ktorej poruszamy postacia w prawo i w lewo o 1 pixel. Przy pingu stalym <20ms bedzie wszystko ok postac plynnie bedzie sie poruszac w prawo. Przy pingu ,ktory chodz przez chwile bedzie miec opoznienie >20ms nastapi "zabi skok" poniewaz pakiet nie zdazy dojsc w odpowiednim momecie do Atari i postac jako ,ze interfejs nie otrzymal stanu joysticka pozostanie przez 1/50 sekundy w miejscu
jak cos takiego bedzie wystepowac troche czesciej niz 1 raz na sekunde bedzie to napewno widoczne.
w sumie mozna bylo by to rozwiac tak ,ze jesli interfejs na czas nie otrzymal by odpowiedzi od gracza moglby powtorzyc ostatni komunikat jaki dostal od gracza, dzieki czemu zostal by usuniety problem z "zabimi skokami" i przy pingu <50ms dalo by sie sensownie grac, ale przy pingu wiekszym powielanie ostatniego stanu joysticka dalo by efekt slizgania sie postaci na lodzie...

moze zbytnio teoretycznie i za bardzo sie czepiam ;) ale mysle ,ze problem z obsluga i przesylaniem pakietow powinien byc rozwiazany w pierwszej kolejnosci...

Hej!
Jesli chodzi o jezyk programowania to polecam asemblera, jest to jedyny sensowny jezyk w jakim mozna programowac na atari i wcale nie taki trudny jak niektorzy mowia. Jesli masz juz jakies doswiadczenie/pojecie o programowaniu to nie trac czasu i nie zawracaj sobie glowy Turbo Basic'em, Action! itp. Asembler naprawde nie jest taki trudny na jaki wyglada, poprostu trzeba miec troche inne podejscie.
Jesli chodzi o kompilatory to pod Windowsa polecam xasm (bardzo szybki i dobry kompilator) oraz MADS, ktorego sam ostatnio uzywam (o wiele wolniejszy ale za to ma to czego nie ma xasm a co bardzo upraszcza sprawe w duzych projektach - MAKRA! wiedz jesli nie masz takiego trupa jak ja tylko jakis szybszy komp to nie powinno ci to robic problemu), jest jeszcze hardcore assembler Epiego, ktory jest mega szybki i posiada tez makra itp (niestety narazie nie kojarze aby byl dostepny publicznie :( ). Co do linuxa to jest pewien crossasembler ale nie pamietam nazwy ^__^
wszystkie wyzej wymienione programy sa to crossasemblery i mysle ,ze o wiele wygodniej i lepiej jest pisac na PC+emulator niz siedziec przy Atari (sam kiedys wolalem siedziec i programowac na real Atari, ale teraz poprostu wiem ,ze napisanie wiekszego projektu bylo by prawie nie mozliwe, w najlepszym przypadku bardzo utrudnione), pod Emulcem masz swietny Debuger oraz nieporownywalna wygode pracy.

Co do petli FOR to najprostrza wyglada mniej wiecej tak w C++:

  for (char i=0; i<64; i++)
  {
    tmp=tmp+i;
  }

natomiast w Asemblerze 6502 tak:

  ldx #0 ; int i=0
loop
  txa
  clc
  adc tmp
  sta tmp ; tmp=tmp+i
  inx ; i++
  cpx #64
  bne loop ; skoczy gdy X<64 (dokladniej gdy nie rowne 64)

instrukcja IF to tez prosta sprawa

C++
  if (A==B)
    ...


Asm6502:
  lda A
  cmp B
  bne endif
; A=B
  ...

endif

i drugi przyklad

C++
  if (A>=B || A<C)
  {
    ...
  }
  ...


Asm6502:
  lda A
  cmp B
  bcs warunekspelniony ; skocz gdy A>=B
  lda A
  cmp C
  bcc warunekniespelniony ; skocz gdy A>=C
warunekspelniony
  ...

warunekniespelniony
  ...

a co do ogolnego programowania to wcale nie musisz znac na poczatku sprzetu ;) w praktyce (bynajmniej jesli chodzi o prace "scenowe") wystarczy podstawowa znajomosc ANTIC'a + wiadomoci o organizacji pamieci ekranu oraz w jaki sposob dane sa przechowywane w pamieci komputera. Jesli miales juz stycznosc z programowaniem to po zalapaniu tego nie powinno byc klopotow (no dopoki nie bedzie ci potrzebne szybkie mnozenie lub inne "nienaturalne" operacje matematyczne ;> ale to juz troche inny temat)

No ja tez mam jeszcze 19lat ;P
A co do wolnego czasu to roznie ale i tak nie narzekam...
jak bys mial jakies pytania/problemy to wal do mnie na GG:2342303 z checia pomoge

oczywiscie wszystko zalezy jaka to bedzie "obrobka". Teksturowanie napewno bedzie wolniejsze bo juz je testowalem jakis czas temu ;) co do blur'a to sie nie wypowiem, wszystko zalezy od algorytmu, dla dokladniejszego blur'a prawdopodobnie sposob z buforem 1bajt/pixel bedzie szybszy i wygodniejszy, poniewaz trzeba bedzie odczytywac kilka pixeli (co napewno bedzie szybsze niz bawic sie z nibblami), w sumi gdyby sie zastanowic to mozna dojsc do wniosku ,ze wszystkie algorytmy ktore wymagaja odczytu zawartosci pixela powinny dzialac szybciej z buforem 1bajt/pixel, bo caly klopot to wlasnie odczyt pixela z bufora (trzeba ANDowac albo uzywac do tego tablic) a nie zapis...

jedno jest pewne, taka organizacja ekranu jest "ladna" z punktu widzenia programisty bo wtedy bardzo przyjemnie sie pisze program, z szybkoscia bywa roznie ;)

trzeba jeszcze wziosc pod uwage, ze czyszczenie takiego bufora zajmuje 2 razy wiecej czasu niz czyszczenie ekranu, poniewaz bufor bedzie 2 razy wiekszy niz pamiec ekranu...

a co do:

lda kolor
ldy pos_x
sta (screenp),y

policzmy cykle: 3+3+6=12cykli na zapis do bufora, teraz dodamy jeszcze cykle jakie sa potrzebne zeby "skonwertowac" pixel:

ldx backbuf
lda mul16tb,x
ora backbuf+1
sta screen

mamy 4+3+4+4=15cykli/per two pixels, czyli srednio 8cykli na pixel, dodajmy to 12+8=20 cyki, do tego jeszcze dochodza 4 dodatkowe cykle na czyszczenie bufora, 10+4=24 i tyle potrzeba cykli aby postawic 1 pixel.

teraz normalna procka do stawiania pixeli (na nibblach):

ldx pos_x
ldy div2tab,x
lda (scr),y
and maska,x
ora kolor,x
sta (scr),y

3+4+5+4+4+6=26cykli

hmm czyli teoretycznie wyglada na to ,jesli dobrze wszystko obliczylem ,ze stawianie pojedynczych pixeli jest szybsze w trybie "chunk" o 2 cykli T___T, ale napewno jest wolniejsze niz stawianie kilku pixeli na raz, bo procka na nibblach by wygladala mniej wiecej tak:

ldx kolorpixelapierwszego
lda mul16tb,x
ora kolorpixeladrugiego
sta (scr),y
iny
...

co by dawalo 3+3+3+6+2=17cykli/per two pixels, czyli 8/9 cykli na pixel

a w "chunk" wygladalo by to tak:

lda kolorpixelapierwszego
sta (scr),y
iny
lda kolorpixeladrugiego
sta (scr),y
iny

3+6+2 + 3+6+2 = 22cykli na zapis do bufora + 8 cykli na wyczyszczenie bufora + 15cykli na konwersje, czyli mamy razem 35cykli/per two pixels!!! czyli 17-18cykli na pixel!!! co jest dwa razy wolniejsze niz ta sama procedura na niblach....

sorry, za lekkie spoznienie...
tutaj mozna zassac skany: http://83.18.144.22/~pr0be/corewars.zip.

zgadza sie, Wojny Rdzeniowe byly w czasopismie "Moje Atari" 6/91, mam wlasnie ten numer przed soba, ale nie mam niestety skanera, popytam sie kumpli moze ktos w poblizu ma, to zeskanuje...

hehe tez kiedys nad tym myslalem ;)
pomijajac fakt wygenerowania tych obrazow oraz ich przechowania, to niestarczylo by nikomu zycia aby przejzec chociazby 1/10000000 tych zdjec, pomijajac juz fakt ,ze 99,9% tych obrazow nie nadawalo by sie wogole do ogladania ;)