Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa wersja przeglądarki HighWire HighWire 0.5.0 Beta przynosi obsługę HTTPS, nowoczesnego CSS oraz kart pod TOS, FreeMiNT i MagiC.
CAS2Audio 1.0.5 Nowa wersja aplikacji CAS2Audio dla systemu Android przynosi całkowicie odświeżony i nowoczesny interfejs użytkownika.
Nowa gra na Atari 8-bit: Agents Alpha Bocianu prezentuje nową grę Agents Alpha.
Altirra 4.50 test 19 Phaeron opublikował nową wersję testową emulatora Altirra z licznymi poprawkami m.in. dla VBXE.
NeoST 0.6.1 Nowa wersja emulatora NeoST z ulepszeniami emulacji układów Atari ST, MIDI oraz obsługą sieci.
atari.area forum » Posty przez Cyprian
Skrzyp, mój błąd, otóż nie chodziło mi o wstążkę :)
Miałem na myśli konfigurowalne menu nad nią - "Quick Access Toolbar":
Dla mnie jest on super, dzięki niemu mogę schować zwykły zajmujący sporo miejsca toolbar/wstążkę.
W LibreOffice również można konfigurować toolbar ale tylko główny, MS dał opcję wyboru - główny toolbar bez modyfikacji plus własny "Quick Access Toolbar".
Swoją drogą, mam wrażenie że LO 4.4.2.2 jest bardziej przyjazny niż 4.3.6. Trzeba się przyjrzeć co poprawili.
No ja bym wstążki w LO nie chciał...
czym to jest spowodowane?
taki mam zasilacz
też 64.6 W
Co do cofania się do roku 2003 - powiedział użytkownik Atari wink
dla tego pewnie nie skreślam LibreOffice :)
Mi tam pasuje właśnie ten oldskulowy styl a nie współczesne wstążki-srążki.
Co do wstążki to dla mnie jest naprawdę dobre rozwiązanie. Wrzuciłem do niej najpotrzebniejsze narzędzia.
Dzięki temu mogłem schować pasek narzędzi i uwolnić kawałek przestrzeni roboczej
Dzięki Draco za info, przymierzałem się właśnie do upgrade.
Jest werja 4.4.2 dla Windows, którą w tym momencie pobrałem i działa.
Automatyczny LibreOffice upgrade pokazuje 4.3.6
JZawsze lepsze to, niż MS Office, w dowolnej wersji.
Jedyny duży plus jaki widzę to łamanie monopolu MS.
Jeśli chodzi o 4.3.3.2 użyteczność oraz interfrejs Calc i Base to niestety czuję się jak bym się cofnął do 2003 roku.
git,
ja testuję EmuTOS pod Winuae
Skrzyp, pewnie masz rację. Amigę widziałem ostatni raz w '92, więc mogę się mylić.
No ale z tego co pamiętam to np. Vampire 600/500, PAK 68/3 jaki i właśnie Furia 600 montuje się na CPU.
A czy ST ma w sobie port rozszerzeń w tym stylu co Amigi czy jedynie port na kości pamięci Ram oraz ROM w kartridżu?
w amidze rozszerzenia CPU montuje się tak samo jak w Atari - nakładając na CPU, więc tu nie powinno być problemu.
Z tego co pamiętam to problemem może być typ podstawki, kwadrat (STE/A600) vs prostokąt (STfm/A500), oraz to że procesor w amidze jest wykastrowany z istotnych sygnałów (np A600 z E-clock i jeśli się nie mylę to z sygnałów FC0-2).
W najbardziej krytycznej czasowo części kodu dużo miejsca na optymalizację już nie było, a zawsze będzie 3 linie mniej :)
ok, na dzień dzisiejszy mamy 10 linii mniej dla tej figury (lewa strona BT4PC_C, prawa kod zoptymalizowany):
Figura ta wykorzystuje wyłącznie "multi_words", więc nie wiem jak optymalizacja wygląda w przypadku krótkich wektorów.
Widzę jeszcze miejsce na optymalizację, np. aktualnie generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask wymaga inicjalizacji dla każdego wielokąta osobno. gdyż odbywa się ono pomiędzy "compute_triangle_dx" a "fill_triangle".
Można by spróbować wykonać tylko jedną inicjalizację dla wszystkich wielokątów. Czyli wykonać "compute_triangle_dx" dla wszystkich wielokątów, potem tylko jedna inicjalizacja BLiTTERa, a następnie dla każdego wielokąta generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask. No i na koniec "fill_triangle" dla każdego wielokąta.
A jak sprawdzić ile watów ma zasilacz w TT?
Who knows...
Słusznie!
Ten nowy sprzet to prawdziwy amiga killer.
czemu używasz brzydkich słów na "am" ? :P
Nie istnieje coś takiego jak XEX. Jest to aplikacja pod Spartę X która łyka dowolną bitmapę 256/256/256 i nią kręci. O, czyli zapomniałem, że Sparta też jest tu potrzebna :P
brzmi spoko, zapodaj jakąś binarkę :)
A monitor SC1435 mogę Ci naprawić.
dał byś radę rzucić okiem na mój SC1435?
Pinex, ja też poproszę. zapodaj jakiegoś xexa
ok, zgłaszam zaległy iwenty
"Zeszło-Zeszłotygodniowe łikendowe piwko"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: zeszły zeszły łikend
Cena piwka: <zakładana cena>
Jedynie Irish Beer i Black Beer Stout warte uwagi.
Nowy termin:
"Zeszłotygodniowe łikendowe piwko"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: zeszły łikend
Cena piwka: <zakładana cena>
Wszystkie cacy
Nowy termin:
"Dziś bania"
Miejsce: u mnie
Organizatorzy: Cyprian i Ja
Termin: dziś a w zasadzie to już trwa :)
Cena piwka: <zakładana cena>
Na razie git
szach mat :)
mały OT. Tutaj nowość od konkurencji :)
https://youtu.be/ZQ3-nnoXGng?t=49
Sprawdziłem w debuggerze winuae no i jeden obiekt generowany jest w cztery ramki
Wczoraj w nocy udało mi się dodać optymalizację w której BLiTTER generuje nową tablicę leftEdge address/rightEdge address/leftMask/rightMask. Skraca ona czas całości o trzy linie skaningowe. Nie jest to powalający wynik, ale nowy kod daje miejsce na dalsze optymalizacje.
.poly_fill_line wygląda teraz tak:
.poly_fill_line:
movem.w (A0)+,D0-D3 ; D0 - left; D1 - right; D2 - left mask; D3 - right mask
movea.l a5,a4
lea logLine(a5),a5 ;next y offset line
lea (a4,d0.w),a4 ;add line x offset
sub.w d0,d1 ;line width
asr.w #3,D1
bgt.s .multi_wordsKod jest brudny, wieczorem siądę by go oczyścić i jutro wrzucę go na forum.
Super, widzę że sprawy idą w słusznym kierunku. Wprowadziłeś kawał niezłego kodu, jutro siadam do studiowania :)
Ja niestety dopiero dzisiaj miałem okazję znowu siąść do kodu.
Bazuję teraz na ostatnim BT4PC_C. Dodałem nową procedurę BLiTTERa - inicjalizacja i generowanie nowej tablicy leftEdge/rightEdge/leftMask/rightMask oraz nową wersję poly_fill_line bazującą na tej tablicy. Pierwszy etap - generowani tablicy działa poprawnie, niestety drugi - poly_fill_line już nie. Dziś już nie dam rady, ale może jutro wieczorem uda mi się siąść do debuggera i przejść przez poly_fill_line.
Co do clippingu to czy on zawsze jest on potrzebny? Np. dla glenz nie wychodzącego poza ramki ekranu?
Naprawdę słuszna koncepcja :)
jeśli chodzi o moją część to, mam działający kod ale niestety nie miałem jeszcze czasu zintegrować go z trianglefi. Muszę jeszcze raz przemyśleć użycie rejestrów gdyż w trianglefi większośc jest wykorzystana.
Te dwa słowa na linię w przypadku 16 punktowych linii wynikało z tego że rejestry Halftone inicjowałem tylko jeden raz, ale za to wartościami dla wszystkich kolorów.
By wypełnić cztery bitplany w jednym strzale (z uwzględnieniem Mask1/Mask3) musiałem dać ujemne dstYinc, co powoduje że Halftone są dekrementowane. Działa to dobrze w "multi_words" ale nie w wariancie z tylko jednym słowem (<=16 punktów) na bitplan. Tak więc dla linii 16 punktowej musiałem zwiększyć szerokość linii do dwóch słów by móc zastosować ujemne dstYinc.
Widzę że w 5_C inicjujesz Halftone częściej, ale za to tylko jednym kolorem. To daje możliwośc poprawienia 16 punktowych linii.
Niestety dopiero wieczorem będę miał więcej czasu, siądę do Twojego ostatniego kodu i zrobię parę testów.
Jeśli chodzi o wybraną ilość planów to jasne, zapodawaj :)
Jakby co to też mam kod, tylko jeszcze go nie publikowałem. W sumie są to kosmetyczne zmiany do aktualnej procedury blittera.
Hmm... 2? A nie 4? A co z danymi do wypełniania zawartymi w halftonach?
cykl szyny (z punktu widzenia CPU/BLiTTERa) czyli 4 cykle CPU :)
17 cykli szyny na załadowanie danych z pamięci do D0-D7 i drugie 17 na przesłanie z D0-D7 do Halftone
Potem generowanie leftMask/rightMask na podstawie Halftone i leftEdge/rightEdge - 2 cykle szyny (Jeden odczyt i Jeden zapis) - 8 cykli procesora na jedną maskę
Tylko pamiętaj, że na lsrze stracisz. Ja poszedłem w drugą stronę i zrobiłem oddzielne tablice dla prawej i lewej strony, dzięki czemu zamieniłem lsra na dwa addy. No i sam movem sporo zabiera.
Chodziło mi o to by BLiTTER na podstawie leftEdge/rightEdge wygenerował tablicę leftMask/rightMask,
oraz by uniknąć lsl/addów BLiTTER dokonał na leftEdge/rightEdge operacji - AND $FFF0 i rotacji o 3 bity w prawo.
Najprościej będzie jak w wolnej chwili siądę do assemblera i sprawdzę czy to działa.
A tutaj napisany z palca, tak na szybko, szkic kodu fill_triangle_line_loop:
fill_triangle_line_loop
movem.w (A0)+,D0-D3 ; D0 - left; D1 - right
; D2 - left mask; D3 - right mask
move.l D6,A4 ; current line address
add.l #160,D6 ; next line address
lea (A4,D0.w),a4 ; add line x offset
sub.w D0,D1 ; line width
asr.w #1,D1 ; words number
bgt.s .multi_words
and.w D2,D3
move.w D3,endmsk1(a6) ;only mask
...No ciekawe. Chodzi o usprawnienie compute_triangle_dx?
Jakby co to mam ideę na zmianę w fill_triangle_line_loop. BLiTTER, na podstawie leftEdge/rightEdge może wygenerować left mask/right mask. Koszt to 34 cykle szyny na inicjalizację rejestrów Halftone a potem tylko 2 cykle szyny na maskę.
A jeszcze jakby udało się przeorganizować tablice leftEdge/rightEdge na taką:
REPT rezY
ds.w leftEdge, rightEdge, leftMask, right Mask.
ENDRto w fill_triangle_line_loop można by jednym zgrabnym "movem.w (A0)+,D0-D3" ładować od razu wszystkie potrzebne dane.
Btw, co prawda nie znam się zupełnie na SID-dzie i nigdy nic na to nie pisałem, ale zrobiłem dziś parę patternów, żeby sprawdzić, jak chodzą SID-owe procedury na Raspberry Pi 2 (GoatTracker).
No i wydaje mi się, na moje drewniane ucho, że chodzą prawidłowo.
http://yerzmyey.i-demo.pl/yerz_SID_rasp ... i_test.mp3
brzmi git
atari.area forum » Posty przez Cyprian
Wygenerowano w 0.147 sekund, wykonano 15 zapytań