graphics.setautogoto

[OddChild]

I have a suggestion for the command...

When making games that have sidescrollers where different images have to go off screen and so forth, it would be good if the

graphics.setautogoto

could be altered after it has been set into motion.

an example would be:

graphics.setautogoto image,20 - backgroundx, 300


backgroundx being the x of where the background is... that way you can have it moving to a static location off screen, but as the player moves in one direction the can catch up to the moving sprite... i hope that makes sense...

[hartnell]

Is this what you mean?

graphics.setautogo image_x, image_y, destination_x, destination_y ?

-hartnell

[OddChild]

i dont think so...

right now if you call a setautogoto you cannot alter the destination untill it gets there. if you try it does some wierd things... what would be nice, if you could make the final destination of the setautogoto changeable. For example, have it autogoto where the mouse is...

Or for the reason I am wanting to use it, have it go to a place that is offscreen.

Usually I have been using backgroundx and backgroundy. These basicly extend the x y axis to offscreen. So that an image isnt just x, y but x - backgroundx, y - backgroundy. This way as the background scrolls images are in the appropriate places. When using setautogoto it would be nice to be able to send the sprite to a non static location.

[Guilect]

I don't believe that there is anything wrong with the setautogoto command.
It can be dynamically update with new end points every call.
In the example below (try it) you move the mouse cursor over the screen and the box will follow it.
When you stop moving the mouse cursor the box stops at the cursor.


option explicit

dim bRunning
bRunning = True

dim CI

sub main()

if (graphics.initialize <> True) then exit sub

CI = graphics.CreateImage(60,60) ' this creates a new image 100 x 200 pixels
graphics.setx CI, 200 ' we locate the image's x position on the screen

graphics.RenderImage CI ' this allows us to draw onto the new image
graphics.setrect 0,0,100,200,&HFFFFFFFF
graphics.RenderNormal ' here we say we are done drawing to the image

graphics.setTitle "Demo - Create Image - press [ESC] to exit"

key.initialize
mouse.initialize

do while bRunning = True
if key.pressed(1) or key.pressed(0) = True then bRunning = False
   graphics.clear
    graphics.setautoGoto CI, mouse.x, mouse.y, 400
    graphics.setimage CI
   graphics.display
loop

key.terminate
graphics.terminate
   mouse.terminate
end sub

Call Main()


[u9]

I have a feeling he is talking about the same thing I was with the particle effects. I think he has a scrollable background and needs to keep the character "fixed" to the background, not the coordinate system of the screen. But I would guess it might work if, when ever you move the background, you stop the autogoto command, reposition the image, then restart the autogoto command.

A bit more info (advanced)
If you try the above mentioned, you'll soon figure out that you have to keep track of how far the image has traveled since you started the autogoto command as any subsequent calls to it have to be executed in the time remaining from the previous call. Otherwise the character will tend to slow down whenever you move the background. Like you can see with Guilect's example. The box slows down when it gets close to the mouse.

[Guilect]

you are right that all the graphic commands draw to screen co-ordinates.
I have started to formulate in my mind how a World co-ordinate 'offset' might be able to be applied globally to all images that get drawn to screen co-ordinates. (is it that simple?)

Let me dwell upon that for a while.

[OddChild]

u9 said:

I have a feeling he is talking about the same thing I was with the particle effects. I think he has a scrollable background and needs to keep the character "fixed" to the background, not the coordinate system of the screen. But I would guess it might work if, when ever you move the background, you stop the autogoto command, reposition the image, then restart the autogoto command.

exactly...

also using the current command wouldnt work because then if the image changes XY (final destination points) then it would arrive to the final in the same time as if it was far away...


example would be if the background changed, and the place is no longer onscreen and is 1,000 spaces away.. it would travel VERY fast and arrive at the final xy in the same amount of time as if it was 100 spaces away...

[u9]

admin said:

you are right that all the graphic commands draw to screen co-ordinates.
I have started to formulate in my mind how a World co-ordinate 'offset' might be able to be applied globally to all images that get drawn to screen co-ordinates. (is it that simple?)

Let me dwell upon that for a while.

At first, I thought this was a bad idea... but having "dwelt" upon it myself for a while, it might make sense. That way I wouldn't have to keep track myself where e.g. my space ships were relative to the camera. I just draw them at their position after setting the camera's position.

If you do implement anything like this, make sure it doesn't interfere with the understanding of newbies. Also make sure it is as optimized as possible, i.e. not trying to draw anything that is outside the screen entirely. Good luck.