SDL2 i Qt

tarpauwatratar 2016-08-20 22:34:28 UTC #1

Niestety, ale przerwę od SPOJa muszę sobie zrobić o wiele wcześniej, niż pierwotnie planowałem. Co za dużo algorytmów to niezdrowo

Aby jednak mi się nie nudziło postanowiłem coś sensownego zakodować. Sensownego, to znaczy nie arcydzieło na użytek Bitogrodu tylko faktycznie coś sensownego. Przy okazji chętnie poznam lepiej świat obiektówki i (bardziej) zaawansowanego C oraz C++.

Pomysły mam dwa:
1. https://www.youtube.com/watch?v=I4oV-_xibro&list=PL1XeWujwlZtnbRRcrIxrDkp6JiIhsc5Tm Niestety, ale znalezienie tej gry oraz jej uruchomienie to mały koszmar. Za desperackie próby jej zdobycia połączone z zapomnieniem, że brat ma Windowsa a nie Linuxa, zapłaciłem jakimś Hijack.AutoConfigURL.PrxySvrRST, który działa jak nazwa sugeruje i od ponad tygodnia nie umiem doprowadzić komputera do pełnej używalności Jak więc widać motywację mam sporą i jestem w stanie poświęcić sporo dla zdobycia tej gry. Mogę ją nawet stworzyć od podstaw. Wydaje mi się prosta; niemalże modyfikacja Sokobana, którego napisałem kiedyś dla wprawy na konsolę.
2. http://pytaczmaster.pl/ Zawsze ceniłem sobie programy tego rodzaju, choć nigdy nie używałem ich zgodnie z przeznaczeniem. Nigdy jednak nie znalazłem czegoś, co faktycznie spełniłoby moje oczekiwania. Potrzebuję czegoś, co będzie działało jak quiz przeznaczony do utrwalania jakiegoś materiału. Program wyświetli tekst / grafikę (odpowiednio sformatowane) a po wczytaniu z klawiatury wejścia (na przykład odpowiedzi na wyświetlone pytanie) sprawdzi, czy jest ono zgodne z zapisanym w odpowiedziach. Wydaje mi się, że jest to dużo trudniejsze niż gra i temu to byłby projekt numer dwa.

Uważam, że do 1. najlepiej ogarnąć SDLa. Projekt 2. raczej nadaje się na Qt - to ma być proste, małe okienko.

Mam trzy pytania. Czy mój zamysł jest wykonalny, czy też nieświadomie chcę porwać się z motyką na Słońce? Czy w miarę dobrze wydaje mi się to co napisałem, a zwłaszcza przypuszczenie, że gra jest łatwiejsza? W szczególności, czy SDL jest łatwiejszy od Qt? Sądzę, że byłbym bardzo zdemotywowany, gdybym poległ używając SDL i na pewno nie zabrałbym się za projekt w mym mniemaniu bardziej skomplikowany. Co prawda, znalazłem sporo tutoriali i projektów stworzonych przez innych, ale moje doświadczenie programistyczne jest żenująco niskie, zaś kontaktu z informatyką i informatykami (z pominięciem SPOJa) nie mam prawie wcale więc nie wiem, czy implikacja sporo tutoriali i projektów => proste jest słuszna.

Podobno nie warto zbyt szybko zaczynać od grafiki i stąd moje ostatnie, trzecie pytanie. Czy powinienem zacząć od zrobienia porządnej, obiektowo orientowanej wersji konsolowej każdego z tych projektów a dopiero potem próbować dołożyć grafikę? Gra mogłaby polegać na poruszaniu się znakiem X po planszy i zbieraniu diamentów oznaczonych O. W przypadku quizu obsłużyłbym jedynie tekst a nie obrazy.

mariusz193 2016-08-21 07:47:03 UTC #2

Ja nie używam ani SDL, ani Qt - piszę w VisualStudio Microsoftu

1) Grałem w to kiedyś, w jakiej prehistorii, pewnie większość obecnie tu piszących była w fazie co najwyżej projektu

Statyczna wersja gry (czyli bez animacji) ale jako graficzna aplikacja Windows nie jest szczególnie trudna - trochę łatwiej było by ją napisać w VisualBasic lub C# niż w C++

Ale może lepiej było by to napisać na Androida - tam łatwiej włączyć animację

2) To prosty program - logika oczywista - jedyny problem to rozłożenie kontrolek i podpięcie jakiejś bazy danych.

To, że te programy nie są zbyt skomplikowane, to nie znaczy, że nie będą czasochłonne, na pewno oba nadają się jako projekty do nauczenia się czegoś.

A Sokobana tez pisałem własnego, poziomy skopiowałem z oryginalnego kodu, gra była w oknie windowsowym, oczywiście bez animacji, ale ze statystyką liczby kroków i przesunięć oraz możliwością cofania o dowolną liczbę kroków, zapisem najlepszych wyników oraz zapisem i odczytem stanu gry. Tyle, że jak już przeszedłem wszystkie poziomy to przestało to mnie bawić

krystian01 2016-08-21 09:03:58 UTC #3

Oczywiście, że jest wykonalny.

Czy ja wiem ... Uważam, że stworzenie gry jest raczej o wiele trudniejsze. Musisz zaprojektować, różne skrypty, ustawić odpowiednie miejsca, w których skrypt ten jest uruchamiany. Musisz także zaprojektować AI(Artifical Intelligence), kolizje wszystkich postaci i reagowanie na te kolizje ... Mógłbym się tu jeszcze długo rozpisywać, ale napisałem Ci taką listę, po to, by uświadomić Ci, że jednak stworzenie gry jest trudnym zadaniem.

Qt jest zaprojektowany w całości obiektowo, natomiast biblioteka SDL powstała pod C i oczywiście można jej używać także w C++. Obie biblioteki są przeznaczone do innych rozwiązań. Jeżeli chcesz napisać program wspomniany w punkcie 2), to uważam, że lepiej zrobić go w Qt, bo biblioteka ta jest właśnie przeznaczona do takich zastosowań. Natomiast do projektu w punkcie 1) polecam właśnie SDL2 lub OpenGL.

Ale skąd takie przypuszczenia?

Tworzenie w konsoli jest nieco problematyczne i wiem to ze swojego doświadczenia. Niby możesz użyć: system("cls"); Do imitacji czyszczenia mapy, a do renderowania: cout << ...;
ale nie jest to najlepsze rozwiązanie. Jeżeli umiesz choć trochę programowac obiektowo, wiesz co to dziedziczenie i polimorfizm, spokojnie możesz wziąć się za grafikę. Najważniejsze jest stworzenie takiej struktury projektowej, by mogła być ona rozszerzalna w przyszłości.

Co do SDL polecam ten tutorial:
http://lazyfoo.net/tutorials/SDL/

To możesz jak najbardziej zrobić w konsoli, ale wyswietlanie tekstu jako grafiki nie jest wcale trudne.

Pozdrawiam. Jakbyś miał więcej pytań to pisz

tarpauwatratar 2016-08-21 11:27:48 UTC #4

Dziękuję za odpowiedzi! Wszystkie bardzo mi pomogły.

Skoro moje pomysły da się zrealizować samodzielnie to nie pozostaje mi nic innego, jak wkrótce zabrać się do pracy.

W razie problemów będę pisał w tym temacie bądź na PW

narbej 2016-08-21 19:25:27 UTC #5

Czy to nie za kiepska okazja? Jeżeli chcesz lepiej poznać świat obiektówki, to najlepszą nawet nie okazją a drogą jest codzienne jej stosowania na zmianę z dokształcaniem, czytaniem, pytaniem się. Nawet tu na spoju, najprostsze zadania można rozwiązywać w dowolny sposób, i nie trzeba stosować ani OOP ani zaawansowanego C/C++, aby dostać AC. Ale czy nie jest to wyśmienita okazja do nauki i poznawania, robiąc każde, nawet najprostsze zadanie obiektowo?

Pisanie programów, to teraz już praca zespołowa. Nie znaczy, że nie możesz samodzielnie.

Moim zdaniem większość gier nie ma sensu, nie są edukacyjne [chyba, że dla piszącego grę], a dodatkowo mogą powodować uzaleźnienia jak wszelkie inne używki. [poczytaj "komputerowy ćpun"].

Programów do nauki za pomocą quizu jest całe multum ale ich użyteczność do nauki jest średnia - zależy od motywacji uczącego, systematyczności i od sensownej [i dużej] bazy pytań i odpowiedzi.

==========
Był też Bouder Dash (np C64 ) <-- https://www.youtube.com/watch?v=FiEVfa1OK_o
Kiedyś używałem SuperMemo - programu typu Pytacz Master - i pierwsze wersje działały w trybie konsoli - pod dosem.
==========
Czyszczenie i używanie konsoli to nie tylko sys("clear"), cin, cout, ale przede wszystkim pisanie w dowolnym punkcie ekranu, w dowolnym kolorze, w dowolnym okienku tekstowym, ramki, menu itd, i aby to ułatwić powstały biblioteki np ncurses.
==========
Do pisania gier można użyć też jednego z dostępnych silników gier, ale tu chyba bardziej liczy się dobry pomysł, a dopiero potem można ubrać go na początku w skromne szatki konsoli a dopiero potem w grafikę np 3D.
===========
Jeżeli gra z grafiką, to w zespole powinien "znaleźć się" dobry grafik. [lub samodzielna nauka programów typu gimp, blender itd]
===========
Efekty [efektywne] dźwiękowe - muzyk [lub samodzielna nauka podstaw muzyki i programów do tworzenia i przetważania hałasu ]
==========

Hm
Na razie tyle, aby Cię zbytnio nie zniechęcać.
============
I jeszcze jedno, twoje pomysły to raczej programy dłuższe od typowych,najłatwiejszych kodów wysyłanych na SPOja, więc czytelne pisanie i sensowne komentowanie będzie w twoich kodach dużo bardziej ważne.
Jeżeli twój guru [to odnośnie rozmowy na pw] mówi Ci, że piszesz trudno czytelny kod, powinieneś natychmiast spytać go, dlaczego tak uważa. Czy się zastosujesz do jego uwag, to już inna sprawa. Estetyka kodu, to indywidualna sprawa, i każdy ma swój styl, ale powinnien on być w granicach rozsądku i pewnych standartów - tu znowu kłaniają się książki, i czytanie kodów mistrzów. Jeżeli nie, to będzi Ci dużo trudniej uzyskać pomoc od innego kodera, który będzie musiał się przegryźć przez zawiłości twojego kodu.

tarpauwatratar 2016-08-21 20:38:21 UTC #6

SPOJ to świetna okazja do opanowania podstaw obiektówki, ale stosowanie ambitnych obiektowo orientowanych rozwiązań na SPOJu to przerost formy nad treścią. Klasy i struktury - ok. Chociażby moja nie tak dawna klasa BigInt. Ale to w gruncie rzeczy wszystko. Nota bene zrobienie klasy BigInt to i tak za dużo jak na SPOJa bo nigdzie nie jest to tak na prawdę potrzebne - jedno zadanie to raczej nie więcej niż jedna operacja na BigInt. Na przykład porównując BigInty najlepiej wczytać dwa stringi a nie pisać całą klasę z wyrafinowanymi metodami. Dopiero pisząc coś praktycznego algorytmy odchodzą na dalszy plan (można używać gotowych rozwiązań w możliwych do pobrania bibliotekach) a zaczyna się liczyć porządne klepanie kodu dobrej jakości. Czyli między innymi obiektówka.

O "komputerowym ćpunie" nie słyszałem, choć o uzależnieniu od komputera jak najbardziej. Szczęśliwie będę w to grał tyle ile grałem w Sokobana - kilka minut by upewnić się, że działa. Nie jestem aż tak ambitny by opracowywać złożone poziomy. Poza tym rzadko gram na komputerze bo mi się to znudziło. Chcę po prostu nauczyć się pisać aplikacje o złożoności prostej, starej gry komputerowej i opanować lepiej tak zwaną sztukę kodzenia. Więc w moim przypadku gra na szczęście jest sensowna

Bouder Dash to chyba nawet coś bliższego temu, co najprawdopodobniej uzyskam. Nie znałem tej gry tak swoją drogą.

Pomysł na grę jest jak na mnie bardzo dobry bo jest ona prosta a przy tym nie jest trywialna (na przykład ucieczka z labiryntu byłaby zbyt prosta). W grafikę 3D nie wnikam bo i niewiele o niej wiem. Obiły mi się o uszy pojedyncze słowa i tyle. Jakość grafiki oraz muzyki są dla mnie nieistotne. Muzykę mogę pobrać albo o zgrozo zaśpiewać do mikrofonu. Grafika będzie równie ambitna. Potrzebuję by to działało, a nie olśniewało (to jeszcze bardziej zmniejsza i tak minimalną szansę, że z twórcy stanę się "komputerowym ćpunem" )

Nie zniechęcają mnie uwagi, także krytyczne. Zwrócenie uwagi na C# albo problemy z wykrywaniem kolizji i animacjami to przykładowe trzy rzeczy o których na tą chwilę za bardzo nie myślałem. A jednak są istotne.

Co do PW - oczywiście spytałem. Poza tym uwagi Twoje i wielu innych lepszych ode mnie SPOJowiczów uwzględniam / staram się uwzględniać na bieżąco w każdym następnym programie.

narbej 2016-08-22 20:03:26 UTC #7

http://ksiegarnia.pwn.pl/Komputerowy-cpun,142344390,p.html

Sam twój pomysł nie jest zły, natomiast to że trochę go krytykuję, nie wynika z miłości do SPOJ'a. Może czepiam się słówek, ale wydaje mi się, że masz [jak wielu innych] złe podejście. Jeżeli chcesz "poznać lepiej świat obiektówki" to nie rób tego przy jakiejś okazji. To samo dotyczy zaawansowanego c/c++. Jeżeli tego chcesz, to rób to w każdym momencie i w każdej sytuacji, programując namet mikro mikroprogramiki - rozwiązania zadań na SPOJu - przy okazji poznając algorytmy

krystian01 2016-08-22 20:21:02 UTC #8

Tak wiem, że to nie tylko system("clear"), cin, cout. Zamiast używać system("clear"); można używać uchwytu konsoli HANDLE, a później ustalić pozycję kursora:

SetConsoleCursorPosition(hCon, coord);

Ale nie zmienia to faktu, że pisanie programu konsolowego jest ograniczaniem się. Wiem to ze swojego doświadczenia. Ponad rok temu napisałem Snake'a konsolowego bez użycia bibliotek do konsoli(ncurses itp.) i uważam teraz, że było to tylko stratą czasu(nie sam pomysł zrobienia gry, ale pomysł zrobienia go w konsoli)

Jeżeli znajduje się odpowiedni kurs co do grafiki, to według mnie lepiej nie zawracać sobie głowy konsolą tylko od razu wziąć się za jakąś bibliotekę graficzną. W przyszłości może się to przydać, bo większość bibliotek graficznych posiada podobną budowę(np. SDL2 i OpenGL). Dodam także, że niektóre biblioteki mają wsparcie innych. Np. SDL2 ma częściowe wsparcie OpenGL(urposzczony model projektowy), a Qt posiada wsparcie dla OpenGL. Taka jest moja opinia Pozdrawiam.

narbej 2016-09-04 18:30:01 UTC #9

Pisanie programów to jedyny sposób i jedyna metoda nauki i doskonalenia umiejętności programowania [kodowania]. Pisać można po to aby np rozwiązywać kolejne zadania na spoju [czy innym konteście], ale można też dla kogoś lub dla siebie. Gdy piszemy dla kogoś [znajomego] lub dla siebie, to najlepiej by było, aby programy były użyteczne i używane i żyły dalszym własnym życiem.

Jeżeli nie masz pomysłu, na program, rozwiązujący jakiś problem, którego jeszcze nie ma, to realizuj w ostateczności twoje pomysły. Ale jeszcze raz. Czy program typu quizu nie jest za mało ambitny? Programów takiego typu jest całe multum, a problemem są bazy, a nie program. Poczytaj: https://pl.wikipedia.org/wiki/SuperMemo
Są też dostępne otwarto źródłowe programy tego typu, np anki - gdzie można podpatrzeć jak robią to inni.

W twoim wypadku i na twoim miejscu, pomyślałbym o napisaniu jakiejś aplikacji, lub komputerowej graficznej vizualizacji procesów chemicznych. Porozmawiałbym [dowiedział się] czy istnieje możliwość napisania jakiegoś użytecznego i potrzebnego programu [aplikacji] tego typu z prowadzącymi, a jeszcze lepiej, czy istnieje możliwość napisania pracy końcowej, której podstawą lub elementem byłaby takiego typu aplikacja. Byłoby to połączenie twojej przyszłej profesji z zainteresowaniami i jeżeli by się to udało, sądzę, że dużo lepiej wyglądałoby w twoim przyszłym portfolio niż to że napisałeś samodzielnie renimiscencję starej gry komputerowej czy program typu quiz z GUI - oczywiście pod warunkiem, że nie zamierzasz związać swojej przyszłej kariery z branżą gier komputerowych lecz myślisz o procesach chemicznych np zamieniających wodę [z dodatkami] w wino.

PS
Pisać [kodować] można też za pieniądze i dla pieniędzy