modifying construct source. (& mip maps Q)

Hello again!

I have been talking with a programmer friend regarding performance in CC, we have been analyzing it with the direct X PIX app, and noticed that for each object, construct generates like, 10 scaled instances of each object for mip map scaling, as these are probably not necessary for what I am doing we were talking about making some modifications to construct for our specific use, max performance, lowest memory overheads.

So there's 2 questions..

1 - Are these mip maps necessary? it's practically doubling VRAM.

2 - We can't build CC because we don't have the profUIS file ProfUIS284ym.lib - and even if we buy the latest version, it seems that the version of this lib may be newer, and therefore leaving us unable to build CC even if we do pay the $100+ for it.

has anyone managed to make a build of the CC source?

I mailed Ashley regarding it, but haven't got a reply, so I dunno if he's just (understandably) extremely busy or just not wanting to discuss the distribution of the profUIS ProfUIS284ym.lib file..

Mipmaps probably can be safely disabled, it's just to improve image quality when an image is small.

That profuis lib is only needed for compiling the editor. I don't think Ashley has been ever able to share that file.

That said you can compile the runtime since it doesn't use profuis. It was built with vs2008, but I've been able to build it with the vs2008 express edition.

weird, it always fails looking for that one lib.. I will talk to my programmer, see what we can figure out, he can probably give me more info to pass on..

thanks

If it fails on that lib then you're trying to build the editor. The runtime is a seperate sln file in the runtime folder of the source as I recall.

ok, thanks!!, will talk to my programmer about it - I probably got the info wrong.. its all very appreciated!!

Hi again.

So, am I correct in saying editing the runtime will allow us to remove things like the mip maps, but the preview function is always part of the editor, so we can't remove them from that? If so, that means the editor will always contain the mipmaps, thus causing a discrepancy between the amount of VRAM used in the preview and the exported EXE file??

When compiling the runtime you can change the preview exe as well. It's just another configuration. You can choose from "Release" and "Debug" from these configurations:

APP

APP_p

APP_pd

DX9

DX9_p

DX9_pd

"APP" and "DX9" are the two runtimes. "p" means preview, and "pd" means debug preview. These match the exes in the "Construct Classic\data" folder. Also you may notice exes with a "s" as well. That means with python scripting, which is done by building with "#define python" uncommented and renaming the built exe to have an "s" in it.

So in the simple case an exported project will use DX9.exe and when previewing DX9_p.exe is used.

We changed DX9_p to not generate mipmaps but the VRAM size was the same.

Or is it that the VRAM calculation assumes we're generating mips for every texture and isnt the actual memory footprint?

Thx!

OK, so we looked into it a bit more, and interestingly, that VRAM usage calculation didn`t include the mip maps anyways - so now we removed them it`s actually accurate..

Yeah, the calculation was done manually based on imagewidth*imageheight*4 as I recall.

Did you get significant performance increase from them? As someone working on a game with no sprite scaling and some performance issues I'd be VERY interested in anything that helps out with that.