TPC memory problem - GameCreators Forum

Author

Message

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 18th Apr 2007 11:26 Edited at: 18th Apr 2007 11:29

Link

I'm coding a TPC using DirectX sprites, and I have some problems with the memory.

Here is the original sprite :

And when it's loaded n times and displayed (black rectangles on the left are extracts from sprites, don't take care of them) :

The numbers displayed on the right are the pointers to sprites datas. As you can see there's some pointers different from others that don't display the sprite.

In bold, pointers to a correctly displayed sprite :

21839232
21839392
21839552
21839712
21833280
21833440
21833600
21833760
21833920
21834080
21834240
21834400
21839880

My code works when used in C/C++ coded application, but when used as TPC with DBpro, there is this problem. I suppose the problem comes from DBpro...

Is there a limit to the memory allowed to a TPC ? How is this memory allowed ?
And how can I have normal memory management with DBPro ?

Back to top

Profile PM Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 18th Apr 2007 20:48

Link

When you say C/C++ coded applications, is this done using DGDK? If your creating a TPC plugin via DBPro DLLs instead, both the DGDK and DBPro dlls will differ slightly in terms of engine code. Can you clarify what you mean?

Also, if you can provide a small snippet of code to show how you're displaying the sprites and how you're obtaining the pointer addresses, it may be something as simple as a problem with pointer arithmetic or something, if you're using them directly to display the images.

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 19th Apr 2007 20:42 Edited at: 30th May 2007 20:56

Link

No, when I say C/C++ coded application, it's using DirectX9 SDK (April 2006). My DLL code is just reused into a Win32 application to test differences between this app and the DLL when it's used with DBPro.

Here is some code from the DLL. I'm really bored that this problem still exist after weeks and weeks of tests to find a solution, so, yes I can show it ^^.

I use a structure to contain sprites datas :

+ Code Snippet

Code deleted

Then pointer & sprite creation :

+ Code Snippet

Code deleted

Sprite display (just one of the functions I created to dispaly a sprite, there are functions for sprite tile display, sprite rectangle display, etc... The code doesn't vary a lot) :

+ Code Snippet

Code deleted

Begin/End for the sprite that have to be rendered are functions called from DBPro. Of course, when I uses these in DBPro, there's only sprite displaying between begin and end). I've tried to include these two function in a sprite display function, but that doesn't work more :/ :

+ Code Snippet

Code deleted

In the string table, these four functions looks like this :

+ Code Snippet

Code deleted

Visual C++ Express 2005 say me that there's a pointer truncation when I convert a M2ESPRITE* to a long (L in string table). The only integer type without truncation is the LONGLONG (R in string table), but all crashes when I use a LONGLONG as output/input parameter.

Note that when I allocate an array of M2ESPRITE* at the initiazing, all works... It's the only alternative I've found, but not powerful, it must be decided how many sprites may be create :/.

Back to top

Profile PM Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 20th Apr 2007 03:08

Link

Ok, just saw the reply, lemme digest the code to see if I can spot anything...

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 21st Apr 2007 05:03

Link

Mod, I've been trying to analyze your posted code snippets, but I can't honestly see what's going on. I will ask that I've not seen what the Draw method does since this was partially used as part of the rendering pipeline, but I can only assume that there is some kind of pointer wrapping going on, and hence, invalidated memory address space is being pointed to when calling the draw method.

But even if it is a DBP issue, it seems to most likely point to a pointer irregularity. Any possibilities on the above?

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 21st Apr 2007 12:38 Edited at: 30th May 2007 20:57

Link

(I've not totally understand your message, maybe will I answer a little wrong...)

In DBPro, a simple program with my TPC looks like this :

+ Code Snippet

initialize m2e d3d

pSprite = dxs create sprite("sprite.png")

do

dxs begin sprite render pSprite
dxs draw sprite pSprite,50,50
dxs end sprite render pSprite

loop

There's just one function before calling dxs create sprite :

+ Code Snippet

Code deleted

lpDirect3DDevice9 is global LPDIRECT3DDEVICE9 variable.

If it's a pointer problem, I don't know where it's located. I have functions that return sprite width, height, scale, etc, with no bug, even if the sprite is not displayed. It's only the LPD3DXSPRITE variable in M2ESPRITE structure that seems to cause problem.

There's too these strange variation with M2ESPRITE pointers :

+ Code Snippet

21839232                                ok
21839392 (+ 160)                        ok
21839552 (+ 160)                        ok
21839712 (+ 160)----------|             ok
21833280 (- 6432)         |             x
21833440 (+ 160)          |             x
21833600 (+ 160)          |             x
21833760 (+ 160)          |             x
21833920 (+ 160)        (+ 168)         x
21834080 (+ 160)          |             x
21834240 (+ 160)          |             x
21834400 (+ 160)          |             x
21839880 (+ 5480) <-------|             ok

160 is the size in bytes of an M2ESPRITE variable. I don't understand why there are these two big variations, - 6432 and + 5480 in the memory. In a C/C++ application, there are not. That's why I've guessed that the bug may comes from the allocation.

Thanks for trying to help me ^^

Back to top

Profile PM Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 21st Apr 2007 18:32

Link

Mod,

Can you modify your function as follows:

M2ESPRITE* DXS_CreateSprite(LPCSTR spriteFichier)
{

// Allocation de mémoire et création du sprite. (Allocate memory for each sprite)
	M2ESPRITE* sprite = (M2ESPRITE*) malloc(sizeof(M2ESPRITE));
	if( !SUCCEEDED( D3DXCreateSprite(lpDirect3DDevice9, &sprite->sprite ) ) )
	{
		free( sprite );
		return NULL;
	}

// On remplit les données du sprite créé par des valeurs correctes.(Fill sprites datas with correct value)
	sprite->alpha =	255;
	sprite->rouge =	255;
	sprite->vert =	255;
	sprite->bleu =	255;
	sprite->scale.x = 1;
	sprite->scale.y = 1;
	sprite->center.x = 0;
	sprite->center.y = 0;
	sprite->angle = 0;

// création de la texture à partir des paramètres obtenus (Texture creation from an extern file)
	if( !SUCCEEDED( D3DXCreateTextureFromFileEx(	lpDirect3DDevice9,			// Device Direct3d utilisé.
													spriteFichier,				// Fichier image utilisé pour créer le sprite.
													D3DX_DEFAULT,				// Largeur sprite prise comme celle du fichier.
													D3DX_DEFAULT,				// Hauteur sprite prise comme celle du fichier.
													1,							// Niveaux de mipmap en provenance du fichier.
													0,							// Type de ressource.
													D3DFMT_UNKNOWN,				// Format de l'image à charger.
													D3DPOOL_MANAGED,			// Positionnement de l'image dans la mémoire.
													D3DX_FILTER_NONE,			// Filtre d'image.
													D3DX_FILTER_NONE,			// Filtre de mipmap.
													spriteTransparence,			// Couleur transparente : blanc.
													&sprite->info,				// On récupère les infos sur la texture créée.
													NULL,						// Palette de couleur non récupérée.
													&sprite->texture) ))		// Pointeur vers la texture.
	{
		free( sprite );
		return NULL;
	}

sprite->tile.x = sprite->info.Width;
	sprite->tile.y = sprite->info.Height;

return sprite; // I've ever supposed that the problem may come from this return, but don't find any type that can replace M2ESPRITE* type without crash under DBPro...
}

// Retourne un pointeur

+ Code Snippet

M2ESPRITE* DXS_CreateSprite(LPCSTR spriteFichier)
{

	// Allocation de mémoire et création du sprite. (Allocate memory for each sprite)
	M2ESPRITE* sprite = (M2ESPRITE*) malloc(sizeof(M2ESPRITE));
	if( !SUCCEEDED( D3DXCreateSprite(lpDirect3DDevice9, &sprite->sprite ) ) )
	{
		free( sprite );
		return NULL;
	}

	// On remplit les données du sprite créé par des valeurs correctes.(Fill sprites datas with correct value)
	sprite->alpha =	255;
	sprite->rouge =	255;
	sprite->vert =	255;
	sprite->bleu =	255;
	sprite->scale.x = 1;
	sprite->scale.y = 1;
	sprite->center.x = 0;
	sprite->center.y = 0;
	sprite->angle = 0;

	// création de la texture à partir des paramètres obtenus (Texture creation from an extern file)
	if( !SUCCEEDED( D3DXCreateTextureFromFileEx(	lpDirect3DDevice9,			// Device Direct3d utilisé.
													spriteFichier,				// Fichier image utilisé pour créer le sprite.
													D3DX_DEFAULT,				// Largeur sprite prise comme celle du fichier.
													D3DX_DEFAULT,				// Hauteur sprite prise comme celle du fichier.
													1,							// Niveaux de mipmap en provenance du fichier.
													0,							// Type de ressource.
													D3DFMT_UNKNOWN,				// Format de l'image à charger.
													D3DPOOL_MANAGED,			// Positionnement de l'image dans la mémoire.
													D3DX_FILTER_NONE,			// Filtre d'image.
													D3DX_FILTER_NONE,			// Filtre de mipmap.
													spriteTransparence,			// Couleur transparente : blanc.
													&sprite->info,				// On récupère les infos sur la texture créée.
													NULL,						// Palette de couleur non récupérée.
													&sprite->texture) ))		// Pointeur vers la texture.
	{
		free( sprite );
		return NULL;
	}

	sprite->tile.x = sprite->info.Width;
	sprite->tile.y = sprite->info.Height;

	return sprite; // I've ever supposed that the problem may come from this return, but don't find any type that can replace M2ESPRITE* type without crash under DBPro...
}

// Retourne un pointeur

At the moment, I can only assume that one or more of the DX functions is failing. Even though you're returning valid pointers, which may well be allocated in different locations, so you can't assume that they will all be sequentially allocated every 160 bytes.

If the DX functions are failing, your sprites will obviously not draw.

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 22nd Apr 2007 19:21

Link

Here is the result :

It seems that's not a sprite creation problem. Ireally wonder from wher's coming this bug.

Back to top

Profile PM Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 24th Apr 2007 19:59

Link

More informations about my problem...

I've compiled my TPC using the Multi-threaded Debug DLL... And all seems to work in a normal way, sprites are well displayed.
I don't know a lot about all Visual C++ Express options. I begin to think that the error may come from compilation parameters.

here is how is actually set the Code Generation :

Any error ?

Without this Debug Dll, I've found new informations.

When I replace this line :

+ Code Snippet

sprite->sprite->Draw(	sprite->texture,NULL,&sprite->center,&sprite->position,D3DCOLOR_ARGB(sprite->alpha,sprite->rouge,sprite->vert,sprite->bleu));

By this one :

+ Code Snippet

sprite->sprite->Draw(	sprite->texture,NULL,NULL,&sprite->position,D3DCOLOR_ARGB(sprite->alpha,sprite->rouge,sprite->vert,sprite->bleu));

Here is what I get :

Instead of this :

Each time I put back the original command, two sprites disappeared, and when I put the NULL, they appeared...

So, I added to the DBpro code the command that return the sprite center...
With the NULL, I get this :

And without, this :

I'm getting mad... I understand nothing between the modification and its effect. I can't guess where's the bug coming from. The only thing I can suppose is that it is related to the Draw method.

Back to top

Profile PM Website

IanM

Retired Moderator

22

Years of Service

User Offline

Joined: 11th Sep 2002

Location: In my moon base

Posted: 24th Apr 2007 23:14

Link

I can't fix your problem - the fact that it works differently in debug and release modes point to the fact that somewhere you are trashing the memory.

Next, the 'pointer truncation' warning is simply that - a warning. If you go to the C++/General property page and switch off the 64bit warnings, then that warning will disappear. It's meant purely for writing code that needs to run in both 32 and 64 bit mode - your plug-in will only need to be 32 bit.

I can also state that the memory offsets for your pointers are meaningless - you can't tell whether your program is acting correctly or not from their values. In fact, I'd be very surprised if they didn't jump around a little.

Without seeing more code, we're not going to spot anything. You'll need to either post the code here, or send a copy of your project to Paul or myself to take a look at - we're both trustworthy ... honest

For free Plug-ins and source code
http://www.matrix1.demon.co.uk
New Utility plugins collection

Back to top

Profile PM Email Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 25th Apr 2007 12:44

Link

I've sent you and APEXnow the code source of my TPC,a small DBPro code and a compiled DLL... I hope you'll can find the bug !

Back to top

Profile PM Website

IanM

Retired Moderator

22

Years of Service

User Offline

Joined: 11th Sep 2002

Location: In my moon base

Posted: 25th Apr 2007 19:41

Link

Fixed, and on its way back to you

For free Plug-ins and source code
http://www.matrix1.demon.co.uk
New Utility plugins collection

Back to top

Profile PM Email Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 25th Apr 2007 20:12

Link

LOL, Nice work Ian. I only just got in from work and saw the email, and then came here. What was the problem?

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

IanM

Retired Moderator

22

Years of Service

User Offline

Joined: 11th Sep 2002

Location: In my moon base

Posted: 25th Apr 2007 20:53

Link

The structure wasn't being initialised correctly. I just added a memset after the allocation. Oh, and the sprite structure wasn't being free'd when the sprite was being deleted either.

For free Plug-ins and source code
http://www.matrix1.demon.co.uk
New Utility plugins collection

Back to top

Profile PM Email Website

APEXnow

Retired Moderator

21

Years of Service

User Offline

Joined: 15th Apr 2003

Location: On a park bench

Posted: 25th Apr 2007 20:57

Link

Nice work

Paul.

Abundance = Choice = Freedom - Scarcity = Dependancy = Control, Truth!

Back to top

Profile PM Email Website

Mod

19

Years of Service

User Offline

Joined: 8th Oct 2005

Location: France

Posted: 26th Apr 2007 12:48

Link

Great, it works really fine, now !

Thanks a lot, IanM !

I'll be able to release the DLL after few more tests

(I'm really a noob for the memory leak ^^")

Back to top

Profile PM Website

Sorry your browser is not supported!

DLL Talk / TPC memory problem