Sprite attributes (properties)

RichardW

Member
Licensed User
Longtime User
I just downloaded and unzipped it myself and it runs fine (not counting the exception).

Here is a zip of with just the source and the images without the exe and dlls.
 

agraham

Expert
Licensed User
Longtime User
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
I don't see that, it downloads fine for me, both by left clicking the link and right clicking then selecting "Save Target As".
 

agraham

Expert
Licensed User
Longtime User
This has grown into a much more extensive exercise that I anticipated!

Version 1.24 has the following changes.

CollisionMouse events now occur in the order you might expect. That is Sprites added later, and so drawn on top of other Sprites, raise the event first. Sprites may now be modified in the CollisionMouse event without the possibility of raising an exception. This is also true for the other events.

Previously the Tick routine drew the Sprites then moved them ready for the next Tick. This left the position of the Sprites as reported by their X and Y properties different to their screen position. This made clicking a fast moving Sprite difficult as the user saw the current screen position but the collision test saw the next screen position. Now Tick moves all the Sprites then draws them leaving their reported X and Y positions equivalent to their screen positions.
 

Attachments

  • Sprite1.24.zip
    7.4 KB · Views: 219

RichardW

Member
Licensed User
Longtime User
thanks for the great work agraham. the effort is appreciated. sprite.dll is now a really useful library for games development.
 

agraham

Expert
Licensed User
Longtime User
Attached is a provisional help file for version 1.3. There is a description of the additions and changes in the Overview topic.

I will wait a few days to see if anyone comes up with any isuues or requests for changes then I will pass the library and help sources over to Erel for issue as an official library. The official release will include the source code so that the library may be merged when optimised compiled.
 

Attachments

  • SpriteHelp1.3.zip
    25.4 KB · Views: 227
Last edited:

enonod

Well-Known Member
Licensed User
Longtime User
Thank you so much agraham, anything extra with sprites is a Godsend. The movement change is especially good news, even though I was unaware of the cause of the difficulty.
I don't know what happened with the download, 1.24 and help both work fine.
Well done.

[Edit] Weeellll, there is one question. Would it be possible to attach data to a sprite? For example an array or list or perhaps a pointer, but not so good.
 
Last edited:

agraham

Expert
Licensed User
Longtime User
Version 1.25 adds two properties to a Sprite, Data and DataArray. These may be used to hold data individual to each Sprite.

Sprite.Data : String [I/O] : Gets or sets a single data item.
Sprite.DataArray : String() [I/O] : Gets or sets a single dimensioned array of data items.

A small demo is in the archive.
 

Attachments

  • Sprite1.25.zip
    8.1 KB · Views: 237

enonod

Well-Known Member
Licensed User
Longtime User
Version 1.25 adds two properties to...
When I read that I thought I had missed it in some very old version, then I read it again...
WoW this is marvellous, thank you.
Have you ever been in the situation where a fruit machine pays out and gets stuck... then every coin you put in causes another payout?
I notice with 1.25 that there are 4 digits left!!

Much obliged, I'm thinking hard...
I haven't tried this new bit yet and can't think quick enough to remember 'data items' types, so I will ask. Does the data item in the array permit an x,y coord as one entry?
 

agraham

Expert
Licensed User
Longtime User
Does the data item in the array permit an x,y coord as one entry?
No, as it's a single dimension array but you could use

arr(0) = x & "," &y

but it's more efficient just to use individual elements. You could use a structure, which is actually an array, to make it easier.


Dim Type(x, y, z, name)Spritedata
....

Dim Spritedata(4) ' make a new array
... ' set it up
Sprite.DataArray = Spritedata() ' assign it to a Sprite
 

enonod

Well-Known Member
Licensed User
Longtime User
Thank you agraham that is excellent.
 

agraham

Expert
Licensed User
Longtime User
Yet another version! While playing with square Sprites without transparency I found problems with fragments of the edges of Sprites being left behind. The problems were masked in the Demo because the edges of the Sprites there are mainly transparent and the displacements on each tick were only a few pixels. These are mainly solved (I hope!) but a GameWindow method is now provided to erase a Sprite from its' current position in cases where it might be necessary.

To provide more control over a Sprites' animation a Sprite now has a FrameCount property to get the number of frames in the animation and a boolean FrameForwards property to get or set the direction of animation. Previously the direction could be set by the SetFrameDirection method but could not be read back.

To allow the animation to be changed a Sprite now has LoadBitmap and LoadFile methods. The parameters for these are the same as for New2 and New3.

GameWindow now has an EraseSprite(index) method for use when manipulating a Sprite in some way might leave fragments of it visible. This might be before changing the animation to a smaller set of bitmaps or before moving a Sprite by changing its' X or Y properties.
 

Attachments

  • Sprite1.26.zip
    8.2 KB · Views: 206
Last edited:

enonod

Well-Known Member
Licensed User
Longtime User
I use square sprites without any transparency and have never noticed anything odd. They move constantly.
If moving to x,y would this routine need to be called for every movement and will it slow it down (if the artefacts are present)?

A question for your experience and knowledge of how sprites work. I know this can be done outside the sprite, but could there be any advantage, speed wise or any other way, if a sprite had a destination property (dX,dY) such that the sprite would automatically travel toward it and upon arrival trigger an event?
My thinking is that in this way the testing of each pixel position passed would be by internal code rather than user (external) code.
 

agraham

Expert
Licensed User
Longtime User
I ... have never noticed anything odd
Trust me :), between versions 1.21 and 1.25 there was a problem even if you didn't notice it. I don';t know if it was in earlier versions but I have changed a lot of the library internally and am not going back to find out!

If moving to x,y would this routine need to be called for every movement
Depends what you mean by movement. Basically if you are going to assign to X or Y then you may need to erase the sprite first as the library will now no longer know where it was and so won't erase it properly. If you are letting it move itself each tick you don't need to do it. It will be obvious if it is needed.

but could there be any advantage, speed wise or any other way, if a sprite had a destination property (dX,dY) such that the sprite would automatically travel toward it and upon arrival trigger an event?
Yes, it should be a lot faster. I'll have to think about whether such a facility could fit in the present architecture of the library.
 
Last edited:

enonod

Well-Known Member
Licensed User
Longtime User
Thank you again for your valuable time.
 

agraham

Expert
Licensed User
Longtime User
if a sprite had a destination property (dX,dY) such that the sprite would automatically travel toward it and upon arrival trigger an event?
This version includes such an event. However I haven't implemented the "automatically travel toward" bit, you will have to calculate and define its direction yourself.

Version 1.27 changes are as follows.

GameWindow has a new CollisionDestination event.

Sprite has new IsAnimated, DestinationX, DestinationY and HasDestination properties.

There is a help file describing the changes in the archive.
 
Last edited:

enonod

Well-Known Member
Licensed User
Longtime User
Very many thanks agraham. I just need time to try all this.
 

enonod

Well-Known Member
Licensed User
Longtime User
I am having difficulty with the data array but it must be me.
Dim Type(x, y, z, name)Spritedata
....
Dim Spritedata(4) ' make a new array
... ' set it up
Sprite.DataArray = Spritedata() ' assign it to a Sprite
The second Dim gives the error that SpriteData is already in the dictionary.

I tried Dim Type(x,y)SpriteData(4) which is OK but
Sprite.DataArray = Spritedata() gave the error...
Object of type 'System.String[,]' cannot be converted to type 'System.String[]'

Can you advise please

[Edit]The destinations work a treat!!
 
Last edited:

agraham

Expert
Licensed User
Longtime User
The second Dim gives the error that SpriteData is already in the dictionary.
I can't see anything wrong with that code. The only way I think you can get that error is if two Dim statements for the same array are in Sub Globals, only the Type statement must be in there. If it persists you will need to post some code that shows the error so I can see the context. Look at the DataDemo.sbp in the archive which contains that same code.

I tried Dim Type(x,y)SpriteData(4) which is OK
Actually it's not. That makes SpriteData into a two dimensional array hence the comma in "String[,]" in the error message. The library expects a single dimension array, hence the error.

EDIT:- The occurrence of the "cannot be converted error" implies that the "Dim SpriteData(4)" statement is not being executed before "Sprite.DataArray = Spritedata()" as that converts it back to a one dimension array. Looks like the execution sequence is wrong. Each Sprite needs its own array. If you don't re-Dim it for each Sprite they will share the same array - which you might or might not want to do, most likely not!
 
Last edited:

enonod

Well-Known Member
Licensed User
Longtime User
Yes I did have both Dim's in Globals Sub. My problem is one of comprehension. I cannot seem to get to grips with this 'sort of indirection' or 'temps' that we mentioned earlier, instead of direct.
I don't see why each of the Type(x,y,z) doesn't become one entity and then placed in a single dimension.
I am trying to assign points((2,3),(3,7)...) to a sprite. That is why I did what I did.
I cannot seem to translate that using the example.
Sorry to be thick but perhaps I could ask for your help on that specific problem?

[Edit]
I also tried in app_start...
Dim points(4)
Points(0).x= 49
Points(0).y=1

[Edit 1]
The example line 35 'seems' to only permit one array element of x,y,z but it is dimensioned for 3, how to add Data(1)??
In the example line 24 I don't see why...
& CRLF & "Array(1) = " & arr(1))
cannot become...
& CRLF & "Array(1) = " & spr.DataArray(1))

Is it for the same reason as Spr.Value = Spr1.Value ?

[Edit 2]
It looks to me that x,y,z have been converted to data(0)=x,...(1)=y etc. Which means that there is only one true element permitted as I mentioned above so...
Spr.DataArray = data() where data is as above
 
Last edited:

agraham

Expert
Licensed User
Longtime User
A structure is a short hand for one dimension of an array to make access to elements of the array more intuitive
B4X:
Dim Type(x, y, z, name)Data
...
Data.x = 0
Data.y = 1
Data.z = 2
Data.name = 3

Is equivalent to 

Dim Data(4)
...
x = 0: y = 1: z = 1: name = 3
Data(x) = 0
Data(y) = 1
Data(z) = 2
Data(name) = 3
For an array of strutures
B4X:
Dim Type(x, y, z, name)Data(2)
...
Data(0).x = 0
Data(0).Y = 1
Data(0).z = 2
Data(.).name = 3

Is equivalent to 

Dim Data(2,4)
...
x = 0: y = 1: z = 1: name = 3
Data(0,x) = 0
Data(0,y) = 1
Data(0,z) = 2
Data(0,name) = 3
In these examples Data is a variable, Dim creates the array and assigns it to the variable. If you want a new array for each Sprite you need to do a Dim for each one to create a new array. The old array still survives if you have assigned it to a Sprite and you can assign it back to the array variable by

B4X:
spr1.Value = gw.Sprite1
Data() = spr.DataArray
sprname = Data.name ' or sprname = Data(3)
 
Top