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" :)

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

Seban, niezbyt się znam na sprzęcie ale jak dla mnie nie jest to bug tylko feature :)

Nie zrzędź ;) Wystarczająco mocne do tego celu GPU mają już karty nie produkowane od 2004 roku.

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...

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

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

:(

Ostatnio edytowany przez Dracon (2012-01-10 15:13:03)

@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 ;)

@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".

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.

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....

@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ć.