When I load my cap I get an Error in the display engine saying invalid data. Dont know what i should do about it. Is it a bug? should I post it to the tracker?
Sounds like a bug. Post it to the tracker.
I think Ive found the problem. The Animations I have are huge some are 50 frames a piece and have 8 directions for each animation. in total I have 792 frames of animation, I think Having all these frames and not being a power of 2 size may cause the computer to run out of Vram.
If this is the case would a suitable work around be to store the lesser used animations in a separate character object and "swap" between the 2 by creating and destroying her different types?
Woah. That's big. I had a look at the .cap you sent David. You just can't get away with that many graphics in an application. Remember if either dimension of the image is over 256, it'll get put on a 512x512 sized texture by the graphics card, and after a quick look, I think every animation frame is going to be put on a texture that big. After a few calculations, you're basically going to try and allocate about 800mb of textures. Some people still have 64mb graphics cards, and not everyone even has that much system memory. You need to entirely rethink how you do your game and probably cut down the animation frames by at least a factor of ten.
I think one graphics card, the nVidia GTX 295, has a slim chance of fitting all that in VRAM (and this is just the beginning of your game I assume). It costs �400. You're going to have a tiny target audience if you carry on this way
Using separate objects won't help. Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.
We are working on a way of cutting her down so she fits on a 256X256 texture and cutting her animations down by a few frames instead of 50 cutting it down to 35 and maybe cutting her walking down from 26 frames to 13 that will help alot in cutting down on the Vram used. Other than that What about the workaround I posted above? Or will it still take up vram?
It will still take up VRAM.
[quote:2x55o1z8]Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.
There is an ability to load textures from a file - or so I've noted by simply gleaming over object features. Perhaps that would help managing the VRAM?
**face Palm** didnt see that. Go me and my reading skills.
Well I need to find someway to really cut down then if its going to load everything across the layouts. I mean that is our first character there will probably be 3 or 4 more. not to mention all her other animations like opening doors and pushing this over etc.....
Well before you go ahead do some calculations and figure out if when the game is done, will one layout's complete textures even fit in system memory? Will the system requirements be too high to be useful to anyone?
You should come up with satisfactory answers to these questions before you make your game. There's no point launching in to creating a game which is impossible to run.
Hmmm... I ripped some of the animations out the falling and things but for some reason I was still getting the error. It seems that construct dosent remove the files until you save and restart or maybe just save.
[quote:yvskx95j]Currently Construct loads all textures from all objects in to VRAM on startup. This should be improved to be configurable layout-by-layout in future, but that still won't help.
are there any plans for a configuration option soon?
seems kind of odd to load in textures i won't even use until the end of the game when I boot it up...
I'm also working on this project and can scale the render size of the character...
Also, would loading external images work? loading when we need them only?
Or once loaded, can they be forgotten somehow?
if I got the textures down to 256x256 and cut the animation sizes to a maximum of 30 frames at most for the longest animations, 16 for walking, and 6-8 for idle would this be a big help?
Yeah, it needs to be changed and it will. It makes the requirements higher than they need to be, because all your menu textures will be in VRAM while you're in the main game, etc. However, it does almost completely eliminate loading times. Scaling never affects it because only the source original texture is stored in VRAM.
A 30 frame animation of 256x256 frames is still going to use about 8 mb VRAM, so after a handful of objects you could be knocking out all cards with less than 128mb VRAM from playing your game. Even if Construct was clever enough to load animation frames only when they're displayed, it would perform very poorly, because transferring textures from the CPU to GPU is slow, and they're stored as PNG files which need to be decompressed first. To be honest, you're going to have difficulties designing your game like this. Try scaling everything down to 128x128 or smaller.
Develop games in your browser. Powerful, performant & highly capable.
Try scaling everything down to 128x128 or smaller.
Try scaling everything down to 128x128 or smaller.
One desperate question: could I stack two 128x128 sprites on top of one another?
Would this help at all or am I just SOL?
If my proposed solution does not work, I may only make the character this large and make the enemies small ...
Thanks for the help.
This might affect Sol because I know he wants to go "BIGGER IS BETTER" with Chamber, and make all graphics native to HD resolutions and scale it down from there.
Perhaps some sort of optional, advanced "Buffer on call" feature for sprites and tiles could be implemented? Then any sprite or tile marked with such a thing would have to be manually told to load to or clear from VRAM with events.
What he said. this was we can clear the Vram and have more control over what is loaded and what isnt. Even if you only loaded on the start of the layout, it may be slower but it would be better for higher res games.