Grafika 2D a obiektowość

0

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 ;)

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.

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ć.

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.

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.

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.

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.

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.

1 użytkowników online, w tym zalogowanych: 0, gości: 1