• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.


  • Content count

  • Joined

  • Last visited

Community Reputation

153 Neutral

About windghost91

  • Rank
  1. SDL

    The debugger I used was Visual Studio 2015, since that is the only option that popped up. The message was not really that clear to me. It said something like "invalid access at memory location" and then it listed the address. Or perhaps that is just me not used to using debuggers too much. I definitely am seeing the need to use one as my program is around 400 lines and only puts sprites on the screen and lets someone move them. If you know of any good debuggers for Codeblocks using MinGW that are better than Visual Studio 2015, please let me know. I see what you mean about using the address of operator- this solved the problem and the sprite clips render perfectly now with type SDL_Rect. I have seen the ampersand used before in SDL_RenderCopyEX, but I was not sure if it was a reference or the address. I did not know that it was legal to pass a memory address to SDL_RenderCopyEX without declaring a pointer, since the documentation says that SDL_RenderCopyEX requires a pointer. I knew in this context, i.e., a function call, that an ampersand means memory address, but not knowing that you did not have to declare a pointer confused me somehow. I am glad that is all cleared up now. I honestly had no idea what I was thinking and how not knowing this crucial piece of information mixed my brain up exactly! I am glad I am learning more about SDL 2 works with C++ after getting away from the tutorials and making my own (simple) games.
  2. SDL

    Yes, I get a screen to choose a debugger. The message sounded like a pointer error, which is what I was wondering about. In my experience, sometimes, the compiler is able to convert SDL_Rects to pointers, but other times, it is not able to and I get an error something like "Unable to convert SDL_Rect to const SDL_Rect* for argument..." when attempting to render. This has frustrated me, so I tried to switch to pointers. That was troublesome too as you have seen. If I were to use SDL_Rect instead of SDL_Rect*, do you know of a way to bypass this problem so that the compiler is able to make the conversion to pointers properly for SDL_RenderCopyEX?
  3. SDL

    Ok, thanks. I always wondered why tutorials did it that way. I tried it without the pointer, but it sounds like you need it. I meant SDL_Texture*. I'm not sure why I put SDL_Rect*. My include files were not shown in the post, but they are in the file. I have SDL.h and SDL_image.h. Ok, I was unable to find documentation on IMG_LoadTexture specifically. Thank you for the info. pSprite was supposed to contain the current sprite being shown on the screen. Thank you for telling me that it was not initialized. #include "game.h" //contains SDL.h, SDL_image.h, iostream, and stdio.h. Also has using namespace std. #include "worlds.h" //class declaration //gets window size, loads sprite sheet, and prepares initial sprite for rendering World1::World1(int SCREEN_WIDTH, int SCREEN_HEIGHT, SDL_Renderer*& renderer) { window_width = SCREEN_WIDTH; window_height = SCREEN_HEIGHT; pSpriteSheet = IMG_LoadTexture(renderer, "male_base-test-anim.gif"); if (pSpriteSheet == nullptr) { cout << "Unable to load player Sprite sheet."; } //facing down sprite pSpriteClips[0]->x = 14; pSpriteClips[0]->y = 12; pSpriteClips[0]->w = 145; pSpriteClips[0]->h = 320; pSprite = pSpriteClips[0]; //sets sprite clip upon game start to be pSpriteClips[0] //player rectangle that pSprite is rendered onto pBase->x = 0; pBase->y = 0; pBase->w = pSpriteClips[0]->w; pBase->h = pSpriteClips[0]->h; } //renders player to screen void World1::renderPlayer(SDL_Renderer*& renderer) { //Prepare sprite positions for rendering pBase->x = static_cast<int>(pPosX); pBase->y = static_cast<int>(pPosY); //render SDL_RenderClear(renderer); //clears screen SDL_RenderCopyEx(renderer, pSpriteSheet, pSprite, pBase, 0.0, NULL, sFlip); SDL_RenderPresent(renderer); //puts image on screen } I initalized pSprite and changed pSpriteClips and pBase to pointers. So far, the program builds, but it crashes at runtime. Using pointers to render has proven tricky for me. What can I do to avoid the crash? I will show more code if necessary.
  4. I am trying to implement sprite clips, or rendering a portion of a sprite sheet onto the screen. For now, I am least trying to get one sprite to display on the screen. Controller support and adding the other sprites when changing the character direction will come later. Here is what I have so far. First, the class declaration: class World1 { public: //other stuff //screen resolution int window_width = 0; int window_height = 0; //handles player void renderPlayer(SDL_Renderer*&); //other stuff private: //player graphic and rectangle structs/variables/etc. SDL_Texture* pSpriteSheet = nullptr; SDL_Rect pSpriteClips[3]; SDL_Rect* pSprite; SDL_Rect pBase; SDL_RendererFlip sFlip = SDL_FLIP_NONE; //other stuff }; Then, the constructor: World1::World1(int SCREEN_WIDTH, int SCREEN_HEIGHT, SDL_Renderer*& renderer) { window_width = SCREEN_WIDTH; window_height = SCREEN_HEIGHT; *pSpriteSheet = IMG_LoadTexture(renderer, "male_base-test-anim.gif"); if (pSpriteSheet == nullptr) { cout << "Unable to load player Sprite sheet."; } //facing down sprite pSpriteClips[0].x = 14; pSpriteClips[0].y = 12; pSpriteClips[0].w = 145; pSpriteClips[0].h = 320; //more code... //player sprite pBase.x = 0; pBase.y = 0; pBase.w = pSpriteClips[0].w; pBase.h = pSpriteClips[0].h; } Then, the rendering void World1::renderPlayer(SDL_Renderer*& renderer) { //render SDL_RenderClear(renderer); //clears screen SDL_RenderCopyEx(renderer, pSpriteSheet, pSprite, &pBase, 0.0, NULL, sFlip); SDL_RenderPresent(renderer); //puts image on screen } So far, the program does not build and I obtain the following error: C:\Users\Kevin\Documents\Codeblocks\KnightQuest\worlds.cpp|12|error: invalid use of incomplete type 'SDL_Texture {aka struct SDL_Texture}'| Am I mistaken to assume that C++ will automatically assign a memory address to SDL_Rect* when I assign a value to it via the dereference operator? Or, perhaps there is another issue?
  5. Hmm yes indeed. However, I am more worried about the line below it, where you assign pVelY with a new value, no matter what the "if" assigned.   I get what you are saying. You think having 2 breaks in one switch statement is good- one with the if (it handles collisions) and one underneath the if (if there are no collisions)? It's weird how it has been working already though, and I don't know how I didn't think of something like that already. Ok, putting an extra break caused no problems. I have read that using break and continue statements (other than the one usually in a switch statement) should be avoided if possible, however. The code works this way too, though.
  6.   This is always true. Double equals, not single equals.   Bump up your warning level in your compiler/IDE.     As I thought could happen, I did something silly. Thanks for your time looking through the code. Thank you for the heads up. That condition should be '<' instead of '==' so that the character is able to get to the edge of the screen. I have been putting the break statements on their own line, but I tried the same line. It seems I like different lines better, though. That is what is recommended overall anyways, right?  So, it seems like changing the '=' to '==' solved the problem. I will definitely check the warning settings on my compiler. I need to turn some of them off, actually. The one for this situation appeared, but I turned so many on that I thought I would check them all later! Some of them trigger warnings from include files or from things that are mandatory in SDL 2 (such as the main function) that seem superfluous.  On that note, -Wshadow triggers on the function parameter lists of handlePlayerEvents. Any thoughts?
  7. handlePlayerEvents: //event handling void World1::handlePlayerEvents(SDL_Event& e, bool& quit) { while( SDL_PollEvent( &e ) != 0 ) { //User requests quit if( e.type == SDL_QUIT ) { quit = true; } //handles movement with collisions this->keyboardMovePlayerEvent(e); this->controllerMovePlayerEvent(e); } } goes inside main loop: //main loop of program void World1::mainLoop(SDL_Renderer*& renderer) { quit = false; this->loadPlayer(renderer); while (!quit) { this->handlePlayerEvents(e, quit); this->movePlayer(); this->renderPlayer(renderer); } } which goes inside game.cpp: int main( int argc, char* argv[]) { static const int SCREEN_WIDTH = 1024; static const int SCREEN_HEIGHT = 768; SDL_Window* window = NULL; //make window SDL_Renderer* renderer = NULL;// make renderer SDL_Joystick* gameController = NULL; //make controller init(window, renderer, gameController, SCREEN_WIDTH, SCREEN_HEIGHT); //World Loader World1 world(SCREEN_WIDTH, SCREEN_HEIGHT); world.mainLoop(renderer); //exit SDL and end program exit(window, renderer, gameController);     return 0; }
  8. It works fine without endl; (unless SDL_KEYUP is executing, then the whole controller part is skipped). Yeah, it's really weird. If I comment out the SDL_KEYUP part, everything works fine (except for the character continuing to move as a result of SDL_KEYDOWN). I tried moving the controller code to a different function to see if this constant execution was messing with the surrounding control flow, but the same problem still remains. SDL_KEYUP constantly executing makes the controller not work, even if each of the cases in the switch statement that keep the velocity at 0 do not execute. I will go ahead and make a test program, though.
  9. For the keyboard input, I had it print out "hello" for SDL_KEYDOWN and "hi" for SDL_KEYUP whenever I pushed down and released an arrow key to see if the code went into these else if branches in movePlayerEvent. I did this after I tried the same approach with SDL_JOYAXISMOTION. I turned on the controller so that the "no controllers detected" code would not execute in my init function (completely outside the world class in main). So, I know that the controller turned on. The code is not going into the else if branch for JOYAXISMOTION. After pushing on the joystick, the following code, if statement and all, never executed: else if (e.type == SDL_JOYAXISMOTION) { cout << "JOYAXISMOTION: " << e.type; //rest of code below did not execute either //... } It worked just fine with SDL_KEYDOWN and SDL_KEYUP, and I even found that else if (e.type == SDL_KEYUP) was constantly executing. This looked fishy. So, I commented out keyboard support entirely after finding out that SDL_JOYAXISMOTION was not executing. Guess what happened next? Controller supported worked! This is telling because I added SDL_KEYUP just recently after changing up the keyboard support. So, now I know that SDL_KEYUP is the problem and that it executes when no buttons on the keyboard are pressed. I'm not sure why this affects SDL_JOYAXISMOTION, since it seems like control flow could just go to the next else if statement, which is the controller, even if SDL_KEYUP was constantly executing. Just commenting out SDL_KEYUP also caused it to not work after changing SDL_KEYDOWN to work with the newly implemented SDL_KEYUP (instead of  having playerbase.x++ and playerBase.y++, I changed it to work with velocities instead just like the controller). Not sure how to change keyboard support to work with controller support now that I have changed keyboard support to work with velocity, but I will have to figure all this out more tomorrow. Alberth/anyone, feel free to post thoughts so far between now and tomorrow when I get back to this (later tonight really since it's past 12AM now where I live).
  10. pPosX and pPosY change in the movePlayer function. renderPlayer executes in the main loop after the movePlayer function. All the code executes. I added pPosX and pPosY because I changed the velocity to a decimal and playerBase cannot be a decimal due to the values being pixels which are only whole numbers. I'm not sure why you are asking those questions or if you are trying to hint something, but I think it is strange how only the controller part of the code does not work at this point, yet I see nothing wrong with the controller code. The keyboard movement with the arrow keys works fine, but trying to move with a controller does nothing and the rectangle does not move on the screen. The problem is still unclear. Relevant code so far: void World1::movePlayerEvent(SDL_Event& e) //function is called inside handlePlayerEvents { //keyboard movement support if (e.type == SDL_KEYDOWN) { switch(e.key.keysym.sym) { case SDLK_UP: if (this->getPlayerRectPosY() == 0) pVelY = PLAYER_VELOCITY_Y; pVelY = -PLAYER_VELOCITY_Y; break; case SDLK_DOWN: if (this->getPlayerRectPosY() == window_height - this->getPlayerRectH()) pVelY = -PLAYER_VELOCITY_Y; pVelY = PLAYER_VELOCITY_Y; break; case SDLK_LEFT: if (this->getPlayerRectPosX() == 0) pVelX = PLAYER_VELOCITY_X; pVelX = -PLAYER_VELOCITY_X; break; case SDLK_RIGHT: if (this->getPlayerRectPosX() == window_width - this->getPlayerRectW()) pVelX = -PLAYER_VELOCITY_X; pVelX = PLAYER_VELOCITY_X; break; default: break; } } //keyboard movement support continued else if (e.type = SDL_KEYUP) { switch(e.key.keysym.sym) { case SDLK_UP: case SDLK_DOWN: pVelY = 0; break; case SDLK_LEFT: case SDLK_RIGHT: pVelX = 0; break; default: break; } } //controller movement support else if (e.type == SDL_JOYAXISMOTION) { if (e.jaxis.which == 0)//controller 0 { if (e.jaxis.axis == 0)// x axis { if (e.jaxis.value < -CONTROLLER_DEAD_ZONE) pVelX = -PLAYER_VELOCITY_X; else if (e.jaxis.value > CONTROLLER_DEAD_ZONE) pVelX = PLAYER_VELOCITY_X; else pVelX = 0; } else if (e.jaxis.axis == 1)//y axis { if (e.jaxis.value < -CONTROLLER_DEAD_ZONE) pVelY = -PLAYER_VELOCITY_Y; else if (e.jaxis.value > CONTROLLER_DEAD_ZONE) pVelY = PLAYER_VELOCITY_Y; else pVelY = 0; } } } } //moves player void World1::movePlayer() { //update x and collision check pPosX += pVelX; if (pPosX < 0 || (pPosX + playerBase.w > window_width)) pPosX -= pVelX; //update y and collision check pPosY += pVelY; if (pPosY < 0 || (pPosY + playerBase.h > window_height)) pPosY -= pVelY; } void World1::renderPlayer(SDL_Renderer*& renderer) { //prepare postions for rendering playerBase.x = static_cast<int>(pPosX); playerBase.y = static_cast<int>(pPosY); //render SDL_RenderClear(renderer); //clears screen SDL_RenderCopy(renderer, pTexture, nullptr, &playerBase); SDL_RenderPresent(renderer); //puts image on screen } void World1::mainLoop(SDL_Renderer*& renderer) { SDL_Event e; quit = false; this->loadPlayer(renderer); while (!quit) { this->handlePlayerEvents(e, quit); this->movePlayer(); this->renderPlayer(renderer); } }
  11. Alberth, thanks for the debugging tips. I could definitely use more pointers with that. Lactose, I like your suggestion of changing things at rendering time and not mixed with updating the positions. The code feels cleaner and more separate like it should (if that makes any sense).   Edit: Now the controller support does not work. The character does not move when I use the controller when the controller is connected. //renders player to screen void World1::renderPlayer(SDL_Renderer*& renderer) { //prepare postions for rendering playerBase.x = static_cast<int>(pPosX); playerBase.y = static_cast<int>(pPosY); //render SDL_RenderClear(renderer); //clears screen SDL_RenderCopy(renderer, pTexture, nullptr, &playerBase); SDL_RenderPresent(renderer); //puts image on screen } void World1::movePlayer() { pPosX += pVelX; if (pPosX < 0 || (pPosX + playerBase.w > window_width)) pPosX -= pVelX; pPosY += pVelY; if (pPosY < 0 || (pPosY + playerBase.h > window_height)) pPosY -= pVelY; } Success! As far as the keyboard movement goes, anyways (which I did before this topic). Now the controller does not move. It's like one thing works and something else pops out. //controller movement support else if (e.type == SDL_JOYAXISMOTION) { if (e.jaxis.which == 0)//controller 0 { if (e.jaxis.axis == 0)// x axis { if (e.jaxis.value < -CONTROLLER_DEAD_ZONE) pVelX = -PLAYER_VELOCITY_X; else if (e.jaxis.value > CONTROLLER_DEAD_ZONE) pVelX = PLAYER_VELOCITY_X; else pVelX = 0; } else if (e.jaxis.axis == 1)//y axis { if (e.jaxis.value < -CONTROLLER_DEAD_ZONE) pVelY = -PLAYER_VELOCITY_Y; else if (e.jaxis.value > CONTROLLER_DEAD_ZONE) pVelY = PLAYER_VELOCITY_Y; else pVelY = 0; } } } I printed out playerBase's coordinates to the console via cout, and they just stayed the same. I hope there is not something silly that I am missing.
  12. So, I am trying to get things to work that way now. My solution looked something like this: void World1::movePlayer() { playerBase.x+= static_cast<int>(pVelX); if (pPosX < 0 || (pPosX + playerBase.w > window_width)) playerBase.x-= static_cast<int>(pVelX); playerBase.y+= static_cast<int>(pVelY); if (pPosY < 0 || (pPosY + playerBase.h > window_height)) playerBase.y-= static_cast<int>(pVelY); }  However, the character position does not update on the screen. It stays at its original position when it is loaded. Why could this be, you think?
  13. If you wanted to contribute to an open source game, what benefit would this have on your resume or portfolio? If you are trying to build up your portfolio or resume, should you pursue open source contribution, or should you just work on things like your own game demos or something else?
  14. I am guessing that you are recommending float for memory purposes? It's half as large, so I like your suggestion since I know it's good to not use up memory if it is not needed. The screen will not be bigger in pixel size than what float can hold, so float is adequate in this case. I just use SDL_RenderCopy and it passes in the whole rectangle as shown in the above code, so I cannot convert when rendering. I can convert before rendering during the move function, but I cannot pass arguments like that with the way that I have things coded. I just wonder why the rectangle on the screen disappeared when changing my position and velocity variables and my velocity constants to float. It all worked fine with double.
  15. Convert with static cast?