Hej!
w/g mnie coś jest nie tak :) Nie powinno być tych czarnych "obrysów" oraz kresek ;) Stanowczo coś źle u Ciebie działa :)
Nie jesteś zalogowany. Proszę się zalogować lub zarejestrować.
Nowa obudowa dla 800XL - zostało 36 dni Niewiele ponad miesiąc do końca kampanii.
Zmarł twórca języka BASIC Zmarł Thomas E. Kurtz twórca języka BASIC
Zmiana serwera atari.area Serwis przeszedł właśnie ważną aktualizację infrastruktury
4th Atari ASCII Compo - wyniki Dostępne są już wyniki tegorocznego ATASCII Compo.
thing neo 1.60 Olivier Landemarre wydał nową wersję desktopu Thing.
atari.area forum » Emulacja - 8bit » Atari800Win PLus 4.1 beta 2
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
Hej!
w/g mnie coś jest nie tak :) Nie powinno być tych czarnych "obrysów" oraz kresek ;) Stanowczo coś źle u Ciebie działa :)
Ok, rozpoznałem o co chodzi - w przypadku gdy po ustawieniu na smooth zamknę i otworzę emulator to wtedy widzę taki efekt.
Jeśli zmienię metodę stretching na smoth w trakcie pracy to wtedy obraz jest normalnie rozmyty.
Jak dla mnie taki obrysowany smooth jest naprawdę git. proponuję dodać go jako następny tryb "outlined" :)
Hej!
Myślę iż niestety jest to jakiś błąd w sterownikach do karty graficznej i to co Ci się udaje uzyskać wychodzi zupełnie przypadkowo :) Napisz może jaki Windows, jaka karta, jaka wersja sterownika. Może Jaskierowi uda się coś ustalić.
Winows 7 Enterprise SP1
Radeon HD 6470M
Chip Type: AtI display adapter (0x6760)
Bios Information BR41330.001
Driver Version: 8.821.1.0
Driver Date: 2011/2/06
hej!
Ja sprawdziłem na trzech komputerach, wszystkie mają różne ATI:
1) ATI Radeon HD 2400 Series, AMD Catalyst 11.12, Win7 ENT SP1
2) ATI Radeon HD 4550 Series, AMD Catalyst 11.12, Win7 ENT SP1
3) ATI Radeon HD 4600 Series, AMD Catalyst 11.12, Win7 Pro SP1
Wszędzie mam OK, nie udaje mi się uzyskać efektu który występuje u Ciebie.
ps) A już chciałem plugawić Nvidię :) Bo sądziłem że skoro u mnie na żadnym ATi nie występuje to musi być jakaś karta ze stajni NV :) Sprawdzę jeszcze na ATi 6xxx-cośtam, i dam znać.
Seban, niezbyt się znam na sprzęcie ale jak dla mnie nie jest to bug tylko feature :)
Potwierdzam, bardzo fajny feature :)
Nigdy go wcześniej nie widziałem. Czy występuje zarówno w trybach DirectX jak i GDI? Jeśli tak to jedyną wspólną ich rzeczą jest funkcja Interpolate2, której większa cześć jest zawarta wewnątrz takiego ifdefa:
#ifdef PFUSIK_ASM
a potem leci sterta kodu w asmie. Mielibyśmy winowajcę :)
Ale wydaje mi się, że coś się chrzani w liczeniu palety kolorów i zamiast koloru przejściowego jest czarny.
@laoo
A potem będą wymagania: DX10, Radeon 5xxx lub GF5xx :)
Algorytm Hi-end bez wątpienia dobrze się skaluje na procesory. Nie wiem jednak kto to miał by robić. 6 lat temu go przypadkowo w sieci znalazłem i wsadziłem w beta1. Niestety obsługiwał tylko kolor 16bit więc musiałem przepisywać okran z 32bit na 16 i z powrotem. Przez 6 lat nic się zmieniło a jakieś pół roku temu algorytm wziął na warsztat jakiś człowiek i zrobił wersję z kolorem 32 bit. Jak więc widać zainteresowanie rozwojem tego typu skalowania jest przeogromne :)
Muszę napisać do tego gościa aby go do pracy zmotywować. Może zrobi wersję wątkowaną lub GPU???
@laoo
A potem będą wymagania: DX10, Radeon 5xxx lub GF5xx :)
Nie zrzędź ;) Wystarczająco mocne do tego celu GPU mają już karty nie produkowane od 2004 roku.
Algorytm Hi-end bez wątpienia dobrze się skaluje na procesory. Nie wiem jednak kto to miał by robić.
Ty? Przecież to trywialne. Instalujesz VS 10 (np express). Inkludujesz <ppl.h> i używasz funkcji parallel_for. Runtime zrobi całą brudną robotę za Ciebie łącznie z wykryciem ile korów jest w systemie i odpaleniem optymalnej liczby wątków. Programowanie wielokorowe nie jest już poletkiem dla dziwolągów...
Mam problem z 4.1 - zainstalowałem instalatorem, odpaliłem z instalatora - działa. Zamknąłem i już nie mogę otworzyć ponownie. Klikam skrót w menu Start - nic. Dwuklikam exe - nic. Nic = nic się nie pojawia, w liście procesów pusto. Po reinstalce znowu działa. Z 4.0 nigdy nie miałem takiego problemu. Windows 7 x64.
Ale wydaje mi się, że coś się chrzani w liczeniu palety kolorów i zamiast koloru przejściowego jest czarny.
Też na to stawiam. A to już nie mój kod. ;) Może kluczowe w rysowaniu czarnych obwódek są Palette Options - przydałby się ich zrzut ekranu.
Pól roku temu robiłem eksperymenty z HQX. Świetnie sobie radzi z hiresem, gorzej z GR. 15, a z trybami GTIA w ogóle:
http://fail.sourceforge.net/hqx/hqx2.html
http://fail.sourceforge.net/hqx/hqx3.html
http://fail.sourceforge.net/hqx/hqx4.html
Potwierdzam czarne obwódki, jeśli w momencie uruchamiania emulatora jest wybrane Smooth. Nie zauważyłem wpływu Palette Options.
Mój problem z uruchamianiem PLusa to kolejny feature: zaznaczcie "Reuse emulator window", zamknijcie emulator, a następnie mając otwartą w przeglądarce internetowej kartę tego topicu spróbujcie otworzyć emulator. Zostaniecie przełączeni na forum, a emulatora nie będzie. :) Sprawdzone w Chrome, IE 9 i FF 3.6.23. Trick działa też z "Atari800Win PLus 4.1.docx" w Wordzie. :)
hej!
Potwierdzam również obwódki. Nigdy wcześniej nie udało mi się tego uzyskać bo nigdy nie włączam trybu smooth :P Btw. myślałem że smooth to karta graficzna robi a nie software-owo emulator ;P
"feature" odkryty przez fox-a również potwierdzony :P
myślałem że smooth to karta graficzna robi a nie software-owo emulator ;P
I dziwisz się swoim 237% procentom? ;)
Oryginalny atari800 jako multiplatformowy musi robić wszystko softwarowo, ale port pod windowsa operacje na obrazie (szczególnie takie proste) powinien robić na karcie. Już skończyły się czasy homogenicznych komputerów. Teraz karta graficzna to koprocesor z niezłą mocą, który ma każdy. Nawet zintegrowany intel na laptopie potrafi całkiem dużo, a takie APU od AMD są całkiem wypaśne (zintegrowane HD6xxx).
No tak, tez jestem milosnikiem (uzytkownikiem) Radeona, ale taki np. Helion (moim zdaniem) bez sensu wydaje ksiazki nt. rozwiazan jed(y)nej i konkurencyjnej firmy zamiast zajac sie rozwiazaniami zunifikowanymi (w DX11):
http://helion.pl/ksiazki/cuda-w-przykla … cudawp.htm
:(
dlatego najlepiej się zainteresować OpenCL.
@dracon: tutaj można by dyskutować o celowości i sensowności takiego działania. Mamy wolny rynek jeżeli mają popyt na tego typu twory to już ich sprawa czy wydadzą książkę o tym czy nie. Równie dobrze mogą się cieszyć miłośnicy NV. Ale sprawa ma jeszcze drugie dno... nie wiem co NV i komu robi dobrze, ale różni wykładowcy którzy pracują ze studentami opowiadają im takie głupoty że szok.
Z ust wykładowcy padają stwierdzenia godne rasowego Fan-Boya firmy NV, oczywiście nie mające żadnego związku z rzeczywistością. Rozumiem że gość miał doświadczenie jakieś z pracą przy kartach od NV wspomagających CUDA. Ale gość się pieni i pluje że OpenCL i ATi/AMD do niczego się nie nadają :) Tego typu relacje słyszę od czasu do czasu od osób które muszą sobie dokupić kartę firmy NV bo tego wykładowca im powiedział że nie będą mogli wykonać prac zaliczeniowych ;)
@Dracon i @Adam: Microsoft lubi być o krok do przodu i w VS11 będzie C++AMP, czyli kod akcelerowany zintegrowany z kodem C++ - nie trzeba będzie pisać kerneli w osobnym języku (np OpenCL czy DirectCompute) i kodu odpalającego te kernele, tylko wszystko będzie wprost kodowane i kompilowane jako C++.
@laoo: może to i fajne rozwiązanie ale dla określonego środowiska. Przynajmniej w teorii rozwiązania NVidii i ATI są niezależne od systemu operacyjnego i przenośne pomiędzy komputerami o ile jest tam otoczenie gcc.
A Microsoft lubi być raczej po swojemu "o krok obok".
Microsoft C++AMP zrobił na bazie swojego DX11. Nie ma żadnej przeszkody, aby ludzie od gcc zrobili swoją implementację na bazie OpenCL (mam nadzieje, że tak się stanie), wówczas C++AMP na GCC będzie wszędzie tam, gdzie jest OpenCL - nie wiem czy można być bardziej niezależnym od systemu.
A z tym krokiem obok, to masz rację. Niekiedy wdepną w g***, ale często wytyczają nowe ścieżki. Ten pomysł akurat wydaje mi się trafiony - programowanie masowo heterogeniczne ( i to niezależne od wendora sprzętu ) trafia pod strzechy.
Dracon: faktycznie zunifikowane, szczegolnie z innymi (popularniejszymi w przypadku atari800) platformami niz "jedyna sluszna".
rozwiazanie laoo wydaje sie najsensowniejsze (choc jeszcze niedostepne...) jesli bedzie "dookreslone" tak, by dalo sie to na innych kompilatorach rowniez zaimplementowac.
poki co pozostaje "reczne" przygotowywanie kodu oddzielnie pod apu i oddzielnie porozumiewajacy sie z nim kod na cpu.
Konkurencja zawsze wymusza postęp. Ważne jednak aby ta biblioteka nie korzystała z jakichś trików, które uniemożliwią jej implementacji w innych środowiskach. Przykładem jest STLport, które ma mnóstwo obejść aby faktycznie być multiplatformowym a niby jest to zestandaryzowana biblioteka którymś ISO/ANSI.
Tego typu relacje słyszę od czasu do czasu od osób które muszą sobie dokupić kartę firmy NV bo tego wykładowca im powiedział że nie będą mogli wykonać prac zaliczeniowych
To karygodne, tak jakby tamci wykladowcy byli "sponsorowani" przez NV. A potem jest tak, ze w jednym programie masz wiecej efektow bo wykorzystuje PhysX albo CUDA, a w drugim bieda, bo sie programisci nastawili na jeden sprzet.
Sa i takie podobno, ktore rusza tylko pod NV (program do modelowania 3d zwany "MARI"), szkoda.
Adam ma racje, warto teraz promowac OpenCl.
Odnosze wrazenie, ze ATI (teraz pod nadzorem AMD) podobnie jak kiedys firma ATarI za slabo sie promuje i stad tez takie efekty....
Upscaling zrobiliśmy programowo, gdyż Tomek Szymankowski twierdził, że Windows nie dawał pełnej kontroli nad algorytmem skalowania na wszystkich kartach graficznych i wersjach Windowsów, które były w obiegu dziesięć lat temu. Robiliśmy też wiele pomiarów wydajności naszych procedur.
@laoo
VS express nie ma MFC więc bym musiał hqx zrobić na osobną bibliotekę. W sumie wykonalne.
Nie wiem jednak jaki jest narzut tych pętli równoległych. W emulatorze trzeba co 1/50 lub 1/60 sekundy (a w turbo jeszcze częściej) wykonywać obliczenia. Jeśli te pętle korzystają z wątków techniką Thread Spawn, to narzut ich tworzenia może być znaczący.
Myślałem raczej nad zaimplementowaniem techniki Thread Pool. Przecież liczba potrzebnych wątków się nie zmienia.
@Fox
Nie doświadczyłem problemów z uruchamianiem emulatora po zainstalowaniu go. Raz w debugerze nie chciał mi sie uruchomić a też w liście procesów go nie było. Od tej pory nie używam opcji "Reuse emulator window". Powód może być podobny. Wtedy jeśli dobrze pamiętam on jakimś cudem znalazł na liście okien okno o nazwie Atari800Win no i nie chciał się odpalić.
Przerzucanie się na okno przeglądarki lub Worda po uruchomieniu jest spowodowane tym samym. To chyba stary kod jeszcze z win9x. Trzeba by wsadzić tam lepszą implementację rozpoznawania czy aplikacja jest już uruchomiona.
Przetestowałem emulator z włączoną i wyłączoną opcją PFUSIK_ASM i włączoną opcją turbo (na ekranie startowym Draconusa):
w trybie smooth wzrost z 2000% do 3200% po przełączeniu się z asm na C++
w trybie scan lines brak różnicy, ale tutaj obie wersje są w asm.
Myślę, że rozwój kompilatorów swoje jednak zrobił. Trzeba będzie wszystko przerzucić na C++.
Nie mam obecnie planów na przerzucanie emu na GPU. Nie znam się na tym i na razie nie mam zamiaru znać.
Spróbowałem przekompilować źródła u siebie, ale zobaczyłem, że projekt korzysta z ddraw.lib i dinput.lib i zapłakałem...
Te liby są tak deprecated, że aż usunięte z najnowszego (acz półtorarocznego) DXSDK.
Jakby co nie sieję defetyzmu, tylko sygnalizuję miejsca do potencjalnego odświeżenia.
Co do Thread Spawn vs Thread Pool, to Parallel Patterns Library zarządza wątkami lepiej, niż zwykły programista jest w stanie, więc o to bym się nie bał...
Strony Poprzednia 1 2 3 4 Następna
Zaloguj się lub zarejestruj by napisać odpowiedź
atari.area forum » Emulacja - 8bit » Atari800Win PLus 4.1 beta 2
Wygenerowano w 0.032 sekund, wykonano 68 zapytań