Sprite attributes (properties)

[enonod]

The first suspect should always be the author and I failed to keep suspicion on me. I don't think I really thought this would be different from Delphi.
So one must always have an interim (or effectively a temp) to overcome this.

I appreciate your help and thanks for the snippet.

[Edit]Interestingly the information on the two labels switches around for the second of the two interupts.

[agraham]

Originally Posted by enonod

So one must always have an interim (or effectively a temp) to overcome this.

Sort of! Because there is no typing in Basic4ppc everything internally is a string.

Basic4ppc can cope with assignments of types between library objects

Spr1.Value = gw.Sprite1 ' assign a Sprite reference type

but internally variables and values are untyped so you can't cascade properties and methods as internally there is no reconition of types.

[enonod]

Thank you agraham, useful to know.

[agraham]

This version 1.22 of the Sprite library has the additional changes listed below.

Each Sprite has a boolean IsCollider property that defaults to True which determines whether a Sprite can collide with another Sprite or not. All Sprites will always collide with the boundary, I'll probably put an option for this in the next release.

GameWindow now draws itself properly as a Windows Control in response to Paint events. Previously it didn't which could lead to flashing and even not appearing under certain circumstances.

Each collision now hopefully only raises the collision event once. This change also increases performance as previously each collision possibility was checked twice, once for each Sprite. As each possibility is now only checked once this approximately halves the time taken for the collision checking.

Various invisible bits of internal tidying up that should not be visible.

[RichardW]

AGraham as you are updating the sprite library and putting in the option to turn off collisions another feature would be to add a z-order to sprites so smaller or higher priority ones could be positioned over less important or static sprites.

[enonod]

Thank you so much for your time and effort agraham, it is very much appreciated.

[agraham]

This is probably the last iteration as I can't think of anything else to add - can you?

Version 1.23 has the following changes.

Each Sprite has an IsVisible property, default True. This is complementary to the IsActive property. An inactive Sprite is not drawn, does not move and does not take part in collisions. An active invisible Sprite acts normally except that it is not drawn.

Each Sprite has an IsContained property. If True the Sprite will collide with the game window boundary, if false it won't.

GameWindow now has SpriteOnScreen(index) and SpriteOnScreenID(id) methods that return True if the specified Sprite is positioned in the game window or False if it is not. This refers to the Sprites' position, not its' visibility.

GameWindow now has a SpriteReplace(Sprite, index) method.

More internal tidying up that should not be visible.

Originally Posted by RichardW

add a z-order to sprites

To efficiently provide an explicit z-order for individual sprites is difficult as the code needs to have high performance as it is run many times per second. However there is already an implicit z-order as sprites added later are always drawn after earlier sprites. To keep a Sprites' place in the drawing order you could use the new SpriteReplace method.

[enonod]

I think this is great, and I can't think of anything else that could enhance the use of sprites, (oh, except the obvious help update eventually).
Thank you again very much for making the system so much more useful.

The above statement is not binding for all time.

[RichardW]

I have uploaded a program which will trigger an exception when running the compiled (optimized) code. To cause the error simply mouse click on the egyptian delta province. This just cycles thru a series of coloured images but as compiled it will "Continue" only after displaying an annoying error message.

I have another interesting issue. I position a province sprite on the map and then drop on a city sprite on top of it. If I click the city I get 2 mouse collision events; first the underlying province and then for the city itself. This seems strange as I would expect the city first, then the province. I can get around this by using images but just curious over this behaviour.

The flashing is truly gone. I was going mad trying to figure what in my map scrolling was causing that. Thanks for fixing it.

[enonod]

There seems to be a download problem, the file has some ID on the front and registers as corrupt.
4171d1246351689-sprite-attributes-properties-sprite1.23.zip