Hej. Od jakiegoś czasu ogarniam sobie SDL pisząc w C, wszystko jest okej, ogarniam zdarzenia itd. ale...
Czy jeżeli będę chciał na przykład pisać grę czy coś podobnego, pisanie tego w "czystym" C, bez obiektowości jaką daje C++ będzie bezsensowne?
Z góry dzięki ;)
- Rejestracja:ponad 12 lat
- Ostatnio:prawie 8 lat
- Postów:107
C 
- Rejestracja:prawie 22 lata
- Ostatnio:około 5 godzin
- Postów:6633
0
Możesz z powodzeniem używać SDL w obiektowych aplikacjach C++. Nie ma jakiegoś twardego zakazu/blokady, sam tak robiłem.
Kiedy nie było C++, tak właśnie pisano gry i da się w ten sposób napisać grę. Aczkolwiek obiektowość to wygoda dla programisty i łatwiej pisać zwarty kod (o ile wiemy co robimy ;) ). A także składnia C++ eliminuje potrzebę używania funkcji typu malloc, free itp. Dochodzi STL, vectory itp. A to dużo ułatwia przy pisaniu gier i to jest mniej błędogenne.
edytowany 3x, ostatnio: Spine
spartanPAGE
Sam SDL(2) Jest pisany w "obiektowym" C :P
- Rejestracja:prawie 13 lat
- Ostatnio:około 10 lat
- Postów:74
0
Wiesz co, grę możesz pisać gdziekolwiek chcesz, nawet w kodzie maszynowym jak Ci tak łatwiej :D
Ale obiektowość jest niesłychanie naturalna w stosunku do tworzenia gier. W C nie zrobisz klasy "Przeciwnik" mającej pola "ilość naboi" i metody "strzelaj" i "uciekaj". Nie zrobisz klasy "Ultra Przeciwnik" dziedzicząc po Przeciwniku i dodając tylko parę ultra epickich zdolności. Mając te wszystkie odmiany przeciwników w C++ będziesz mógł się odnosić do każdego w jeden i ten sam sposób (za pomocą polimorfizmu i klasy bazowej), tzn. że tej samej funkcji nie będziesz musiał powtarzać wielokrotnie, tylko raz dla wszystkich typów przeciwników. Oprócz niesamowitych możliwości związanych właśnie z polimorfizem, dziedziczeniem, szablonami, itd. najważniejsze jest chyba sama struktura takiego projektu. Gdzie wszelkie elementy, postacie możesz pakować do osobnych klas i nie musisz przetrząsać całego kodu w poszukiwaniu tego dotyczącego danego elementu, ale znajdujesz sobie po prostu klasę "Bohater" albo "Domek" i w obrębie niej masz tylko to co dotyczy tego elementu. A w C możesz zrobić tylko udawać coś takiego, nigdy nie będziesz miał tak łatwego rozgraniczenia, w szczególności jak gra się rozrośnie.
SDLa nie znam, ale osobiście bardzo polecam SFML. Wiadomo, że najłatwiej jest w Unity (teraz można juz robić gry 2D w normalny sposób). Ale ja się dużo nauczyłem w SFMLu, głównie jeśli chodzi o organizację kodu i wymyślanie samemu prawie od zera jak dany efekt uzyskać.
- Rejestracja:prawie 22 lata
- Ostatnio:około 5 godzin
- Postów:6633
0
Mossar napisał(a):
SDLa nie znam, ale osobiście bardzo polecam SFML. Wiadomo, że najłatwiej jest w Unity (teraz można juz robić gry 2D w normalny sposób). Ale ja się dużo nauczyłem w SFMLu, głównie jeśli chodzi o organizację kodu i wymyślanie samemu prawie od zera jak dany efekt uzyskać.
Po raz kolejny piszę, że SFML nie ma bardzo ważnej funkcji (zablokowanie myszy - https://github.com/LaurentGomila/SFML/issues/394 ), którą z powodzeniem zaimplementowano w SDL:
SDL_ShowCursor(0);
SDL_WM_GrabInput(SDL_GRAB_ON);
Bez tego nie da się zaprogramować wielu gier tak jakbyśmy chcieli, a twórcy SFML to olewają od dawna.
LWJGL w Javie też ma taką możliwość: http://www.lwjgl.org/javadoc/org/lwjgl/input/Mouse.html#setGrabbed%28boolean%29
Widać, że ta funkcja jest bardzo ważna i szkoda, że taki polecany przez wszystkich SFML tego nie ma.
edytowany 1x, ostatnio: Spine
Chodzi Ci o ukrycie myszy czy o funkcjie, która ją unieruchamia?
Chodzi mi o funkcję, która solidnie zablokuje mysz na obszarze aplikacji. Żebym w aplikacji mógł np. zaimplementować własną obsługę kursora myszy pobierając relatywne przemieszczenie myszy co klatkę. W SFML ukrycie kursora systemowego, ręczne wyśrodkowywanie kursora i pobieranie relatywnego przemieszczenia da się zrobić, ale wywoływanie tych funkcji (zwłaszcza ręczne wyśrodkowanie kursora) w każdej klatce strasznie przymula aplikację, a i tak nie zapewnia, że mysz nie wyjdzie poza okienko.
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
- Postów:4882
0
@Mossar plecisz Pan
http://4programmers.net/Forum/C_i_C++/227760-c_projekt_pare_pytan?p=1003034#id1003034
tutaj masz początki "obiektowości". Oczywiście, że w C można napisać psuedo obiektowość (zobacz źrodła quake'a 2). Ale tu nie chodzi co się nie da a co się da (bo w każdym języku wszystko się da jeżeli jest kompletny w sensie Turinga). Tylko chodzi o to, że w C musi bardzo dużo rzeczy zaimplementować sam, (oczywiście może szukać gotowych rozwiązań na necie) to co ma już w C++. Dodatkowo, jest masa "dodatków" do c++ jeżeli chodzi o gry, nie wiem jak wygląda to z C (zapewne gorzej). Na dzień dobry musi zaimplementować jakiś kontener. Jak jest kontener to przydałby się do niego interator, i w sumie przydałaby się mapa i przydało by się jeszcze (...). Nie wiem jak z wielowątkowością w C, ale chyba tutaj też trzeba wszystko samemu zaimplementować. Także jest od cholery pisania czegoś co w c++ jest. Po miesiącu już napisze wszystko co potrzebował do swojej gry (czas jest z d**y wzięty) i zapewne po tym już mu się odechce pisać gier, bo nadal nic nie zobaczył na ekranie ze swojej gry.
Chyba że to będzie pisane beż żadnej architektury tylko tak by napisać (czyli nawet wszechwiedząca funkcja main)
a do autora, tytuł ma się ni jak do treści pytania. 2d do obiektowości ma się tak samo jak 3d do obiektowości. a nawet 1d.
Jak chcesz to możesz pisać nawet a asm i też będzie ok. Po prostu zajmię Ci to więcej czasu.
edytowany 6x, ostatnio: fasadin
Że się da to nie znaczy, że jest sens skoro jest C++ i tworzenie klasy jest dużo bardziej naturalne i intuicyjne. Może się zapędziłem ze słowami, że "nie zrobisz w C", ale właściwie klasy nie zrobisz tylko strukturę, która będzie ją imitować. No ale też nie zabraniam, jak ktoś woli się męczyć "obiektowością" w C.
@Mossar "Męczyć" Ale to jest naprawdę świetna zabawa :-D + http://www.uvm.edu/~ejeldrid/resources/mipsoob.pdf
No więc jak Ci to sprawia przyjemność to nie widzę problemu ;)
- Rejestracja:ponad 15 lat
- Ostatnio:minuta
0
Mossar napisał(a):
Ale obiektowość jest niesłychanie naturalna w stosunku do tworzenia gier. W C nie zrobisz klasy "Przeciwnik" mającej pola "ilość naboi" i metody "strzelaj" i "uciekaj". Nie zrobisz klasy "Ultra Przeciwnik" dziedzicząc po Przeciwniku i dodając tylko parę ultra epickich zdolności.
To akurat da się zrobić ;) Są nawet całe publikacje udowadniające, że C to kompletny obiektowy język :D Problem w tym, że kod nie wygląda wtedy za fajnie, używa się dość mocno wskaźników do funkcji przez co z kodu robi się miejscami makaron.
edit
Dla mnie przewaga C++ to głównie wysokopoziomowe struktury danych oraz narzędzia wspomagające prace z nimi. Szybciej osiąga się efekty jeśli część pracy zostawiasz kompilatorowi.
edytowany 1x, ostatnio: several
Jest tylko jeden problem - obiektowość obiektowości nie równa, bo każdy implementuje ją na własną rękę ;)
Racja, dlatego nie bawię się w polimzpoorfizm w C, kod wygląda wtedy tak że po tygodniu przestaje go ogarniać. Ale enkapsulację można zrobić całkiem bezboleśnie :)
- Rejestracja:prawie 15 lat
- Ostatnio:prawie 5 lat
- Postów:358
0
Według mnie programowanie obiektowe to sposób projektowania, myślenia. Język może udostępniać mechanizmy obiektowe (wspomagające realizację obiektową) ale w zasadzie można starać się podejść do problemu obiektowo w języku nieobiektowym. Oczywiście jeśli zachodzi taka sytuacja należy raczej postawić sobie pytanie czy aby na pewno język został właściwie dobrany do rodzaju problemu - a raczej planowanego sposobu jego rozwiązania.
edytowany 2x, ostatnio: matek3005
- Rejestracja:prawie 13 lat
- Ostatnio:ponad 10 lat
- Lokalizacja:Opole
- Postów:533
0
#include <stdio.h>
#include <memory.h>
typedef struct {
int a,b;
void (*memberFunc)(struct KlasaDom * this,int parametr1);
}KlasaDom;
//funckja "składowa" "klasy" KlasaDom
void setA(KlasaDom * this, int parametr1) {
this->a = parametr1;
}
int main(void) {
// your code goes here
KlasaDom * obiekt = (KlasaDom*) malloc(sizeof(int) * 2 + sizeof(void(*)(KlasaDom,int)));
obiekt->memberFunc = &setA; // ustawiamy wskaźnik na funkcje "skladowa"
obiekt->memberFunc(obiekt,5); // tutaj wywołanie funkcji pseudoskładowej. Wygląda prawie jak normalnie. Trzeba tylko jawnie przesłać "this"
printf("%d", obiekt->a);
free(obiekt);
return 0;
}
program wyświetla prawidłową wartość tj 5(testowane), ale jest trochę warningów. Mniejsza o to chodziło mi tylko o pokazanie pewnej koncepcji jak zrobić żeby dało się wywołać pseudo funkcję składową dla struktury. Trzeba tylko alokować pamięć dynamicznie bo jeśli obiekt KlasaDom byłby alokowany na stosie to nie szło by przesłać adresu tego obiektu do funkcji. Teraz tylko jakoś zrobić żeby dało się oddzielić składniki prywatne od publicznych i będziemy mieli "prawie programowanie obiektowe" :D. Wadą tego sposobu jest to, że można tworzyć jedynie dynamiczne obiekty oraz za każdym stworzeniem obiektu ustawiać wszystkie funckje pseudoskładowe. Można powiedzieć, że C nie jest językiem wspomagającym programowanie obiektowe co nie oznacza, że nie da się napisać obiektowego programu. Programowanie obiektowe to kwestia zapisu. W języku nie przystosowanym do programowania obiektowego ten zapis będzie mało czytelny. Wadą takiego programowania jest to, że kompilator nie będzie sprawdzał cię czy wszystko robisz poprawnie. Jednym słowem ty musisz pilnować się i trzymać się ścisłych wymogów. Nawet jeśli popełnisz błąd kompilator go nie wykryje w przeciwieństwie do kompilatorów języków obiektowych(np C++). Ten kod może i jest porąbany albo nieprawidłowy. Chodziło mi tylko o pokazanie pewnego sposobu myślenia.
WTF? czemu nie po ludzku:
(KlasaDom*)malloc(sizeof(KlasaDom));
Gdzie konstruktor?! Destruktor!? Poza tym, @fasadin podał już link z przykładem obiektowości w C, ponadto wszystko wyjaśnił
a to przeoczyłem jego post :D