Pokaż wiadomości

Ta sekcja pozwala Ci zobaczyć wszystkie wiadomości wysłane przez tego użytkownika. Zwróć uwagę, że możesz widzieć tylko wiadomości wysłane w działach do których masz aktualnie dostęp.


Wiadomości - siso

Strony: [1] 2 3 4 5 ... 37
1
Projekty rozpoczęte / Odp: Falleswen - New Land
« dnia: Marzec 29, 2019, 21:50:18 »
Fajne :)

Trzymam kciuki!

2
Projekty rozpoczęte / Odp: Symulacja Systemu Operacyjnego [Allegro5]
« dnia: Kwiecień 08, 2018, 19:19:48 »
Fajnie, że wracasz do tego projektu, bo widać Twoją wytrwałość :)

Skoro już tyle osiągnąłeś, to teraz czas na przyjacielską radę. Zainteresuj się tematem UI na Linuxie. Pogooglaj za takimi hasłami jak:
- X.org
- XLib (dlaczego nie)
- XCB (dlaczego tak)
- Wayland
- ICCCM
- EWMH
- Window Manager
 - TinyWM
 - Awesome
 - I3
 - Xephyr

Następnie rozważ jednak przepisanie kodu na język angielski i kontynuuj :)

Powodzenia!

3
Językoznawstwo / Odp: W czym się teraz pisze gry?
« dnia: Lipiec 09, 2016, 21:46:02 »
No takich farmazonów dawno nie słyszałem ;].
VS to standard w branży i najlepsze IDE z jakim pracowałem.
A słyszałeś o IntelliJ Idea? To jest najlepsze IDE.

Pod Unity skrojono na tej platformie Consulo. Polecam. Sam sobie w nim hobbystycznie klikam.

4
Projektowanie kodu / Odp: Strategia 2d - organizacja mapy
« dnia: Czerwiec 03, 2013, 10:26:33 »
Litości...
W dzisiejszych czasach  nie wypada aż tak drastycznie oszczędzać pamięci. Tym bardziej w domowym projekcie.  Jeśli już chcesz trzymać dane domenowe w gołych intach, opakuj je chociaż w strukturę. Zamiast bawić się w ręczne kodowanie binarne, użyj pól bitowych.

I pod żadnym pozorem nie poruszaj tu tematu optymalizacji. Jeszcze jest na to o trzy lata, dwa miesiące i jedenaście dni za wcześnie.

5
Gry / Odp: Start Trek w wersji tekstowej
« dnia: Maj 30, 2013, 18:14:37 »
To też nie to, niestety.

Tamta gra raczej na pewno działała w oknie Workbench'a, dzięki czemu wyglądała dość współcześnie. Tak mi sie przynajmniej zdaje :)

6
Hmmm, nie miałem zupełnie chęci zgłębiać samego tematu TDD-owania GUI teraz, i dlatego poprosiłem o implementację. Ale ok, skoro tak, to niech będzie przykład z obszaru luźno-kompilowalnej Javy:

public interface Window<T> {
    Handle getHandle();
    String getTitle();
    Point2D<T> getTop();
    Size2D<T> getSize();

    boolean isVisible();

}

public class MyFancyWindow implements Window<Integer> {

    public MyFancyWindow(Handle handle, Poin2D<integer> top, Size2D<Integer> size, String title) {...}

    public String getTitle() {...};
    public Point2D<T> getTop() {...};
    public Size2D<T> getSize() {...};

    public boolean isVisible() {...};
}

public class MyFancyWindowTest {

    @Test
    public void shouldCreateWindow() {
        // given
        Handle handle = new Handle();
        Point2D<Integer> top = new Point2D<Integer>(10, 20);
        Size2D>Integer> size = new Size2D<Integer>(200, 300);
        String title = "my very first unit-tested window";

        // when
        MyFancyWindow window = new MyFancyWindow(handle, top, size, title);

        // then
        assertThat(window.getHandle()).isEqualTo(handle);
        assertThat(window.getTitle()).isEqualTo(title);
        assertThat(window.getTop()).isEqualTo(top);
        assertThat(window.getSize()).isEqualTo(size);
        assertThat(window.getVisible()).isFalse();
    }

    @Test
    public void shouldMoveWindow() {
        // given
        Handle handle = new Handle();
        Point2D<Integer> top = new Point2D<Integer>(10, 20);
        Size2D>Integer> size = new Size2D<Integer>(200, 300);
        MyFancyWindow window = new MyFancyWindow(handle, top, size, "my very first unit-tested window");
        Point2D<Integer> newPosition = new Point2D<Integer>(10, 20);

        // when
        window.move(newPosition);

        // then
        assertThat(window.getTop()).isEqualTo(newPosition);
        assertThat(window.getSize()).isEqualTo(size); // size doesn't change when moving (object invariant)
    }

}

I tak dalej, pamiętając oczywiście o rozdzielaniu pojęć, a więc:
- okno samo się nie renderuje, robi to renderer dostając je jako argument wywołania;
- uchwyt okna to tylko dane (tak samo, jak okno w tym przykładzie), więc odpowiedzi na pytanie "is it valid?" udziela jakieś magiczne WindowRegistry czy cokolwiek w ten deseń.

Jeśli chcieli byśmy pozwolić oknu renderować samodzielnie, to koniecznie trzeba to zrobić jako delegację wywołania do dostarczonego z zewnątrz jako zależność klasy renderera. Wówczas można tegoż renderera sobie zamokować i upewnić się, że wywołanie renderujące okno wymusza rendering na rendererze. Renderer, rzecz jasna testujemy całkiem osobno.

Podobnych przykładów można by tu namnożyć, większość będzie zależna od sposobu, w jaki projektujemy GUI. Niezależne są tylko pojęcia leżące u podstaw designu.

7
Może być interfejsu. Ale testuje się nie interfejsy, a implementacje i o to mi dokładnie chodziło. Przykład testu dla konkretnej implementacji. Żeby nie było pustosłowia.

Wiem, wiem... Będziecie się tu teraz dupereli czepiać, żeby tylko pokazać, że unit testy są zUEm, bo w "gejmdewie się ich nie używa", "bo to za dużo zachodu", "a czasami się po prostu nie da", i w ogóle to wszystko do bani jest :)

8
Gry / Odp: Start Trek w wersji tekstowej
« dnia: Maj 30, 2013, 13:37:13 »
Dzięki za linki, ale żaden z podanych nie pasuje mi do wspomnień.
Przeszukałem tez tą bazę gierek Amigowych. Nie ma tam. Ale baza sama w sobie zacna :)

9
Zapodaj kod kontrolki, dam Ci do niej testy.

10
Gry / Start Trek w wersji tekstowej
« dnia: Maj 29, 2013, 17:44:19 »
Hello,

Kiedyś, dawno temu, wyszła na Amigę taka fajna gierka shareware, które mogła być klonem Star Fleeta, jak podejrzewam. W SF nie miałem okazji pograć, ale w tamtą i owszem i bardzo miło ją wspominam.
Rozgrywka toczyła się w oknie, nie pamiętam nawet czy fullscreen był dostępny. Możliwe nawet, że gra obsługiwała kilka okien systemowych na raz. Całe sterowanie, rzecz jasna, zrealizowane było w trybie tekstowym. Była sobie taka mała konsolka, z poziomu której można było zrobić wszystko :)
Nie muszę dodawać, że gra była masakrycznie grywalna.

Pamięta ktoś tytuł może? Albo linka jakiegoś? :)

11
Cytuj
Jak nie namieszać a zrobić to mądrze ?
Oddziel renderer GUI od logiki GUI.
Logika powinna zajmować się wszystkimi obliczeniami i przygotowaniem kontrolek do wyświetlenia. Renderer ma tylko wyświetlać przygotowane dane. Nie ma prawa modyfikować stanu przygotowanego przez klasy logiki.

Na styku tych dwóch światów masz tzw. "szew" (ang. "seam"). Możesz odciąć jeden od drugiego i przetestować renderer, każąc mu narysować w zadanym viewporcie to, co dostarczyłeś mu do testu jako "fake'owy" stan GUI. Z drugiej strony możesz przetestować sama logikę, każąc jej wyliczyć wszystko do osiągnięcia odpowiedniego stanu zdatnego do wrzucenia na wejście renderera, a następnie ten stan zweryfikować.

Trochę to wszystko nadmiarowe, ale z drugiej strony...
Teraz nie ma mowy o pomyłce. Do każdego typu kontrolki możesz napisać sobie testy jednostkowe. Piszesz test raz, a kiedy założenia testu są ujęte poprawnie, implementacja logiki nie ma innego wyjścia, jak tylko sprawić, by test był "zielony". Zielone testy opisują Ci wszystkie wymagania logiki GUI i wszelkiej maści utilsów, jakie tylko będą potrzebne. Żadne wymaganie się nie prześlizgnie, a jeśli któreś z nich oddziałuje na inne, od razu zobaczysz, że coś jest nie halo. Któreś testy zechcą się wyłożyć.

Unikaj stanu statycznego. Bardzo niewygodnie się takie coś testuje.

Mając świadomość, jakie to wszystko sprytne, postanawiasz pójść o krok dalej. Co by się stało, gdyby najpierw napisać test, a później dopiero implementację, która go zazieleni? W ten sposób otrzymasz implementację, która nie robi nic ponad to, co niezbędne.
Pisząc taki trzeci czy czwarty cykl z rzędu zaczynasz zakochiwać się w TDD...

Wszystkiego dobrego na nowej drodze życia! :)

12
Ja bym radził pisać jednak ładny kod, jeśli chce się mieć z niego tę wymarzoną grę ;)

13
Projektowanie kodu / Odp: Obsługa zachowania encji
« dnia: Październik 28, 2012, 22:48:31 »
No i widzicie, Bracia i Siostry? A jednak potrafimy się z Krzyśkiem zgodzić co do designu ;)

14
Projektowanie kodu / Odp: Obsługa zachowania encji
« dnia: Październik 28, 2012, 17:55:15 »
Nie boję się if-ów ani switch-y, o ile:
- są one częścią algorytmu wyliczającego jakąś wartość i unikanie ich tam prowadziłoby po prostu do zagmatwanego kodu albo wprowadzałoby dodatkowy narzut;
- są częścią logiki wybierający docelową implementację do wykonania.
Z drugim przypadkiem mamy do czynienia tutaj, kiedy rozważamy użycie jakichś strategii czy też callbacków podpinanych dynamicznie pod sloty w obiektach. Tutaj jednak należy zachować ostrożność. Jeśli desing wymaga, alby do tego samego typu podpinać więcej niż jeden typ callbacka, na przykład jeden odpowiedzialny za zarządzanie zasobami encji, drugi za jej poruszanie, a trzeci za odpowiedź w walce, to warto umieścić ich konfigurację (inicjalizację) w jednym miejscu. O tym właśnie pisałem wcześniej.
Zamiast robić w kilku miejscach switch do podpinania każdego z nich, jadący po typie encji, lepiej zrobić fabrykę encji, która będzie umiała skonfigurować obiekt za jednym zamachem. Wiadomo - jeśli zajdzie konieczność zmiany callbacka w locie, to inna kwestia. Wtedy logika warunkowa będzie potrzebna do jego wyboru. Ale w większości przypadków wystarczy zapewne pojedyncza fabryka z jednym switchem. Występowanie więcej niż jednego switcha z tym samym enumem w kodzie to już jest sygnał, że coś przekombinowaliśmy. Utrzymanie takiego kodu jest przecież trudniejsze.

Nie mam też nic przeciwko samym callbackom. Przecież napisałem poprzednio, że wystarczy, jeśli będą one implementować jakiś interfejs. Poszczególne typy callbacków będą implementować inne interfejsy, rzecz jasna, zależnie od potrzeb (patrz: SDK Androida).

15
Projektowanie kodu / Odp: Obsługa zachowania encji
« dnia: Październik 25, 2012, 01:19:32 »
Już teraz planujesz zrobić przynajmniej dwie metody operujące na tej encji. Idąc za radą Krzyśka upaprasz się na dzień dobry dwoma switchami, z których każdy będzie musiał mieć obsługę wszystkich typów. Każda nowa funkcja wymusi nowego switcha. Kiedy dodasz nowy typ encji, będziesz musiał obsłużyć go we wszystkich funkcjach. Kod zaczyna śmierdzieć. Jeśli termin "zapach kodu" nic Ci jeszcze teraz nie mówi, warto o tym pogooglać.

Rozwiązanie pierwsze jest najgorszym z możliwych. Nie bez powodu wymyślono przecież polimorfizm.

Rozwiązanie czwarte próbuje naśladować polimorfizm, ale wymaga dużo więcej pracy.

Jeśli chcesz podmieniać zachowanie w locie, rozwiązanie drugie może w tym pomóc. Zastosuj wzorzec Strategy albo coś koło tego, niech to zachowanie wie wszystko o encji i tylko wykonuje na jej danych swoją specyficzną logikę. Encja jest tutaj tylko suchym zestawem danych, niczym więcej.

Poszczególne zachowania nie muszą po sobie koniecznie dziedziczyć. Jeśli nie będzie konkretnych przesłanek do dziedziczenia głębokiego, struktura tych klas powinna być całkiem płaska: jeden interfejs (klasa abstrakcyjna) i dużo klas konkretnych implementujących zachowania. Rendering można pewnie załatwić prościej, jedną funkcją dla wszystkich typów, jeśli dane będą odpowiednio przygotowane.

To najczystsze z możliwych rozwiązań. W żadnym innym, a już na pewno nie w zaifowanym-spaghetti-enumie nie dostaniesz takiej czytelności przy żądanej elastyczności.

Strony: [1] 2 3 4 5 ... 37