Sprite attributes (properties)

[agraham]

If you can possibly avoid it it would be best to not call Tick in the GameWindow Paint event. This is because Tick, as it exits, calls Invalidate then Update to force an immediate repaint of the new window - which of course then calls Paint!

[enonod]

I have finally used the debugger and noticed that when using the Destination Event with a breakpoint, the sprite (rectangular) is shown touching the destination not overlapping/on it.
Is there an explanation for this please? Note my caution with words, I do learn.

[agraham]

Originally Posted by enonod

Is there an explanation for this please?

The operations done in Tick in this order are Erase all the Sprites from a bitmap buffer, Move all the Sprites, Draw all the Sprites on the buffer, Process collision events then Paint the buffer to the screen. This sequence leaves the Sprite positions on the screen corresponding to their reported X and Y coordinates so NoCollisionMouse events use the screen X and Y coordinates which was not the case with the old version of the library.

If you breakpoint in an event raised by the Process operation the screen will most likely not yet have been repainted so the screen you are seeing represents the Sprite positions on entry to Tick before being moved. You can check this by looking at the colliding Sprite X and Y positions. If you set a flag in the event then check and stop on it after calling Tick you will probably see the overlap.

[enonod]

Thank you agraham. Very clear.

[enonod]

A bit late in the day I appreciate and this may have gone to bed. Is it possible to associate an individual timer to an individual sprite that will of course trigger an event or events that will be attributable to that sprite by returning that sprite say as Sprite1?

[agraham]

I don't really understand this request as a Timer is not associated with anything apart from its' event Sub that it runs when required. Perhaps you mean having a Tick method like Tick2(sprite As Sprite) that just moves that Sprite and checks for events? I don't understand how that could be useful and it would pose problems about erasing and redrawing a single Sprite without erasing and redrawing them all which would be possible but time consuming Perhaps you could explain in more detail what your idea is?

[enonod]

My thinking was for a timer that is a method for a sprite. It would run for the specified period after which it would trigger an event and within the event sub properties could be changed or methods called that are only associated with that sprite, maybe change speed or stop or start, for example a cyclic timer could stop and start the sprite or cause it to change direction dependent upon the timer.

I suspect that this could be done without an associated timer but one would have to then address the sprite required as with any timer event affecting anything in the program. I suppose I am trying to encapsulate so that the timer 'belongs' to the sprite and anything to do with the sprite is controlled by its own methods/properties.
I guess I am an OOPer and like black boxes instead of birds nest coding.
I don't know if this makes sense.

[agraham]

I am afraid I can't see how that could work. Processing Sprites at different times would make the redrawing terribly inefficient as you can't just erase a single Sprite and redraw it without risking affecting the image of another Sprite so you would need to code in a loop involving all the Sprites. Also you would need a timer per Sprite which brings in more overhead. I'm afraid it would really stagger on a device.

[enonod]

Thanks for the consideration
[Edit] In fact I was not thinking that the sprite would move independently, it would still be controlled by the ticker but the timer would sort of act as a switch in series with ticker and when both have activated then...
However I am thinking now that perhaps I could do something by counting ticks. It would be nice if that were 'built in' (like destination collision event, a count ticks reached zero event?????) but perhaps I can set a count and when it gets to zero do whatever to the properties. There just won't be an event to allow all this to happen in auto for a sprite.

[agraham]

I can add a count to a Sprite and raise an event when it reaches zero. The event would be common to all Sprites and you would use Sprite1 to access the Sprite itself as with other events.