I was thinking: I'm saving processing time by using a timer for drawing and doing a good design and saving processing time doing a logic timer too...

But to improve even more the game design, I was thinking in doing the drawing
not at the same time the logic is...

Because I was doing something like this:

Logic/Draw:
0 = false
1 = true

Example:

Logic  Per Second : 30
Frames Per Second : 15

Logic:   1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

Draw :   1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0

So as you can see the drawing is done at the same time the logic is...

Would make any difference if I do something like this?

Logic  Per Second : 30
Frames Per Second : 15

Logic:   1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0 1 0

Draw :   0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0

So, when I'm drawing I'm doing no logic, and at that way there isn't gonna be jumping scenes or stuffs like that...

But the question is... Would it make any difference in performance?

Nope. *

(* Depends on specifics not included in your post.)

I think this type of implementation is more valuable for sophisticated games, when the Logic is very complex...

Well, actually I have nothing else to say...

If a game take X_time doing logic, and X_time doing drawing a way to stay away from adding this two times is doing the drawing or the logic...

And do what? You're still spending the same number of cycles doing logic, rendering, or waiting. It doesn't really matter* if you wait half a frame before rendering, then wait half a frame again, or if you just render and then wait a frame.

You're not gettinga way from having to spend time_logic + time_rendering, you're just inserting a bit of wait time in between for no obvious reason.

(* Again... aside from unspecified factors and minor influences.)

(And by the way, 15 fps is going to be extremely choppy.)

One basic problem is that you have to be careful how to overlap logic and drawing. For example this will work:

[logic]         [logic]           [logic]
       [draw]          [draw]            [draw]

This will not:

[logic]         [logic]           [logic]
[rendering]    [rendering]    [rendering]

In the above case the logic is still modifying the game state which is also used for rendering. The result will be that things won't work at all, objects may be missing or appear duplicated. If you solve it by putting a mutex around your [logic] and [rendering] blocks then you force things to run sequentially again even if they are in different threads. Something which may work would be:

[logic]         [logic]           [logic]
       [copy][rendering][copy][rendering][copy][rendering]

Here I split the rendering part into a [copy] part which makes a copy of the game state. Or alternatively create a rendering representation (e.g. a list of triangles). Once that is done the subsequent rendering can overlap the logic again as the list of triangles being rendered by D3D/OpenGL isn't modified by the logic thread.

I don't think he's actually using more than one thread. That's what the * in my first post was about (obviously a multithreaded approach requires more caution). I think he just has two timers running at the same time, but responding to them sequentially.

No actually what I'm doing is something very simple:

{"name":"log.jpg","src":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a54f7d5493658a27696cacb57e481012.jpg","w":400,"h":300,"tn":"\/\/djungxnpq2nug.cloudfront.net\/image\/cache\/a\/5\/a54f7d5493658a27696cacb57e481012"}

With some mathematics I figure out when I have to draw so the drawing correspond to 15 FPS... inside the 30 FPS logic loop...

The problem is that when I'm inside the logic I don't know how long is going to take to finish the process, the same happends with the drawing.

I can't say to my drawing function, "hey you're taking too much time, stop"

So, even when your game is made to run at 30 FPS in some old computer this might not be happening, and for that reasons some games let you know the quantity of FPS.

And for that reason I came up with this idea, if I do the logic and the drawing at the same time, this might reduce the FPS of my game at that point, but if I do only the drawing and only the logic, this might let the CPU/GPU do one thing at the time, and this I could improve the FPS of my game...

I can't understand why you think Logic + Render + Wait + Wait would somehow take longer than Logic + Wait + Render + Wait.

You're already doing this! It's all a single thread so by the time you get around to drawing, your logic has already finished running!

I'm not saying that...

Lets say that a game is made to run with a logic of 30 FPS.

1 Sec = 100 CS

that means that 100 ÷ 30 = 3.3 CS

So the game has 3.3 CS to do the logic or the drawing, to keep running at 30 FPS, but if it take more than 3.3 CS the FPS will be reduced.

So... if I do the logic and the rendering at the same time, as you can see in the table below my FPS will be affected...

Processes     ||  Time
_____________________________
Logic + Render = 4 CS
Logic          = 1 CS
Render         = 3 CS

In my new implementation (the Image up there, in my previous post), I'm just doing one thing at the time... But in my old implementation that is what I was talking about, I was doing

----- 30 FPS -----
   Logic

   if(draw){

   draw
   
   }

So the logic was always running, and at the same time, at some point, the rendering was also done together with the logic...

For that reason I think is much better to do the draw or the logic, but never at the same time.

Well At least That Is What I Think

Without using a supplementary thread you are not drawing while doing some logic.
Your computer isn't smart enough to split your code along your multi-core CPU without you doing a little bit of a job.

Everyone is saying the same thing, but you're not listening: Unless your application is threaded, things happen sequentially, not in parallel. Your math table there is wrong. Your logic and rendering are not being done "at the same time". They are done one after the other.

Well I don't want go further with this discussions because I already solve it, I just was asking to get an overview about what people think, if drawing and at the same time doing logic is the same of doing only logic or only drawing.

What I can tell you is that I don't need a Multithreath algorithm to do logic and drawing at the same time (and when I say "at the same time", I am talking about doing something in a period of time and not actually doing several things in the CPU ), maybe your point of view is different from mine.

Dont worry, in a future I'll use one core for the logic and another for the drawing

Or not wait... there is hexa-core processor too, so I'm going to use 4 cores for drawing and 2 for logics, yheaa

How is that even possible? Maybe I'm missing something here. But it seems you are mixing up something fundamental here. You cannot do two things at once without some type of multiprocessing capability and solution. And when I read your post, it seems like you are saying that you can. I think you need to re-read X-G's replies because he addresses that point specifically.

Another point to make here is : Why separate the framerates of your logic and drawing to begin with?

Why bother calling logic if you're not going to display the result of that logic? The only reason to do more than one logic call per drawing call is to free up the time spent drawing, but only if you need to. This is where your timer comes in handy. If your game isn't running full speed on a slow computer, then you can skip drawing frames if you have to. Simply call logic the same number of times as you have ticks on your timer and then call draw. The framerate will be lower than what you hope for, but it will still appear to be moving at the same speed, although some objects may start teleporting.

I think you're making things more complicated than they need to be to achieve the results you are looking for.

OK, quick rundown of common timing approaches.

• fixed global framerate - the standard in older consoles; just lock into the system's frame rate and code your logic so that one logic update per frame works. For PCs, this is useless, because you can't reliably control the physical frame rate.

• fixed logic rate - set a timer for the logic, then after each redraw, see by how many ticks it has advanced and update your logic that many times.

• variable delta - use a high-resolution timer to measure the time elapsed between the previous redraw and the current one, code your logic so that it takes a delta-time parameter, and call it once per redraw

• multi-threaded - set up two threads, one for the logic and one for the drawing; these two need to communicate through some sort of thread-safe mechanism (almost a classic producer/consumer scenario).

Unless you go for the last approach, you will never have drawing and logic going on at the same time though.

I think my algorithm is so dumb that doesn't have a name...

Suposse this is my code

blablablabla
blablablabla
blablablabla
blablablabla
blablablabla
blablablabla

Which is running at 30FPS...

It doesn't matters if is logic, drawing or anything else... That code over there is running at 30FPS

then I decide that, that code is going to do some logic and then draw something, so I do this;

logic blabla
blablablabla
Draw blabla
blablablabla
blablablabla
blablablabla

Then.. Since the logic of my game, is controlling 400 objects which interact each other, I say:

Ok... I'm doing the logic at 30FPS and the drawing at 30FPS too, right?

But since the drawing take much longer than the logic, and I really don't need to redraw my screen at 30FPS... I do this...

draw=0;//This is outside the code running at 30FPS (a global variable lets say))

if(++draw!=15){
logic blabla
blablablabla
blablablabla
} else {
draw=0;
Draw blabla
blablablabla
blablablabla
}

Now, even when my logic is running at 30FPS the drawing doesn't...

What name have this type of Algorithm???

draw=0;//This is outside the code running at 30FPS (a global variable lets say))

if(++draw!=15){
logic blabla
blablablabla
blablablabla
} else {
draw=0;
Draw blabla
blablablabla
blablablabla
}

Correct me if I'm wrong (I have a nasty cold, and I'm tired...) but wouldn't that code draw twice a second rather than 30 or even 15 times a second?

The code which is inside the else statmen is running at 2 FPS...
I haven't say 15FPS...

Why would you want that?

Because with some maths I can make it run at 15FPS... and instead of running my code at 30 I could do 200FPS and my drawing at 100FPS, in other projects. what worries me is the implementation...

Ummm... Is your game really going to need incredibly precise maths? If not, I'd say just go with Delta timing. It's quite easy, and you've just got to be careful of using the timestep properly. You'll get your game running with any FPS in any computer(though clamping the Delta Time is good practice or else you're going to have a massive frame skip at the slightest lag).

Well actually isn't... the last time that I mess with precise maths was... was... I don't remember...

I just found this one the... "easiest one" so if this inmplementation doesn't have a name, now is going to be called the "E.O." Ok?

BTW here in Spain we're at 2ºC what is happening there in Canada?

Prior to last week, it was -25c or colder, and we got a shit load of snow. This past few days however, starting on Thursday or so we got close to 0c, and today it hit 5c, which was nice. But my furnace stopped working on Friday. No heat till yesterday afternoon, except what I could get from the sun, and my oven for a couple hours each day.

A broken furnace in Canada??? Oh boy... I would have two replacement if I were living in Canada.. 4 if were Russia... .

Here in Spain - A Coruña we're betwen -8ºC to 7ºC... nothing special... Well take it easy... summer is... is... well not so close but... ahh whatever...

A replacement will cost me at least $2400. I can't afford to have a new one let alone two new ones

I was very lucky that it decided to die after the cold snap.

If we're going to talk about weather now, let me add that it's 28C over here, and the news report that it's over 42C on the capital city.

Well yes... my problem was solve, In Fact I Just Finished to talk with Bill Gates, he called me to tell me that he wants to buy my Algorithm... I'm millionaire... So... I got to go... I need to buy a ticket to Hawaii... CYA..

PS: What? 28ºC?... You're a lucky guy....

42ºC! lucky? well, only the ones who have an air conditioner unit, I have one!

Not when you have to pay 10-20c/kWh. And the AC is a little too small to do the job so it eats up more power than spec'ed...

This is just pseudo-code. Essentially, the logic() portion is only given a fixed amount of time in which it can update everything. If it gets it done in time, great. If not, the function exits, the draw() function will possibly be drawn (and those elements would not have been updated/moved), and you will have to wait until the next logic update is called before the remainder of those items are updated.

It's not perfect, but then you can use it to explicitly limit the amount of time your functions can suck up the processor.