Lemma Soft Forums

This is something that has occupied my mind and reminded by recent game such as Rejoice Gospel of Matthew. Though Jake's Battle Engine is pretty much good already at what it should do, the fact that I have to use VRAM-hogging filmstrips makes the animations choppy and downright terrible (I'm using 8-16 frames of 128 to 256 square). Combine that with large panning backdrop and I already know my game fails in performance alone.

I think that's a problem that should be tackled on the Ren'Py side with regards to image animation handling. I think the solution would just be to use a single sprite map and use the game engine to animate the pieces themselves, instead of exporting frame by frame.

What if it were possible to make a Odin Sphere or Muramasa or Grim Grimoire or Dragon's Crown animations in visual novel sequences? That could be really cool. I therefore humbly request the creator/maintainer of Ren'Py to at least look into the feasibility of enabling compatibility with the following:

http://www.kickstarter.com/projects/539087245/spriter

Spriter game animations won't be tied to a specific development tool. Spriter saves to a fully open XML based format we call SCML, which is an acronym for Spriter Character Markup Language. Our intention is to get Spriter animation supported on every major game authoring tool. So far, we have a feature complete Scirra Construct Classic plugin in beta for creating DirectX 9 games with Spriter. Work has begun by third parties on Unity and Torque2d support for Spriter animations, which means soon Spriter animated characters could be possible on PC, Mac, PS3, XBOX360, Wii, Android, iOS, and Flash.

Anything that can read XML and display images in different positions, can support Spriter animation. With the early version of the plugin we're developing for Scirra's amazing HTML5 game creator Construct 2, we've actually managed to load and animate a Spriter character in a standard HTML5/javascript webpage, this is without using any special plugins - just a stock browser. We are also pursuing support on GameMaker, MMF2, DarkBasic, and other popular game engines.

16 frames of 64 kilopixels each isn't really all that big, though. So I'm not sure that would be the problem, versus scene complexity or something like that.

Oh my God, this would be so amazing if it was hooked up to Ren'Py. Just think of the beautiful animations you could do *dies from sheer awesome overload*

PyTom wrote:16 frames of 64 kilopixels each isn't really all that big, though. So I'm not sure that would be the problem, versus scene complexity or something like that.

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... I remember in my "C coding days" that using batch could draw 1000 sprites easily on screen

Whoah, Spriter would let me have animated sprites. That would be huge! Imagine the girls throwing their hair when you say something stupid..

Ive also been looking at nyatraps work and thoroughly agree the problems start with HD resolution with tex bigger than 1024. Really tempted to downscale and redo the scenes. But imagine how smooth a game using Spriter + ATL will be!

You should never use texture bigger than 1024, just in case you want to do Android port (or iOS in future). It just won't work on those devices...!

jack_norton wrote:You should never use texture bigger than 1024, just in case you want to do Android port (or iOS in future). It just won't work on those devices...!

All android devices must support at least 2048x2048 textures.

Hm no, from what I understand, that's true starting from Honeycomb, so Android 3.2+ which is currently not very widespread compared to older versions.
But yes, in future will be more common for sure as the HW becomes more powerful - anyway it's always wise to not use textures too big if you can

Still, very few devices that are capable of running Ren'Py will have a texture limit under 2048x2048.

Yes, Android only starts supporting resolution bigger than 1280x720 from version 3.2 (even 3.0 still can't run anything bigger than 1280x720). And tablet with Honeycomb is still pretty rare. And let's not forget the resource needed to run HD content (it eats the battery). I think you need to think about that if you want people play your game in tablet.

All of those not really a problem in PC though...

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.

Sorta OT but another main motivator was this game (essentially ex-Bioware devs having almost exactly the same gameplay concept as Elspeth's Garden, but starring Vikings instead of loligoths in airships):

http://www.kickstarter.com/projects/sto ... anner-saga

So yeah they seem to have hand-drawn frame by frame animation similar to Tokitawa, but something just as nice looking can be made with Spriter graphics.

What I currently have is prerendered 3D that while good enough, still sticks out against the handdrawn backdrops. I wouldn't mind having to toss the 3D work already made if it means having characters that move in a more lively and charming manner.

Right now my image code in the Battle Engine is something like this: If in the future the code can be something like this: I'm still not sure about how isometric graphics will be handled, but just like with 16-bit graphics, it will be enough to just have a character have a few animation states regardless of the map rotation.

I am actually willing to fund Spriter plugin development for Ren'Py for eventual public release, I'm that serious about it.

Would this be possible? Should I grab Spriter and try to do something with it, or is it not going to happen?