Jump to content
  • Advertisement

learnedseeker

Member
  • Content Count

    10
  • Joined

  • Last visited

Community Reputation

123 Neutral

About learnedseeker

  • Rank
    Member
  1. learnedseeker

    Issue with runtime error

      Sounds about right. Do you recommend any programs and or tutorials for this issue (I don't even know what exactly I should google)? I'm using Visual Studio community edition... So I doubt it'll have many debugging bells and whistles.     Oh i know there are issues, one I get this taken care of, I am going to do some cleaning.   I cannot get the Sprite in some areas to accept the parameters from the constructor, I am not sure why it won't eat the parameters, will check on that and see. I think that might be something I need some help with.   I didn't delete it because I can't even get it to work yet. =)     I took this to the after school help area and they couldn't help me, it's really hard to learn this stuff, even if your going to school for it, which is why I am doing this whole thing in the first place... Programming class in school teaches you how to crawl, and they pretty much expect you to be a marathon runner by the time you get a job, so here I am trying to get on two feet. Programming is really something you need a mentor for more than a 25 person class. =\   Thanks for the help so far.
  2. Hey guys I am having an issue where my program is crashing and it compiles fine, I think it's an issue with composition but I am not sure, if you could help me out, I've been stuck on it for almost a week now, I would super dooper appreciate it. An explanation of the issue is included in the pastebin above the code.     http://pastebin.com/8YR8jmA2   thanks   learnedseeker
  3. learnedseeker

    SDL Renderer Issue

      Because that's not how C++ works. It expects you to be explicit about things like assignment, and does not attempt to "magically" assign constructor parameters to member variables based on the parameter names and/or types.   C++ as a language generally assumes you know it and know what you are doing.     Here is where I am screwed up though. I create an pointer object of SDL_Renderer in sprite, then I create one in main... Two different SDL_Renderer objects of two different scopes. How do these renderer objects "connect"? That is what is screwing me up. I don't see how two different renderer objects translates to having multiple objects on the same screen that has only been issued one renderer??? (I only assigned one renderer to the SDL_WIndow, I did not attach the sprites renderer to that window object). I guess SDL just always takes any renderer pointer and sends it to the same "master" renderer? Even though there is more than one renderer object?   If anything, this seems to go against how C++ functions.   Would appreciate the explanation.   thanks,   learnedseeker
  4. learnedseeker

    SDL Renderer Issue

      Yeah that was the problem. Why uhhhh did I have to add this line: renderer = passed_renderer; into the cpp for sprite?   Now I have to ask so that it sinks in...: How come the compiler cannot "figure it out"?   I was trying to assign that renderer to the renderer in GraphicsCore?   THANK YOU FOR YOUR HELP. GAHHH. <3
  5. learnedseeker

    SDL Renderer Issue

    it's initialized in sprite.cpp
  6. learnedseeker

    SDL Renderer Issue

    Thanks for the idea, but no, I've already tried that. (I gave it another go, just to be sure).
  7. learnedseeker

    SDL Renderer Issue

      Player is a texture, HANDLED IN THE SPRITE CLASS. It is not texture 2, that is leftover from the "conversion". Ignore anything commented out. Here is a link to the sprite files (I'm 99.9% certain the sprite class is fine, not sure why I decided to not post them before...): http://pastebin.com/7Jnq6DEd Which I didn't include in the other files, which I am posting here for convenience (same as above): http://pastebin.com/NsfmYC0J    Thanks for your help!   - learnedseeker To run through the program - I launch, it compiles fine (as long as sprite is commented out). The window boots up, music plays (didn't include those files for obvious reasons). The grass texture shows up as planned, and it runs until I x out of the window. But player doesn't show. =\ =\ =\  Everything works except the player.
  8. learnedseeker

    SDL Renderer Issue

    I cannot get my player object of the sprite class to display on the screen. I am pretty sure it is a composition issue having to do with SDL* Renderer, but I cannot figure out exactly what the problem is. I have been banging my head on the keyboard for five days now and I cannot get the sprite object to display. Really appreciate the help.   http://pastebin.com/NsfmYC0J If you see any other bugs, let me know.   - learnedseeker Also, the texture does display fine, and since I couldn't get the sprite to display, I actually created it as a texture and then slowly converted it over to being a sprite (and that was after a few days of just fiddling with the sprite itself) - so the screen and the texture display just fine. It's just getting the sprite class rendered.
  9.   Okay so, you basically "toss" the GUI elements on top of the gl context. Cool. Gotcha.
  10. Obviously the window/event etc is handled by SDL.   The main game has basically 3.5 viewports. There is the main viewport, which is purely opengl; then there will be a GUI across the bottom, a notification bar on the left hand side, and a minimap in the bottom left side. Not sure if I should make that a separate context or attach it to the giu bar...   Question is, how exactly should I implement it? Should I create a glcontext for the main window viewport, then 3 seperate SDL_Renderer viewports for the other three windows? Or should I just kind of "toss" the overlays on top of the 1 single glcontext, and not render graphics that are behind the sdl viewports?   And uhh,... How exactly would you implement that? 3 separate renderer objects in SDL?   thanks,   learnedseeker
  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!