Malloc and New

[Asimov]

Hi Chilli,

Whenever I watch your tutorials I always have a look at different webpages to see what different people say about certain commands.

I found the malloc tutorial very interesting, but I also just read that with C++ when using the New command that malloc is no longer needed.

Does this mean when we go into full C++ we will not be using Malloc anymore?

Also I realise that even though in the past I thought I was using C++ I think I have been using mainly C without knowing it. LOL

Asimov

[chili]

We probably won't be using malloc for much longer. The only advantage that I can see to using malloc is that then you can call realloc on the pointer latter on. There is no C++ equivalent to realloc.

[Asimov]

Hi Chilli

We probably won't be using malloc for much longer.

Damn and I have just got it working on my sprite code LOL.
I can load any size sprite now with the malloc working. It is good because my sprite routine is different to yours I have had to use malloc in a slightly different way, but I got it working.

Asimov

[chili]

Nice job.

[Asimov]

Hi Chilli,

Congratulations are a bit too soon I am afraid. Yes I did get malloc working with my animated sprite, but when I used malloc to load my backdrop something strange happened. My program then only worked at half speed. It was like running in treacle. I don't understand it.

BTW when I first used malloc I forgot to add #include <stdlib.h> and yet it still worked. I only added it after to see if that was causing my slow down in speed, but it wasn't the case.

I have added the original version which runs at top speed, and the malloc version which runs slow. I hope you can help. Although I know soon we won't be using malloc.

Asimov

[LuX]

I noticed some drop in performance as well. Not too bad ones, tho. But I discovered some time ago that the program tends to run reallllllllly sloooooooow when you run it through debug mode, so if you haven't already, try running in release.

[chili]

There should be zero drop in performance with malloc. Look over your code carefully Asimov and try to think what you're doing different in the new version (besides malloc). I think you can figure this one out on your own.

[Asimov]

Hi Chili,

I haven't found the problem yet, but I have taken something out which shouldn't have been there LOL

Code: Select all

surface = (D3DCOLOR*)malloc( sizeof( D3DCOLOR ) * sWidth * sHeight );
	LoadPNG(filename, surface);

to

Code: Select all

surface = (D3DCOLOR*)malloc( sizeof( D3DCOLOR ) * sWidth * sHeight );
	LoadPNG(filename);

As the surface doesn't need to be sent.

Also I am calling my drawsprite routine with this

Code: Select all

DrawSprite(x,y,ImageWidth,ImageHeight,gfx);	

I don't need to as ImageWidth and ImageHeight are already in the same class, so changed it to this

Code: Select all

DrawSprite(x,y,gfx);	

I am determined to work this one out yet LOL.
WATCH THIS SPACE

Asimov

[Asimov]

Hi Chilli,

I now know why the program runs slower with Malloc. The truth is that Malloc has nothing to do with it at all. In the original one before malloc I am calling gfx.Drawsurface(which uses the stripped down putpixel code) for my background. In the new version I am sending everything to my alpha sprite code. So what is happening is this. If I send the background code to the alpha sprite routine, it goes really slow.

Right so the answer at present is this. I will send any sprites to the alpha code and send the background to the standard putpixel code. I am now putting a function in my sprite class to call the putpixel code just for the background.

So the question is this. Why does the alpha sprite code run so slow compared to the original putpixel code.

I realise that checking the ARGB for every pixel would slow it down a little, but why does it slow it down so much.

Last question. Is there a way to optimize the code to speed it up.

I do realise that it is not necessary to use Alpha for the backdrop, but I am thinking that if I had a lot of sprites on screen that the slow down might be noticeable.

Asimov

[LuX]

I started using alpha stuff my self too. It was slow. It's not anymore : -)

The actual calculation shouldn't take much time at all, it's drawing the pixel whats slow. I'm not sure how your drawing routine goes, but if it's the same as it used to be, where you draw the new pixel over the old pixel, then this should work:

Make an array for your alpha, red, green and blue. (or combine all in same array) and then instead of drawing the pixels in the middle of the code, do the pixel calculations inside the array.

Then at the end of the code, simply draw the raw pixels of the array. This helped for me at least a lot. Runs 100 times faster.