26.02.2010 08:00
[#1]
Problem z SDL_SetCursor
Czy ktoś zetknął się z programem pod MorphOS, który używa funkcji SDL_SetCursor, zmienia wygląd wskaźnika myszy na własny (zdefiniowany)? Ta funkcja działa w PowerSDL? Ja zaliczam zwis aplikacji przy próbie użycia tej funkcji. Dodam, że aplikacja skompilowana pod Windows działa z tą funkcją bez problemu i wskaźnik myszy jest zmieniany.
Może ktoś portował jakąś SDLową aplikację, która w ten sposób zmieniała wskaźnik myszy i ma jej źródła. Chętnie bym zobaczył jak są przygotowane dane (grafika) dla takiego wskaźnika myszy jeżeli to działa pod MorphOS poprawnie.
Ostatnia modyfikacja: 26.02.2010 08:13:13
Może ktoś portował jakąś SDLową aplikację, która w ten sposób zmieniała wskaźnik myszy i ma jej źródła. Chętnie bym zobaczył jak są przygotowane dane (grafika) dla takiego wskaźnika myszy jeżeli to działa pod MorphOS poprawnie.
Ostatnia modyfikacja: 26.02.2010 08:13:13
26.02.2010 10:11
[#2]
Re: Problem z SDL_SetCursor
@MDW, post #1
Nie wiem na ile będzie to pomocne bo nie testowałem, a tym bardziej na Morphos (mini zakupiony własnie do mnie jedzie wiec MOS tuż, tuż:) ) ale w tym przykładzie dane wchodzą jak pixmapa wiec nie ma szaleństwa :)
MDW błagam SDL to zuo jak możesz :]
Pozdrawiam,
RadziN
MDW błagam SDL to zuo jak możesz :]
Pozdrawiam,
RadziN
26.02.2010 10:35
[#3]
Re: Problem z SDL_SetCursor
@RadziN, post #2
No szaleństwa nie ma ale nie działa. :)
Dlaczego SDL to zło? Ja swoje mini-aplikacyjki jestem zmuszony przenosić między trzema systemami, kompilować je i używać na każdym z nich. W dodatku zarówno na PowerPC jak i Intelu. SDL się świetnie sprawdza. Poza tym ile ja go tam używam... Raptem do otwierania okna/ekranu, obsługi dźwięku, klawiatury, myszy i obsługi endianów (chociaż to zrobiłem też już swoje, bo musiałem pod iPhone/iPod). To wszystko. Cała reszta jest już nie-SDL-owa (C++, Objective-C, OpenGL, w pewnych przypadkach OpenAL).
Zauważ, że kiedyś do aplikacji przenośnych, które renderowały grafikę użyciem OpenGL używało się biblioteki GLUT. Jednak to było dopiero zło, bo przez swoją multiplatformowość miało się bardzo małą kontrolę nad wszystkim. Poza tym GLUT od wielu lat nie jest rozwijany. No i dzisiaj do tego typu zastosowań bardzo często używa się właśnie SDL. Duet OpenGL+SDL jest bardzo często spotykany. I SDL wcale nie służy do renderowania grafiki nawet jeżeli aplikacja jest 2D. Znacznie lepiej i wydajniej zrobić to w OpenGL i tak się zwykle robi.
Tak więc SDL moim zdaniem ok jeżeli to ma sensowne uzasadnienie. Gdyby Pixel nie był pod SDL to pewnie byłby na jeden system. Tak samo z moimi śmieciami. Dzięki temu, że używam multiplatformowych standardów, mogę jakieś 10 razy szybciej pisać, bo mogę to robić na każdej maszynie. A tak mógłbym tylko w domu gdzie niestety ostatnio nie mam za dużo czasu. :(
No i nie należy kojarzyć SDL z tym co było na Classicu. Akurat PowerSDL jest naprawdę sensowną wersją SDL (jak na warunki amigowe) i życzyłbym sobie w każdej dziedzinie mieć tej klasy odpowiednik. :)
Ostatnia modyfikacja: 26.02.2010 10:36:36
Dlaczego SDL to zło? Ja swoje mini-aplikacyjki jestem zmuszony przenosić między trzema systemami, kompilować je i używać na każdym z nich. W dodatku zarówno na PowerPC jak i Intelu. SDL się świetnie sprawdza. Poza tym ile ja go tam używam... Raptem do otwierania okna/ekranu, obsługi dźwięku, klawiatury, myszy i obsługi endianów (chociaż to zrobiłem też już swoje, bo musiałem pod iPhone/iPod). To wszystko. Cała reszta jest już nie-SDL-owa (C++, Objective-C, OpenGL, w pewnych przypadkach OpenAL).
Zauważ, że kiedyś do aplikacji przenośnych, które renderowały grafikę użyciem OpenGL używało się biblioteki GLUT. Jednak to było dopiero zło, bo przez swoją multiplatformowość miało się bardzo małą kontrolę nad wszystkim. Poza tym GLUT od wielu lat nie jest rozwijany. No i dzisiaj do tego typu zastosowań bardzo często używa się właśnie SDL. Duet OpenGL+SDL jest bardzo często spotykany. I SDL wcale nie służy do renderowania grafiki nawet jeżeli aplikacja jest 2D. Znacznie lepiej i wydajniej zrobić to w OpenGL i tak się zwykle robi.
Tak więc SDL moim zdaniem ok jeżeli to ma sensowne uzasadnienie. Gdyby Pixel nie był pod SDL to pewnie byłby na jeden system. Tak samo z moimi śmieciami. Dzięki temu, że używam multiplatformowych standardów, mogę jakieś 10 razy szybciej pisać, bo mogę to robić na każdej maszynie. A tak mógłbym tylko w domu gdzie niestety ostatnio nie mam za dużo czasu. :(
No i nie należy kojarzyć SDL z tym co było na Classicu. Akurat PowerSDL jest naprawdę sensowną wersją SDL (jak na warunki amigowe) i życzyłbym sobie w każdej dziedzinie mieć tej klasy odpowiednik. :)
Ostatnia modyfikacja: 26.02.2010 10:36:36
26.02.2010 11:48
[#5]
Re: Problem z SDL_SetCursor
@Grzegorz Kraszewski, post #4
Każda gra tak ma. Wyciska ile się tylko da klatek na sekundę. Niezależnie od tego jak jest pisana gra (SDL czy nie) to gdzieś tam ma pętlę w której maksymalnie wszystko zaiwania (update wszystkiego, liczenie, rysowanie). Oczywiście jeżeli to jest gra dynamiczna, gdzie wszystko się cały czas zmienia. No bo jeżeli to są jakieś szachy czy Saper i nic się tam nie animuje to oczywiście można to zrobić bardziej "eventowo" i zmieniać zawartość ekranu tylko wtedy gdy trzeba. SDL nie wymusza takiego pisania. Przeciwnie - ma nawet system eventów. To tylko uroki dynamicznych gier gdzie wszystko musi być cały czas aktualizowane. Jak się ma dynamiczną grę to raczej gracz chce żeby wykorzystała max możliwości maszyny. Tym bardziej na ami-maszynach w których nadmiaru prędkości nie ma.
Czasem ogranicza się ilość klatek na sekundę gry do jakiejś wartości (np. 60 fps). No i wtedy jak jeden przebieg pętli (update, rysowanie) zostanie zrobiony w mniej niż 1/60 sekundy to potem programik może sobie poczekać zostawiając czas procesorowi. No ale pokażcie mi dynamiczną grę (zwłaszcza 3D) która ma za dużo prędkości na ami-maszynach. :)
Nie pamiętam na pewno ale zdaje się, że Pixel nie zjada procesora na maxa. No ale tam gość mógł sobie na to pozwolić, bo nic się cały czas nie animuje, ekran jest odrysowywany tylko gdy coś się na nim zmienia.
Tak więc to nie cecha SDL tylko uroki gamedev. :)
Ostatnia modyfikacja: 26.02.2010 11:48:34
Czasem ogranicza się ilość klatek na sekundę gry do jakiejś wartości (np. 60 fps). No i wtedy jak jeden przebieg pętli (update, rysowanie) zostanie zrobiony w mniej niż 1/60 sekundy to potem programik może sobie poczekać zostawiając czas procesorowi. No ale pokażcie mi dynamiczną grę (zwłaszcza 3D) która ma za dużo prędkości na ami-maszynach. :)
Nie pamiętam na pewno ale zdaje się, że Pixel nie zjada procesora na maxa. No ale tam gość mógł sobie na to pozwolić, bo nic się cały czas nie animuje, ekran jest odrysowywany tylko gdy coś się na nim zmienia.
Tak więc to nie cecha SDL tylko uroki gamedev. :)
Ostatnia modyfikacja: 26.02.2010 11:48:34
26.02.2010 12:09
[#7]
Re: Problem z SDL_SetCursor
@MDW, post #5
Weźmy taką grę jak PushOver na przykład. Jest to gra, w której się niewiele dzieje w sensie animacji. Mimo to, nawet jeżeli myślę nad rozwiązaniem i nie przesuwam bohatera (wtedy na ekranie się w ogóle nic nie dzieje), to gra wchłania 100% mocy procesora. Lamerstwo programisty, bug w PowerSDL czy może błąd koncepcyjny w SDL jako takiej?
26.02.2010 12:39
[#9]
Re: Problem z SDL_SetCursor
@Grzegorz Kraszewski, post #7
Na pewno nie błąd PowerSDL. Ja bym to podciągnął pod błąd koncepcyjny. Chociaż właściwie wszystkie gry tak mają (nie licząc układanek czy biurowych pasjansów). :) Jeżeli jednak coś się tam animuje to program nie może czekać na akcję ze strony użytkownika. Musi coś aktualizować, animować, odrysowywać. Chociaż faktycznie może to zrobić oszczędnie jeżeli to gra 2D i rzeczywiście niewiele się dzieje na ekranie (wszystko zdąży się zrobić w mniej niż 1 ramka). Na przykład dema też napierniczają ile wlezie, a i tak ciągle im mało. :D
Dobrą praktyką byłoby przejście w jakiś stan oczekiwania gdy jest włączona pauza i okno/ekran są nieaktywne.
Ostatnia modyfikacja: 26.02.2010 12:41:39
Dobrą praktyką byłoby przejście w jakiś stan oczekiwania gdy jest włączona pauza i okno/ekran są nieaktywne.
Ostatnia modyfikacja: 26.02.2010 12:41:39
26.02.2010 12:42
[#10]
Re: Problem z SDL_SetCursor
@MDW, post #3
Nie chce tu się wdawać w zbędną polemikę, sadze że po części masz rację ja za bardzo się jeszcze oglądam na czysto sentymentalny poziom amigowania dlatego mam trochę inny układ odniesienia, no ale mnie mam ze jako nowy user Morphosa zmienię zapatrywania. No mocy CPU będę miał pod dostatkiem więc i możliwości więcej :)
Sorry za OT.
Pozdrawiam,
RadziN
Sorry za OT.
Pozdrawiam,
RadziN
26.02.2010 13:10
[#11]
Re: Problem z SDL_SetCursor
@RadziN, post #10
Rozumiem doskonale. :) Tylko ja mam wybór - albo tak będę robił albo wcale. Biorąc na logikę to powinienem zupełnie nie brać pod uwagę takich platform jak AmigaOS czy MorphOS. No bo niby po co przy takiej ilości potencjalnych graczy/użytkowników. Jednak właściwie głównie ta wersja sprawia mi prawdziwą radochę. :) Pozostałe to tylko sposób na sfinansowanie projektu (chociaż ostatnio to nawet na to już nie liczę). Mój ból polega na tym, że lubię robić gry (od zawsze tego chciałem), a amigowe systemy dawno zostały opuszczone przez graczy. Ale co mi tam, przecież to hobby więc mogę sobie grzebać...
Poza tym nie chciałbym żeby mnie źle ktoś zrozumiał. To nie jest tak, że ja klepię pod Windows czy MacOSX, a potem tylko raz na kilka tygodni przenoszę pod MorphOS żeby skompilować, zobaczyć czy wszystko jest ok i wprowadzić ewentualne zmiany specyficzne dla tej platformy. Co więcej - pierwsza połowa (albo nawet więcej) silniczka powstała tylko na MOSa i była pisana tylko na MOSie. Dopiero potem wpadłem na pomysł, że mogę wykorzystać czas gdy muszę używać innego systemu i tak dostosować projekt żeby było możliwe grzebanie w tym także pod Windows. Przygotowałem sobie w pełni mobilne środowisko, które mam na pendrive i to działa. :) Jeden #define i teoretycznie projekt przenoszę (chociaż to zalezy co). Po drodze byłem zmuszony do rezygnacji z pewnych rzeczy przez MorphOSa. Na przykład byłem zmuszony z rezygnacji z OpenAL na rzecz dźwięku przez SDL-a. Niestety zachowanie OpenAL pod MorphOS było dosyć średnie (zwisy) i nie udało mi się znaleźć na to lekarstwa.
Przy drugiej grze problemu przenośności juz nie ma, bo nie będzie jej na nic poza iPhone/iPod. To jest po prostu niemożliwe, bo bez ekranu dotykowego z multitouch nie miałaby sensu. Ale trzecia gra już jak najbardziej będzie na MOSa. :) No ale na razie skupiam się na kończeniu pierwszej i dochodzeniu do połowy drugiej więc trzecia to tylko przemyślenia podczas codziennej jazdy autobusem/tramwajem MPK. :)
Ostatnia modyfikacja: 26.02.2010 13:11:54
Poza tym nie chciałbym żeby mnie źle ktoś zrozumiał. To nie jest tak, że ja klepię pod Windows czy MacOSX, a potem tylko raz na kilka tygodni przenoszę pod MorphOS żeby skompilować, zobaczyć czy wszystko jest ok i wprowadzić ewentualne zmiany specyficzne dla tej platformy. Co więcej - pierwsza połowa (albo nawet więcej) silniczka powstała tylko na MOSa i była pisana tylko na MOSie. Dopiero potem wpadłem na pomysł, że mogę wykorzystać czas gdy muszę używać innego systemu i tak dostosować projekt żeby było możliwe grzebanie w tym także pod Windows. Przygotowałem sobie w pełni mobilne środowisko, które mam na pendrive i to działa. :) Jeden #define i teoretycznie projekt przenoszę (chociaż to zalezy co). Po drodze byłem zmuszony do rezygnacji z pewnych rzeczy przez MorphOSa. Na przykład byłem zmuszony z rezygnacji z OpenAL na rzecz dźwięku przez SDL-a. Niestety zachowanie OpenAL pod MorphOS było dosyć średnie (zwisy) i nie udało mi się znaleźć na to lekarstwa.
Przy drugiej grze problemu przenośności juz nie ma, bo nie będzie jej na nic poza iPhone/iPod. To jest po prostu niemożliwe, bo bez ekranu dotykowego z multitouch nie miałaby sensu. Ale trzecia gra już jak najbardziej będzie na MOSa. :) No ale na razie skupiam się na kończeniu pierwszej i dochodzeniu do połowy drugiej więc trzecia to tylko przemyślenia podczas codziennej jazdy autobusem/tramwajem MPK. :)
Ostatnia modyfikacja: 26.02.2010 13:11:54
27.02.2010 09:11
[#12]
Re: Problem z SDL_SetCursor
@MDW, post #1
Problem się rozwiązał. Próbowałem zdefiniować mouse pointer taki jaki w przykładzie z dokumentacji, czyli 32x32 pixele. No i były zwisy przy próbie użycia czegoś takiego. Jak zdefiniowałem 16x16 pixeli to jest ok. No więc w wersji dla MorphOS wskaźniki myszy będą mniejsze. :) Nie wiem czy karta graficzna ma jakieś specjalne twory (sprajty) do wskaźnika myszy ale jeżeli tak widocznie w Radeonie 9250 nie mogą być 32x32 pixele.
28.02.2010 11:45
[#14]
Re: Problem z SDL_SetCursor
@Jacek Piszczek, post #13
Dzięki za informację. Zgodnie z poradą wysłałem pytanie do autorów morphosowego portu SDL. Chociaż i tak pewnie zostanę przy takim wskaźniku myszy na wszelki wypadek gdyby ktoś jeszcze używał np. Voodoo4.
Jest trochę przykładów w których autorzy znikają systemowy wskaźnik myszy i na jego współrzędnych rysują własny sprite. Jednak ja takiego rozwiązania nie lubię, bo to od razu czuć. Jest pewne opóźnienie przy szybkim przesuwaniu wskaźnika myszy. Nigdy nie działa on tak idealnie jak systemowy wskaźnik. No a akurat w tej mini-grze którą teraz dziubię nie ma może być mowy o takim opóźnieniu.
Jest trochę przykładów w których autorzy znikają systemowy wskaźnik myszy i na jego współrzędnych rysują własny sprite. Jednak ja takiego rozwiązania nie lubię, bo to od razu czuć. Jest pewne opóźnienie przy szybkim przesuwaniu wskaźnika myszy. Nigdy nie działa on tak idealnie jak systemowy wskaźnik. No a akurat w tej mini-grze którą teraz dziubię nie ma może być mowy o takim opóźnieniu.
22.03.2010 17:09
[#17]
Re: Problem z SDL_SetCursor
@recedent, post #16
Dzięki za podpowiedź, ale mam na myśli ukrycie wskaźnika do odwołania (jakąś kombinacja klawiszy), tak żeby pulpit nie reagowal na klikniecie prawym przyciskiem.
Ponawiam więc pytanie. Czy istnieje jakieś commodity do tego celu ? jeśli nie to jaką funkcją mógłbym to zrealizowac, z jakiej biblioteki ?
Ps Potrzebne jest mi to do w miare godnego używania E-UAE. Być może jest jakiś inny sposób na to o którym nie wiem. Jeśli nie ma, to bardzo proszę o naprowadzenie mnie za pomocą jakich funkcji mógłbym sobie zbudować taki "utilek".
Ostatnia modyfikacja: 22.03.2010 17:10:45
Ponawiam więc pytanie. Czy istnieje jakieś commodity do tego celu ? jeśli nie to jaką funkcją mógłbym to zrealizowac, z jakiej biblioteki ?
Ps Potrzebne jest mi to do w miare godnego używania E-UAE. Być może jest jakiś inny sposób na to o którym nie wiem. Jeśli nie ma, to bardzo proszę o naprowadzenie mnie za pomocą jakich funkcji mógłbym sobie zbudować taki "utilek".
Ostatnia modyfikacja: 22.03.2010 17:10:45
22.03.2010 20:06
[#19]
Re: Problem z SDL_SetCursor
@Jacek Piszczek, post #18
Teoretycznie wygodniej :) z tym, ze nie lubie wachlowac ekranami a przy duzej rozdzialce i panoramie jest wystarczajaco miejsca na pulpicie zeby zmiescic okno e-uae. Uzywam nie-SDLowego bo jest szybsze i stad problem. W SDLowym
(chyba) nie ma problemu dwóch kursorów. Najlepiej byloby gdyby e-uae obslugiwal kursor ambienta no ale taki mod jest daleko po za moim zasiegiem (albo mozna tak, tylko nie doczytalem sie nigdzie jak to zrobic w ramach ustawien e-uae lub sytemu). W kazdym razie dzieki za sugestie bo zapomnialem w ogole o wersji SDLowej co jest z reszta parodoksem tego watku :P, takze sprawdze sobie jeszcze czy ta roznica predkosci wersji SDL i nieSDL jest odczuwalna, hyy jakiej predkosci co ja tu wypisuje :) .
(chyba) nie ma problemu dwóch kursorów. Najlepiej byloby gdyby e-uae obslugiwal kursor ambienta no ale taki mod jest daleko po za moim zasiegiem (albo mozna tak, tylko nie doczytalem sie nigdzie jak to zrobic w ramach ustawien e-uae lub sytemu). W kazdym razie dzieki za sugestie bo zapomnialem w ogole o wersji SDLowej co jest z reszta parodoksem tego watku :P, takze sprawdze sobie jeszcze czy ta roznica predkosci wersji SDL i nieSDL jest odczuwalna, hyy jakiej predkosci co ja tu wypisuje :) .