Sprite making (runtime)?

[Donone]

I have studied very extensively but cannot find a way.
Is it possible to draw an item i.e. G_Rect, and then at runtime have it converted to a sprite, along with the attendant features of sprites?
If it is not, would it be difficult to mimic the methods of the Game Editor (in code) to have it produce the requirement (on the fly)?

An example of why I ask.
I want to produce a variable length sprite that cannot be produced by stretching due to the nature of the drawing.
I would imagine it to be a massive overhead to use as an 'in advance' animated sprite of maybe 30 different lengths of bmp.

Each of a varying quantity of these sprites, are a long rectangle with circles at regular intervals, but whose length can be varied by as little as one circle at a time or many. (Too many combinations for each sprite).

This is simple to achieve as a class redrawing a rectangle of n length and n circles on demand, but it will not act as a sprite in that I can't click it.
I know from a much earlier question that we cannot produce a custom control with events (this sounds very similar), but I thought this question from a different angle (game editor) might achieve the same desired result.
Another long-winded one from Donone. :-)

[Mike Halliday]

Hi Donone,

Don't know if this is what you are looking for, but i managed to create a sprite and then make it 'x' times longer and still be able to move it around the screen?

Check out the code - Probably nothing like you need and you have probably tried this already but it does seem to work.

I used the SETSPRITETILEX function to add extra sprites to the currently loaded one.

Regards

Mike.[br]1193736191_671_FT7373_spritetest.zip

[Donone]

Thanks for that Mike. It is almost there, what I need is to click on the sprite at say position 3 and have it shorten to that length and still be the same single referable sprite, rather than alter a length at the start and then retain that length. I looks good and promising with a slight tweak.
If this solves it, which it probably will...
in case the original post appears to be totally answered I should like the original question to remain open because on the next occasion the shape/problem may not be the same and so cannot be solved this way. [EDIT] i.e. vertical or diagonal.

[zehlein]

Maybe a solution is to create a new surface, draw the stuff you need there and assign it to the sprite. I attach a little file to show what I mean. Simply draw on the screen there, afterwards your drawing gets painted to a surface and assigned to a sprite..[br]1193740340_30_FT7373_balls_at_walls.zip

[Donone]

@zehlein I have had a quick look, and it appears that you have produced precisely what my post described and by the same method I needed, but was unaware of. There are so many functions!!!
I intend testing now, but to cement this is my mind, you appear to have produced a drawing (could be any shape) and have turned it into a sprite that can be clicked and controlled. I will play with altering the drawing routine on the fly and then ReplaceSprite with the new, thus appearing to be the same sprite.

Therefore, in addition, on the surface, you have produced what I was after months ago, which was to produce a new user defined 'control' with events. Therefore with some work, a StatusBar of sorts could be produced with divisions for example. Later!
Thank you.

@Mike, I am still also looking into you method, which has some attractive prospects. Thanks.

[Mike Halliday]

Glad you have found a solution, and also glad that I have given you a different angle on things! :)

Mike

[Donone]

Thanks again, I actually haven't decided finally, the best for this project, but zehlein's is best for making new controls.
Yours may be easier for constant length changing by a fixed amount.
It may be that neither solve the problem and I'll be back :-)

[Mike Halliday]

Have just looked at zehlein's solution and it shows how powerful PPL can be.

This opens up all sorts of possibilities.

[Donone]

Absolutely. My original thinking was that if a sprite acts like a control then it is a control to all intents. Just another angle.
I am afraid my learning is slow and I haven't got the hang of all the tecniques yet.
I have a problem and know how I would like to solve it, but not whether it is possible or which functions.

Zehlein seems to be a master at pulling rabbits and you seem to be good at lateral thinking.

[zehlein]

Zehlein seems to be a master at pulling rabbits and you seem to be good at lateral thinking.




Will change my nick to Harry P. *grin*

[Donone]

Good thinking! I am presuming you have read. I have not and don't intend to.

[Donone]

@zehlein
I am having difficulty with assigning a SpriteProc to the created sprite to have a little control over it but the system crashes.
If I replace NULL with &SpriteProc in 'sprite$=NewSprite(NULL)' I get stack too small and if I leave the original and add SetSpriteProc(Sprite$,&SpriteProc) Windows crashes. In the procedure I only have
WM_USERTIMER:
MoveSprite(Sprite$,Spritex(Sprite$)+1,3);

Are you able to suggest what I'm doing wrong?

[kornalius]

Post the whole function SpriteProc, I am sure you are not always returning a value from it.

[Donone]

I don't need to post it, you are absolutely right. You must be psychic to pick that of all the things that could have been wrong. I left off the Return(True);
Thank you kornalius. The simplest things trip us up (or should I say me).

Today has been a momentous day for me with the outcome of this request. I didn't think there could be a solution. This is powerful stuff!
[EDIT] I have one final!!! question. I am trapping the LButtonDown in the spriteproc but it is also firing the one in MainProc. Is there any way to differentiate that the click was on the sprite and not the screen as a whole, without checking coordinates, which I don't want to do. I want the program to know I clicked the sprite but if I miss it it will register for the screen as a whole. Tricky??
PPL gets more and more interesting.

[Donone]

Don't waste any more time on this please. Problem solved with a simple flag setting/clearing to differentiate the two.

[PointOfLight]

Man, look at all the fun I missed out on while being sick!* This appears to have been quite an informative thread.* Good job to all!* I'm curious to see what you're working on there, Donone!

[kornalius]

Donone, try putting WM_LBUTTONDOWN event in the SpriteProc, this way you know the left button was down on the sprite itself. You can then put a WM_LBUTTONDOWN in GameProc to catch all possible stylus events no matter if a sprite was touched or not.

[Donone]

@kornalius: I was already in that position but if I clicked the sprite I got a response from SpriteProc and then a response from MainProc, which I didn't want, so I put a flag in and switched it if button was detected on sprite and therefore stopped it doing anything in Main and it solved it.

@PointOfLight: Either this is a damp squib and everybody has been doing this all along or at least to me it has potential.
I hope to post something today in code sharing, but at present I lost the sprite to invisibility.

[EDIT]: Got the colour back and have now posted it in Code Sharing.

[Donone]

Having gone quite a way down the road with this, I feel I need the equivalent of ReplaceSprite without the filename because when using NewSprite from a drawing, I need to replace with a new drawing not a new bitmap.
Is this possible?

[EDIT] i.e. attach a new surface to the same sprite.

[PointOfLight]

If what you're looking for is really as simple as replacing the surface, just use SetSpriteSurface.

[Donone]

Thankk you. I have now looked that up and can't understand why I didn't see this.