11.12.2017 21:39
[#61]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #59
Nie no, supcio. Jedyne technikalium jakie jeszcze bym sobie życzył to kolejne wersje kodu jako kolejne commity na repo w githubie - byłby ładny diff. No i łatwiej o wciągnięcie takiego kodu w swój projekt mechanizmem submodułów z możliwością łatwej synchronizacji ze źródłowym repo.
EDYT: Wiem że Ci truję z tym githubem ale truć będę. Łatwiejsza dostępność kodu, możliwość znalezienia Twoich wypocin przez zagraniczniaków i wiele innych bonusów. No i ktoś Ci może podrzucić jakąś fajną zmianę pull requestem, którą albo sobie zatwierdzisz i włączysz do kodu albo nie.
Ostatnia aktualizacja: 11.12.2017 21:41:24 przez teh_KaiN
EDYT: Wiem że Ci truję z tym githubem ale truć będę. Łatwiejsza dostępność kodu, możliwość znalezienia Twoich wypocin przez zagraniczniaków i wiele innych bonusów. No i ktoś Ci może podrzucić jakąś fajną zmianę pull requestem, którą albo sobie zatwierdzisz i włączysz do kodu albo nie.
Ostatnia aktualizacja: 11.12.2017 21:41:24 przez teh_KaiN
11.12.2017 22:31
[#63]
Re: W temacie mojej procedury konwersji c2p
@teh_KaiN, post #61
EDYT: Wiem że Ci truję z tym githubem ale truć będę. Łatwiejsza dostępność kodu, możliwość znalezienia Twoich wypocin przez zagraniczniaków i wiele innych bonusów. No i ktoś Ci może podrzucić jakąś fajną zmianę pull requestem, którą albo sobie zatwierdzisz i włączysz do kodu albo nie.
Wiem, że jesteś wielkim fanem Gita, ale ja nie (jeszcze nie).
Gdybym pisał na PC i testował na emulatorze WinUAE to pewnie bym z Gita korzystał. Ja jednak rozwijam i testuję program na swojej Amidze.Mam pakiet RCS na Amidze, z którego jednak nie korzystam, a ma on diffy, branche i wiele innych fajnych rzeczy. Szczerze Ci powiem, że w tym ogromie możliwości się jeszcze nie odnalazłem.
Poza tym open-source tu trochę nie pasuje (mimo, że publikuję kod do wglądu). Ja chciałbym rozwijać kod po swojemu, i najlepiej zrobić biblioteczkę z tego, by inni amigowi programiści mogli korzystać z dobrodziejstw opracowanych przeze mnie funkcji, ale nie martwili się o rzeczy techniczne. Вы меня́ понима́ете?
11.12.2017 22:45
[#64]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #63
Jeśli planujesz kariere programisty to git, branche, diffy, pull requesty, cherry picki i inne clony powinny Ci być nie straszne, wręcz są wymagane. Uczestnictwo w projektach open source też przez wielu pracodawców jest dodatkowym atutem. Bo jak na dłoni widać co potencjalny pracownik potrafi lub dodatkowo, jeśli to duży projekt, jak pracuje w zespole.
Ostatnia aktualizacja: 11.12.2017 22:47:08 przez jarokuczi
Ostatnia aktualizacja: 11.12.2017 22:47:08 przez jarokuczi
11.12.2017 23:16
[#65]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #64
Jeśli planujesz kariere programisty to git, branche, diffy, pull requesty, cherry picki i inne clony powinny Ci być nie straszne, wręcz są wymagane. Uczestnictwo w projektach open source też przez wielu pracodawców jest dodatkowym atutem. Bo jak na dłoni widać co potencjalny pracownik potrafi lub dodatkowo, jeśli to duży projekt, jak pracuje w zespole.
+100. Dodatkowo, git nawet w przypadku jednoosobowych projektow jest wspanialym narzedziem. Kurde, ja gita nawet przy pisaniu publikacji uzywam ;)
11.12.2017 23:40
[#66]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #64
Zgadzam się z Wami. Git to dzisiaj nieodzowne narzędzie pracy każdego zawodowego programisty. Tak jak napisałem, o ile rozumiem czym jest Git i ogólnie systemy kontroli wersji, o tyle nie potrafię jeszcze się odnaleźć w jego wszystkich możliwościach i nie potrafię skorzystać z jego wszystkich dobrodziejstw i funkcji. Obecnie np. na studiach ważną umiejętnością jest znajomość LaTeXa przy pracach z pogranicza matematyki i informatyki. Ale Git też często jest potrzebny w różnych projektach, zaś w pracy przyda się na 100%. Jednak odłożyłem sobie zaznajomienie się z pełnym spektrum możliwości Gita na trochę później.
Ostatnia aktualizacja: 11.12.2017 23:42:55 przez Hexmage960
Ostatnia aktualizacja: 11.12.2017 23:42:55 przez Hexmage960
12.12.2017 07:36
[#69]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #66
Na początek w małym jedno osobowym projekcie wystarczy git (od biedy svn, merculial lub inny cvs) z domyślnym branchem (master) i tylko commity kolejnych wersji do niego. Ja osobiście w zamieszłych czasach pakowałem sobie kolejne wersje w archiwa żeby móc do którejś z czasem wrócić. Niestety przy kilku wydanych wersjach okazywało się że znalezienie konkretnego pliku w nie wiadomo, której wersji to wielki problem. Przy gicie są narzędzia (oraz są wspaniale zintegrowane z wszelakimi IDE na mainstreamowe platformy) do przeglądania repo możesz od razu podglądać plik w każdej rewizji i porównywać je z sobą. Nie wyobrażam sobie programistycznego życia bez tego obecnie.
12.12.2017 08:26
[#70]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #66
No to w 15 minut opanuj podstawy a potem już tylko potrzebujesz 4 komendy: jedną git init, a potem w pętli git add, git commit, git push. Reszta przyjdzie z czasem. BTW. możesz przecież zadawać pytania, pomożemy. ;)
A repozytorium z procedurami c2p by się przydało, najlepiej jako moduł z warunkową kompilacją gdzie wybierasz jaki masz procesor i w zależności od tego dostajesz plik .o z możliwie najlepszym c2p i do tego plik .h. I tu nie chodzi mi o wydajność scenową, bo pewnie najlepsza prędkość jest jak się go wplecie w resztę okolicznego kodu, ale do gier i innych zastosowań gdzie te parę % wydajności nie robi różnicy.
Swoją drogą ciekawe kiedy będzie git dla Amigi z rozsądnymi wymaganiami sprzętowymi.
Ostatnia aktualizacja: 12.12.2017 08:28:08 przez teh_KaiN
A repozytorium z procedurami c2p by się przydało, najlepiej jako moduł z warunkową kompilacją gdzie wybierasz jaki masz procesor i w zależności od tego dostajesz plik .o z możliwie najlepszym c2p i do tego plik .h. I tu nie chodzi mi o wydajność scenową, bo pewnie najlepsza prędkość jest jak się go wplecie w resztę okolicznego kodu, ale do gier i innych zastosowań gdzie te parę % wydajności nie robi różnicy.
Swoją drogą ciekawe kiedy będzie git dla Amigi z rozsądnymi wymaganiami sprzętowymi.
Ostatnia aktualizacja: 12.12.2017 08:28:08 przez teh_KaiN
12.12.2017 08:26
[#71]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #63
Ja chciałbym rozwijać kod po swojemu, i najlepiej zrobić biblioteczkę z tego, by inni amigowi programiści mogli korzystać z dobrodziejstw opracowanych przeze mnie funkcji, ale nie martwili się o rzeczy techniczne.Tym bym się nie przejmował. Wstawisz kod a i tak się nie doczekasz ani jednego pull requesta. Osoby, którym się wydaje, że wstawiając kod jakiegoś amigowego projektu na GitHuba pozyskają tabuny współprogramistów, żyją złudzeniami.
12.12.2017 08:29
[#72]
Re: W temacie mojej procedury konwersji c2p
@Krashan, post #71
O to to. Wystarczy spojrzeć na mojego gita, hyhy. Największy walor w tym wszystkim jest taki że jak by Cię z jakiegoś powodu zaniemogło albo po prostu by Ci się odechciało, to ten kod dalej sobie leży na użytek innych i kto wie, jest jakaś szansa (jeden na milion?) że ktoś kiedyś będzie kontynuował Twoją pracę.
12.12.2017 08:46
[#73]
Re: W temacie mojej procedury konwersji c2p
@teh_KaiN, post #72
Jak napisałeś że nie będziesz w obecnym stadium rozwoju akceptował pull requestów to się nie dziw że ich nie ma :P. To mały off top ale ostatnio (po anonsie Twojej gry) zainteresowałem się projektem ACE i kto wie może już niedługo jakiś pull request pójdzie. Na razie jestem na etapie ogarnięcia vbcc i kompilacji pod morphosem.
Ostatnia aktualizacja: 12.12.2017 08:46:26 przez jarokuczi
Ostatnia aktualizacja: 12.12.2017 08:46:26 przez jarokuczi
12.12.2017 10:35
[#74]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #69
@Jarokuczi
Ja wiem jakie możliwości dają systemy kontroli wersji. Nie powstały one zresztą dopiero teraz. Już w początkach informatyki oraz języka C (lata 80. zeszłego wieku) były one już dostępne. Ja zaznajomiłem się z RCS (Revision Control System) jeszcze gdy miałem Amigę CDTV na płycie CDPD na dyskach Freda Fisha, które się na tej płycie znajdują.
Update RCS znajduje się na tym dysku:
https://ftp.uni-erlangen.de/aminet/misc/fish/fish-0451.readme
Poniżej zamieściłem zrzut z przeglądarki dysków Freda Fisha o nazwie KingFisher.
Już wtedy RCS umożliwiał pracę w wiele osób przy kodzie, tworzenie wielu gałęzi projektu, a potem ich łączenie oraz oczywiście checkout i checkin.
Zatem z powodzeniem gdybym chciał - mógłbym pielęgnować kod na Amidze używając RCSa, bo tak jak napisałem - kod piszę i testuję na Amidze, przenoszę zaś na PC żeby opublikować.
Technicznie niewiele różni się RCS od jego następców typu SVN, dają podobne możliwości i mają podobną zasadę działania.
Jeśli ktoś rozumie i wie jak korzystać z RCSa, będzie na pewno miał łatwiej w przypadku nowoczesnych systemów.
@Teh_KaiN
Ja wiem gdzie są szkółki do Gita.
Tak jak napisałem lubię rzetelnie podchodzić do tematu i zaznajomić się porządnie z możliwościami i funkcjami Gita, co odłożyłem sobie na później.
Nie będę Wam zawracał głowy lamerskimi pytaniami, najlepiej jak przeczytam książkę o Gicie, która jest dostępna, przez co będę miał jako-takie pojęcie w tym temacie.
Poza tym powtarzam, że pracuję na Amidze.
Co do kontynuowania pracy, to ja chętnie podzielę się kodem jeśli ktoś sobie życzy (co zresztą czynię), ale nie na zasadzie - wrzuć na Gita, a ja sobie ściągnę. Rozumiem, że w dzisiejszych czasach tak się właśnie współpracuje przy kodzie, jednak jeżeli ktoś chce pracować przy swojej wersji mojej procedury C2P, wystarczy że mnie o to poprosi.
Nie chcę żeby kod był zupełnie uwolniony, co dawniej nazywało się Public Domain. Dziś częściej stosuje się określenie open-source.
Co do repozytorium z procedurami C2P, to ja nie chcę w tej formie mojej procedury udostępniać, tylko docelowo w postaci biblioteki współdzielonej w formacie Amigi, żeby wygodnie z niej korzystać w programach/grach na Amigę.
Przyznam, że - podobnie jak z jest Gitem - nie opanowałem wielu nowoczesnych technik i poruszam się w tym bardzo ostrożnie.
Prawda jest taka, że oprócz C2P należy zrobić jeszcze wiele procedur wymagających prędkości w asemblerze M68k typu mapowanie tekstur, remapowanie, wklejanie obiektów itp., zaś w C pisać dopiero samą logikę gier/programów czy dem.
Można to tak zaprogramować, by z C wywoływać te procedury w sposób wygodny.
Także to C2P razem z procedurami pracującymi na grafice chunky to niezbędna podwalina pod projekty w językach wyższego poziomu.
Ostatnia aktualizacja: 12.12.2017 10:40:59 przez Hexmage960
Ja wiem jakie możliwości dają systemy kontroli wersji. Nie powstały one zresztą dopiero teraz. Już w początkach informatyki oraz języka C (lata 80. zeszłego wieku) były one już dostępne. Ja zaznajomiłem się z RCS (Revision Control System) jeszcze gdy miałem Amigę CDTV na płycie CDPD na dyskach Freda Fisha, które się na tej płycie znajdują.
Update RCS znajduje się na tym dysku:
https://ftp.uni-erlangen.de/aminet/misc/fish/fish-0451.readme
Poniżej zamieściłem zrzut z przeglądarki dysków Freda Fisha o nazwie KingFisher.
Już wtedy RCS umożliwiał pracę w wiele osób przy kodzie, tworzenie wielu gałęzi projektu, a potem ich łączenie oraz oczywiście checkout i checkin.
Zatem z powodzeniem gdybym chciał - mógłbym pielęgnować kod na Amidze używając RCSa, bo tak jak napisałem - kod piszę i testuję na Amidze, przenoszę zaś na PC żeby opublikować.
Technicznie niewiele różni się RCS od jego następców typu SVN, dają podobne możliwości i mają podobną zasadę działania.
Jeśli ktoś rozumie i wie jak korzystać z RCSa, będzie na pewno miał łatwiej w przypadku nowoczesnych systemów.
@Teh_KaiN
Ja wiem gdzie są szkółki do Gita.
Tak jak napisałem lubię rzetelnie podchodzić do tematu i zaznajomić się porządnie z możliwościami i funkcjami Gita, co odłożyłem sobie na później.Nie będę Wam zawracał głowy lamerskimi pytaniami, najlepiej jak przeczytam książkę o Gicie, która jest dostępna, przez co będę miał jako-takie pojęcie w tym temacie.
Poza tym powtarzam, że pracuję na Amidze.
Co do kontynuowania pracy, to ja chętnie podzielę się kodem jeśli ktoś sobie życzy (co zresztą czynię), ale nie na zasadzie - wrzuć na Gita, a ja sobie ściągnę. Rozumiem, że w dzisiejszych czasach tak się właśnie współpracuje przy kodzie, jednak jeżeli ktoś chce pracować przy swojej wersji mojej procedury C2P, wystarczy że mnie o to poprosi.
Nie chcę żeby kod był zupełnie uwolniony, co dawniej nazywało się Public Domain. Dziś częściej stosuje się określenie open-source.
Co do repozytorium z procedurami C2P, to ja nie chcę w tej formie mojej procedury udostępniać, tylko docelowo w postaci biblioteki współdzielonej w formacie Amigi, żeby wygodnie z niej korzystać w programach/grach na Amigę.
Przyznam, że - podobnie jak z jest Gitem - nie opanowałem wielu nowoczesnych technik i poruszam się w tym bardzo ostrożnie.
I tu nie chodzi mi o wydajność scenową, bo pewnie najlepsza prędkość jest jak się go wplecie w resztę okolicznego kodu, ale do gier i innych zastosowań gdzie te parę % wydajności nie robi różnicy.
Prawda jest taka, że oprócz C2P należy zrobić jeszcze wiele procedur wymagających prędkości w asemblerze M68k typu mapowanie tekstur, remapowanie, wklejanie obiektów itp., zaś w C pisać dopiero samą logikę gier/programów czy dem.
Można to tak zaprogramować, by z C wywoływać te procedury w sposób wygodny.
Także to C2P razem z procedurami pracującymi na grafice chunky to niezbędna podwalina pod projekty w językach wyższego poziomu.
Ostatnia aktualizacja: 12.12.2017 10:40:59 przez Hexmage960
13.12.2017 05:59
[#76]
Re: W temacie mojej procedury konwersji c2p
@BULI, post #75
Postaram się w najbliższym czasie wyciągnąć swoją A1200 z Fastem i zobaczyć jakie będą wyniki
Będę bardzo wdzięczny jak sprawdzisz program testujący na swojej konfiguracji.
Bardzo ciekaw jestem wyników z A1200 + FAST.Ostatnia aktualizacja: 13.12.2017 06:19:04 przez Hexmage960
13.12.2017 07:15
[#78]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #77
Zaletą biblioteki współdzielonej dodatkowo rozwijanej jako open source jest to, że każdy będzie mógł skompilować po swojemu i dalej rozwijać jeśli Tobie z jakiegoś powodu się odwidzi. Oczywiście wypuszczenie obecnie jako open source to nie gwarancja ciągłego rozwoju, ale wtedy szanse są zdecydowanie większe. Przez takie podejście że każdy sam sobie, które można je jeszcze sensownie uzasadnić w komercyjnych projektach, w naszym małym ami światku wiele fajnych projektów szlag trafił niestety. Naczelny przykład nasz ulubiony system operacyjny, gdyby w czasach commodore/escom został uwolniony to kto wie gdzie by teraz była Amiga ze swoim systemem. Tak się jednak nie stało i jesteśmy gdzie jesteśmy.
13.12.2017 08:21
[#79]
Re: W temacie mojej procedury konwersji c2p
@jarokuczi, post #78
Zaletą biblioteki współdzielonej dodatkowo rozwijanej jako open source jest to, że każdy będzie mógł skompilować po swojemu i dalej rozwijać jeśli Tobie z jakiegoś powodu się odwidzi.
To byłaby moja pierwsza biblioteka dla Amiga OS3 (i druga dla Amiga OS ogólnie, bo zrobiłem kiedyś prostą bibliotekę dla AmigaOS4, ale tam robi je się inaczej).
Żeby umieścić całe środowisko kompilowania bibliotek współdzielonych Amigi trzeba sporo dodatkowej pracy.
Obecnie chciałbym po prostu zrobić z tego bibliotekę według wytycznych z RKRM, a nie tworzyć takie środowisko.
Tak na marginesie, to ja nie jestem takim zagorzałym fanem idei open source, jako że to właśnie porty - te niechlujne - ściągnęły nieszczęście na takie systemy jak AmigaOS4, wymuszając na użytkownikach kupowanie dużo droższego sprzętu, niż w rzeczywistości jest wymagany dla danego oprogramowania.
Obawiam się, co stało by się z moim kodem, gdybym dał pełną swobodę jego modyfikacji. Od wprowadzenia bugów, aż po wygórowane minimalne wymagania typu Vampire.
Dlatego też jestem sceptyczny w tej kwestii. Jeżeli miałbym porzucić swoją pracę na rzecz Amigi, przekazałbym wszystkie swoje prace komuś zaufanemu w pierwszej kolejności.
Nie zamierzam jednakże porzucać tej pracy. Zamierzam dopisać procedury w asemblerze do prostej obróbki grafiki, korzystające z mojej konwersji c2p, a następnie bibliotekę współdzieloną, no i grę (RTS) korzystającą z tych funkcji.
13.12.2017 09:12
[#80]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #79
Jak kod będzie uwolniony to raczej nie sądzę żeby to popłyneło w stronę "minimalne wymagania 100MHz 060", a już minimalne wymagania Vampir to jest totalne nieporozumienie. Jeśli kod jest otwarty to raczej to nie grozi. A szanse na to że ktoś zechce się przyczynić do rozwoju biblioteki zawsze będą większe. Musisz ewentualnie zadbac o to żeby biblioteka się nadmiernie nie rozrosła i nie próbowała byc "do wszystkiego", co powinno być to do ogarnięcia. Tabunów koderów dobijających sie do drzwi repo bym się nie spodziewał jednak
Ostatnia aktualizacja: 13.12.2017 09:13:34 przez pisklak
Ostatnia aktualizacja: 13.12.2017 09:13:34 przez pisklak
13.12.2017 09:15
[#81]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #79
nie jestem takim zagorzałym fanem idei open source, jako że to właśnie porty - te niechlujne - ściągnęły nieszczęście na takie systemy jak AmigaOS4, wymuszając na użytkownikach kupowanie dużo droższego sprzętu, niż w rzeczywistości jest wymagany dla danego oprogramowania
Jako że kod jest otwarty, to wystarczy go "chlujnie" przeportować, przepisując znaczne części od nowa. Ba, potem można nawet swoje poprawki dodać do głównego brancha, to wszyscy skorzystają.
13.12.2017 09:23
[#82]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #59
Tymczasem oto linki do:
kodu nowej wersji
źródła programu testującego
samego programu testującego
Hex, coś popsułeś ;) Teraz jest wolniej na Vampire :D
BYŁO: 1.37200 / 5.44600 ms
JEST: 1.38040 / 5.46560 ms
Oczywiście nikt tej różnicy gołym okiem nie zauważy, ale byłem zdziwiony, skoro pisałeś że masz przyrost +25% i +17% na 020/030 :D
13.12.2017 09:35
[#83]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #79
Tak na marginesie, to ja nie jestem takim zagorzałym fanem idei open source, jako że to właśnie porty - te niechlujne - ściągnęły nieszczęście na takie systemy jak AmigaOS4, wymuszając na użytkownikach kupowanie dużo droższego sprzętu, niż w rzeczywistości jest wymagany dla danego oprogramowania.
Jakie to niechlujne porty ściągnęły nieszczęście na AmigaOS4 poprzez wymuszanie kupowania drogiego sprzętu? Generalnie według mnie gdyby nie porty, nie mielibyśmy prawie żadnego nowego oprogramowania. Skończyły się czasy kiedy programiści rozwijali pod AmigaOS komercyjne programy (z małymi wyjątkami). Całe szczęście teraz oprogramowanie pisze się w językach wysokiego poziomu przez co ich portowanie jest/było stosunkowo łatwe, lecz wymagania przez to są większe. Niestety powoli i to się zmienia, pojawił się LLVM i CLANG czy inne RUSTy, których próżno u nas szukać a przez, które portowanie na nasze platformy jest coraz trudniejsze a w zasadzie nie możliwe.
13.12.2017 14:21
[#85]
Re: W temacie mojej procedury konwersji c2p
@skipp, post #82
Hex, coś popsułeś ;) Teraz jest wolniej na Vampire :D
Nic nie popsułem.
Kod obu wersji procedury jest dostępny do wglądu. Na 68020 i 68030 jest szybciej.Widać dostęp do pamięci jest szybszy na A1200 + 020/030 aniżeli na Vampire, bo jedyne co zmieniłem to wstawiłem maski do rejestrów (które pierwotnie były danymi natychmiastowymi), zaś do pamięci odnoszę się co każdą linijkę bitmapy (a konkretnie do pól bm_BytesPerRow i bm_Rows, które pierwotnie były w rejestrach).
Ostatnia aktualizacja: 13.12.2017 14:22:12 przez Hexmage960
13.12.2017 14:28
[#87]
Re: W temacie mojej procedury konwersji c2p
@skipp, post #86
A próbowałeś odpalać test wielokrotnie? Ze względu na to, że moja procedura pracuje w wielozadaniowości wyniki poszczególnych testów mogą się różnić (bardzo nieznacznie, na 020/030 błąd rzędu 0.1 ms).
Być może moja optymalizacja nie wpłynęła zbytnio na wynik na karcie Vampire.
Ostatnia aktualizacja: 13.12.2017 14:30:11 przez Hexmage960
Być może moja optymalizacja nie wpłynęła zbytnio na wynik na karcie Vampire.
Ostatnia aktualizacja: 13.12.2017 14:30:11 przez Hexmage960
13.12.2017 14:31
[#88]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #87
A tak w ogóle to jaki jest sens wymyślać koło na nowo ? Przecież tego typu procedurki tworzono i co ważniejsze wykorzystano w finalnych tytułach. Sądzisz, że zrobisz to lepiej niż Team 17 ? :) Śmiem wątpić.
Amiga do 3D się nie nadaje i tyle. Chyba, że ma kartę graficzną ze wsparciem dla 3D, ale wtedy korzystasz z gotowych bibliotek i tworzysz sobie co tam tylko chcesz.
Amiga do 3D się nie nadaje i tyle. Chyba, że ma kartę graficzną ze wsparciem dla 3D, ale wtedy korzystasz z gotowych bibliotek i tworzysz sobie co tam tylko chcesz.
13.12.2017 14:37
[#89]
Re: W temacie mojej procedury konwersji c2p
@xray, post #88
Oryginalne procedury chunky2planar w Gloomie czy Alien Breedzie 3D II nie są najszybsze.
Chunky nie stosuje się tylko w 3D. Z powodzeniem może posłużyć do procedur 2D, takich w których mapujemy piksele (np. zmieniamy jasność, obliczamy wypadkową dwóch barw, czy robimy inne efekty).
Amiga do 3D się nie nadaje i tyle.
Chunky nie stosuje się tylko w 3D. Z powodzeniem może posłużyć do procedur 2D, takich w których mapujemy piksele (np. zmieniamy jasność, obliczamy wypadkową dwóch barw, czy robimy inne efekty).
13.12.2017 14:39
[#90]
Re: W temacie mojej procedury konwersji c2p
@Hexmage960, post #87
Być może moja optymalizacja nie wpłynęła zbytnio na wynik na karcie Vampire
Też tak myślę. W rozumieniu, że te to już granica, której nie da się przeskoczyć ;) No i testuję różne rdzenie AGA obecnie, jest prawdopodobne, że te mikroskopijne różnice stąd się biorą (nie pamiętam, na którym testowałem Twoje C2P w wersji 1). Przy drugim teście, na jednym i tym samym rdzeniu TESTC2P_V2 jest minimalnie wolniejszy, o 0.0032 i 0.0028 ms ;) Tak więc tyle co nic, no i wklejam te wyniki wyłącznie jako ciekawostkę. Najważniejsze, że masz sporą poprawę osiągów na 020/030, bo o to przecież chodzi.