In serious trouble with surface

[Donone]

I have been told about surfaces but have obviously failed to grasp an essential ingredient. I am trying to create a surface and then attach it to a sprite and move it.
None of these occur, it is drawn on the screen (presumably by rendersprites) at 0,0 and I can't move it.
If I change 0,0 it draws elsewhere.
The 0,0 were supposed to be relative to the surface not the screen.
What stupidity have I introduced or failed to?

Surface$=NewSurface(width$,height$);
old$=SetRenderTarget(surface$);
g_beginScene; //to paint on it
g_FillRect(0,0,width$-1,height$-1, g_RGB(255,0,0));
g_update;
SetRenderTarget(old$);

Sp$=NewSprite(null);
SetSpriteSurface$(Sp$,surface$,1,0);

[Mike Halliday]

Is there an issue with the SetRenderTarget command?

I ran your code and was bombed out of PPL. - I also ran the NewSurface example from the help and was also bombed out of PPL.

Any ideas Alain?

[Donone]

Thanks for the time on this Mike. I didn't have any bombing problems so suspect the SetRenderTarget is OK.
I tried my code without begin/end scene and it didn't make any difference, so I have something seriously wrong with my comprehension.

[PointOfLight]

When you attach a surface to a sprite, the surface will be drawn wherever the position of the sprite is.* If you were to do a SetSpriteX and / or SetSpriteY on sp$ after you assign the surface to it, the surface will be drawn at the values passed to SetSpriteX / SetSpriteY.* Also, since you're not wanting to render the surface to the screen directly, you don't need g_beginscene and g_update.

@Mike: were you trying to run the code posted here and the NewSurface code on the PC or PPC?* On the code from this thread, did you populate values for width$ and height$?* On the NewSurface example, did you provide a valid path for the SaveSurface routine?

I've attached a simple demo that runs both the NewSurface example and the code in this thread.* For the NewSurface code, hit the Up arrow on your keyboard.* For the code from this thread, hit the Left arrow key.* To exit, hit the Down arrow key.

[br]1196437981_49_FT8181_surfacetest.zip

[Donone]

I don't know if I misunderstand but after assigning to sprite I did change x,y of sprite and it didn't move, only if I change the coords of fillrect.
Any further help would be appreciated I have been on it for four hours!!

Having seen your test...
I have not done this code in WM_TIMER, but didn't assume I had to.

[Donone]

If you are still available I used your code and it moved, this was my actual code and I can't see why it doesn't.
S$ is the surface with rectangle
// create the sprite that will display the surface and set values
Sprite$ = NewSprite(NULL);
&Spr$=Sprite$;
Spr.Surface$=S$;
Spr.x$=150;
Spr.y$=150;

[PointOfLight]

If you modify a sprite "by hand" (in other words, do a sprite.property$ = value) instead of using one of the SetSpriteXXX functions, you must make a call to ProcessSprites in order for those changes to take effect.* Check out the help file for how ProcessSprites works.* And you don't have to do the code in the WM_TIMER event.* That's just where I chose to do it.

[Donone]

Thank you PointOfLight, that was worth four hours. It is amazing how lack of knowledge of one simple thing can screw everything.
I am now getting one sprite to work as expected BUT I have a second at 0,0 on the screen.
Just help me this one further step please.

[PointOfLight]

Did you create two sprites, or are you just seeing two images?* Did you remove the g_beginscene and g_update calls from around g_fillrect?

[Donone]

Removed the scene stuff and I only made one sprite but have two images, as if the rectangle is drawn to screen and then added to the sprite and rendered.

[PointOfLight]

Any chance you'd be able to post your code so I can try running it?* I didn't have that problem.

[Donone]

Yes, give me ten minutes, its convoluted and in a mess (probably the cause)

[Donone]

@PointOfLight
My undying thanks to you. I have found the problem while trying to get my code in a reasonable form for your eyes.

I was creating an object within an object. The first I did yesterday (wrongly creating a sprite) and the second part today which thanks to you is correct and should be a sprite. Yesterdays object was (and should be) on the same surface and was set to 0,0 If that makes sense? I got two sprites.

Thank you for your valuable time.

[Mike Halliday]

Eric,

Yes i did substitute the width$ and height$ on this code and I did provide a path for the saveSurface on the help code - It's my weird machine - probably why my stuff works for me and no one else! Rofl.

@Donone - Glad you finally sorted it out! :D - Are we gonna see something great from you using this technique then? :)

[Donone]

@Mike
Well I don't know about great but I am working on what I think is a good example (fairly simple also) of Class usage, and hope in a day or two to have it and a writeup on classes and their use and advantages for even simple tasks which might be of use to someone. I want to avoid the usual blurb of big words and technical explanation which often frighten people off never to return.

Classes are fine but I can't get used to these darn surfaces. I hope I have it now.

[Mike Halliday]

How odd.

Eric's code works fine on my machine - Creates the test bitmap and puts the red square on the screen.

Checking the code it is the same as the .Help file that caused me grief!!!

Now I'm confused. - I knew surfaces worked because thats what I used in the ZOOM snippet!

[Donone]

There are a lot of odd things and oddly enough it usually turns out to be us.
Who can say what the cause is, tiredness, overwork, staring at a screen...

[Mike Halliday]

In my case I think its stupidity! :) DOH!