How to have various objects moving at different speeds ?

For example on videogames, there are several objects movinga around the screen in different patterns and different speeds at the same time.
How is this achieved ? On Xojo using threads I suppose…
Just wondering

for each frame, run over the array for objects. Each object may have properties with velocity and so change it’s position.
So for each frame each object moves and when you redraw frame, it looks like they move.

[quote=124194:@Horacio Vilches]For example on videogames, there are several objects movinga around the screen in different patterns and different speeds at the same time.
How is this achieved ? On Xojo using threads I suppose…
Just wondering[/quote]
If you are looking into making games. I suggest you either develop your own game engine or use something else. AFAIK there is no full game engine out but you can try and base your engine off of the X3 engine. http://xojo3d.com/download.php

If you are not particularly looking to create video games then Xojo without a game engine may suite your needs and Christian’s advice should be taken. Use the paint event of a canvas to draw to the screen and use a timer with the interval of 1 and invalidate the canvas with that to redraw.

It sounds like you are just getting started with Xojo. If you find that Xojo does not suite your needs you can follow my Facebook page and get updates on a game development tool which I am working on.

I hope I don’t sound rude about advertising my product. I am particullaly trying to discourage this person from using Xojo. I am just trying to help this person choose the right tool for there needs. I strongly believe that if Xojo suite your needs its a great product but if it doesn’t then I won’t be quite about it.

Not directing this at anyone just saying I am trying to give my tuppence worth (or as the American’s call it ‘my two cents’) if redirection from Xojo is necessary.

HSH

No, no games for me.
I was just wondering and trying to understand what are the mechanics of simultaneous movement of different objects on screen. from a programming language perspective. What system it’s needed…

this is not true simultaneous, this is a basically a for-next circuit.

[quote=124225:@Horacio Vilches]No, no games for me.
I was just wondering and trying to understand what are the mechanics of simultaneous movement of different objects on screen. from a programming language perspective. What system it’s needed…

this is not true simultaneous, this is a basically a for-next circuit.[/quote]
I am pretty sure that the objects appear to move simultaneously because once the instructions are processed, they get drawn to the screen every frame at the same position.

[quote=124225:@Horacio Vilches]No, no games for me.
I was just wondering and trying to understand what are the mechanics of simultaneous movement of different objects on screen. from a programming language perspective. What system it’s needed…
[/quote]

The human eyes perceives 1/30 th a second images in succession as one object in motion. That is the way television works. Movie is only 1/25th a second. Regular computers never do anything simultaneously, but in rapid succession. That is dues to the Von Neuman architecture von Neumann architecture - Wikipedia .

What you perceive as simultaneous movement is in fact a very fast succession of images displayed by programs through whatever form of timing available. For-Next being one of these structures only.

The screen itself is not really simultaneous. Although modern screens do not show the same scanning spot as cathodic ones did in the past, their content is electronically refreshed through multiplexed columns and rows.

In Xojo like inside a lot of multitasking operating systems, threads are themselves nothing but rapid switch of the operations between different threads. Thread (computing) - Wikipedia

Multicore processors do process instructions in parallel, but programmation is extremely complex because not only operations have to be dispatched between cores, but they have to be reconciled at the end to produce results. And in fine, bus and memory remain sequential. Multi-core processor - Wikipedia

Christian did give you the principle used by modern games to let you believe objects are moving simultaneously.

Here’s an explanation of the way I’ve done this. I don’t know enough about Xojo yet to give you the exact code (just downloaded it recently, still learning):

  1. Create a Type (or Struct or Class) which contains the following variables, all of them Floating Point (ie: DOUBLE or SINGLE):
    ChangeInX – this number of how far the object moves in the X (horizontal) direction each frame.
    ChangeInY – same thing but for Y (vertical) direction.
    XPosition – X Location on the screen. Do not “round” it, keep the decimals!!
    YPosition – Same thing but for Y Location.

  2. Create an Array of the above Type. This will hold each of your objects.

  3. Each Frame (each time you re-draw the screen), use a FOR loop to go through all the objects in your Array.
    For each object:
    XPosition = XPosition + ChangeInX
    YPosition = XPosition + ChangeInX

  4. You would also draw the objects in your FOR loop. Since X and Y positions are Floating Point, and most Graphics routines need Integers, you’ll need to convert them. The code would be something like this (again this may not be correct for Xojo, I don’t know Xojo’s exact syntax yet):
    X and Y are Integers.
    X=CType(XPosition,Integer)
    Y=CType(YPosition,Integer)
    DrawObject Object_Number, X, Y

  5. Wait for the next Frame (or next Tick of the Timer), then repeat steps 3,4,5.

So to make the Objects move at different rates, you simply set the object’s ChangeInX and ChangeInY to different values.

For example, you want Object #1 to move slowly to the right and quickly down:
Obj(1).ChangeInX = 0.1
Obj(1).ChangeInY = 1.3

You want Object #2 to move very quickly both Left and Up:
Obj(2).ChangeInX = -3.0
Obj(2).ChangeInY = -3.0

You have to experiment with the values to see exactly what ChangeInX/ChangeInY values will do what you want them to do. Easiest thing is to do some simple math using the Frame Rate for your game/graphics engine and the size of the screen. For example, if your engine runs at 60 frames per second, and the screen is 640 pixels wide, you know that you’d need a ChangeInX of about 10.67 to get an object to move across the screen horizontally in 1 second (640/60 = about 10.67).

The same theory works for basic movement 3D games, you’d just add a ChangeInZ and a ZPosition variable. But in 3D you also have to deal with Rotating the object to make it look correct. That gets complex!!!

OOPS!! A Typo. The “code” for step 3 should read:

XPosition = XPosition + ChangeInX
YPosition = YPosition + ChangeInY

[quote=124225:@Horacio Vilches]No, no games for me.
I was just wondering and trying to understand what are the mechanics of simultaneous movement of different objects on screen. from a programming language perspective. What system it’s needed…

this is not true simultaneous, this is a basically a for-next circuit.[/quote]

It will appear simultaneous because the computer is so fast that all the objects get drawn on the screen (in the video card’s screen buffer memory) before the monitor even displays it.

This is the way ALL games, simulations, ect will move large numbers of objects on a home computer. Even threaded ones. You are either using a FOR loop or some other type of Loop such as WHILE/WEND or REPEAT/UNTIL. Every game you’ve ever played, every simulation you’ve ever ran, they are all doing it with some kind of Loop in the code. It just does this so fast that to us humans it seems simultaneous.

Consider this: An average present-day home computer has 4 processor cores, and if it is “hyper-threading” can theoretically run 8 threads at a time. So the most objects that CPU could ever move at exactly the same time would be 8. Even if you “thread” the hell out of it. Only 8 at a time, period.
Now, lets say you have 100 objects. Lets say every one of them is its own thread. There isn’t a single FOR Loop or any other kind of Loop in your Code. Its all threading.
How do you think the Compiler makes your code SEEM to move all these objects at the same time when the CPU can only do 8 at once? It has an internal (ie: “behind the scenes”) LOOP!!! Thats right, a LOOP that goes through all the Threads, waits for a CPU Core to become available, then sends off a thread to the CPU Core.

The only way you’d ever get true simultaneous movement of large numbers of objects would be if the number of CPU Cores was greater than the number of objects (greater than because you need at least 1 CPU Core to act as the “Director” or “Coordinator” to run all the other cores). Even for just 100 objects, you are talking a Super-Computer.

About threads, we use the same name for two different things. Seth Hopkinson mentioned hyper threading where cores work in parallel moving objects.

Xojo never executes on more than one core. So threads in Xojo are just an astute way of switching between tasks using a sequential process, giving each thread a bit of time, then going to the next and so on in a logical merry go round. Nothing parallel.

I don’t think Xojo uses CType. I cast everything like this ‘ClassToCastTo(ObjectToCast)’.

Xojo does have CType. It allows the compiler to help you with type conversion, and allows you to explicitly convert otherwise incompatible types such as boolean to integer.

In my psuedo-code above, CType() is used to convert the Floating Point number (with decimal) into an Integer number (whole number, no decimal). I’ve read over the documentation for CType, and it looks like Xojo does this automatically. In other words if X is an Integer and XPosition is Floating Point (ie: Single or Double), then X=XPosition would work fine in Xojo. That is what is meant by “implicit” – the Xojo Complier or Interpreter will add in the “CType” behind the scenes if it is needed, so you don’t have to put it in your Xojo code.

In some other programming languages (for example, C or C++), the above (X=XPosition) would cause an error, warning, or an unpredictable result because the variables are of different types (Integer vs Floating Point). You’d need some function to convert the Floating Point number into an Integer number. In other words you would need to do an “explicit” conversion. Hence, I put in X=CType(XPosition,Integer). Old habit from being a programmer for 20+ years. Also a side-effect of still learning the specifics of Xojo.

[quote=124259:@Michel Bujardet]About threads, we use the same name for two different things. Seth Hopkinson mentioned hyper threading where cores work in parallel moving objects.

Xojo never executes on more than one core. So threads in Xojo are just an astute way of switching between tasks using a sequential process, giving each thread a bit of time, then going to the next and so on in a logical merry go round. Nothing parallel.[/quote]

Good to know, thanks.
On today’s processors, even Interpreted code tends to run so fast that for most situations you’d never need to truly thread your code (ie: run on multiple processors / CPU Cores).

One more quick thing:

I am planning to post some actual working code to illustrate the above at some point. There’s a neat-looking “fireworks” program I made, which I use to teach this stuff. Usually isn’t very long (typically no more than 20 to 30 lines depending on the programming language).

But I might not be able type up the code for a few weeks because I have a very busy work-schedule. Stay tuned…

I finally got that code I mentioned above done. Turned out pretty good. You can download the “Fireworks” source code here:
http://aosys.org/sethprg1/x.htm

[quote=135041:@Seth Hopkinson]I finally got that code I mentioned above done. Turned out pretty good. You can download the “Fireworks” source code here:
http://aosys.org/sethprg1/x.htm[/quote]

This is great. Thank you.

I noticed you have a terrible flickering because your label is over the canvas. Just a bit of advice to alleviate that :

  • Set the Canvas to double buffer in the inspector
  • Place the label off the window
  • Add this to the canvas Paint event :
Label1.DrawInto(g, 0, 0)

no more flickering :wink:

Double buffer may not be absolutely necessary, and should be avoided when speed is needed, but most often is beneficial to prevent flickering.

Thanks Michel that was going to be a future question, I’m on with a “Myst” style game and flicker is one of the problems

Thanks for the tip, Michel B. I didn’t even know about DrawInto until I read your post (still learning Xojo).

I added the “DrawInto” line of code, and that eliminated the flicker. But I had to add it to the Picture Object (mPic) rather than the Graphic Object (g). The new FPECanvas.Paint code is:

Label1.DrawInto(mPic.graphics,label1.left,label1.top)
g.DrawPicture(mPic, 0, 0)

I’ve done similar things in other programming languages before. Namely, you never draw anything directly to the ‘canvas’, but instead draw everything to the ‘picture’. Then draw just the completed ‘picture’ onto the ‘canvas’. Its a very similar to concept to double-buffering. Pretty much a “must do” when it comes to games or other real-time animation.

I also added a Menu Item and some code to brighten the colors (makes them more pure colors – FF0000, 00FF00, FF00FF, etc. Instead of the current all random numbers which tends to produce colors that are more gray/white/washed out).

I haven’t uploaded the modified code yet, but will do so soon.

[quote=135621:@Seth Hopkinson]Thanks for the tip, Michel B. I didn’t even know about DrawInto until I read your post (still learning Xojo).

I added the “DrawInto” line of code, and that eliminated the flicker. But I had to add it to the Picture Object (mPic) rather than the Graphic Object (g). The new FPECanvas.Paint code is:

Label1.DrawInto(mPic.graphics,label1.left,label1.top)
g.DrawPicture(mPic, 0, 0)

I’ve done similar things in other programming languages before. Namely, you never draw anything directly to the ‘canvas’, but instead draw everything to the ‘picture’. Then draw just the completed ‘picture’ onto the ‘canvas’. Its a very similar to concept to double-buffering. Pretty much a “must do” when it comes to games or other real-time animation.

I also added a Menu Item and some code to brighten the colors (makes them more pure colors – FF0000, 00FF00, FF00FF, etc. Instead of the current all random numbers which tends to produce colors that are more gray/white/washed out).

I haven’t uploaded the modified code yet, but will do so soon.[/quote]

The line I posted actually went simply into the Paint event of the Canvas. But the important thing is that it works for you :wink: