My structures looked a little like this (except I have vertices seperated from polys):

typedef struct
(
int x,y,z;
) pt;

typedef struct
(
pt pts[30];
} poly;

typedef struct
(
poly polys[30];
) object;

typedef struct
(
object objects[300];
) world;

world map;


"Seems like you wrote some simple programs and tried jumpstart into a full game without having the needed knowledge."

I've only been learning C++, Win32 etc.. for a little over a year. I used to do a lot of programming in Basic / Pascal / COBOL / C as a general interest of mine and also my studies, but never in Windows.

I did write a simple program - my first 3D-engine (texture-mapping, but no collision detection, lighting or anything real fancy) which although very basic did at least give me a good understanding of 3D-theory like clipping, transformation, matrices, cameras etc..

I haven't learnt C++ formally, so I don't know much about OOP or dynamic memory allocation, but I have been able to get by up until now. I just overhauled my program, to support objects because the old version only dealt with single polygons, and I also started turning the engine into a level editor so I don't have to create objects manually). I was doing o.k. until this out of memory error.

I do have some books on OOP so I probably should make an effort to learn it - something I have been putting off - it's hard enough learning about Windows message handlers, handles, instances, Direct Input, graphics APIs, 3D, etc... without having to dive head-first into OOP (at least for a procedural programmer like myself).

"I don't think you should make your game require 12 GB RAM so early, maybe in some years, but not now."

Hey, why not? double

Paulcoz.

Edited by - paulcoz on November 23, 2000 9:18:32 PM

quote:

---

I haven''t learnt C++ formally, so I don''t know much about OOP or dynamic memory allocation...

---

FYI, dynamic memory allocation is not something new with C++. It existed in C as well, though it was a slightly different beast. malloc () and free () (and realloc ()) were the dynamic memory-managing routines in C. The only difference between the C and the C++ way of doing things are:
- there is no realloc (maybe a good thing)
- in C, malloc required you to specify the size of the object in bytes, and would always return a void* you would have to cast to your new object. In C++, you just use the new operator of the object type.
- in C++, new and delete will call constructors and destructors. No such thing in C.

That''s really the only difference, so hopefully you can get things going.

Why, may I ask, are you so determined to have everything in the executable instead of loading it from a file into dynamic memory?

I don't intend to have everything in the executable forever (I honestly didn't know that that's how the memory was allocated). I have a couple of polys hard-coded in the .exe at the moment so that I can work out my map structure, and design some simple tools to add objects to, and manipulate objects in, the map.

I do intend to use dynamic memory allocation now that I know that not using it causes that awful error message, and of course I will load the map data from a file eventually.

Paulcoz.

Edited by - paulcoz on November 28, 2000 1:32:33 AM

I''m sorry for the more-or-less useless post, but this is funny, maybe because it''s so late...

I appluad you''re courage for posting your code

quote:

---

map.objs.obj[0].polys.poly[0].vts.vtx[0].x

---

by my calculations you''re using 4,357,200 bytes with that thing
Which is a lot, but doesn''t explain why vs thinks its 2GB...

> It's o.k. to redefine a structure in another file isn't it?

Well it depends, if you meen using the same name for a structure in different source files, then yes absolutely - providing you can still follow source code and not get confused about about which version of the structure you're using.

But defining a global variable this way is bad news. I've seen a lot of code which lists a whole load of externs at the start of each file C/CPP file. Which is prefectly legal C, but as a program grows causes problems since every time a structure changes you have to modify more and more source files to keep the multiple definitions in sync.

The worst case of mismatching extern's I've seen (not im my code ofcause ) is where a variable was sometimes extern'd as an int and other times as float - this generated "one or two" bugs which were a real headache to fix.

The best thing to do is use headers - define the structure in the header, and add an extern for each of your global varaibles. Make sure you include the header in source file were the variable gets allocated - that way any difference between your extern (which is what most of your code see) and its declaration will be picked up at compile time.


The other little nugget of info I can give you is NOT to declare data in headers, eg. Suppose you have the follow declarations in different source files (or header files for that matter)...

int my_var=42;

and

int my_var=99;

Assuming the linker doesn't throw out a multiply defined symbol error message, which one gets used?

Answer: Probably the one in the source file which is included by the linker first, but that's not guaranteed.
The best solution is to have "extern int my_var;" in a header and declared the variable in a single source file as "int my_var=42;"


Edited by - Beelzebub on November 28, 2000 3:16:06 AM

Magmai,

I take it none of you have found the need to have imbedded structures with that many levels? In what way do you read all of your world data into a map then, and keep everything in a logical order? I am hoping I can rewrite my program so that it takes advantage of dynamic memory allocation (keeping those basic structures), but those imbedded structures are no good? I actually thought I had a really good way of referring to all the objects in my world and the polys associated with those objects, and the vertices associated with those polys.

"I applaud you''re courage for posting your code"

I don''t think it has anything to do with courage - I''ll be the first to admit there is a hell of a lot I don''t know about C/C++, and I am not afraid to ask for help so that I can become a better programmer.

I have always tried to use the knowledge that I do have to best effect, and up until now I have been able to get by. I mean to say I don''t think I am a bad programmer, I am an inexperienced programmer - I lack a lot of knowledge about what these later languages are capable of and how they work, and I don''t do stupid things because I''m dumb, I do them because I don''t know of any other way with my comparatively limited skills.

Paulcoz.

I suggest using classes which have private dynamic lists and an interface.

e.g.
class TMap
{
public:
TMap(){list = new TList;};
~TMap(){delete list;};

//the interface
inline TObject* GetObject(int index)
{return (TObject*)list->Items[index];};

inline int NewObject(){return list->Add(new TObject);};
inline void DelObject(int ind){list->Del(index);};

private:
//the dynamic lists, that holds your objects
TList *list;
};

I always use the VCL-list, but you can of course also use
use the std::list.

TObject is a class, organized the same way as class TMap. It also has an interface and a private list, that holds your polys.
and so on...

Like that, you get an optimal way to control your structure.
You could add public Save() and Load() functions to your classes, passing a pointer to an if/ofstream. So you can save/load your file. And inline your interface!

Or do you other guys have better ideas? (I'm interested)
I think, this is good OOP, isn't it?

HTH Wunibald



Edited by - Wunibald on November 29, 2000 4:48:08 AM

Edited by - Wunibald on November 29, 2000 4:51:10 AM

Edited by - Wunibald on November 29, 2000 4:53:00 AM

I forgot to say thanks to everyone who replied with their ideas -Thankyou

One thing this has cleared up for me - I thought dynamic memory allocation was some sort of new C++ only method that I really dreaded learning, but it's actually just a matter of getting a pointer to a free memory block, keeping track of which areas of memory you've put things in, and releasing those you don't need. I thought it was more complicated than that, so thanks for clearing that up.

Paulcoz.

Edited by - paulcoz on November 30, 2000 12:50:10 AM