Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Silly Venture 2024 SE - stuff Dostępny jest już stuff z zeszłomiesięcznego party Silly Venture 2024
FujiCup FujiCup ma na celu wspieranie sceny gier retro, dając uczestnikom szansę na pokazanie swojego talentu
Echa Silly Venture 2024 SE Są już dostępne wyniki Silly Venture 2024 SE
Uaktualnienie firmware do The400 Poprawki do "fizycznego" emulatora ośmiobitowych komputerów i konsol Atari.
Akcja - Wsparcie w reverse-engineering Wspierajmy tych, którzy do tej pory zrobili wiele!
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
To ja bardzo ładnie poproszę o relokowalną prockę, która sobie ściąga przesłane parametry ze stosu (X,Y,R,SCRN_W,SCRN_H) plus LDA i RTS, coby szło z bejzika odpalić :D
EDIT: Pecuś, a czy czasem koła nie będą identyczne, jeżeli dasz w circle R+1 w stosunku do tego, co ze skryptu ?
Ostatnio edytowany przez maw (2010-01-07 13:44:11)
Okręgi z Circle, zawsze są grubsze i maja jakieś "odrosty" :) nie ma znaczenia różnica w promieniu.
A co do procedury, to mam taka gotowa w Scorchu, tylko trzeba się przepiać na systemowy plot i dodać czytanie parametrów... Nie będzie tak szybka jak z własnym plotem, ale uniwersalna za to.
wiesz co, wystarczyłoby by była relokowalna i umiała parametry sczytywać - używam USR-a...
Uniwersalną procedurę w BASICu masz w poście #9. Jeśli jest dla Ciebie dużo za wolna i potrzebujesz w całości w asemblerze, to napisz, dla którego trybu graficznego.
albo lepiej - dla jakiej dl
dla standardowej :-)
Ech, widzę, że tak fajnie z tym rysowaniem tego koła w asm w różnych trybach graficznych nie będzie. W sumie to pod uwagę biorę tylko dwa - GR.8 i GR.15. Gdyby podawać, jaka jest długość linii, można by wtedy procedurę zastosować do innych standardowych trybów (PXY = (Y*SCR_W + X)/liczbaBitówKoloru. Mylę się ?
w sumie - wsio zalezy od tego w jakim obszarze pamieci zaczyna sie gorna krawedz kola, jaka jest szerokosc linii dla danego trybu - i czy poszczegolne linie sa w tym samym trybie...
teoretycznie da sie rysowac uwzgledniajac zmiane trybu co linie, ale to by bylo juz totalnie przekombinowane...
co do zakladania ze caly ekran w jednym trybie - rozne tryby maja rozna "pamieciowo" szerokosc bajtowa ekranu - co wplywa na wyznaczanie adresu dla danych wspolrzednych - uniwersalne algorytmy sie okazuja w takich przypadkach fpyte wolne...
rozne tryby maja rozna "pamieciowo" szerokosc bajtowa ekranu - co wplywa na wyznaczanie adresu dla danych wspolrzednych .
Mozesz podac przyklad trybu graficznego (bo o takich tu mowa) ktory ma pamieciowo inna szerokosc linii niz 40 bajtow?
Gr.3
przeciez to jest 40x24
a to nie jest tak ze szerokosc linii moze byc 128, l60, 192 cykli koloru? 40b na linie wydaje mnie sie ze jest tylko przy tej srodkowej wartosci...
Dobrze gadasz - dlatego min. basicowe drawto daje sieczkę przy szerokim lub wąskim ekranie, bo procedura nie sprawdza, jaka jest długość linii.
- Mozesz podac przyklad trybu graficznego (bo o takich tu mowa) ktory ma pamieciowo inna szerokosc linii niz 40 bajtow?
- Gr.3
- przeciez to jest 40x24
LOL, jesteście lepsi od basha. :D
Imo zbyt hermetyczne nawet na roflcoptera. ;)
no dobra, posmialismy sie, masz epi racje - ten tryb to wyjatek, nadal jednak twierdze ze nie jest prawda jakoby "rozne tryby mialy rozna szerokosc bajtowa linii" jak twierdzi jellonek. Po prostu chcialem zauwazyc ze jellonek wprowadza mawa w blad.
a to nie jest tak ze szerokosc linii moze byc 128, l60, 192 cykli koloru? 40b na linie wydaje mnie sie ze jest tylko przy tej srodkowej wartosci...
jeleniu, owszem, ale to nie zalezy od trybu jak pisales tylko od DMACTL.
Nie no Mikey, załapałem - w 559 bit 0 i 1 dają zmianę długości linii w bajtach, ale żeby poprawnie rysować, trzeba jeszcze podać, ile punktów/cykli kolorów będzie przypadać na bajt i wychodzi mała krzyżówka ilość bajtów linii - ilość punktów na bajt. W sumie obie te informacje procedura może sama z pamięci wyciągnąć, ale co będzie szybsze - podawanie ręczne na stos, czy "autoseeker" - imho podawanie na stos.
a nie lepiej wprowadzic tablice adresow poczatkow linii i w ten sposob uniezaleznic sie od dowolnego trybu/mieszanego i dowolnej szerokosci?
---
a przy okazji przyspieszy to rysowanie
Ostatnio edytowany przez xxl (2010-01-08 12:05:26)
zmiana w DMACTL szerokosci linii mozliwa jest co linie, czy tylko zaczytywana jest w trakcie VBL?
wie ktos, lub moze sprawdzic?
mikey: ja ci nicka nie przekrecam.
DMACTL można zmieniać na DLI. Nie wiem czy w trakcie trwania wiersza tekstowego.
no dobra, posmialismy sie, masz epi racje - ten tryb to wyjatek, nadal jednak twierdze ze nie jest prawda jakoby "rozne tryby mialy rozna szerokosc bajtowa linii" jak twierdzi jellonek. Po prostu chcialem zauwazyc ze jellonek wprowadza mawa w blad.
jeleniu, owszem, ale to nie zalezy od trybu jak pisales tylko od DMACTL
Mikey, pogrążasz się. Z ośmiu trybów graficznych ANTICa tylko 3 mają 40 bajtów na linię: GR.7, GR.8 i GR.15, a "wyjątki" to GR.3, GR.4 (po 10 bajtów), GR.5, GR.6 i GR.14 (po 20 bajtów).
Liczba bajtów w linii to nie wszystko. Mają jeszcze znaczenie: liczba bitów na piksel oraz proporcje.
czuje sie skompromitowany. wystarczy....
Nie wiem czy w trakcie trwania wiersza tekstowego.
Też, a nawet w środku linii. W takich przypadkach jednak uzyskiwany efekt nie jest oczywisty.
zawsze to przy okazji czlowiek uzupelnia swoja wiedze...
Z ośmiu trybów graficznych ANTICa tylko 3 mają 40 bajtów na linię: GR.7, GR.8 i GR.15, a "wyjątki" to GR.3, GR.4 (po 10 bajtów), GR.5, GR.6 i GR.14 (po 20 bajtów).
Liczba bajtów w linii to nie wszystko. Mają jeszcze znaczenie: liczba bitów na piksel oraz proporcje.
<truizm>Milcząco zakładając, że DMACTL wybiera normalną szerokość ekranu (a nie 32 albo 48 bajtów)</truizm>
Strony Poprzednia 1 2
Zaloguj się lub zarejestruj by napisać odpowiedź
[ Wygenerowano w 0.109 sekund, wykonano 13 zapytań ]