I think it might have been missed, I mentioned you can arrange objects alphabetically by right clicking the object bar.

You can also click the object bar then start typing to select an object as well.

Ah, thanks for pointing that out.

Huh, I thought you could set groups for objects using the object folder setting in the properties, but it doesn't seem to work. I guess it's an unfinished feature. You can sort the objects in the object bar by right clicking it.

6.99 is probably the right price. I think 4.99 is too low, and gets into that 'percieved as cheap' realm.

I understand how you feel and I used to feel the same about it, but there has been a huge amount of money thrown at studying how to get people to spend money, and using .99 is effective. It's not scummy. It works. Companies wouldn't do it so much otherwise.

Actually, 512x512 is 1/4 of 1024x1024, so a 512x512x10 animation would be 1/8th, 10MB.

[quote:13btzf5j]Without having a 256mb card myself, how would I know whether the game is suitable for them? Is there a MB or VRAM usage I should be aiming to stay under, or would I have to test the game on a 256mb system?

AFAIK, there's no exact science. What if a user is running something else needing VRAM concurrently? Best to simply use as little as you can manage.

[quote:13btzf5j]But I imagine that every tree and object that can be animated would be a problem regardless of whether the animation is playing, since the images used in the animation would still need to be loaded up. Is that right, or are the images only loaded up when they are needed?

All frames in a sprite are loaded when the object is loaded. Dynamic stuff will take up less VRAM because you can bend or rotate one image instead of loading a ton of them. That's also why you'd check what trees are onscreen first, and only animate those. I don't know what you're doing though, so optimization is up to you to experiment with.

Any tips and tricks I should know about cutting up the image?

Maybe make the branches objects and place them on a trunk?

Also, it doesn't matter what format you use, it all gets converted to PNGs.

An animated 512 or 1024 sprite is huge and the 1024 especially is going to use a ton of VRAM - probably about 80MB. Large images (512 and up) are a huge bottleneck when compiling, though they are cached and don't need to be recompiled until you change them or reload the project.

I got around it by loading large images at runtime, but I'm not sure how well that will work for animations concerning hotspots, etc.

As far as I know, larger textures aren't a problem for GPUs to render (as long as they support them - stick to 1024 and under), though it will take longer to transfer all those textures to the GPU at the start of the frame. That's generally not an issue, though. The bigger concern is a GPU not having enough VRAM - then it will have to swap textures every frame. Your main problems are compile time and VRAM use.

If you're aiming for 256MB cards (which doesn't mean you have 256mb to work with - the OS uses some, etc.) it might be okay depending on amount of other stuff in the scene, and you could leave the trees animations out and put them back in as the last step before exporting to an exe.

You sure you can't use that animation system in real time on only the onscreen trees? It would be smoother, use less VRAM, load faster and could be dynamic as well. Unless it requires a ton of cpu time, obviously.

It's frustrating having to wait upwards of 60 seconds with a 'Construct is not responding' message every time I want to test my layout.

I hear that. Mine does too.

Watch out though - if you price it too low, it can create the perception that might be cheap and not worth buying. Might want to reconsider $9.99.

Construct can do everything you mentioned and more.

It's extremely unlikely before construct 2.