Vertiefung in C++ OOP für Plattformunabhänigkeit

  • C/C++

Diese Seite verwendet Cookies. Durch die Nutzung unserer Seite erklären Sie sich damit einverstanden, dass wir Cookies setzen. Weitere Informationen

  • Vertiefung in C++ OOP für Plattformunabhänigkeit

    Der Text oben sagt es eigentlich schon aus. Ich habe mich jetzt mit den Basics von C++ auseinander gesetzt und bin fasst fertig damit. Also Funktionen, Zeiger, Arrays, Schleifen und Bedingungen usw. Fehlt mir nur noch die Klassen aber die kommen noch in den Youtube Tutorials. Ich würde mich gerne im Objekt orientierten Bereich gerne auf plattformunabhängigkeit bewegen. Das heist nicht mit WinApi oder diretx usw. arbeiten, damit ich meine Programme auf Linux und Windows laufen lassen kann. Als IDE verwende ich Code::Blocks das es bereits für Linux und Windows gibt. Jetzt ne frage wie soll ich am besten mit C++ weitermachen. Ich habe alles wirklich schnell und gut verstanden, weil vieles mich an GML errinert, welche APIs muss ich da verwenden, welche Erweiterungen? Könnte mir da jemand einen Rat geben?

    MFG: Mar96K

  • Wenn du die notwendigen Grundbegriffe verstanden hast, und dir verständlicherweise nicht mehr mit dem WinAPI Kram herumschlagen willst, empfehle ich einfach mal eine Idee für ein eigenes Projekt zu entwickeln.

    Um dabei möglichst platformunabhängig zu bewegen sollte man beim Implementieren vorzugsweise auf die Standart Bibliotheken setzen. Um beim Implementieren nicht unzälige Male das Rad neu zu erfinden, sollte man sich im Internet die Passenden Open Source Bibliotheken suchen. Dabei solltest du darauf achten die Lizenzen des verwendeten Codes genauestens zu studieren.

    Nachdem du einige Erfahrungen mit C++ gesammelt hast und ein umfangreiches Repertoire zur Lösung verschiedenster Probleme besitzt, bleibt dir z.B. die Möglichkeit eine vollständige Spieleengine basierend auf OpenGL bzw. OpenAL zu schreiben. In den jeweiligen Platformen musst du dann nur noch Weniges individuell anpassen.

    Wenn aber mitten in einem Projekt einmal beim Verfassen komplexerer Abläufe Schwierigkeiten entstehen und sich die Implementationen nicht mehr flüssg fortsetzten lassen, empfehle ich als folgende exzellente Literatur:

    msedv.at/books/eckel/

  • Kommt drauf an, was du machen willst.
    An sich ist C++ insofern plattformunabhängig, dass du den Code nur für die jeweilige Plattform kompilieren musst, und dann läuft es. Mir sind lediglich folgende Problemkinder bekannt, bei denen man immer zwischen Windows und UNIXoid unterscheiden muss, um dann entweder händisch Präprozessorweichen zu stellen (#ifdef __WIN32 oder so) oder eine Bibliothek zu nutzen, die das für einen erledigt: Netzwerkkram (BSD sockets vs. Windos sockets), Threads (pthreads und co vs. was auch immer man mit der Windows API machen kann), GUI und größen von Datentypen (ich hab schon leute fluchen sehen, weil sie auf nem 32-Bit-System entwickelt haben, Annahmen über die Größe von Datentypen getroffen haben, die dort zwar galten, aber auf einem 64-Bit-System nicht mehr, was dazu führte, dass es dort knallte).

    Das letzte dieser Probleme wird eigentlich nur relevant, wenn man irgend ne Form von Bitgeschubse betreibt.

    Wenn du von DirectX und WinAPI sprichst, willst du wohl auch grafische Ausgabe; auch hier ist wieder entscheidend, was du willst.
    Willst du "nur" eine GUI in deinem Programm haben, empfehle ich dir, dir mal wxWidgets anzusehen. Das ist eine Bibliothek, in der du beim Programmieren mit jeder Menge Makros und Ableiten von Klassen deine GUI designest, und zur Compilezeit werden dann die vorhandenen plattformspezifischen Mittel genutzt. D.h. wenn du das dann auf einem Windows kompilierst, wird gegen die WinAPI kompiliert.
    Willst du dagegen eher ein Spiel schreiben, empfehle ich dir, dich mit OpenGL auseinanderzusetzen. Wenn du nur in der zweiten Dimension unterwegs sein willst, wie beim GM ohne den 3D-Modus, kannst du dir auch die SDL-Bibliothek ansehen; die ist angeblich leichter zu benutzen.

    Und für die übrigen oben erwähnten Probleme (Netzwerk, Threads, etc.) kannst du dich mit Boost auseinandersetzen. Diese funktioniert so ähnlich, wie wxWidgets für GUIs: Du programmierst mit Mitteln von Boost, und beim Kompilieren wird dann passend zur jeweiligen Plattform kompiliert.

  • im Prinzip gehts eigentlich nur darum mich weiterzubilden/vertiefung in c++. Ich kann jetzt nicht alle Fragen etc./ Antworten beantworten weil ich keine Zeit habe und gleich weg muss. Werder mir den Thread spätestens bis Abend genauer ansehen :)

    danke für die Antworten ;) MFG: Mar96K

    Edit: Ich habe mich für SDL entschieden und kapier vieles schon doch ich besitzt noch gar kein Wissen wie ich weitermachen soll. Im Internet finde ich nur schlechte Toturials und ein Buch will ich mir auch nicht kaufen... Ich hab da auch schon ein Problem und zwar möchte ich eine Figur oder ehergesagt ein Bild laufen lassen, dass geht ja auch nur es funktioniert nicht flüssig, bzw. nicht richtig

    Spoiler anzeigen

    C-Quellcode

    1. #ifdef __cplusplus
    2. #include <cstdlib>
    3. #else
    4. #include <stdlib.h>
    5. #endif
    6. #ifdef __APPLE__
    7. #include <SDL/SDL.h>
    8. #else
    9. #include <SDL.h>
    10. #endif
    12. class unit{
    14. public:
    15. int x;
    16. int y;
    17. int hp;
    18. };
    20. int main ( int argc, char** argv )
    21. {
    22. // initialize SDL video
    23. if ( SDL_Init( SDL_INIT_VIDEO ) < 0 )
    24. {
    25. printf( "Unable to init SDL: %s\n", SDL_GetError() );
    26. return 1;
    27. }
    29. // make sure SDL cleans up before exit
    30. atexit(SDL_Quit);
    32. // create a new window
    33. SDL_Surface* screen = SDL_SetVideoMode(640, 480, 16,
    34. SDL_HWSURFACE|SDL_DOUBLEBUF);
    35. if ( !screen )
    36. {
    37. printf("Unable to set 640x480 video: %s\n", SDL_GetError());
    38. return 1;
    39. }
    41. unit player;
    43. player.x = 300;
    44. player.y = 300;
    45. player.hp = 100;
    47. // load an image
    48. SDL_Surface* bmp = SDL_LoadBMP("cb.bmp"); /// Dieses Objekt dient nur zum Testen :D
    49. if (!bmp)
    50. {
    51. printf("Unable to load bitmap: %s\n", SDL_GetError());
    52. return 1;
    53. }
    55. // load the image of the player
    56. SDL_Surface* bmp_player = SDL_LoadBMP("player.bmp"); /// Hier wird das Bild des Players geladen
    57. if (!bmp_player)
    58. {
    59. printf("Unable to load bitmap: %s\n", SDL_GetError());
    60. return 1;
    61. }
    63. // centre the bitmap on screen
    64. SDL_Rect dstrect;
    65. dstrect.x = (screen->w - bmp->w) / 16;
    66. dstrect.y = (screen->h - bmp->h) / 16;
    68. SDL_Rect dst_player;
    69. dst_player.x = player.x;
    70. dst_player.y = player.y;
    72. // program main loop
    73. bool done = false;
    74. while (!done)
    75. {
    76. // message processing loop
    77. SDL_Event event;
    78. while (SDL_PollEvent(&event))
    79. {
    80. // check for messages
    81. switch (event.type)
    82. {
    83. // exit if the window is closed
    84. case SDL_QUIT:
    85. done = true;
    86. break;
    88. // check for keypresses
    89. case SDL_KEYDOWN:
    90. {
    91. // exit if ESCAPE is pressed
    92. if (event.key.keysym.sym == SDLK_ESCAPE)
    93. done = true;
    94. break;
    95. }
    96. } // end switch
    99. if (event.key.keysym.sym == SDLK_UP) /// Problem beim bewegen ist hier
    100. {
    101. dst_player.y -= 8;
    102. }
    104. if (event.key.keysym.sym == SDLK_DOWN)
    105. {
    106. dst_player.y += 8;
    107. }
    109. if (event.key.keysym.sym == SDLK_LEFT)
    110. {
    111. dst_player.x -= 8;
    112. }
    114. if (event.key.keysym.sym == SDLK_RIGHT) /// <- Help
    115. {
    116. dst_player.x += 8;
    117. }
    119. } // end of message processing
    121. // DRAWING STARTS HERE
    123. // clear screen
    124. SDL_FillRect(screen, 0, SDL_MapRGB(screen->format, 0, 0, 0));
    126. // draw bitmap
    127. SDL_BlitSurface(bmp, 0, screen, &dstrect);
    128. SDL_BlitSurface(bmp_player, 0, screen, &dst_player);
    130. // DRAWING ENDS HERE
    132. // finally, update the screen :)
    133. SDL_Flip(screen);
    134. } // end main loop
    136. // free loaded bitmap
    137. SDL_FreeSurface(bmp);
    138. SDL_FreeSurface(bmp_player);
    139. // all is well ;)
    140. printf("Exited cleanly\n");
    141. return 0;
    142. }
    Alles anzeigen


    hat da jemand eine Ahnung ? :)

    PS: Tschuldigung das ich mich so spät melde aber ich war auf einer klassenfahrt in München und fürs Internet-Cafe habe ich nicht Zeit gefunden :)
    MFG

    Dieser Beitrag wurde bereits 1 mal editiert, zuletzt von mar96k ()

  • Ich mach mal einen neuen Post, weil er die Editierten bereiche nicht als veränderung meldet ;)
    Hab nämlich ein Problem :o

    Ich weiß nicht ob ich mit SDL weitermachen soll, weil es mir ganze Zeit nur Probleme verursacht. Codes scheinen von Internet-Tutorials nicht zu funktionieren etc.??
    Was mich auch sehr interessiert wie wäre der detailte Bereich über Header-Files und eigenen Biblotheken etc. oder Plugins für Code::Blocks usw.

    MFG: Mar96K

  • Dein Tastenprüfcode muss auch in den "case SDL_KEYDOWN"-Block hinein, also so:
    Spoiler anzeigen

    Quellcode

    1. // check for keypresses
    2. case SDL_KEYDOWN:
    3. {
    4. // exit if ESCAPE is pressed
    5. if (event.key.keysym.sym == SDLK_ESCAPE)
    6. done = true;
    7. break;
    9. if (event.key.keysym.sym == SDLK_UP)
    10. {
    11. dst_player.y -= 8;
    12. }
    14. if (event.key.keysym.sym == SDLK_DOWN)
    15. {
    16. dst_player.y += 8;
    17. }
    19. if (event.key.keysym.sym == SDLK_LEFT)
    20. {
    21. dst_player.x -= 8;
    22. }
    24. if (event.key.keysym.sym == SDLK_RIGHT)
    25. {
    26. dst_player.x += 8;
    27. }
    28. }
    29. } // end switch
    Alles anzeigen

    SDL ist definitv keine schlechte Idee für deine Pläne. Ich kann dir dabei nur die Tutorials von LazyFoo ans Herz legen, sind wirklich klasse.

  • vielen dank elvissteinir für die guten tutorials, zwar auf english aber trotzdem verständlich :)
    Dein Vorschlag mit dem Laufen klappt schon besser nur das Problem ist das es dem GML-Befehl: "if keyboard_check_pressed" ähnelt. Ich würd gern das er durchgehend läuft und nicht immer wenn ich die taste neudrücken muss. Ich tippe mal das ich das mit einer Schleife oder so machen muss... MFG: Mar96K