DX7 And Modules...Bad performance

[git]

Hi all,

I've just done major work on my game, which is a Direct X 7 game (originally just Direct Draw, but I've added Direct 3D to it too to have nice drawing effects). I previously had around 8000 lines of code in one form - it was simply a mess to work with. So I started playing around with class modules, and found them to be slow when it came to having many copies of objects. For instance I had a class module which served as a Direct X 7 surface template, containing the Direct X 7 surface, the surface width/height as longs, surface name, etc.. After I'd created many instances of it things got very very very slow.

That didn't work, and I still needed to clean things up, so instead of using class modules, I decided to just use normal modules. I dumped all 8000 or so lines of code into 25-30 seperate modules, including special modules which contained DirectX related functions, for example I have a Direct Draw module containing a function which loads surfaces for me when I give it the surface object and various information about it (width, height, filename/filepath, colour key information, etc.). After a lot of debugging, renaming of variables, and various work, I managed to get everything working well - or at least I thought I had.

One catch - my game requires around 500 seperate graphic tiles to be loaded. Originally in the first complete version of the game, each of these tiles was stores on a surface size of ?x120 pixels (where ? is any size, usually between 50 and 100 I guess). This was not a problem, as the original version of the game I achieved very good performance (running 640x480x16). For this version of the game, I was able to cut redundant graphics, and get the size down to ?x40. I thought everything was going to run very fast, but when I goto load the tiles, my program seems to chew up a lot of memory, and gives me an error message a bit over half way in of loading the surfaces. I get an error of either 'File not found' or 'Invalid procedure call or argument' on the line where Direct Draw creates the tile surface (BTW these are normal 2D surfaces, not 3D - I'm using D3D for other graphics...).

Anyhow, here's what I think is part of the problem. I have a module which contains an array/type for tiles, which contains the surface. This is an example of what is in the tile module.

Public Tiles() as TileType

Public Type TileType
    Surface As DirectDrawSurface7
    Width As Integer
    Height As Integer
    TileType As Integer
    'Etc.
End Type

I created another variable/array in another module (the Direct Draw functions module) as a surface (not the TileType type above) and tried loading the tiles, and it loaded them fine. I then tried testing it the same way, back in the tile module, and it produced the original error again.

BTW the errors produced can't be because of wrong declarations or missing files. Whenever the errors pop up, VB's window (and the rest of Windows) looks like all the resources are drained. As I said, the surfaces I create are still Direct Draw types, even though I'm using Direct 3D too.

So, any ideas on how to get around this? I'd appreciate any help on this one - I'm really confused what could be causing it (pretty sure it's related to using modules), and how to fix it! I hope I explained this issue correctly and didn't confuse anyone. =)

Oh, BTW, I am loading all surfaces through function in the Direct Draw module I made which I said about above...

Thanks,

-Git

[git]

BTW I just realised, could it be because I'm passing entire surfaces to functions? The function which sets up surfaces needs a surface (as the DirectDrawSurface7 type) as input - if this function is being used by different modules, to pass blank surfaces and file/path information for the surface be created, could this be depleting a lot of resources? If this is the case, what should I do in the future, just avoid passing massive amounts of data to functions? Although would a surface (which has only been declared, not set up at all) be that big? Or would there be a lot of processing needed to pass the completed surface back out of the function...?

[Janus]

The DirectX documentation says not to create multiple instances of DirectDraw7 or DirectX7 - make sure you're not doing that.

[git]

Thanks for the reply. Nope, just checked and there's only two declarations of it. One is in another form which grabs the acceptable resolutions/depths for the user to pick, and after it gets the states it nulls out DD's value. The other dec. is for the game itself.

I'm starting to think it's probably the function... I'm going to run some tests and see if it is indeed the function/module which is chewing up all the memory.

[Arbiter]

Try and combine some of those 500 graphics tiles.

Sentience has hundreds, but they're grouped into clumps and then referenced by co-ordinates. Means a bit more maths but a hell of a lot less memory.

Might help you....

[Arbiter]

PS - I can't even spell DirectX but I thought I'd post some form of advice...

You might be better posting some code as Janus and Zaei are both BX wizards (to my knowledge...)

[git]

Yup, I did originally have all the tiles/blocks in 640x480 surfaces, but I think there was some reason why I had to seperate them... I can't remember now (I changed that probably 6-8 months ago).

Anyhow, I tried to test the function by constantly creating surfaces into an array, which I'd Redim Preserve and increase in size. It kept going, and going, and going (up to like over a thousand tiles). When I hit Stop it did take a while to unload though... I thought that was quite strange, that it'd keep going without running out of memory, so I tried the code for loading the tile graphics again as normal, and it worked, no problems. Wierd, eh? It's really puzzling as to why it's working now... Ohwell, I'm not complaining.

Thanks for helping guys! =)

[Arbiter]

It'd probably be making the biggest swapfile known to man.

Still, as long as it works eh....