1

Temat: software objekt ;-)

witam, kolejna prosba o optymalizacje

procedura ma wstawiac na ekran softwarowego bajera

               ldy #sob_lenght
_copy       lda playfield,y
; sta temp_playfield,y
               and sob_mask,y
               ora sob_data,y
               sta playfield,y
               dey
               bpl _copy

pytanie czy mozna to zrobic inaczej (szybciej) i jaka ma byc organizacja ekranu. w przypadku jak powyzej
chyba najlepiej aby to byl tryb znakowy kazda linia kody od 0 - 31. zaznaczam, ze co 1-3 ramki cala linia 32 znaki beda przedefiniowane wiec nie ma potrzeby zachowywac tego co plajer nadpisal. pozycja x bedzie zarazem kodem znaku - ruch co 1 znak.

jest jeszcze opcja na trybie bitowym (jak w grze phantom) - nie mam doswiadczenia w temacie dlatego chcialbym sie dowiedziec co bedzie szybsze ? trzeba brac pod uwage rozniez to ze antic nie hamuje tak 6502 przy trybach znakowych. a skoro juz mam mikrofon - czy urzywanie niepublikowanych rozkazow 6502 jest trendy ?

ps. jak na forum pisac kod? <pre> dziala? </pre>

Ostatnio edytowany przez xxl (2005-07-21 08:06:04)

http://atari.pl/hsc/ad.php?i=1.

2

Odp: software objekt ;-)

czy urzywanie niepublikowanych rozkazow 6502 jest trendy ?

Bardziej trendy jest używanie słownika ortograficznego :)

Co do nielegali uzyskasz pewnie kilka cykli szybkości, ale musisz się liczyć, że program nie będzie działać np. na 65816.

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

3

Odp: software objekt ;-)

uzywanie nielegalnych (tudziez nazywanych niepublikowanymi) jest feeee
i to na tyle feeee co uzywanie nielegalnych skokow

po to sa oficjalne tablice skokow/oficjalne kody rozkazow, coby wsio dzialalo
wszedzie (uwaga, trudne slowo: ,,compatibility'') np. na 65C02 ktory tez
nie obsluguje rozkazow ,,dodatkowych'' ,,normalnego'' procesora MOS6502

btw. dely - czepiasz sie ;) ale to czepianie sie fajnie ci wyszlo :D
mi tam slownik podlacza sie pod textarea w firefox-ie z wielkimi oporami (wsio w powietrze wylatuje ;/ )

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

4

Odp: software objekt ;-)

xxl napisał/a:

procedura ma wstawiac na ekran softwarowego bajera

               ldy #sob_lenght
_copy       lda playfield,y
; sta temp_playfield,y
               and sob_mask,y
               ora sob_data,y
               sta playfield,y
               dey
               bpl _copy

Ale osssochodzi? Wyjaśniłbyś co to sob_mask i sob_data i co zawierają, bo kawa naturalna mielona się skończyła, została tylko rozpuszczalna i fusów niet. Może dałoby się połączyć te dwie tablice w jedną i całą sprawę załatwić jednym eorem?

xxl napisał/a:

trzeba brac pod uwage rozniez to ze antic nie hamuje tak 6502 przy trybach znakowych.

Nie? A mnie się wydawało, że Antic jednak w trybach znakowy bardziej spowalnia. Mogę się mylić, ale lepiej to sprawdzić.

Za stosowanie nielegali powinno się skazywać delikwenta na dożywotnie używanie Atari Basica. ;)

Zawsze mam rację, tylko nikt mnie nie słucha.

5

Odp: software objekt ;-)

no to mam juz odpowiedz na najmniej istotne pytanie. temat nepublikowanych rozkazow uwazam za zamkniety.

pozostaje pytanie glowne. organizacja ekranu i szybka procedura rysowania plajera.



---------
o wlasnie.

podgladalem zrodla rysowania sprajtow na trumnie i w sumie mozna to tak zapisac:

ekran: 11110000, maska plajera: 11000011, plajer: 00011000
(maska jest zawsze tak dobrana aby zostal 'wolny pixel' miedzy tlem a plajerem.


na ekran zostanie zapisany: 11011000

Ostatnio edytowany przez xxl (2005-07-21 12:44:39)

http://atari.pl/hsc/ad.php?i=1.

6

Odp: software objekt ;-)

Mi się słownik podłącza pod mózg (tak! mam coś takiego).

A ciągnąć dalej temat używania nielegali to, jak napisałem już wcześniej nie opłaca się całkowicie. Np. wyobraź sobie (nie, nie boisko), że Twój program będzie chciał uruchomić użytkownik takiego DracOS-a. Nie uda mu się to ponieważ DracOS wymaga '816, a ten widząc rozkaz z poza listy oficjalnie udokumentowanych wykona na pewno nie to, co chciałeś xxl :)

Możesz też zrobić alternatywną wersję procedury (z nielegalami oraz bez) i zrobić wykrywanie procesora. Tak np. postąpili Hard, którzy użyli nielegali w plot landscape w demie Joyride. Na "normalnym" 6502 landscape działa, natomiast na 65816 zamiast spektakularnego odlotu systemu B KOCMOC efekt stoi, a demo leci dalej :)

Czy możecie wyjaśnić, Stirlitz, dlaczego wasz służbowy adres stirlitz@rsha.gov.de ma aliasa justas@gru.su?
Nie czytam PM. Proszę używać e-mail.

7

Odp: software objekt ;-)

nielegalom mowimy stanowcze NIE.

http://atari.pl/hsc/ad.php?i=1.

8

Odp: software objekt ;-)

ps. jak na forum pisac kod? <pre> dziala? </pre>

sądze ze najprościej używając znaczników bbcode
(popatrz na linka tuz pod szybka odpowiedzia o tej nazwie ;)

Mi się słownik podłącza pod mózg

nie kazdy jest na tyle inteligentny ;)
jako dyslektyk musze sie wspierac ksiazkowa wersja badz komputerowa
tego narzedzia ;)

Ostatnio edytowany przez jellonek (2005-07-21 15:59:02)

The UNIX Guru`s view of Sex:
unzip; strip; touch; finger; mount; fsck; more; yes; umount; sleep

Odp: software objekt ;-)

Za moich czasow nie bylo dyslektykow ;)

A zeby nie podpasc pod regulamin: nielegale sa fe, chociazby dlatego, ze BugHunter ich nie widzi! ;)

10

Odp: software objekt ;-)

ONT: Nielegale sa be :)

OFFT.
sobie kiedys napisalem takiego pelnoekranowego debugera co widzial nielegale oraz dodatkowe rozkazy procka SALLY. Niestety, chyba przepadl, bo szukalem dlugo na wszystkich dyskietkach i atr'ach jakie mam.
Nie byl puszczony nigdy, ale moze ktos jakas moja dyskietke 'skubnal' na party jakims to moze to tam jest. Oddam gacie za ten program (zbieram swoje stare 'dziela') Binarka nazywala sie DISASSOR.COM, a na dysku ze zrodlami byl plik DISMYASS.ASM (to pamietam dokladnie) Jakby ktos mial to gdzies to sowicie sie odwdziecze oraz upublicznie program oczywiscie.
ps. program pracowal na pelnym ekranie z 'przeplotem' co linia trybu GR.0 bylo $0 antica) Cos takiego tight freezer mial. Dodam ze program ogladalo pare osob, w tym Waldi oraz chyba Samurai albo Slaves. (na qp97)
Wszelkie info mile widziane.
<OFFT:>

11

Odp: software objekt ;-)

zmyslasz Mikey, takiego programu nigdy nie bylo :P

*- TeBe/Madteam
3x Atari 130XE, SDX, CPU 65816, 2x VBXE, 2x IDE Plus rev. C

12

Odp: software objekt ;-)

Mikey, a nie wyslales Waldiemu tego proga, zeby zupgrejdziel? ;)

13

Odp: software objekt ;-)

Tebe jak zwykle w formie :P
Vasco: nie, pamietam ze pokazywalem waldiemu osobiscie u niego w domu, i potem napewno zabralem dyskietke :)

14

Odp: software objekt ;-)

wylamujac sie poza szereg i piszac o czyms innym niz nielegalach...
na spektrumie ta dodatkowa ramka na okolo sprajta byla powodowana tym, ze w znaku mogles miec 2 kolory (przykladowo) wiec jakby jej nie bylo, a sprajt bylby w kolorze innym niz np drzewo to wygladalo by to fantastycznie - mianowicie kawalek drzewa bylby przemalowany na jakis inny kolor z dziwnym wzorkiem na lisciach
po prostu calosc zlala by sie
przy twojej organizacji ekranu wybor trybu nie powinien miec znaczenia - czy to bedzie tryb znakowy czy tryb graficzny ilosc danych jaka antic bedzie musial pobrac bedzie porownywalna, z tym, ze w trybie znakowym mozesz przynajmniej teoretycznie miec obok siebie kilka takich samych znakow, co powinno zaowocowac jednym dostepem antica do pamieci generatora znakow - ale to czysta teoria - praktycy niech sie wypowiedza
zamiast redefiniowac zestaw co 1/3 ekranu i miec sobie commodorowska organizacje pamieci tegoz ekranu pomyslalbym na twoim miejscu o jednym zestawie znakow z wydzielonym obszarem na znaki redefiniowalne
co prawda ograniczy ci to ilosc mozliwych obiektow ktore bedziesz mogl zasymulowac, ale tez zmniejszy ilosc potrzebnej pamieci i zaoszczedzi troche cykli

przechodze na tumiwisizm

15

Odp: software objekt ;-)

no nie calkiem, wybierajac tryb znakowy masz o tyle prosciej ze bajty sprite np 8*8 (tryb antica 2) leza kolo siebie - tak jak pm, na ekranie i w pamieci, w trybie bitowym dane takiego sprite mozesz trzymac w jednym miejscu  ale przy wyswietaniu beda oddalone o x bajtow. poza tym latwiej zrobic detekcje kolizji, animacje. ja to tak widze, ale chcialbym poznac zdanie innych.

http://atari.pl/hsc/ad.php?i=1.

16

Odp: software objekt ;-)

ale jak sobie go przesuniesz o 1 pixel to juz jest na dwoch znakach i zaczyna sie zabawa :]

przechodze na tumiwisizm

17

Odp: software objekt ;-)

to trzeba sprita 8*8 trzymac w matrycy 16*16 ? ;-)  i tu jest wyzwanie dla MASA koderow. albo... przesuwac co 1 znak a nie pixel :-)

z przyjemnoscia obejrzalbym zrodlo softwarowego sprita z przesuwaniem co 1 pixel w grafice znakowej 2 lub 4 antica.

http://atari.pl/hsc/ad.php?i=1.

18

Odp: software objekt ;-)

Candle: pozycja pozioma spritea jest niezależna od jego szerokości, więc jak przesuniesz o jeden piksel - nadal masz jego dane w tym samym miejscu. Same kierowanie duszkami jest niezależne od trybu, inna jest tylko organizacja pamięci ekranu.

Sikor umarł...

19

Odp: software objekt ;-)

Tylko mowa tutaj o sprite'ach software'owych, a Ty Sikor wyjeżdżasz ze sprzetowymi.

XXL, co z tego, że w trybie graficznycznm piksele o tej samej współrzędnej są oddalone od siebie skoro są oddalone od siebie zawsze o tyle samo. :P Zamiast:

lda sprite
sta ekran
lda sprite+1
sta ekran+1

robisz:

lda sprite
sta ekran
lda sprite+1
sta ekran+32 ; 40, 48, czy jak tam czhcesz mieć szeroki ekran
Zawsze mam rację, tylko nikt mnie nie słucha.

20

Odp: software objekt ;-)

xxl napisał/a:

to trzeba sprita 8*8 trzymac w matrycy 16*16 ? ;-)  i tu jest wyzwanie dla MASA koderow. albo... przesuwac co 1 znak a nie pixel :-)

Trzymac go mozesz jako 8*8, ale liczyc musisz na matrycy 16*16 (zawsze trzeba wypelnic definicje 4 znakow pod spodem - tylko w kilku sytuacjach bedzie to 2 znaki a wyjatkowo 1). Na szczescie w trybie znakowym nie musisz zapamietac calego tla - wystarcza Ci kody 4-rech znakow pod spritem, a tlo odtwarzasz z ich definicji wlasnie.

xxl napisał/a:

z przyjemnoscia obejrzalbym zrodlo softwarowego sprita z przesuwaniem co 1 pixel w grafice znakowej 2 lub 4 antica.

Napisanie takiej (a do tego uniwersalnej i obslugujacej zadana liczbe obiektow) procedury nie jest bardzo trudne - poglowkowac trzeba troszke tylko - polecam :).
Moze to nie jest zrodlo a efekt dzialania - ale popatrz na animacje napisu LASERMANIA w tej grze - tam nawet wieksze sa te sprity ;)

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

21

Odp: software objekt ;-)

hmmm zerkam.  na czym polega sztuczka 2 zestawow znakow i DL z pobierajacym danych 2 razy z tego samego miejsca? dlaczego odrazu nie zdefiniowac pobieranie tylko 40 bajtow przez antic na calym ekranie i manewrowac zestawami znakow. wszelkie operacje dokonujemy w pamieci znakow.

wracajac do glownego watku. nie chodzi mi o niewiadomo jaka procedure mistrzow swiata z avalonu tylko o optymalizacje procedury ktora ma polozyc sprita na znakach w okreslonym miejscu z dokladnoscia do jednego znaku a nie pixela z tym tylko aby tlo bylo widoczne pod znakiem tak jak opisalem w 1 poscie. mysle ze mozna to przyspieszyc badajac tylko skrajne bajty sprita. cos komus przychodzi do glowy?

http://atari.pl/hsc/ad.php?i=1.

22

Odp: software objekt ;-)

xxl napisał/a:

na czym polega sztuczka 2 zestawow znakow i DL z pobierajacym danych 2 razy z tego samego miejsca? dlaczego odrazu nie zdefiniowac pobieranie tylko 40 bajtow przez antic na calym ekranie i manewrowac zestawami znakow. wszelkie operacje dokonujemy w pamieci znakow.

Po drugie jesli bedziesz mialpo prostu 40-to znakowy ekran,to gdzies w okolicach 4tego wiersza skonczy Ci sie zestaw znakow. Tak wiec lepiej wtedy robic 32 znakowy, albo podmieniac zestawy a te kilka nigdy nie wyswietlanych znakow zastosowac przy wyswietlaniu spriteow.

Po pierwsze ;) tryb z dwoma zestawami znakow zmienianymi co wiersz jest bardzo wygodny w przypadku gier w ktorych plansze skladaja sie z blokow 2*2 znaki. Co drugi wiersz znakowy jest powieleniem poprzedniego, wiec nie zajmuje miejsca w pamieci i nie trzeba na nim operowac przy zmianie obrazu. Po prostu pierwszy zestaw znakow zawiera gorna polowke obiektow, a drugi dolna... powielenie "robi sie samo" zmieniasz dwa znaki w pamieci ekranu, a na ekranie zmienia sie obiekt majacy 4 znaki :)
W takim przypadku trudniej jest zapanowac nad spriteami programowymi, dlatego zazwyczaj naklada sie sprzetowe przy ruchach obiektow przekraczajacych raster - LASERMANIA w czasie gry np.

Bla bla bla bla, bla bla bla. Bla bla bla - bla - bla. Blabla bleee.

23

Odp: software objekt ;-)

Mikey a pamietasz BAD SECTOR WRITER, taki eliciarski nigdy nie publikowany util Vasca :D

24

Odp: software objekt ;-)

no ba, l33t c0de.

25

Odp: software objekt ;-)

Ja w tej sprawie offtopicznej sie wypowiem.

Mianowicie przyszlo mi na mysl, ze teoretycznie jest mozliwe aby maszyna wyposazona w procesor 65816 wykonywala rozkazy "nielegalne" z repertuaru 6502, oczywiscie za posrednictwem odpowiedniego programu.

Trudnosc polegalaby na wydzieleniu czesci stanowiacej kod rozpatrywanego programu z nielegalami od czesci z pozostalymi danymi. To mozna byloby teoretycznie zrobic automatycznie, co nie jest niemozliwe, ale za to niezmiernie trudne, albo poprzez wskazanie programowi w jakims dodatkowym pliku, czy w innej formie.

Dalej wystarczyloby "przeleciec" kod programu z nielegalami w ich poszukiwaniu i zapamietac wszystkie adresy ich wystapienia wraz z kodem nielegalnego rozkazu, a w to miejsce wstawic instrukcje BRK wywolujaca przerwanie.
Podczas przerwania BRK sprawdzany bylby kod nielegala i wywolywana odpowiednia z procedur symulujacych dzialanie stosownego typu nielegala. Ewentualne argument(y) dla tej symulowanej instrukcji znajdowalyby sie zaraz za instrukcja BRK. Po tym dzialaniu nastepowalby juz tylko powrot do programu z symulowanymi instrukcjami zaraz za ta instrukcja i jej argumentami.
Teoretycznie wiec kazdy niemal program z uzyciem nielegali pozostawiajacy w spokoju przerwanie BRK i odpowiedni skrawek przeznaczonego na ten cel obszaru pamieci programu symulujacego nielegalne instrukcje, mozna byloby wykonywac na maszynie z procesorem 65816, oczywiscie zaznaczajac tutaj ta okolicznosc, ze czas wykonywania niektorych fragmentow kodu bylby znaczaco wolniejszy niz wczesniej.

Oczywiscie zgadzam sie z opiniami, ze nie jest to pomysl wart realizacji. Skadinad wiadomo, ze nielegale 6502 (dowiedzialem sie o nich po przeczytaniu artykulu w "Atari Magazynie", pt. "Nielegalne rozkazy procesora 6502", Draco), sa praktycznie malo uzyteczne i z tego co powszechnie wiadomo, nie sa praktycznie uzywane. To tylka taka teoretyczna proba zmiezenia sie z problemem, ktorego faktycznie nie ma.