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..

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!

is the layout object source contained within the editor? we can't seem to find the source for it...

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??

Took a look, and yeah it certainly does the job, but now you've mentioned it works on the bullet object at least, I worry if it would either not affect some other behaviours or possibly even rest their behaviour instead of "halting" it as I add more..

With that possibility in mind, in your opinion, do you think I could come up against issues like that further down the line?

I guess I can get my programmer buddy to take a look at the layout object, maybe he can fix it, or rewrite a custom pause object based on it..

maybe we can come up with a solution once we get past the CS source building issue I mentioned in another post!!!

cheers!

Hi again everyone!

I just got my main game logic cycling from title layout (1), character select layout (3) , main game (2), then to continue or quit (6), then back to title (1) if quit.

Now, the weird issue is, that after I go from the title(1) to character select , the character select layout (3) should go to layout 2 as always.. but - it doesn't, it goes to title (layout 1).

This only happens on the second playthrough of the game loop, the first time around its fine... there are no other events in that layout to take me back layout 1..

so confused by this - can anyone help?

*UPDATE*

on further examination, I was testing the LAYOUT object - and this might be causing the issue , deleted it and tried a quick jump back to title with it deleted and it was OK - I guess this is one of the bugs?

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

intriguing! Ok I will have a look very soon and see what happens... thanks as always!

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

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..

Hi all, does anyone know if there is an issue with the xbox controller object set to GLOBAL across layouts? it seems to crash my preview.

saved to test caps to see if anyone has the same issue...

A BUTTON makes a sprite appear, START jumps back and forth between layouts.

2 xbox controller object instances over 2 layouts = OK!

https://copy.com/OUtWqa8hP6U1HFEQ

controller instance set to global = NOT OK!

https://copy.com/3OYh6nuLc37c3KI9

Thanks as always Jayjay, you rock.. will take a look ASAP!