Master of Sprites - sprite edytor w javie

[juntek]

Wiem if - else if - else tam powinno być a nie switch.

Z punktu widzenia wydajności nie ma różnicy.

Natomiast zmień „x/2” na „x >>> 1” bo tu różnica będzie znaczna.

Możesz jeszcze zmienić inkrementację postfiksową na prefiksową (x++ na ++x) bo wtedy kompilator nie musi tworzyć w pamięci zmiennej roboczej.

[Operator Teleksu]

Wiem if - else if - else tam powinno być a nie switch.

Z punktu widzenia wydajności nie ma różnicy.

Ja miałem na myśli że to się wgl nie skompiluje bo kompilator oczekuje wartości stałej po instrukcji case. Tak przynajmniej o ile pamietam bylo w C (a w Javie nie jestem już pewien).

[Operator Teleksu]

Ogólnie widzę że chcąc nie chcąc wywołałem dość długą dyskusje. Ja podsumuję to na razie tak, że mam już zrobione obracanie i eksport do kodu asemblera.

Obracanie zrobiłem tak prostą metodą jak opisał Gordian (może nawet jeszcze prostszą) - owszem nie działa to idealnie dla trybu multikolor, ale lepszy rydz niż nic, być może nie możliwe nawet wymyśleć nic lepszego. Poza prostokątnymi pikselami trybu multikolor trzeba zauważyć jeszcze inne problemy:

• ogólnie bardzo niska rozdzielczość - obrót o dowolny, inny niż 90 stopni, kąt zawsze będzie sporym przybliżeniem
• duszki nie są kwadratowe tylko zawsze trochę szersze niż wyższe - obrócony sprite może nie mieścić się w swoich ramach

Także jestem i tak zadowolony z tego co jest.

Tylko następna wersja nie tak prędko - chcę uzbierać trochę więcej zmian, przede wszystkim ten podgląd animacji.

[juntek]

Ja miałem na myśli że to się wgl nie skompiluje bo kompilator oczekuje wartości stałej po instrukcji case. Tak przynajmniej o ile pamietam bylo w C (a w Javie nie jestem już pewien).

Jaki problem przenieść "palette.getColor()" do trzech zmiennych "final" przed wszystkie pętle "for"?
Po cholerę wołać to samo x * y razy?

[Gordian]

duszki nie są kwadratowe tylko zawsze trochę szersze niż wyższe - obrócony sprite może nie mieścić się w swoich ramach

Tym bym się nie przejmował. Założyłbym, że jeśli ktoś obraca duszka, to zarysowany obszar jest mniejszy od 24x21.
Ale gdybyś pokusił się o wprowadzenie opcji tworzenia duszków z kilku duszków (o tym wspominał Carrion), to można by było na siatce duszków 2x2 wrysować obiekt o większych rozmiarach w środek i nie byłoby problemu z obcinanymi fragmentami.

[Operator Teleksu]

Po cholerę wołać to samo x * y razy?

Fakt. Czasami, z rozpędu piszę, nie myśląc zupełnie.

Jaki problem przenieść "palette.getColor()" do trzech zmiennych "final" przed wszystkie pętle "for"?

Żaden i owszem tak już zrobiłem (dla lepszej wydajności). Ale jeśli chodzi o switch - case to NetBeans nadal mi protestuje że po case wymaga stałej - nawet jak palette.getColor() zapisałem do zmiennej final.

[Operator Teleksu]

duszki nie są kwadratowe tylko zawsze trochę szersze niż wyższe - obrócony sprite może nie mieścić się w swoich ramach

Tym bym się nie przejmował. Założyłbym, że jeśli ktoś obraca duszka, to zarysowany obszar jest mniejszy od 24x21.

Też się tym nie przejmuję, też z takiego powodu.

Ogólnie to jest zadowolony, pisałem tylko w tym sensie że za ideał uważam sytuację, kiedy obrót o x w jedną stronę daje się zawsze cofnąc obracając o x w drugą. Dla 90 stopni i trybu singlecolor to w zasadzie tak owszem jest (jeśli zarysowany obszar jest mniejszy od 24x21).

[juntek]

Ale jeśli chodzi o switch - case to NetBeans nadal mi protestuje że po case wymaga stałej - nawet jak palette.getColor() zapisałem do zmiennej final.

Uparłbym się i zrobił z tych getColor()-ów enuma
To powinno uspokoić NetBeansy.

[Operator Teleksu]

Jakby ktoś chciał zobaczyć postępy i jak działa te obracanie - zdecydowałem się jednak wypuścić kolejną jarkę:

https://github.com/tstamborski/master-o ... prites.jar

Obiecywanego podglądu animacji nie ma nadal, ale i tak chciałem zrobić tag na githubie zanim zajmę się tym zadaniem.

[Operator Teleksu]

Zrobiłem wreszcie obiecywany podgląd animacji (i nakładania). Postanowiłem z tej okazji wrzucić na csdb:

https://csdb.dk/release/?id=243281

Mam nadzieje że to działa jak należy. (?)

[Gordian]

Tak myślę, że obrót można by było jeszcze inaczej rozwiązać. Właściwie wiązałoby się to ze zmianą edycji duszka w multikolorze.
Mianowicie edytor pozwalałby rysować duszka w 4 kolorach, ale w siatce 24x21. Natomiast podgląd i generowanie tworzyłoby oczywiście piksele 2x1. Mogłaby być ewentualnie opcja wyboru czy kolor piksela 2x1 ma być wzięty zawsze z lewego czy zawsze z prawego piksela.
Dzięki temu obrócony/skalowany duszek mógłby być generowany ze źródłowego duszka hires'owego.
Program musiałby umożliwiać zapis we własnym formacie, gdzie zawarty byłby tenże hires'owy duszek.

Jeśli natomiast wczytany z innego formatu duszek byłby w mulikolorze, to trzeba by traktować każdy piksel 2x1 jako dwa odrębne pixele hires w tym samym kolorze.