Switching to Direct3D Mode = Massive Slowdown?

Recently I opened an old project, which I had created solely using MMF2 Standard. I wanted to test some shaders it, so I switched from standard mode to "Direct3D 9." After I did that, however, The game slowed from its usual consistant 50 fps to about 20.

I thought HWA was supposed to speed up games and reduce slowdown. =/ Maybe I'm not completely clear on exactly what "Hardware Accelerated" means...

Anyway, what a kind soul care to explain to me what's causing this slowdown, and why the slowdown exists?

Please?

Perhaps you're using an extension that hasn't been converted to HWA yet?

Yes, the likely cause is that an extension that has not been optimised to work with the HWA version is slowing down the game. Anything that messes with graphics, forcing the data to be pushed back and forth between video and standard RAM, is likely to be the culprit.

Hmmm... Looks like you guys are right. I removed some of my extensions, and it greatly increased the speed.

Thanks for the answers.

I hope it's not too obnoxious to revive this old topic, but is there any way to tell what extensions have been optimized for HWA and those which have not?

The graphical extensions that have been optimized are :

- Active System Box and Background System Box (don't use too many ASB with texts though, I think text is not really fast)
- Picture and Active Picture
- Particle Spray
- Perspective
- Viewport
- Speech Bubble
- Text Blitter

Happy birthday Yves!

Thanks :)

Ah, Thanks very much for the reply, Yves. So will every extension eventually be optimized for HWA, or will it stay a more limited selection?

Non-graphical extensions don't need to be optimized for HWA and will perform completely normally, since there is no difference for them, but only a certain set of graphical extensions will be optimized for HWA. Reasons they might not be optimized would be either if their creator has stopped updating them, or if its just not feasible for the extension, or if the object is just redundant with the HWA mode so much its not worth it.

For example, don't hold your breath for a lens object update.

Pixelthief is right : there are not tons of extensions to optimize, and some extensions can't be easily optimized. We'll try to optimize the ones that can be optimized.

Docilemouse :
Which extensions did you remove?

That reminds me, I found a problem with the text blitter and rendering PNG images, at least in HWA:
http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=165314#Post1653 14

Looks like the method it uses to decompress the images and draw them is slightly different between the text blitter and everything else (the active picture object was giving the 'true' colors). I dunno, would that just be a property of the compression scheme of mspaint & irfanview? I tried other compressions but most of them simply wouldn't load in either

Does the png have a icc color profile encoded in it? That often causes this problem, due to some things adjusting to match the color profile and others not understanding color profiles...

I remember PNG wouldn't work at a higher resolution once for a object and i posted about it somewhere. It might not be the same thing but in my opinion if a image format is supported it should work right away rather than having to mess around with compression and rates outside of MMF to get it working.

Edit, this forums search feature isn't much help but i found it -

http://www.clickteam.com/epicenter/ubbthreads.php?ubb=showflat&Number=135533

Image Manipulator does not support 24bit PNG images, but not sure if this applys for other objects also but maybe the image filter things need a update though.

Hrumm it really does seem odd. I mean I can see the logic that you can't expect full support of all PNG compression schemes, since theres a bajillion of them out there, but so far I haven't gotten PNG files to sync at *any* resolution/compression/rates. I've actually tried lowering my images to 256 colors, and then putting them on the MMF2 default palette. But even then there was a noticeable discrepancy.

But yeah Atom one of my attempts to fix this problem was to load the PNG image in the image manipulator object and then export as a temporary bitmap and load it from that. Guess that explains why that did not work!

Andos, I pretty much removed everything except for strings, backdrops, and actives. But among them were:

Background images object
Stringreplace object
Ini's
Advanced direction object

It seems the Background images objects were slowing the game the most, then the ini's... It was weird.

Why did you remove all the non-graphical ones? It is only the graphical objects that could cause the slowdown difference between the two runtimes.

Well, I removed them before I knew that specifically only graphical extensions were the problem...

So only the Background images object should have presented a problem? Maybe I was running too much data in my ini's. But then why would my standard version run perfectly? Ack... I'm so confused...

IIRC, background images object has a low vs high RAM "efficiency" checkbox in its options. Try changing that for all of them. I actually have no idea if that would make a difference seeing as my project runs fine with all of them set to high RAM, which presumably would take less work off the GPU. In fact I have no idea if that checkbox does anything at all

but give it a try