Tutaj dorzucę swoje 5 groszy, "co nie byłoby trudne do implementacji w FPGA?" chodzi tutaj głównie o 'koszt" zasobów niezbędny do implementacji. VBXE jest konstrukcją dosyć leciwą a jego zasoby, jak na dzisiejsze czasy, dość skromne :)

Nie tylko wielbiciele BASICa zaglądają na to forum i różne mądre dyskusje tutaj już były. Jak nikt się nie znajdzie, to trudno. Jakieś tam swoje pomysły już mam.

Ostatnio edytowany przez laoo/ng (2024-06-25 18:50:18)

@tOri, ja wywnioskowałem, że tu chodzi o nowy rdzeń do VBXE, stąd te ograniczenia. Więc tylko programowe
@laoo/ng: wydaje mi się, że wskazanym jest uderzyć bezpośrednio do Foxa lub XXL-a

@tOri, ja się opierałem na tym:

Więc chyba jednak chodzi o rdzeń VBXE.
Wskazuje też na to to:

Oraz odpowiedź MatGuru:

Dla mnie jest to jednoznaczne, ale co ja wiem, nie potrafię czytać ze zrozumieniem... :D

OK.

Niech laoo/ng sprecyzuje ponieważ ten moduł RLE trzeba by wkomponować "sprzętowo" własnie w rdzeń VBXE :)
Zresztą - pytanie było o coś lepszego niż RLE - to wszystko kwestia dostępnych zasobów w FPGA no i zręcznego projektanta, hehe.

tOri

Hej.
Trochę niefortunnie wyszło, bo nie jestem mistrzem w pisaniu zwięźle. Może jakby pierwszy temat był w dwóch zdaniach, a nie na całą stronę, to byłoby jaśniej.
W skrócie chodzi o zupełnie nowy rdzeń do VBXE, który będzie robił trochę inne rzeczy i pomyślałem, że może ktoś ma w rękawie jakieś fajne pomysły, jak zmodyfikować format kompresji z Lynksa, aby było jeszcze fajniej. Jak nikt nie ma, to nie ma problemu, bo jakieś tam pomysły już mam. Dzięki za odzew!

Ostatnio edytowany przez laoo/ng (2024-06-27 06:16:40)

Dałoby się ciekawą pracę magisterską napisać analizując i porównując sposoby, w jakie była generowana grafika w konsolach 8 i 16 bitowych.
Przez 18 lat nikt nie wziął i nie napisał innego rdzenia do VBXE, każdy, który by się za to brał, miałby swoją wizję. Moja wizja jest rezultatem moich doświadczeń i przemyśleń i uważam, że jest dobra. Póki nie okaże się, że w VBXE zrobić tego się nie da, rewolucji na miarę "zróbmy NeoGeo" nie przewiduję, bo to zupełnie inna filozofia (no i NeoGeo swoją wypaśność zawdzięcza bardziej grubej rurze, którą lecą piksele z cartridge'a na ekran, a nie jakiejś finezji - a takiej rury w VBXE nie mamy).

VBXE ma kilka slotów we flaszu. Jeszcze nie wiem jak to będzie można najlepiej technicznie rozwiązać, ale tak, trzeba będzie raz wgrać alternatywny rdzeń do VBXE i się na niego przełączyć, żeby odpalić grę, która go potrzebuje (to czego nie wiem, to czy gra będzie mogła poszukać sobie tego rdzenia i przełączyć się na niego sama, czy użytkownik będzie musiał sam się na niego przełączyć przed odpaleniem gry, ale to technikalia do ogarnięcia później).

Cala idea jest taka, aby (jak juz wszystko bedzie gotowe), kazdy majac minimalna wiedze asm/madp mogl sobie rysowac fajne sprity, majac viewport itd. Cel jest taki, ze nic takiej osoby ma nie interesowac. Wszystkie wczesniejsze shanigans, ktore powstawaly jak tworzylismy na Lynxie beda uzyte. Sprity beda spritesheetami w png i juz. Moga byc nawet 24bit. Automat dobierze najblizsze kolory i zaladuje do pamieci, a osoba piszaca gre/prodke zrobi ldx pox ldy pox lda sprite jsr rysuj , sta dziekuje.

Tak w uber tl;dr. Cel - ma byc tak prosto, ze majac demencje zakodzi sie fajna strzelanke. xd.

Co do kompresji - idea taka, aby dane spritow byly zawsze spakowane, a blitter w locie dekompresowal. Przy 4bitowych assetach  i ogolnie pixelowkach dobrze sie pakuje slownikowo. Osobe, ktora bedzie robila gre/itd nic ma nie interesowac - ma ladne sprity w png i tyle. A potem lda #SPRITES.enemies.hellcat jsr narysuj_mi_sprita i sie narysuje.

Planuje zrobic duzo przykladow, mockupow oraz pelnych produkcji, kazda bedzie publicznie dostepna.

Ostatnio edytowany przez solo/ng (2024-06-27 22:48:20)

VBXE ma już 18 lat (to już powoli retro bo jest starszy niż nasze Atari podczas rozkwitu sceny :)), więc próba tchnięcia w stary sprzęt nowego życia za pomocą świeżego firmware'u jest wg mnie jak najbardziej w duchu sceny.
Dodatkowo jest tego naklepane setki sztuk, więc może mieć to nawet wymiar dość praktyczny, jeżeli dałoby się tego użyć prościej.

Nie potrafię odpowiedzieć na to pytanie, ale nie wiem, czy jest to witalne zagadnienie. Skoro przez 18 lat nikt się tym nie interesował, to dlaczego nagle teraz miałby być wysyp zainteresowanych? Na razie są wczesne prace nad pomysłem, o którym myślę sobie od paru lat, mam prototyp funkcjonalności w Altirrze (więc od razu będzie emulacja) oraz pracujemy z Mateuszem nad prototypową implementacją w MiSTerze, jak będzie z wciśnięciem tego co wyjdzie do VBXE to zobaczymy. Jak się nie uda, to nie będzie tematu :)

Dekompresja jest w locie podczas rysowania sprajta. Szału nie ma, ale w zależności od sprajta kilkadziesiąt procent rozmiaru można być do przodu.

To zależy od narzędzi. Mamy już jakieś narzędzie do robienia rzeczy na Lynksa, tutaj blitter będzie dość kompatybilny z tym Lynksowym, więc narzędzia projektujemy analogiczne. Tu jest mój program do konwertowania PNG do sprajtów Lynksowych, mam już wersję dla "nowego rdzenia VBXE". Można poczytać co on potrafi - jest projektowany na generowanie scen, które mają wspólną paletę. Rozmiar sprajta z grubsza dowolny. Można trzymać wiele klatek animacji poziomo.

Ostatnio edytowany przez laoo/ng (2024-06-28 10:01:01)

Doświadczenie pokazuje, że taki rodzaj wykrywania kolizji jest bezużyteczny. Sens mają tylko hitboxy.
Jeżeli starczy miejsca, to chciałbym dodać do rdzenia sprzętowy "akcelerator hitboxów" - trzymałoby się w pamięci VBXE tablice boxów i FPGA mogłoby wykryć kolizje pomiędzy wybranymi zestawami. Ale to zobaczymy ile się zmieści.

Na razie vanilla-prostokąty bez udziwnień. Lepiej żeby było szybciej niż fikuśniej. Ale można mieć z tyłu głowy, że goście od Lynksa zrobili potem 3DO ;)

Jeśli może to być kompresja stratna to może coś z rodziny S3TC się nada.