Komentowana treść: Tony - wersja cyfrowa
09.06.2024 19:16
[#31]
Re: Tony - wersja cyfrowa
@kiero, post #25
Chciałem tylko napisać, że na platformach nieamigowych wcale nie jest tak cudownie i różowo. Nie potrafię zaakceptować tego co się dzisiaj wyprawia. Granice przyzwoitości zostały wielokrotnie przekroczone. Absolutnie nie wymagam cudów, żadnych specjalnych optymalizacji tylko odrobiny honoru i przyzwoitości w tym co się robi. Często to co jest nam serwowane za dosłownie setki milionów i sprzedawane jako wielka nowoczesność jest żartem i kpiną. I nie ma to nic wspólnego spólnego z Amigą, bo ona w tym świecie nie istnieje.
Ostatnia aktualizacja: 09.06.2024 19:29:33 przez MDW
Ostatnia aktualizacja: 09.06.2024 19:29:33 przez MDW
09.06.2024 20:50
[#32]
Re: Tony - wersja cyfrowa
@MDW, post #31
Ok, ale to chyba trochę rozczarowanie/zgorzknienie tym jak dzisiaj wyglądają duże komercyjne projekty. Zgadza się, ale nie musisz tego uogólniać na wszystkie dziedziny. Przejście z programowania na Amigę nie musi oznaczać że kończysz z programowaniem dla sportu/przyjemności. I wiele osób nie kończy.
Ostatnia aktualizacja: 09.06.2024 20:53:02 przez kiero
Ostatnia aktualizacja: 09.06.2024 20:53:02 przez kiero
09.06.2024 21:06
[#33]
Re: Tony - wersja cyfrowa
@kiero, post #32
Oczywiście, że zakończenie zabawy z Amigą to nie koniec programowania. Wręcz przeciwnie - to dopiero początek sensownego programowania. Generalnie dotykanie Amigi po 1995 roku to zawsze było uwstecznianie się i hamowanie własnego rozwoju. W żaden logiczny sposób nie da się wytłumaczyć aktywności w świecie amigowym od drugiej połowy lat 90 XX wieku. 
Jedynym wytłumaczeniem było "bo lubię".
Jedynym wytłumaczeniem było "bo lubię". 09.06.2024 21:39
[#34]
Re: Tony - wersja cyfrowa
@kiero, post #25
Ja osobiscie MDW bardzo dobrze rozumiem i nawet sie z nim zgadzam jesli chodzi o pewne aspekty programowania.
Ze swojej strony chcialbym pokazac jak wyglada obecnie programowanie nie komputerow ale systemow przemyslowych opartych o sterowniki PLC oraz robotow.
Siedze w tej brazny prawie 20 lat i widze jak to sie zmienilo na przestrzeni tych lat.
Kiedys programisci tych sterownikow faktycznie walczyli o kazdego bita bo sterowniki byly jakie byly.
Obecnie systemy dla przemyslu poszly tak daleko do przodu ze nie ma praktycznie zadych oganiczen a producenci tych systemow dali programistom wolna reke.
I uwazam ze to byl najwiekszy blad. Mlodzi ludzie zaraz po studiach ktorzy lizneli jezyki wysokiego poziomu zaczeli z tego nadmiernie kozystac programujac PLC.
Spwodowalo ze zamiast napisc cos prosto zaczeli wprowadzac swoje zdolnosci obiektowosci i inne go...na do tego stopnia ze analiza takich programow trwa godzinami.
A potrafia wymysliac takie rzeczy w STLu lub SCLu ze wlosy jeza sie na glowie.
Jesli zatrzyma sie maszyna to liczy sie czas i pieniadze. I obecnie ponowne jej uruchomienie moze trwac godzine a powinno 5 minut.
Jednym slowem kibel straszny.
Napisalbym co jeszcze o obecnych sieciach przemyslowych ale juz nie mam sily. Jednym slowem gorsze wyparlo lepsze. Ktory to juz raz?
Ostatnia aktualizacja: 09.06.2024 21:54:07 przez Phibrizzo
Ze swojej strony chcialbym pokazac jak wyglada obecnie programowanie nie komputerow ale systemow przemyslowych opartych o sterowniki PLC oraz robotow.
Siedze w tej brazny prawie 20 lat i widze jak to sie zmienilo na przestrzeni tych lat.
Kiedys programisci tych sterownikow faktycznie walczyli o kazdego bita bo sterowniki byly jakie byly.
Obecnie systemy dla przemyslu poszly tak daleko do przodu ze nie ma praktycznie zadych oganiczen a producenci tych systemow dali programistom wolna reke.
I uwazam ze to byl najwiekszy blad. Mlodzi ludzie zaraz po studiach ktorzy lizneli jezyki wysokiego poziomu zaczeli z tego nadmiernie kozystac programujac PLC.
Spwodowalo ze zamiast napisc cos prosto zaczeli wprowadzac swoje zdolnosci obiektowosci i inne go...na do tego stopnia ze analiza takich programow trwa godzinami.
A potrafia wymysliac takie rzeczy w STLu lub SCLu ze wlosy jeza sie na glowie.
Jesli zatrzyma sie maszyna to liczy sie czas i pieniadze. I obecnie ponowne jej uruchomienie moze trwac godzine a powinno 5 minut.
Jednym slowem kibel straszny.
Napisalbym co jeszcze o obecnych sieciach przemyslowych ale juz nie mam sily. Jednym slowem gorsze wyparlo lepsze. Ktory to juz raz?
Ostatnia aktualizacja: 09.06.2024 21:54:07 przez Phibrizzo
11.06.2024 09:17
[#38]
Re: Tony - wersja cyfrowa
@Pinto, post #8
Nie sądziłem, że są jeszcze malkontenci co to będą płakać "bo to powinno śmigać na 0,5MB". Pod Winuae też ustawiłeś sobie pół mega ramu? 
I kolejny gdzieś tam pisał "cena za wersję c64 kosmiczna" czy jakoś tak. Zrób, napisz sam, wydaj za darmo, będziesz sławny, będą o tobie pisać książki amigowe. "Dzizas, k...a, ja p...ę" jak mawiał Adaś Miauczyński w Dniu świra...
I kolejny gdzieś tam pisał "cena za wersję c64 kosmiczna" czy jakoś tak. Zrób, napisz sam, wydaj za darmo, będziesz sławny, będą o tobie pisać książki amigowe. "Dzizas, k...a, ja p...ę" jak mawiał Adaś Miauczyński w Dniu świra... 11.06.2024 13:23
[#43]
Re: Tony - wersja cyfrowa
Tutaj tak dla porównania. Proponuję ustawić w ustawieniach od razu 50 FPS.
AMIGA
C64
ATARI XL/XE
AMIGA
C64
ATARI XL/XE
12.06.2024 17:32
[#49]
Re: Tony - wersja cyfrowa
@lukjan, post #48
Dlaczego gra na Amidze wygląda niemal identycznie jak na Commodore 64 i Atari XL/XE? Na pierwszy rzut oka może wydawać się, że twórcy gry nie wykorzystali pełni możliwości, jakie oferuje Amiga, znacznie potężniejsza platforma w porównaniu do swoich 8-bitowych poprzedników. Autor gry, korzystając jedynie z dwóch kolorów, mógł zaprezentować bardziej zaawansowaną grafikę, oferując więcej cieni, większe sprite'y oraz bardziej dopracowane detale. Amiga, dzięki swoim możliwościom sprzętowym, takim jak bogatsza paleta kolorów i bardziej złożona architektura graficzna, powinna była pozwolić na stworzenie wizualnie imponującej gry. Niestety, w tej konkretnej produkcji potencjał ten został zmarnowany.Jednak zaskakująco wysokie wymagania sprzętowe gry na Amidze rodzą pytania. Czy gra naprawdę potrzebuje aż tak dużej ilości pamięci? Wydaje się, że optymalizacja kodu i zasobów nie została przeprowadzona w sposób efektywny, co sprawia, że gra zajmuje nieproporcjonalnie dużo miejsca w pamięci, nie oferując w zamian znaczących korzyści wizualnych. W efekcie, mimo zaawansowanych możliwości sprzętowych Amigi, gra graficznie pozostaje na poziomie, który mógłby być osiągnięty na mniej zaawansowanych komputerach.Podsumowując, w wersji na Amigę na plus wyróżniają się ścieżka dźwiękowa i mechanika gry. Dźwięk w tej wersji jest znacznie bardziej rozbudowany i wykorzystuje możliwości Amigi do stworzenia bogatszych i bardziej złożonych kompozycji audio. Mechanika gry również jest dopracowana, co sprawia, że sama rozgrywka może być bardziej wciągająca i satysfakcjonująca. Natomiast grafika jest bardzo przeciętna, co w kontekście możliwości Amigi jest rozczarowujące.Z kolei wersje na 8-bitowe komputery, takie jak Commodore 64 i Atari XL/XE, to prawdziwe arcydzieła. Twórca gry, mając do dyspozycji znacznie bardziej ograniczone zasoby sprzętowe, zdołał stworzyć imponującą wizualnie produkcje. Wykorzystał on możliwości dostępne na tych platformach, co zaowocowało grą,która mimo swoich ograniczeń technicznych(na maszynach 8 bitowych), prezentuje się bardzo dobrze i jest świadectwem kreatywności oraz umiejętności programistycznych tego autora.
Ostatnia aktualizacja: 12.06.2024 17:34:37 przez skofrant
Ostatnia aktualizacja: 12.06.2024 17:35:24 przez skofrant
Ostatnia aktualizacja: 12.06.2024 17:34:37 przez skofrant
Ostatnia aktualizacja: 12.06.2024 17:35:24 przez skofrant
12.06.2024 18:00
[#50]
Re: Tony - wersja cyfrowa
@skofrant, post #49
Większość gier indie nie wykorzystuje nawet w 10% możliwości dzisiejszych komputerów z Windows/macOS/Linux. Często mają jakąś absurdalnie niską rozdzielczość na poziomie 320x240, paletę na siłę udającą 16 kolorów. A jednak takie gry osiągają sporą popularność, nieźle się sprzedają, podobają się i sporo DOBREGO się o nich mówi. Na przykład w ostatnich kilku latach: "Papier, please" albo "Beat Cop". Nie tylko nikt nie marudzi, że "zupełnie nie wykorzystuje to możliwości dzisiejszych komputerów" ale wręcz taka oprawa graficzna jest zaletą. Taka była wizja autorów i całkiem fajnie to wyszło. Podobnie jest z "Tony" dla Amigi. Taka była grafika, taki był na nią pomysł i po prostu stworzono wersję dla Amigi, która się tego trzyma.
Zauważyłem, że retro-fani mają jakiegoś świra na punkcie ciągłego udowadniania czegoś całemu świat. Gra cały czas musi udowadniać, że można pokazać więcej kolorów niż założyli twórcy sprzętu. Może być kicz, szmirowate tęcze, ale każdy screenshot ma pokazywać więcej niż 32 kolory na A500. Nieistotna jest grywalność, bo i tak nikt w to grał nie będzie. Ma wyglądać jak jarmarczny kramik i wtedy "grafika jest dobra". Niestety mamy trochę takich gier na Amidze - wyglądają kolorowo (czy nie ładnie to dyskusyjne) ale grać się w to nie da, bo jest nudne, sterowanie jest do kitu, pomysł wtórny. Nie da się zrobić klimatycznej grafiki w odcieniach szarości, bo przecież to nie będzie "dobra grafika". Na Amidze takich gier nie można robić. Do takich gier trzeba dzisiejszych komputerów, konsol i smartfonów, bo na nich niczego nie trzeba udowadniać i twórcy spokojnie mogą realizować swoją wizję.
Ostatnia aktualizacja: 12.06.2024 18:03:56 przez MDW
Zauważyłem, że retro-fani mają jakiegoś świra na punkcie ciągłego udowadniania czegoś całemu świat. Gra cały czas musi udowadniać, że można pokazać więcej kolorów niż założyli twórcy sprzętu. Może być kicz, szmirowate tęcze, ale każdy screenshot ma pokazywać więcej niż 32 kolory na A500. Nieistotna jest grywalność, bo i tak nikt w to grał nie będzie. Ma wyglądać jak jarmarczny kramik i wtedy "grafika jest dobra". Niestety mamy trochę takich gier na Amidze - wyglądają kolorowo (czy nie ładnie to dyskusyjne) ale grać się w to nie da, bo jest nudne, sterowanie jest do kitu, pomysł wtórny. Nie da się zrobić klimatycznej grafiki w odcieniach szarości, bo przecież to nie będzie "dobra grafika". Na Amidze takich gier nie można robić. Do takich gier trzeba dzisiejszych komputerów, konsol i smartfonów, bo na nich niczego nie trzeba udowadniać i twórcy spokojnie mogą realizować swoją wizję.
Ostatnia aktualizacja: 12.06.2024 18:03:56 przez MDW
13.06.2024 01:50
[#51]
Re: Tony - wersja cyfrowa
@skofrant, post #49
Kod gry można sobie optymalizować bez końca, tak jak to się dzieje w przypadku Jumpa więc premiera by się odbyła za rok albo wcale.
Jeśli chodzi o wymagany fast ram... skoro stać cię na Amigę to chyba stać również na dokupienie fastu? A jeśli nie, to w winuae jest magiczny suwak przy Fast RAM Zorro 2.
No a co do kolorów. Gra z założenia jest monochromatyczna. Ile trzeba wałkować ten temat? Do pudełka z grą dołączać kredki aby sobie każdy pokolorował? Superfrog był w 16 kolorach i nikt o to jakoś nie płacze!
Jeśli chodzi o wymagany fast ram... skoro stać cię na Amigę to chyba stać również na dokupienie fastu? A jeśli nie, to w winuae jest magiczny suwak przy Fast RAM Zorro 2.
No a co do kolorów. Gra z założenia jest monochromatyczna. Ile trzeba wałkować ten temat? Do pudełka z grą dołączać kredki aby sobie każdy pokolorował? Superfrog był w 16 kolorach i nikt o to jakoś nie płacze!
13.06.2024 07:10
[#52]
Re: Tony - wersja cyfrowa
@skofrant, post #49
Dlaczego gra na Amidze wygląda niemal identycznie jak na Commodore 64 i Atari XL/XE? Na pierwszy rzut oka może wydawać się, że twórcy gry nie wykorzystali pełni możliwości, jakie oferuje Amiga, znacznie potężniejsza platforma w porównaniu do swoich 8-bitowych poprzedników. Autor gry, korzystając jedynie z dwóch kolorów, mógł zaprezentować bardziej zaawansowaną grafikę, oferując więcej cieni, większe sprite'y oraz bardziej dopracowane detale. Amiga, dzięki swoim możliwościom sprzętowym, takim jak bogatsza paleta kolorów i bardziej złożona architektura graficzna, powinna była pozwolić na stworzenie wizualnie imponującej gry.
Bo to ma być z założenia TAKA SAMA GRA z TAKĄ SAMĄ GRAFIKĄ od (Monochrome Productions) na różnych platformach.
Forum PPA nie przestaje zadziwiać ostatnio
Ostatnia aktualizacja: 13.06.2024 07:11:35 przez Jacques
13.06.2024 10:32
[#53]
Re: Tony - wersja cyfrowa
@Jacques, post #52
Rzeczywiście, jest to typowy port. Szkoda, ponieważ na 8-bitowych maszynach, które obserwuję od wielu wielu lat, wciąż powstają wizualne perełki. Niestety, Amiga jest często pomijana w tym kontekście. Rozumiem różne argumenty, ale osobiście przyzwyczaiłem się do charakterystycznej oprawy graficznej Amigi, która zawsze była rozpoznawalna i prezentowała się lepiej niż na większości wtedy platformach...
13.06.2024 17:10
[#57]
Re: Tony - wersja cyfrowa
@kobajaszi, post #56
No nie jest portem.
Ogólnie gra była celowana w 8-bitowce. Grafiki były tworzone w Charpadzie, który jest przeznaczony dla C64. Takie grafiki otrzymałem wraz z danymi mapy. Amiga podwoiła sobie rozmiary kafelków mapy, ponieważ rozmiarowo nie da się trzymać kafla 8x8 pikseli w pamięci, a 16x8 pikseli. Dodatkowo każdy kafelek jest w 3 bitplanach (2 bitplany na grafikę + 1 bitplan na maskę). Dlaczego? Już tłumaczyłem kiedyś.
Skoro kafle są rozmiarów 8x8 pikseli, a komnat jest wiele, to znaczy, że tablica z mapą danego poziomu również jest sporych rozmiarów. Do tego bardzo dużo animowanych grafik i pamięć jest zapełniona. Porównywałem na filmiku te 3 wersje i moim zdaniem wersja amigowa nie jest w niczym gorsza, a tylko lepsza.
- podczas zabijania przeciwnika mając eliksir mamy efekt dźwiękowy + miganie copperem czego nie ma tam, bo tylko znikają przeciwnicy ni stąd ni z owąd
- chodzenie po drabinkach miało być skokowe, tymczasem w 8-bitowcach obie wersje mają płynne przesuwanie sprajta, a tak nie miało być
- gra zawiera muzykę, która niekiedy zajmuje 160 KB w chip ramie, do tego trzeba doliczyć otwarte bitplany, ekran, dźwięki, których jest też sporo oraz bank grafik. Sam plik uruchamialny to 300KB, więc większość tego slow ramu mamy już zawalone nim. Dochodzi do tego tablica mapy levelu, która jest spora, dane duszków i mamy po slow ramie
- duszki w wersji amigowej są unikalne, każdy może się poruszać z inną szybkością w jednej komnacie, co jest przykładem już w wersji demo. Na 8-bitowcach to nie było możliwe
- duszki nietoperzy latających poziomo po komnacie są całkiem ręcznie sterowane. Niektóre potrafią latać dookoła ruchem eliptycznym. Tego nie dało się zrobić w 8-bitowcach
- menu gry również pożarło sporo pamięci CHIP. Rafał uparł się na bardzo długie napisy, które są przewijane na ekranie, a ekran tam jest dual playfieldzie, więc tam siedzi bitmapa bodajże 320x1200 pikseli w 3 bitplanach + bitmapa 320x200 pikseli w 3 bitplanach jako przedni playfield
- w kodzie gry jest dodany trainer, który również posiada swoje dane i powiększa plik uruchamialny. Po nim następuje wyświetlanie komiksu gry, co też trzeba było zaprogramować, przez co plik uruchamialny rośnie.
- grafika pauzy gry: to też zajmuje swoje w pamięci chip
- bitmapa z kolizjami rozmiaru 160x96 pikseli bodajże w 2 bitplanach - również w pamięci chip (a wszystkie takie bitmapy muszą być naraz w pamięci, aby przechodzenie pomiędzy komnatami działało w miarę szybko bez doczytywania z dyskietki)
- bodajże w wersji Atari po zebraniu przedmiotu oczy na belce nie mrugają, a powinny tak jak w wersji amigowej
Sam nie jestem za monochromatycznymi grami, więc wybieranie różnych palet w ustawieniach gry, to był mój pomysł.
Przez takie "wodotryski" mimo, że w 2 kolorach, to jednak pamięć się nam zapycha. Jeśli ktoś uważa że wersja amigowa jest najgorszą wersją, to proszę bardzo wybrać wersję C64, Atari, lub czekać na ZX 128. Każdy jest tylko mądry w gębie. Wersja ZX miała powalić na kolana, a tymczasem nic z tego nie wyszło. Wersja na ST miała powalić wersję z Amigi, dostali całą moją pracę jako wzór i polegli. Nawet dema nie zrobili. Ani w Stosie, ani w asemblerze, ani w C na PC-ta (a pisało ich aż trzech).
Gdybym miał wiedzę chociaż w połowie taką jak Asman i DonAdan, to Tony działałby może nawet na Amidze 1000 z 256KB chip ramu, no ale niestety wymagania poszły w górę. Jeśli tak bardzo zależy na koszerności, no to w takim razie proszę się przesiąść na 8-bitowce i grać w tamte ograniczone wersje gry.
Coś jeszcze wytłumaczyć?
Ogólnie gra była celowana w 8-bitowce. Grafiki były tworzone w Charpadzie, który jest przeznaczony dla C64. Takie grafiki otrzymałem wraz z danymi mapy. Amiga podwoiła sobie rozmiary kafelków mapy, ponieważ rozmiarowo nie da się trzymać kafla 8x8 pikseli w pamięci, a 16x8 pikseli. Dodatkowo każdy kafelek jest w 3 bitplanach (2 bitplany na grafikę + 1 bitplan na maskę). Dlaczego? Już tłumaczyłem kiedyś.
Skoro kafle są rozmiarów 8x8 pikseli, a komnat jest wiele, to znaczy, że tablica z mapą danego poziomu również jest sporych rozmiarów. Do tego bardzo dużo animowanych grafik i pamięć jest zapełniona. Porównywałem na filmiku te 3 wersje i moim zdaniem wersja amigowa nie jest w niczym gorsza, a tylko lepsza.
- podczas zabijania przeciwnika mając eliksir mamy efekt dźwiękowy + miganie copperem czego nie ma tam, bo tylko znikają przeciwnicy ni stąd ni z owąd
- chodzenie po drabinkach miało być skokowe, tymczasem w 8-bitowcach obie wersje mają płynne przesuwanie sprajta, a tak nie miało być
- gra zawiera muzykę, która niekiedy zajmuje 160 KB w chip ramie, do tego trzeba doliczyć otwarte bitplany, ekran, dźwięki, których jest też sporo oraz bank grafik. Sam plik uruchamialny to 300KB, więc większość tego slow ramu mamy już zawalone nim. Dochodzi do tego tablica mapy levelu, która jest spora, dane duszków i mamy po slow ramie
- duszki w wersji amigowej są unikalne, każdy może się poruszać z inną szybkością w jednej komnacie, co jest przykładem już w wersji demo. Na 8-bitowcach to nie było możliwe
- duszki nietoperzy latających poziomo po komnacie są całkiem ręcznie sterowane. Niektóre potrafią latać dookoła ruchem eliptycznym. Tego nie dało się zrobić w 8-bitowcach
- menu gry również pożarło sporo pamięci CHIP. Rafał uparł się na bardzo długie napisy, które są przewijane na ekranie, a ekran tam jest dual playfieldzie, więc tam siedzi bitmapa bodajże 320x1200 pikseli w 3 bitplanach + bitmapa 320x200 pikseli w 3 bitplanach jako przedni playfield
- w kodzie gry jest dodany trainer, który również posiada swoje dane i powiększa plik uruchamialny. Po nim następuje wyświetlanie komiksu gry, co też trzeba było zaprogramować, przez co plik uruchamialny rośnie.
- grafika pauzy gry: to też zajmuje swoje w pamięci chip
- bitmapa z kolizjami rozmiaru 160x96 pikseli bodajże w 2 bitplanach - również w pamięci chip (a wszystkie takie bitmapy muszą być naraz w pamięci, aby przechodzenie pomiędzy komnatami działało w miarę szybko bez doczytywania z dyskietki)
- bodajże w wersji Atari po zebraniu przedmiotu oczy na belce nie mrugają, a powinny tak jak w wersji amigowej
Sam nie jestem za monochromatycznymi grami, więc wybieranie różnych palet w ustawieniach gry, to był mój pomysł.
Przez takie "wodotryski" mimo, że w 2 kolorach, to jednak pamięć się nam zapycha. Jeśli ktoś uważa że wersja amigowa jest najgorszą wersją, to proszę bardzo wybrać wersję C64, Atari, lub czekać na ZX 128. Każdy jest tylko mądry w gębie. Wersja ZX miała powalić na kolana, a tymczasem nic z tego nie wyszło. Wersja na ST miała powalić wersję z Amigi, dostali całą moją pracę jako wzór i polegli. Nawet dema nie zrobili. Ani w Stosie, ani w asemblerze, ani w C na PC-ta (a pisało ich aż trzech).
Gdybym miał wiedzę chociaż w połowie taką jak Asman i DonAdan, to Tony działałby może nawet na Amidze 1000 z 256KB chip ramu, no ale niestety wymagania poszły w górę. Jeśli tak bardzo zależy na koszerności, no to w takim razie proszę się przesiąść na 8-bitowce i grać w tamte ograniczone wersje gry.
Coś jeszcze wytłumaczyć?
14.06.2024 00:08
[#59]
Re: Tony - wersja cyfrowa
@c64portal, post #58
W którymś wątku było. No nieważne. Używając GetAShape 0,0,0,8,8 wstawiasz shape o rozmiarze 8x8, lecz blitter pracuje tylko na wordach, więc ta instrukcja automatycznie tworzy shape rozmiaru 16x8. Gdybyś tworzył shape rozmiaru 17x16, to stworzy shape rozmiaru 32x16. Wszystko jest pod Peek.l (Addr Shape(nr) +14). Maska tworzy się automatycznie pod Peek.l (Addr Shape(nr) +18). Maska to po prostu skopiowane sumy bitów z bitplanów shape'a, ale z wyciętym niepełnym wordem. Dlatego używając Block wkleisz takiego shape'a 8x8, ale obok wymarze Ci kolejne 8x8 pikseli z bitmapy.
14.06.2024 07:48
[#60]
Re: Tony - wersja cyfrowa
@tukinem, post #59
ja to wyszystko wiem, a pytałem z tego powodu że u mnie w RobotJetAction (tóe idzie ostatnio powoli) mam też klocki 8x8 (zaszłość z mojej wersji gry na c64, której już nie zmienię teraz) i nie odnotowałem takich problem. Jasne zajmują więcej w pamięci, ale nie zauważyłem problemów z blitowaniem i nachodzeniem na siebie. Tak czy siak... Tonego już skończyłeś. Jest i działa. Gratulacje.