Jump to content

  • Log In with Google      Sign In   
  • Create Account

Rubiks14

Member Since 29 Sep 2005
Offline Last Active Apr 17 2013 01:22 PM

Topics I've Started

[C++] Elusive access violation error

10 April 2013 - 09:41 PM

So here's the deal, I've been working on a roguelike game in c++ using the advanced windows console functions in wincon.h. I have a randomly generated map and I'm drawing it to a screen. Every once in a blue moon when I'm running the program it will give me an access violation error on program close. I can run the program probably 50 times and if I'm lucky (unlucky actually) the error will show up.

 

I'm using codeblocks as my IDE and have the debugger set to break on an exception. I have been unable to actually recreate the access violation while using the debugger. It only seems to occur when I do a basic run of the program. It doesn't crash the program or lock up, it just gives the error code on close.

 

There is too much code to post here but you can look at it on github: https://github.com/Rubiks14/ASCII . I believe the error is happening in map.h but it might not hurt to look into screen.h and screen.cpp as well. Also I'm sorry for the craziness of the code in advance. Some of the comments are relevent but others need to be updated. I know there are a few things that need to be broken down into more functions and some stuff that would work better if passed by reference (the vectors), I'm just trying to eliminate this bug before altering anything else and before adding any new features.

 

One more thing. I think the problem is somewhere in the drawing procedures for the map or screen class.

 

 

EDIT: Fixed broken link


Specific question about pointers to arrays

29 March 2012 - 09:25 PM

#include <iostream>
#include <string>
class Item{
    private:
	    std::string m_name;
	    int m_value;
    public:
	    Item(std::string name, int value): m_name(name), m_value(value){}
	    friend std::ostream &operator<<(std::ostream &out, Item i){
		    out << "Item name: " << i.m_name << "\n";
		    out << "Value: " << i.m_value << "\n";
		    return out;
	    }
};
int main(){
    Item *inventory[3] = {new Item("Sword", 200),new Item("Shield", 150),new Item("Potion", 50)};
    int arraySize = sizeof(inventory) / sizeof(inventory[0]);
    for(int i = 0; i < arraySize; i++){
	    std::cout << *inventory[i];
    }
    std:: cout << "\n\n";
    for(int i = 0; i < arraySize; i++){
	    std::cout << **(inventory + i);
    }
    delete [] inventory;
}

I have two questions about the code above. Mainly, I'm wondering why my delete [] inventory line returning an error. I know it's that line because if I comment it out it doesn't return an error. It only started erroring after I added the second way of displaying the inventory, which brings me to my second question.

Why am I having to use a pointer to a pointer to get the contents of each item in inventory using pointer notation? I don't have any more than 1 pointer in the program and I only have to use a single pointer in the top loop.

After further experimenting before posting this it appears that the pointer to a pointer is also what is causing the error. It's weird though because when I used that notation in the top section without the bottom section added I was no longer receiving the error.

How do you handle different sized sprites in a single image?

10 July 2011 - 08:29 PM

So I've been messing around with SDL with C++ lately and working with animated sprites. I've run into an issue though with sprites that are different sizes in the same image file. I was wondering if any of you had any tips as to how you handle that.

An example of where this problem could occur is say you have walking animations and running animations. In most games, and in real life, most peoples legs do not move as far apart when they walk as they do when they run. Another example is say you have a diving animation for a person. The image would start out wide and short and work itself to thin and tall.

One way I know to handle this issue is to obviously put enough space in the images to make up for the differences. I was wondering if there were any faster methods that could be handled in code, though.

RPG inventory management question

03 July 2011 - 10:38 PM

So I just recently (today) got back in to programming. I started making a text rpg and was working on an item management class and got to thinking about what woyuld be thea most efficient way of loading items. Now I know with it being ascii at the moment there won't be a huge hit to memory regardless. Still, I would like an opinion. Is it more efficient to load every item into memory on startup and point references to them throughout the code when needed and delete the listmoment on program shutdown or is it better to load an individual object for every item in use.

I personally would think the former because it would require less time to load the item information. I you had a huge inventory and multiple of each item it could end up being more memory than loading all items once (or at least the stuff that wont take large amounts of memory).

Maybe its a combination of both. Load the small stuff for everything (stats and such) and load big things (models or images (once I get to that point again)) only when needed.

Also, sorry if parts of this are hard to read. Did this on my phone and the gingerbread update for droids has almost made them as bad as iphones when it comes to auto correct.

looking for a new book...need sugestions

10 April 2006 - 01:47 PM

I read/have "Beginning C++ Game Programming" and I have the "Gametutorials CD" so I have a pretty good understanding of C++ and drawing to the console window and stuff on those lines. I'm looking for a book that teaches win32. The "Gametutorials CD" has quite a few win32 tutorials and I've read through some of them and I understand it; but, I find it so much easier (and comfortable :D ) to lay down and read a book instead of sit in front of the computer screen to read tutorials. So if anybody knows of any good win32 programming books I would really appericiate it. Thanks, Rubiks14

PARTNERS