I've been using stl (and boy is it a time saver!) to handle scene management in my game engine. Well i've decided to add a texture manager for the engine using the map stl.
i'm mapping using a char* (the name of the file) and a LPDIRECT3DTEXTURE8 like so:
map<char*, LPDIRECT3DTEXTURE8> Textures;
well i've got it working all nice and fine execpt when I insert things. Like so:
typedef pair<char*, LPDIRECT3DTEXTURE8> StrTexPair;
Textures.insert(StrTexPair(filename, temp));
//temp is a LPDIRECT3DTEXTURE8 that's been properly created
It crashes with a memory read violation.
I've spent a good time stepping through line by line (even so in the stl code). I've narrowed it down to where it crashes in the stl code when it tries to retrieve the root node and assign it to a temp value (for it's self). The root() function calls the parent() in the stl and they seem to return NULL's just fine (considering the list is empty when it crashes).
i've also changed my map to a list,vector, and queue. they all crash when trying to do the same thing. So my next thought was that LPDIRECT3DTEXTURE8 had something to do with it. i'm i correct in using LPDIRECT3DTEXTURE8? i've even tried using LPDIRECT3DTEXTURE8*, which doesn't work either. So i'm not sure what's up with the memory management on this thing?
Anybody got any ideas?
-Pac
EDIT: boy those source tags can be annoying [edited by - Pactuul on June 3, 2002 2:58:19 PM][edited by - Pactuul on June 3, 2002 2:59:05 PM]
-Pac "The thing I like about friends in my classes is that they can't access my private members directly." "When listening to some one tell about their problem (whether it's code or not), don't listen to what went right or wrong, but what they assumed....."
I was actually trying to use strings, but I forgot to do #include <string> so it was using another form of string. but i fixed that and am using strings.
Still having that problem. I did try changing LPDIRECT3DTEXTURE8 to an int and it works now, so i''m thinking LPDIRECT3DTEXTURE8 is causing the problem. Is it because it''s a pointer?
-Pac "The thing I like about friends in my classes is that they can't access my private members directly." "When listening to some one tell about their problem (whether it's code or not), don't listen to what went right or wrong, but what they assumed....."
No, STL maps can carry pointers fine, and it doesn''t do anything to/with the second type in the map--that''s just dumb data that sits there. Are you sure your textures are valid when you put them in the map? You aren''t releasing them or anything after putting them in the map? It''d help if you show the code where you use the texture that generates an error, e.g. exactly how you get the texture pointer from the map & how you use it. Also, you might want to try logging the texture pointer values when you put them into the map and when you take them out--they should be the same, and if they''re not, maybe you''re overwriting map entries or something. If they are the same, then it sounds like that pointer becomes invalid before you try using it.
damn I feel stupid...that''s odd though, because I had to create a texture correctly or it would fail. Because the first time through the device wasn''t being created so it would create a texture, but I was still hoping it would insert into the list. Well thanks for the help guys!
-Pac "The thing I like about friends in my classes is that they can't access my private members directly." "When listening to some one tell about their problem (whether it's code or not), don't listen to what went right or wrong, but what they assumed....."
Just because I''m curious and once considered something similar, how''s the performance for your map doing? Do you access the map a lot each frame? I was always worried that the map access would be too slow to use frequently, but sometimes it''s much more convenient to reference something by a string-represented name than by a number (array/vector index). If it doesn''t significantly hurt performance, maybe I''ll start using maps more often.
my scene manage is a parent-child relationship. Each object contains a list (stl of course) of all it''s children. I was trying to write my own attaching and detaching and memory handling and deriving objects from them. it was a headache. then I realize I could use the stl lists. In like 1 hr I rewrote the code using it. It actually was faster (probably since mine was not optimized at all), fully functional (I could access and sort things easier) and less code to debug. Also I didn''t have to do type casting as much.
Well so now i''m using maps to handle my textures and my meshs. It was a big boost, since before I was loading in lots of textures and meshes, but most of them are duplicates, so memory usage and loading speeds were horrible. Using maps, it was a lot faster, and it seems pretty efficent too. I like the fact that if you map something with a key that''s already mapped it won''t re-create another texture or mesh.
I''ve been using strings to map the textures and meshs, and it''s a lot easier and cleaner. In terms of speed alone, I think it holds up pretty well.
-Pac
-Pac "The thing I like about friends in my classes is that they can't access my private members directly." "When listening to some one tell about their problem (whether it's code or not), don't listen to what went right or wrong, but what they assumed....."
I think the point IndirectX was making is that it''s a bad idea to use char* as the key type in the map, since this means comparisons are between addresses rather than strings, so a copy of a key, stored in a different character buffer, would not access the correct data. Anyway, if the guy''s changed to using std::string this can''t be the problem.
[edited by - Pactuul on June 3, 2002 2:58:19 PM]
[edited by - Pactuul on June 3, 2002 2:59:05 PM]
