Well, you would probably want a smaller struct; the following is a very contrived example:


Code:
struct {
    int width, height;
    char mapname[32];
    int mapdata[][];
} mapstruct;

int main(int argc, char* argv[]) {
    //...stuff...
    struct mapstruct thismap;
    thismap.width = thismap.height = 32;
    if (0 > (thismap.mapdata = (int**)malloc(sizeof(int)*thismap.height)) {
        fprintf(stderr,"memory allocation error!");
        exit(-1);
    }
    for(i = 0; i < thismap.height; i++) {
        if (0 > (thismap.mapdata[i] = (int*)malloc(sizeof(int)*thismap.width)) {
            fprintf(stderr,"memory allocation error!");
            exit(-1);
        }
    }
    //...code...
    thismap.mapdata[3][15] = 42;
    //...code...
}


Does that give you a basic idea?
KermMartian wrote:
Well, you would probably want a smaller struct; the following is a very contrived example:


Code:
struct {
    int width, height;
    char mapname[32];
    int mapdata[][];
} mapstruct;

int main(int argc, char* argv[]) {
    //...stuff...
    struct mapstruct thismap;
    thismap.width = thismap.height = 32;
    if (0 > (thismap.mapdata = (int**)malloc(sizeof(int)*thismap.height)) {
        fprintf(stderr,"memory allocation error!");
        exit(-1);
    }
    for(i = 0; i < thismap.height; i++) {
        if (0 > (thismap.mapdata[i] = (int*)malloc(sizeof(int)*thismap.width)) {
            fprintf(stderr,"memory allocation error!");
            exit(-1);
        }
    }
    //...code...
    thismap.mapdata[3][15] = 42;
    //...code...
}


Does that give you a basic idea?


Or you can not be an idiot and do it like so (which also happens to compile, which kerm's does not):


Code:
typedef struct mapdata {
   int width;
   int height;
   int *map;
} mapdata;

int main(int argc, char* argv[])
{
   mapdata *data = new mapdata;
   data->width = data->height = 32;
   data->map = (int*)malloc(sizeof(int) * data->width * data->height);
   for (int i = 0; i < data->width; i++)
      for (int j = 0; j < data->height; j++)
         data->map[j * data->width + i] = j ^ i; // obviously set this to whatever real values you have
}
Neutral . . . what?
Kllrnohj, come on, that's basically the same thing. I just have saner addressing into my array of arrays instead of using an array. Razz And of course it doesn't compile since I wrote it in five minutes, but it's functionally correct. Razz Keith, wherein lies your confusion?
Everywhere. Could somebody, like, give me a literal "for idiots" break down of that code that clearly demonstrates just what each line means and how it all works.

I have never seen a struct before in my life and this is halfway above my head Neutral
KeithJohansen wrote:
Everywhere. Could somebody, like, give me a literal "for idiots" break down of that code that clearly demonstrates just what each line means and how it all works.

I have never seen a struct before in my life and this is halfway above my head Neutral
Well, there's defining what the structure of the struct looks like first, a sort of prototype that defines what any particular struct of this type will contain and how much memory it needs. Then you can create structs of that type and populate them. That's really all you need to know.
KermMartian wrote:
Kllrnohj, come on, that's basically the same thing. I just have saner addressing into my array of arrays instead of using an array. Razz And of course it doesn't compile since I wrote it in five minutes, but it's functionally correct. Razz Keith, wherein lies your confusion?


Hey, you would have done the same :p

And yours has several problems, the biggest is that "int mapdata[][]" isn't legal, you can't declare that. You can only do a multidimensional array like that if the sizes are constant. The second is that you have a bunch of memory allocations that are *all wrong*. When you do "int mapdata[][]" (assuming you used it legally and gave it a constant size), it is created as a single memory block. What you were thinking of is "int* mapdata[]" (aka, an array of pointers).

@Keith: If you couldn't understand Kerm's or my code, go read a C/C++ tutorial. I'm not here to teach "idiot's guide to C/C++" (and let's get this out of the way, C/C++ is *hard*)
Struct question.

Say I have two different variables of the same struct type. Could I store the values of one struct to the other?

e.g.

Code:
struct blah {
  int x;
  int y;
}


At some point I have declared blah Foo and blah Bar
Can I do:


Code:
Foo = Bar;


or is that wrong?
I recall that in my compiler, struct = struct was correctly expanded in the assembly code to do a bytewise copy between the structs. If I did it, I'd imagine that full compilers do too.
Okay, so my game is (predictably) running much faster on my 3.2 GHz desktop than on my 1.6Ghz netbook. My character moves 2, perhaps 3 times faster on the desktop.

I'd prefer to limit this speed but I'm not exactly sure how. My thought was to use a timer of some kind to "regulate" how fast the engine iterates.
TsukasaZX wrote:
Okay, so my game is (predictably) running much faster on my 3.2 GHz desktop than on my 1.6Ghz netbook. My character moves 2, perhaps 3 times faster on the desktop.

I'd prefer to limit this speed but I'm not exactly sure how. My thought was to use a timer of some kind to "regulate" how fast the engine iterates.
Don't try to limit the number of engine ticks or even frames; that's just going to cause you problems down the road. You should, however, use some kind of timer-based method to control character and world movement, so that events will more or less happen respective to the wallclock time rather than the CPU time.
Could you elaborate a bit more, please?
TsukasaZX wrote:
Could you elaborate a bit more, please?


This goes back to what I was saying earlier. You need to use wall-time to control animations and game events.

There are exactly 12890378120381203 tutorials on the internet explaining that in painstaking detail.
I was more or less wondering what problems my original, horrible idea would cause me down the road. I know how to JFGI when it comes to concepts.
TsukasaZX wrote:
I was more or less wondering what problems my original, horrible idea would cause me down the road. I know how to JFGI when it comes to concepts.
If you try to arbitrarily limit engine ticks, you could have it suddenly unplayably slow on old or slow hardware where without your modifications it would run fine, for instance. And regardless, any approach other than the proper one wouldn't make the engine speed independent of the clock speed (and scheduling from the kernel!) of the machine.
A couple questions about storing information:

What would be the best format for a "save file", a way of storing important game data so the player can save and resume at any time?

What would be the best way to store a game's dialogue?
Save file: I'd go with "encrypted" text file or registry keys, far preferably the former over the latter. I say "encrypted" so it's no totally obvious how to modify them to give yourself infinite stats or all the items or something. I'd say whatever structure in the file makes the most sense for you; you'd have to have things like health and the other bar, location, items, events that had been triggered already, etc.

Game dialog: I'd personally go with a single text flat-file, one line of dialog per file line, that you load into an array when the game starts. Perhaps you could prefix each line with some marker indicating where it's spoken and who says it?
KermMartian wrote:
Save file: I'd go with "encrypted" text file or registry keys, far preferably the former over the latter. I say "encrypted" so it's no totally obvious how to modify them to give yourself infinite stats or all the items or something. I'd say whatever structure in the file makes the most sense for you; you'd have to have things like health and the other bar, location, items, events that had been triggered already, etc.
Registry entries are bad, because then it's impossible to move the save file from one PC to another unless the registry is tampered with. Of course, if the purpose is to make it impossible to move the save file, the registry is good, but users don't like restrictions...
It also makes it harder to port the game, which was the primary concern of which I was thinking when I discouraged it, but you make a very good point.
I might be a newcomer, but even I think a registry-based save system is bad practice. Razz

Hmm, creating my own method of "encryption" sounds like fun. As for the flat text file, that gives me a great idea. Thanks! Smile
  
Register to Join the Conversation
Have your own thoughts to add to this or any other topic? Want to ask a question, offer a suggestion, share your own programs and projects, upload a file to the file archives, get help with calculator and computer programming, or simply chat with like-minded coders and tech and calculator enthusiasts via the site-wide AJAX SAX widget? Registration for a free Cemetech account only takes a minute.

» Go to Registration page
» Goto page Previous  1, 2, 3, 4, 5, 6  Next
» View previous topic :: View next topic  
Page 2 of 6
» All times are UTC - 5 Hours
 
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum

 

Advertisement