Loadery do stacji IEC-only

Wiadomość

#41 Post autor: **Nitro** » 17 lut 2011, 22:59

wystarczy sprawdzić kilka punktów obok czy nie zawierają tego samego punktu tekstury a nie trzeba sprawdzać wszystkich.

Trzeba aby była pełna optymalność, przykładowo tunel - symetria pozostałych trzech ćwiartek wzdłuż pierwszej ćwiartki.
Przy tunelu akurat łatwo to zauważyć i można napisać mądry generator, ale prawdziwie uniwersalnym rozwiązaniem jest brute force, który na PC jest czystą formalnością.

Mam tylko jedna uwagę bo ładując z decrunchem efekt gdy nie generujemy speedcodu to musimy mieć mnóstwo wolnej pamięci aby to się zmieściło. Przy generacji zazwyczaj nie ma takich wymagań pamięciowych.

Decrunch jest na bieżąco podczas ładowania, w niektórych przypadkach generator i dane do niego zajmują dużo miejsca, a jeszcze trzeba drugie tyle na speedcode, np. wspomniany distorter.

ps. czy da się w Kickass korzystać w makrach z danych ładowanych z plików zewnętrznych?

Oczywiście, jest również fajny system szablonów co i gdzie jest w pliku, sprawdź manual, rozdział 8.4
Np:

.var dataTemplate = "XCoord=0,YCoord=$100, BounceData=$200"
.var file = LoadBinary("moveData", dataTemplate)
XCoord: .fill file.getXCoordSize(), file.getXCoord(i)
YCoord: .fill file.getYCoordSize(), file.getYCoord(i)
BounceData: .fill file.getBounceDataSize(), file.getBounceData(i)

Nie ma żadnych przeszkód, aby wszystkiego powyżej w makrach.

Digger · #42 Post autor: **Digger** » 20 lut 2011, 22:30

Zajebista dyskusja, dużo się dowiaduję z tego rozgrzebanego mrowiska

Po 15 latach rzeczy się delikatnie mówiąc zmieniły. Personalnie przychylam się do opcji Nitra (kompresowalny speedcode) – łatwo wygenerować w KickAssie, przy tym zabawa w skomplikowany generator na C64 to mega mordęga – ja już nie mam na to czasu, sorry

Noipoco.

Ładowanie plus równoczesna dekompresja +1!

zielok · #43 Post autor: **zielok** » 20 lut 2011, 23:01

Ej no, nie przesadzajmy z tą mega mordęga przy generowaniu speedcodu. Ja przy pisaniu generatora nie spędziłem nigdy dłużej niż góra 20 minut. Zazwyczaj zdecydowanie więcej czasu mi zajmuję zooptymalizowanie procedury którą użyje w speedcodzie (a to także w KickAss występuje). Widocznie nie napisałem mega skomplikowanego speedcodu:)

ps. Zresztą ja to dziwny jestem bo sinusy i fonty także generuje w trakcie wykonywania:)
sp2. Wizualizacji w processingu nie robię głównie dlatego, że jednak specyfika c64 jest inna i musiałbym i tak to pisać jeszcze raz (więc szkoda czasu:))

k. · #44 Post autor: k. » 20 lut 2011, 23:51

@zielok a do generacji sinusów (albo jakiś takich) używasz procedur FP w basicu?

zielok · #45 Post autor: **zielok** » 21 lut 2011, 08:08

Nie, czysty asm (czyli nie wywołuje żadnych procedurek z kernala)

Digger · #46 Post autor: **Digger** » 21 lut 2011, 10:03

@zielok: ale fonty generujesz niby jak? z glyph'ów?

zielok · #47 Post autor: **zielok** » 21 lut 2011, 11:20

Nie z glyphów. Generuje fonty (nie jako litery a jako zestaw ditherowanych kostek) za pomocą specyficznego algorytmu (nie używam randomowych wartosci, więc są zawsze takie same). Dzięki temu fonty zajmują 233 bajty (przed wygenerowaniem) zamiast 2048 bajtów. Oczywiście jeśli dane skompresujemy to różnica nie jest tak duża ale i tak zajmują zdecydowanie mniej miejsca.
Przydaje się to głównie w intrach typu 1024 bajtów ale w demie tez może być czasem przydatne (wszystko będzie zależeć od specyficznej sytuacji)... Zresztą inaczej niemożliwe byłoby zmieszczenie ditherowanej tablicy znaków w takim intrze. Technikę te będzie można zobaczyć w moim intrze które przygotowałem na Forever.