Sprite attributes (properties)

Thank you for your time, please be patient with me.
At the risk of upsetting you, I understand the arrays and I understand the structures but what I am trying to get at is that, as shown in your first example above, the permitted one dimensional array for the sprite is taken up by the structure being 'equivalent' to the 1D array and thus using up all the entitlement the sprite data offers.

I had thought that each structure would actually be usable as an entity (item, variable) which could then be placed in a single element of a 1D array, so that when asking for say, sprite.DataArray(1) I would get back the structure x1,y1,z1, and sprite.DataArray(2) give x2,y2,z2.

I presume from what you say that what I have actually asked for cannot be done because it is 'equivalent to' a 2D array. I 'thought' that you had said, when this data issue began, that I could get around the 1D by using structures and my brain supplied the result mentioned in the previous para, but in fact it seems we must have been at cross purposes.

Now, if what I expected is available then I have failed miserably to comprehend how to obtain the second and subsequent complete structure items (sets of x,y,z) from the sprite data array elements.
:sign0085:
[Edit] So I should perhaps use a 1D array that holds... x,y,z,x1,y1,z1,... and step in threes which is an inelegant equivalent.
Should I have taken this to a different forum?

enonod said:

permitted one dimensional array for the sprite is taken up by the structure being 'equivalent' to the 1D array

Click to expand...

Exactly!

I had thought that each structure would actually be usable as an entity (item, variable) which could then be placed in a single element of a 1D array,

Click to expand...

Nope, Basic4ppc isn't that complicated! No entities, objects, variable references etc. - just untyped values as singletons or arrays of up to three dimensions.

So I should perhaps use a 1D array that holds... x,y,z,x1,y1,z1,... and step in threes

Click to expand...

Yup!

Thanks for that confirmation. It looks as though the stepping along the array is therefore more versatile than a structure for this purpose, because by altering the steps, more 'equivalent' dimensions 'appear' to be available. More ineligant to step through a retrieved structure.
Sorry, but I obviously misunderstood what I thought was your 'way around' 1D.
Everything works fine, and thank you again for all the extras.

enonod said:

More ineligant to step through a retrieved structure

Click to expand...

No, you can treat a structure as an array to iterate it if you want. The structure definition still serves to document the items.

Yes, except that this is only good for getting data out that was previously put in say, manually. using it to put in, puts the same data in x1,x2,x3 etc.

That trivial point aside, I see that there seems little in it either way.

To obtain x,y pairs I have...


Everything you have provided works well, it is only my expectations from what is available in other languages.

I've tried the newest 1.27 but there are some problems.

Moving a sprite leaves a trail.
EraseSprite didn't do anything.

I tried 1.25 as it seems to be before a change that could have been the cause.
There were no trails but there was alot more flashes.

There is a flicker and a flash with the original version.
The flicker is gone with 1.25 but the flash is worse, this is while a form is activated after it has been hidden or minimized.

I've tried many methods to resolve this which don't work with the new versions.

Setting the BackColor to black is a help, the flicker is less noticeable, which appears to have been changed from white to black in the new versions.

Running method Hide on LostFocus and Show on GotFocus, with Door library, also helps.

Setting gw.Tick anywhere where it could help, Resize, Paint, Focus events. Collision events and MouseDown,Up,Move on the GameWindow Form.

Hopefully this can help with any future updates.

Unfortunately for now I have to use the old version.

Can you post an example that show these problems?

Setting gw.Tick anywhere where it could help, Resize, Paint, Focus events. Collision events and MouseDown,Up,Move on the GameWindow Form.

Click to expand...

I'm sorry but I don't inderstand what this means.

I've changed the Sprite redrawing mechanism so that it should not now be possible (famous last words!) for fragments of Sprites to be left behind and for this reason I will remove EraseSprite from the next version as the library should now take care of erasing sprites it in all circumstances.

The flicker is gone with 1.25 but the flash is worse

Click to expand...

I don't understand the flicker/flash problem as in version 1.22, and ever since, the game window has been drawn like a proper Control in response to Windows Paint events. Is this on desktop or device? Before I post the next version can you either post some code that shows it or give me a more complete description of the effects you are seeing and an explanation of what is happening when you see them.

Version 1.28 (I'm going to run out of sub-version numbers before long I should have started at 1.201!) has the following changes.

GameWindow.EraseSprite removed as it should now never be needed as the library now keeps a record of where and at what size each sprite was drawn and uses that data to erase it when required.

Testing on the device I found that adding a Sprite caused a noticeable pause. This was because adding a Sprite builds an array of bitmaps that hold the sprite animation. This process can take an appreciable amount of time on the device, even a powerful one like my iPAQ 214, for an animation with more than a couple of frames. So I have added a Sprite.Bitmaps property that lets you get and set a sprites' bitmap array and the Sprite FrameCount, Height and Width are now writeable to allow direct assignment of a new animation to an existing Sprite. This process is encapsulated in a new Sprite.LoadFrames method and Sprite.New4 initialises a new Sprite using a bitmap array.

So you can now keep "stock" Sprites with their animation loaded and use them to initialise new Sprites. As well as speeding up adding Sprites this also has the advantage of using less memory as all the Sprites with the same animation would share the same bitmap array.

GameWindow is partially AutoScale aware in that it's window size is automatically scaled. However there is no other AutoScaling done. I started but it got too complicated with Sprites so I gave up. I might have another look before issuing the final code but I don't promise anything.

I haven't been able to observe any flashing, as reported by eww245, while hiding and showing a form on either the device or desktop - and in any case I don't think there is anything I could do to alter it as the repainting of the GameWindow is being done as it should be for a Control.

agraham said:

I haven't been able to observe any flashing, as reported by eww245, while hiding and showing a form on either the device or desktop - and in any case I don't think there is anything I could do to alter it as the repainting of the GameWindow is being done as it should be for a Control.

Click to expand...

Well this new version fixed my issues.
I use this with a WM5 Pocket PC.

As far as the events, with door library i've set for the gamewindow, Paint, MouseUp,Down and MouseMove.

I use paint to start the Tick, this was useful to help with some of the filcker.
The mouse events are part of the application to allow moving the sprite, which I also set gw.Tick to help.

For the Form I set Resize event for the gw.tick, as Paint does not work and appears to be overidden in the b4p Enhanced Form.

For some reason the GameWindow would flash white even though it is set to black which I can see through .Net Reflector.
But I did set the backcolor to black to also help control the color of the flicker.

Anyway I've turned it all off except for the Ticks in mouse and paint events.

Thanks for the new version, this one looks ready for release.

Erik

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!

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.

enonod said:

Is there an explanation for this please?

Click to expand...

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.

Thank you agraham. Very clear.

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?

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?

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.

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.

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.

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.