Level Planning

Level Planning

Edgar Reynaldo

Major Reynaldo

May 2007

abraker95 said:

But there should be a way init a dynamic array with a list.

EDIT: Nevermind I found the solution myself while playing around with type casting:

 int *XPOS; XPOS= new int [level->total_tiles];
     XPOS=(int []){0,   44,  88,  132, 176, 220, 264, 308, 352, 1000, 0,   44,  88,  132, 176, 220, 264, 308, 352, 1000};

That little snippet of code you posted there leaks memory. The value returned by new [] is never delete []'ed. There is no way to initialize an array created with new. You can loop over its elements and set a value for them, but each element is always initialized with the default constructor for the type you are using.

Also, if you know the size of the array at compile time, then you don't need to use new on it, just declare it normally :

int intarray[3] = {0,1,2};

abraker95 said:

I have a new problem now; drawing the backround takes ALOT of processing time since the for loops take time to go through the drawing. Is there a way to optimize this?

If the background never changes, then you should only draw it once. Other things to do include only drawing on screen objects.

Eagle and Allegro 5 binaries | Older Allegro 4 and 5 binaries | Allegro 5 compile guide
King Piccolo will make it so Then I could just flip it with some sweet, sweet matrix math. In either case, I’ll ride this wagon until the wheels fall off. Thanks to those that keep it running

abraker95

Member #11,800

March 2010

No, there's delete in the a function later on (in destroy_level()). I needed to do that because the number of elements in that array is a variable; some levels have more or less tiles than others.

EDIT: I checked it with Task Manager IT DOESN'T LEAK MEMORY... but something in the menu
does... :-/

I have to update the background since what ever is drawn on top of that (like the character and enemies) will just erase whatever was there before, having the need to redraw it.

Edgar Reynaldo

Major Reynaldo

May 2007

int array[3] = {0,1,2};
int* i = new int[16*1024*1024];
i = array;

That is exactly what you are doing, and in my example, it will leak exactly 64MB of memory. Also, if you are calling delete on a compile time array, that is wrong.

abraker95 said:

I have to update the background since what ever is drawn on top of that (like the character and enemies) will just erase whatever was there before, having the need to redraw it.

No you don't have to update the background, you have to update the buffer :

BITMAP* buffer = create_bitmap(SCREEN_W , SCREEN_H);
BITMAP* bg = load_bitmap("bg.bmp" , NULL);
// draw other background stuff on bg here


// LATER, in drawing loop
blit(bg , buffer , 0 , 0 , 0 , 0 , bg->w , bg->h);
// draw characters
blit(buffer , screen , 0 , 0 , 0 , 0 , buffer->w , buffer->h);

abraker95

Member #11,800

March 2010

Edgar Reynaldo said:

That is exactly what you are doing, and in my example, it will leak exactly 64MB of memory. Also, if you are calling delete on a compile time array, that is wrong.

What do you mean by compile time array?

Quote:

No you don't have to update the background, you have to update the buffer

It looks like you are saying to put the background on a bitmap that has a 1 whole image instead that you have to redraw instead of lots of smaller ones... Unless
my for loop slows down the operation, it's like this:

P=NP=T

P - total number of pixels need to be drawn
N - the number of bitmaps need to be drawn
T - the time it needs to draw it all

EDIT:
I've TOTALLY forgot about blitting (I was using draw_sprite). It sped up my game ALOT

Now 2 questions:
1) Which is faster; returning a value form a function or passing it to the variable you want to assign it to through a parameter?
2) I have a mem leak in the update_menu or its contents, I looked it a hundred times, but I can't find what's wrong. The leak occurs when I change from menu to menu (but not into the game).

Edgar Reynaldo

Major Reynaldo

May 2007

abraker95 said:

What do you mean by compile time array?

int array1[3] = {0,1,2};// compile time array

int* array2 = new int[3];// run time array

delete [] array1;// bad, wrong, don't do it

delete [] array2;// good, fine, make sure to do it

abraker95 said:

1) This is not worth your time to figure out. They are most likely the same for all intents and purposes.

2) Run each menu 1000 times, noting the memory use before and after it runs. That should tell you which menu is leaking memory.

LennyLen

Member #5,313

December 2004

Edgar Reynaldo said:

2) Run each menu 1000 times, noting the memory use before and after it runs. That should tell you which menu is leaking memory.

Or, if you're using Visual Studio, you can try this.

abraker95

Member #11,800

March 2010

Quote:

int array1[3] = {0,1,2};// I'm not using this

int* array2 = new int[3];// I'm using this

delete [] array1;// bad, wrong, don't do it --  Well duh!

delete [] array2;// good, fine, make sure to do it -- Of course!

Edgar Reynaldo said:

Run each menu 1000 times, noting the memory use before and after it runs. That should tell you which menu is leaking memory.

abraker95 said:

I looked it a hundred times, but I can't find what's wrong.

LennyLen said:

Or, if you're using Visual Studio, you can try this [msdn.microsoft.com].

I'm using Code::Blocks.

LennyLen

Member #5,313

December 2004

abraker95 said:

I'm using Code::Blocks.

What you can try then is downloading VMWare (which is free), and installing linux in a VM (I do this with Ubuntu). You can then build your project with the linux version of C::B and run it through Valgrind.

Edgar Reynaldo

Major Reynaldo

May 2007

abraker95 said:

I looked it a hundred times, but I can't find what's wrong.

How did you decide it was leaking memory? When testing some array classes I wrote, I know it didn't leak memory, but Task Manager said there was way more memory allocated than there should have been. Windows may leave memory allocated even if the program is not using it until it is needed somewhere else, but I'm not sure. No matter how many times I ran the same piece of code in a row, there was always about the same amount of memory allocated (more than what it started with though).

jmasterx

Member #11,410

October 2009

Also, depending on what is running, the OS may page you more memory, when in fact you needed much less. Also, when you call delete, delete[] or free(p), nothing says that memory has to be given back to the OS, you might have just freed a 500MB block and still be using 500MB in Task Manager, the only assertion you get is that if you now need 250MB more or something, your memory usage won't go up. This is because it is faster to let you keep the memory than to have to repage it.

Agui GUI API -> https://github.com/jmasterx/Agui
Agui 0.2 Release Thread -> https://www.allegro.cc/forums/thread/612830

abraker95

Member #11,800

March 2010

Edgar Reynaldo said:

That's the exact same problem I have!

LennyLen said:

I recently got my hands on Ubuntu, but I'm still not familiar with the system...

jmasterx said:

Soooo let me get this strait, It frees memory, but doesn't show it Task Manager?

jmasterx

Member #11,410

October 2009

abraker95 said:

Soooo let me get this strait, It frees memory, but doesn't show it Task Manager?

The term 'freed' refers to the fact that the memory can now be used for something else. Task Manager shows the number of bytes allocated to your executable, it is not showing how much memory all your objects combined are using. If the OS reserved extra memory for your application, and it now sees that for whatever reason it needs it, you will see a drop in Task Manager. Remember that every exe is technically running in a virtual machine, so while you only have 4GB of ram, Task Manager's totals could be much higher than that. Some of it could be swapped memory too.

Virtual Memory is tricky, but fluctuations in TM defiantly do not mean a memory leak.

Agui GUI API -> https://github.com/jmasterx/Agui
Agui 0.2 Release Thread -> https://www.allegro.cc/forums/thread/612830

Tobias Dammers

Member #2,604

August 2002

jmasterx said:

Virtual Memory is tricky, but fluctuations in TM defiantly do not mean a memory leak.

Steadily growing memory usage in TM however do indicate a leak. (BTW, defiantly != definitely).
There's also ProcessExplorer, a more powerful drop-in replacement for Task Manager, which can show you a lot more about your processes.

abraker95 said:

I recently got my hands on Ubuntu, but I'm still not familiar with the system...

Ubuntu seems to suggest that things work pretty much like they do in Windows or OS X, with graphical tools for everything, but those tools are in fact just a thin layer on top of the text-based system underneath. Personally, I prefer debian (which is what Ubuntu is based on); you might also want to look into Arch Linux or OpenSUSE.
IMO, to really benefit from a Unix-like OS, you have to embrace the core principles of openness, textuality and simplicity, and learn the basics of the "Unix Way".

Quote:

Soooo let me get this strait, It frees memory, but doesn't show it Task Manager?

Yes. The memory is "free" in the sense that the program isn't using it, but it's still attached to it because the task scheduler's heuristics assume that you'll be needing more memory later on, and just leaving it reserved for your application to pick up again as long as nobody else needs it is far more efficient than shoving it to and fro all the time.

---
Me make music: Triofobie
---
"We need Tobias and his awesome trombone, too." - Johan Halmén

LennyLen

Member #5,313

December 2004

Tobias Dammers said:

IMO, to really benefit from a Unix-like OS, you have to embrace the core principles of openness, textuality and simplicity, and learn the basics of the "Unix Way".

I don't know his reasons for having a linux installation, but for me, it's to test that my code is a as cross-compatible as possible. Ubuntu is ideal for this, as it takes much of the hassle out of getting familiar with things.

Plus, it's the only installation that actually worked 100% flawlessly that I tried (out of about six attempts to get linux running on my box). Granted that's probably because I ended up just running it on a VM, so it didn't have to try to recognize the real hardware like the other installs did.

And there's nothing stopping anyone from running everything straight out of a console on Ubuntu if you really want to.