3. No, since you always draw on top of the screen buffer there is no way of returning short of saving something which keeps track of what was on the screen and redraws it all after resetting the buffer with a fill color or something.

4. The sim is working with a much higher speed than the device itself, sloppy programming...

__________________"If you are good enough at English to apologize, then there is no need to." - A good friend of mine
Discovered something about the X-Fi2 you think others may not know? Post it here so others can learn about it!
Have a question about X-Fi2 apps? Consult the FAQ before creating a thread about it.Like my work? Tell your friends. Don't like it? Tell me so I can improve. ^.^

Thank you for 3-4 Habhome.
I do not follow 4. Sloppy programming... I can see no way to control the process. I have a loop that does something presumably at its maximum speed. It does it. Presumably one programs for the device and not the simulator. My point is really that because some people might only have the simulator, I got the feeling (maybe wrongly) from reading, that one should try to cater for them also.

i.e. If I had a loop that places a sprite on the screen and then moves it, I would expect not to have to play with timing. Wrong?
I am a little confused. Any further help?

1. You are right that os.wait(10000) should result in a wait for 10 seconds, if it doesn't, then there may be something else causing another wait, or it's a typo?

2. For what I understand, the wait is needed to keep some CPU-time left for the player to do stuff in the background. Perhaps playing music, and I guess for the OS as well. I read somewhere on this forum that 30 milliseconds was advised to use, although 10 is fine also. My apps also freeze if I use less than 10, I don't know why..

3. As Habhome said, you will have to re-draw the parts that have changed. This player doesn't have a screenshot function or something. It is possible to save every pixelcolor, but when redrawing all those pixels the player freezes (got this info from the paint thread.) So yeah you will have to draw over the stuff that has changed.

4. Do you mean os.time? os.date? They give different outputs I know, but os.wait and os.sleep just work the same on the sim and player for me.

Thank you for 3-4 Habhome.
I do not follow 4. Sloppy programming... I can see no way to control the process. I have a loop that does something presumably at its maximum speed. It does it. Presumably one programs for the device and not the simulator. My point is really that because some people might only have the simulator, I got the feeling (maybe wrongly) from reading, that one should try to cater for them also.

i.e. If I had a loop that places a sprite on the screen and then moves it, I would expect not to have to play with timing. Wrong?
I am a little confused. Any further help?

I meant sloppy programming from Creative's sim developer team. They didn't match the CPU speed of the simulator to the actual device. So for example the time to actually put your image on the screen differs from the sim and device, so you have to make two versions of a game for it to e played with sim or device in terms of that.

And well, my main goal is to create simple apps to entertain yourself with on the go and easily stop at any time. There is no use making my games for someone who has a computer, there are already so many games for that doing what we make.

__________________"If you are good enough at English to apologize, then there is no need to." - A good friend of mine
Discovered something about the X-Fi2 you think others may not know? Post it here so others can learn about it!
Have a question about X-Fi2 apps? Consult the FAQ before creating a thread about it.Like my work? Tell your friends. Don't like it? Tell me so I can improve. ^.^

Thanks Brett_val, I guess my wording is sloppy; timing in 4 means speed of screen refresh not time as in time. I have no wait between screens. I move something as fast as the system will permit and it is eratic but much more so on the simulator.
I am presuming from Habhome and now you, that the os.wait simply stops the thread and so will not affect the screen updates or speed of movement.
I can see no way to overcome the jerkiness.

Thanks Brett_val, I guess my wording is sloppy; timing in 4 means speed of screen refresh not time as in time. I have no wait between screens. I move something as fast as the system will permit and it is eratic but much more so on the simulator.
I am presuming from Habhome and now you, that the os.wait simply stops the thread and so will not affect the screen updates or speed of movement.
I can see no way to overcome the jerkiness.

The wait stop the entire app, it will stay in that code line until the wait is over and then continue on to the next. To prevent erratic movements you should only redraw the parts needed and make sure to make big enough movements every time. You don't have to move it 1 pixel at a time, it will still look smooth with more than that. For example I slide my stats bar in Paradise Slots with a movement of 5 pixels at a time. And the info bar with 15 pixel at a time.

__________________"If you are good enough at English to apologize, then there is no need to." - A good friend of mine
Discovered something about the X-Fi2 you think others may not know? Post it here so others can learn about it!
Have a question about X-Fi2 apps? Consult the FAQ before creating a thread about it.Like my work? Tell your friends. Don't like it? Tell me so I can improve. ^.^

Thank you both. I have enough to continue experiments.
No I don't have a killer app, but I will be posting one shortly and in the first instance, although it will work, I will welcome advice from those more experienced on this device. There are a lot of limiting restrictions.
One I notice is that if text is written and then overwritten with the same coordinates, it does not write exactly in the same place. etc. etc. but I do think it is a great device.