arcab072081 Thanks for your answer! Unfortunately, kegs can't be placed at random places. It's not that they need to be at specific points, it's rather that they dont look good just anywhere – and of course they should be on floor too. Sure must be some way, but wont be easy to achieve – not without arising other brand new performance pains. Anyway kegs are no there all the time, they appear when a “proximity box” hits a “token sprite”. But still there's that collision to check. I have not mentioned, the idea is to make everything “autorespawnable”, as it's likely that the same area will be walked through several times.
But see, it's not just kegs... I'm doing something that I thought was pretty cool for the freeversion of C2, with its event limitations, but now that I got me a licence I'm wondering if it wont be causing more trouble than good.
In the early days I decided that all the enemies would be but different animations of the same sprite, and each enemy attributes would depend on instance variables (class=”orc”; hp=”8”; etc). Same applied to items.
Now in the bigger version im working on at the moment, I applied the same philosophy to a new class of sprite, called miscStuff. And miscStuff is everything from kegs to chests to lamps or gates or ships. Each class has one animation, although many are static, and most of them have some rules, which can be as simple as “enable jumpthru”, or more complex things like triggering a function that moves certain elevator, for example. This miscStuff sprite has the following (str) variables: class (“chest”, “lever”, “bonfire”...), then aux1, aux2, aux3. These aux variables can be different things, depending on the class (treasure from a chest, parameters for a function, the hit strength of a trap...).
And (oh surprise) this miscStuff is what's giving me performance pains. Enemies are under control, as they always appear at the same distance (proximity box1) form the player. But then some miscStuffs are doors that you need to open with a key, and I dont want to have them reclosing emselves everytime you get 960 pixels away. So we get proximity box2. Then for some other stuff I want something intermediate, that's proximity box3... I try to use the smallest one whenever possible, as it affects obviously less objects.
This means that I have less than a dozen of visible animated sprite types (not counting invisible boxes or hud elements). That looks good, but there are many instances of them, and the code for each is quite complex, so as I said I have growing concerns about this technique. I wouldnt mind to reconsider it – this or any other thing, really, but it would be very frustrating to take the pains and split all the miscStuffs into many different sprites, then adjust the code accordingly, to finally discover that performance's still shite (or even got worse. That stuff happens).
After all, if I was to split my game blindly, not knowing if it's gonna run better or not, my bet would be on the layout, which I think would be the surest way to improve my fps.