jack_norton wrote:
Maybe batching is the problem? not sure how Jake's engine is coded, but if it's made of tiles or several identic units, using batching should help that a lot...
Off-topic aside:
There's no code in the present release for tiled battlefields, although it's obviously possible since
Tristan and Iseult uses tiles. However, problems with Ren'Py related to drawing at non-native resolutions have made me reluctant to release tile-map code in the main public release (e.g. when the window is resized or put into full-screen; to demonstrate, run
Tristan, wait until a battle and put the game into full-screen mode). However, what I've seen of DaFool's usage does sometimes have multiples of the same unit graphic on-screen at once, so it's theoretically plausible that he could gain some performance benefits from batching.
Unfortunately, batching is practically impossible to do in Ren'Py user code without hacking core, because Ren'Py has a scene model; a call to renpy.show doesn't directly draw the sprite onto the screen right that second, it puts it into a big list of displayables which are currently on-screen, and Ren'Py decides which order to draw what in and when.
There are quite possibly advantages to be gained from batching (whatever particular technological approach is taken), but it'd be up to PyTom to implement it. And to be honest, I'd agree that DaFool's problem is probably more related to huge images than number of sprites on-screen at once.
Which means that tiled-map support would probably help DaFool quite a bit, 'cause he could split his large map graphics up into smaller sub-sections, which wouldn't be such memory-hogs and could be selectively drawn... but for me to put that into a public release would require PyTom to first fix his precision-drawing problems, otherwise it'll just look crap instead of running like crap.
On-topic, though:
I'd agree that it'd be cool, once Spriter is released, for Ren'Py to support that kind of sprite. However, I think it'd be far more cool to have publically-exposed functionality in Ren'Py such that we could implement a spriter-import or similar ourselves; as it stands, Ren'Py doesn't even support a full range of affine transforms, let alone the non-affine stuff that you'd need to support Spriter's stated roadmap.
Also:
LVUER wrote:
Yes, Android only starts supporting resolution bigger than 1280x720 from version 3.2
Texture resolution, not screen resolution.