I create TImages within my code for space ships for example.
Now I want to create a Sprite using this TImage without writing the image to a file first.
Additionally I want to set xhandle and yhandle and blendmode in the source code without writing a sprite.txt file for a sprite file that doesn't even exist
So I miss some creation way for a Sprite with just a TImage.
And I miss the setters for xhandle, yhandle and blendmode.
What are you doing? Procedurally generated content or splitting a larger TImage into smaller sprites? Or something else?
I'm looking over the source and I can't see an elegant way to handle this. The frameworks task is to load MasterSprites for you and you don't "create" Sprites directly, you merely create instances of a MasterSprite.
If your sprites don't fit in that system then perhaps you should a) handle them yourself (as I am for my tile-based game), or b) make them work in a way the framework expects.
I'll look to see if procedural content can be managed gracefully by the current MasterSprite/Sprite/SpriteList system. I assume you will want instances of these sprites too? So it would be good for the framework to handle them.
I think the setters for xhandle, yhandle and blendmode should be added anyway.
I'm not convinced. I think hard-coded manipulation of these values goes against the "data driven" paradigm. Of course you have access to the members anyway but the fact you have no setters sends a clear signal you shouldn't be changing them through code. I've provided DrawDirectEx which ignores the sprites own renderstates but there's nothing for manipulating the handles.
I think I can add support for procedurally generated MasterSprites. I will test it out
matibee said:
I'll look to see if procedural content can be managed gracefully by the current MasterSprite/Sprite/SpriteList system. I assume you will want instances of these sprites too? So it would be good for the framework to handle them.
That would be great! And yes, for some Sprites I would want to have instances, for others I will require a bunch of master sprites.
I'm not convinced. I think hard-coded manipulation of these values goes against the "data driven" paradigm. Of course you have access to the members anyway but the fact you have no setters sends a clear signal you shouldn't be changing them through code. I've provided DrawDirectEx which ignores the sprites own renderstates but there's nothing for manipulating the handles.
I think I can add support for procedurally generated MasterSprites. I will test it out
But for MasterSprites that are created from code by passing an image you would need a way to specify xhandle, yhandle and blendmode as they are required in the sprite code. If you do that with a Create function I'm fine
Here's what I have in mind. It fits well with the current system and you'll do it in the "LoadResources" method (so you can update the loading screen if you want to - especially if there are lots of them to create).
' assume img is your local TImage, however you created it..
local script$ = "xhandle=20~n"
script$ :+ "yhandle=20~n"
script$ :+ "blendmode=1"
AddMasterSprite( "blob01", img, script$ )
You're then free to GetSprite, CreateInstance etc on the MasterSprite called "blob01″. You could code the script as I did above, or load from a file.
I guess it would need a method for inserting animation frames too. I think I know how that will work.
Thanks for considering this code change
No problem! Here's the deal — give me some assets to test with, and I will code it Your assets are safe and secure in my hands or you may just give me placeholders.
That approach looks good - converting a String to a Stream and thus faking a file
Do you still need some assets? What do you need? Should I send you the code to generate a spaceship image? Or should I send you some png files? Not sure. Or do you need some simple routine to create an image, draw something on it and then return that? I'd bet you can code that faster than I can say "thingamadoo"
I was thinking that if you're generating sprites in a special way then I would use your code and assets as a test case. But I don't think it's necessary now. Thanks anyway, and watch this space!
1. Create a new managed bitmap for each frame, and let the system look after it in the same way it does with the ref-counted bitmaps loaded from disk.
2. Create an empty MasterSprite object.
3. Add all your frames to your MasterSprite by refering to each frame by the managed bitmap name.
A fourth and optional step is to apply an animation script as in the string example above.
It's coded, quite thoroughly tested and comes with a new example. I'll work on a new release ASAP.
Login 
Register 
Search 
Forum
Print this Post 
Topic RSS 
