R RichardW Member Licensed User Longtime User Jun 30, 2009 #21 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.
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 Jul 1, 2009 #22 enonod said: 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 Click to expand... I don't see that, it downloads fine for me, both by left clicking the link and right clicking then selecting "Save Target As".
enonod said: 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 Click to expand... 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 Jul 1, 2009 #23 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 Sprite1.24.zip 7.4 KB · Views: 531
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.
R RichardW Member Licensed User Longtime User Jul 1, 2009 #24 thanks for the great work agraham. the effort is appreciated. sprite.dll is now a really useful library for games development.
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 Jul 2, 2009 #25 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 SpriteHelp1.3.zip 25.4 KB · Views: 544 Last edited: Jul 2, 2009
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.
E enonod Well-Known Member Licensed User Longtime User Jul 2, 2009 #26 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: Jul 2, 2009
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.
agraham Expert Licensed User Longtime User Jul 3, 2009 #27 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 Sprite1.25.zip 8.1 KB · Views: 515
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.
E enonod Well-Known Member Licensed User Longtime User Jul 3, 2009 #28 Version 1.25 adds two properties to... Click to expand... 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?
Version 1.25 adds two properties to... Click to expand... 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 Jul 3, 2009 #29 enonod said: Does the data item in the array permit an x,y coord as one entry? Click to expand... 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 said: Does the data item in the array permit an x,y coord as one entry? Click to expand... 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
E enonod Well-Known Member Licensed User Longtime User Jul 3, 2009 #30 Thank you agraham that is excellent.
agraham Expert Licensed User Longtime User Jul 3, 2009 #31 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 Sprite1.26.zip 8.2 KB · Views: 497 Last edited: Jul 3, 2009
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.
E enonod Well-Known Member Licensed User Longtime User Jul 3, 2009 #32 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.
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 Jul 3, 2009 #33 enonod said: I ... have never noticed anything odd Click to expand... 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 Click to expand... 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? Click to expand... 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: Jul 3, 2009
enonod said: I ... have never noticed anything odd Click to expand... 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 Click to expand... 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? Click to expand... 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.
E enonod Well-Known Member Licensed User Longtime User Jul 4, 2009 #34 Thank you again for your valuable time.
agraham Expert Licensed User Longtime User Jul 4, 2009 #35 enonod said: if a sprite had a destination property (dX,dY) such that the sprite would automatically travel toward it and upon arrival trigger an event? Click to expand... 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: Jul 4, 2009
enonod said: if a sprite had a destination property (dX,dY) such that the sprite would automatically travel toward it and upon arrival trigger an event? Click to expand... 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.
E enonod Well-Known Member Licensed User Longtime User Jul 5, 2009 #36 Very many thanks agraham. I just need time to try all this.
E enonod Well-Known Member Licensed User Longtime User Jul 6, 2009 #37 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 Click to expand... 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: Jul 6, 2009
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 Click to expand... 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!!
agraham Expert Licensed User Longtime User Jul 6, 2009 #38 enonod said: The second Dim gives the error that SpriteData is already in the dictionary. Click to expand... 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 Click to expand... 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: Jul 6, 2009
enonod said: The second Dim gives the error that SpriteData is already in the dictionary. Click to expand... 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 Click to expand... 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!
E enonod Well-Known Member Licensed User Longtime User Jul 6, 2009 #39 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: Jul 6, 2009
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
agraham Expert Licensed User Longtime User Jul 6, 2009 #40 A structure is a short hand for one dimension of an array to make access to elements of the array more intuitive Code: 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 Code: 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 Code: spr1.Value = gw.Sprite1 Data() = spr.DataArray sprname = Data.name ' or sprname = Data(3)
A structure is a short hand for one dimension of an array to make access to elements of the array more intuitive Code: 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 Code: 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 Code: spr1.Value = gw.Sprite1 Data() = spr.DataArray sprname = Data.name ' or sprname = Data(3)