Sign in to follow this  

fstream, memory, and speed

This topic is 3629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Hey, I've half created a SNES zelda-like game and the way I programmed in blocks and spikey floors and links to other maps through doors and caves was to have a file corresponding to that map with 2 bytes to correspond to each 16x16 pixel block. (Game is 1024x768 pixel screen, 64x48 blocks) So the way I'm doing it now works, I'm just starting to wonder if I did it the dumb way. See when I started I figured I'd have a 2D array that held like 54 Kilobytes. (54K would hold a map that was 3x3 screens. 64*48*3*3) But I any program I tried to run with a 54K static array would crash. So eventually I completely abandoned loading my files into memory and the way it works now is that the program interacts with the map file all the time (and it works great). I can have almost 1000 monsters who's only interaction is to check for walls and I have no slow down. But every time the monster moves it checks to see if it's moving to the next block and if it is then the program infile.seekg's to the right block and reads in two bytes and checks it. I know file I/O isn't the fastest. So is there a smarter way to do what I'm doing? Why can't I make a massive array? I know a 54 Kilobyte array is huge but I have hundreds of Megabytes of RAM what does my computer care if I have a 54K array? If arrays don't work is there some way to malloc 54K of memory and just dump all the bytes from my file into it and access it from memory from that point on? Eric

Share this post


Link to post
Share on other sites
There is a saying in computer science, write code first, optimize later. For writing a zelda game I doubt it matters too much how you do it, it should still be plenty fast. A fast implementation, however, in my mind would do something like this:





struct Map {

struct Screen {

struct Tile {
// tile data goes here
};

Tile tiles[64][48]; // multidimensional array ok here because it is fixed
};

unsigned int width, height;
Screen *screens;

Map(std::istream &in); // populate the map

private:
Map();
};

// ... later





Share this post


Link to post
Share on other sites
If you post the code where you create, fill, and access the array you were trying to use we can tell you what you were doing wrong. Shouldn't be any problem with a 54K array.

Share this post


Link to post
Share on other sites
If the array is encapsulated in a struct and he passes it by value he will create temporary copies of that array on the stack (which could cause an overflow quite rapidly).

Personally i would suggest that he allocates it on the heap instead, (but seeing some code would be nice, a 54KiB array by itself shouldn't be a problem, (but its probably not the only thing he has on the stack, those things can add up quite rapidly, especially if he uses recursive functions somewhere)

Share this post


Link to post
Share on other sites
Hey you're right a 54K array is no problem at all on my g++ compiler. I just made an array over 5MB. I used to have that problem on VC++ 6.0 I just assumed I couldn't ever make arrays that big and didn't try it again, oops.

Well I guess I'll keep reading from the file for now and if it's ever too slow I'll just use a good ol' 2D array.

Man, I don't know what a heap or a stack is. Well I know what a stack is. I think you're talking about the stack in memory and I don't know anything about it. I don't think it matters for me now but thanks. I'm trying to keep moving forward and only stopping to learn when I get stuck. Learning sucks. Just kidding I just don't want to lose momentum I like making progress every day with 15 minute learning pitstops. I'll learn what a heap is some other day.

Share this post


Link to post
Share on other sites
The stacks is holds the local variables of functions and the arguments passed to them, and is usually a small fixed size, a few megabytes tops. You generally only want small thing here, like numbers and pointers to things.

The heap holds global variables and dynamically created things (via new, malloc, etc) and is huge.

Share this post


Link to post
Share on other sites

This topic is 3629 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this