Demko w Delphi oparte na Canvasie!
działający link:
http://rapidshare.com/files/57685628/demko.zip.html
Po oglądnięciu proszę zagłosować :P
// Pisz sensowne posty, Twój drugi post wywaliłem - co i tak wg mnie mała kara, nie dawaj tu takich bzdur - Deti
Nawet ładnie, szczególnie ta animacja na samym początku.
Chociaż takie efekty to się robi w demkach 512 bajtów-1kB ;)
Wiesz dlaczego takich rzeczy się normalnie w Delphi nie robi? Bo ma paskudny kompilator. Kod jaki to cudo wygenerowało może i by był sprawny ale na 486. Na moim PIII 1GHz przy odpalonej Operze i WMP10 w tle minimalnie się tnie... i do diabła, bląd ortograficzny w napisie w demku? Pomijam wygląd napisu... Piszesz, że demko nie jest obiektowe, z drugiej zaś strony, że na canvasie oparte...
Wrzuciłem to z ciekawości w disassembler, żeby upewnić się, że nam nic 'przyjemnego' nie przynosisz. Wiesz, ja tam widzę zwykłe użycie VCL... Z resztą, takie rzeczy jak bitmapy z napisami to się przygotowuje za wczasu a nie już podczas animacji... Swoją drogą śmieszne, funkcje sinusa czy cosinusa nie są inline'owane, to zwykły call do nierewelacyjnie napisanej procki...
Demka pisze się bardziej niskopoziomowo, bezpośrednie operacje na bitmapach, często ręczne pisanie algorytmów na MMX/SSE /Delphi automatycznie nawet MMX użyć nie potrafi... w przeciwieństwie do VC++/. Demko jako takie jest całkiem fajne...
"To jest chyba pierwsze demko skompilowane w Delphi7:) Do zrobienia demka nie używałem assemblera i C++, sam Pascal. Demko nie jest w ogóle obiektowe! Używałem samych podstawowych procedur i funkcji zaintepletowanych w kompilatorze - głównie Graphics'
Raz, wspomniany ort. Dwa, nie jest obiektowe? A jaka jest część biblioteki VCL, której uzyłeś - Graphics? Trzy, co ma do tego użycie C++? Ostatnia bzdura - zaimplementowanych w kompilatorze... Boże, człowieku, funkcji wbudowanych jest tylko kilka, Ty użyłeś zaś klas z dolączonej do środowiska, linkowanej biblioteki... Swoją drogą, pooglądałem sobie pod disassemblerem funkcje z biblioteki VCL odpowiadające standardowym WINAPI - FillRect i podobne... Masa nadmiarowego kodu, tworzenia jakiś tymczasowych obiektów... A to niby tylko wrappery na WINAPI... Podobne demko na standardowych ustawieniach kompilatora z VC++ powinno zajmować jakieś 10KB?
Dobra, demko jest demko, sztuka się liczy :-)
edit: użycie obiektowości jako takiej nie ma bezpośredniego wpływu na wydajność... jakość implementacji już ma.
p.s. poczytaj trochę o optymalizacji - obliczeń, bezpośrednim dostępie do bitmap, rozwijaniu pętli...
Użycie ASMa czy obiektowości nie jest żadną hańbą, o ile umie się z niej skorzystać.
Zakładając, że chciałeś napisać demo bez kombinowania z samodzielnym dostępem do instrukcji procesora, przynajmniej optymalizuj wywołania, eliminuj nadmiarowe zmienne, a przede wszystkim używaj mechanizmów, które same w sobie są szybkie (porównaj choćby szybkość dostępu do bitmap z użyciem funkcji ScanLine, której w kodzie nie znalazłem, do Pixels[x,y], z którego ciągle korzystasz). Przez to efekt lupy wygląda może i nie najgorzej, ale chodzi tragicznie.
Tak w ogóle: po co wykorzystujesz VCL/RTL, skoro właściwie wywołujesz funkcje, obudowujące czyste Winapi; nie korzystasz natomiast z obsługi interfejsu użytkownika - czyli tego, do czego VCL jest przeznaczone. Zrezygnuj zatem z niego, nie używaj, a rozmiar pliku wykonywalnego spadnie o jakieś 200kB.
Dałem 'może być' dla zachęty, za wkład; pomysł i efekt mógłbym ocenić nawet na 'ciekawe', natomiast ocena sposobu wykonania znajdowałaby się raczej między 'może być' a 'tragedia' (nie jest tak źle, brakuje mi jeszcze jednego pułapu oceny).
Demko niezłe ale wydajność masakryczna. Przy generowaniu krzywych Beziera mój Athlon FX 5200+ (2x2.66 GHz, 2MB Cache) przy odpalonym samym OS osiągnął 50%. Przy generowaniu plasmy było lepiej bo tylko 30%. Co i tak daje masakrę.