Back to General and Gameplay Programming

Earth Time -- Game Time

General and Gameplay Programming Programming

Started by Halsafar July 10, 2005 01:51 PM

19 comments, last by Halsafar 18 years, 9 months ago

332

July 10, 2005 08:24 PM

Quote:Original post by Halsafar
To simulate realism you often want a passing day. You however do not need a passing day to take a full 24hr's earth time. It is unlikely that a player would be satisied by that...

Probably best to use a Galactic Standard Week which breaks down to 1 earth hour.

Halsafar

205

Author

July 10, 2005 10:36 PM

I need some further assistance now.
I am trying to alter a variable between 0.0f and 1.0f over a span of 24 game hours.

The variable alters the light in the sky. So obviously from hours 17-04 it should go down and from 04-17 it should go up.

I am racking my brain on coming up with a decent way to do this.
See it needs to be based off of what hour and minutes I pass in...

Maybe I am just having a bad sunday but every method I try and write to acomodate this ends up crashing into problems.

fPerHour = 1.0f / 24.0f;
fPerMinute = fPerHouse / 60.0f;

sunLight = fCurrentHouse * fPerHouse + fCurrentMinute * fPerMinute;

Halsafar

205

Author

July 10, 2005 10:48 PM

	if (fHour < fSunDownHour && fHour > 4.0f) {		m_fSunlightAmount = ((fHour * fPerHour) + (fMinutes * fPerMinute));		m_fSunsetAmount = ((fHour * fPerHour) + (fMinutes * fPerMinute));	} else {		m_fSunlightAmount = ((fSunDownHour * fPerHour) + (fMinutes * fPerMinute)) - ((abs((fHour-fSunDownHour)) * fPerHour) + (fMinutes * fPerMinute));		m_fSunsetAmount = ((fSunDownHour * fPerHour) + (fMinutes * fPerMinute)) - ((abs((fHour-fSunDownHour)) * fPerHour) + (fMinutes * fPerMinute));	}

void*

292

July 11, 2005 12:09 AM

Have you considered maybe using the sine function, and offsetting it by the time of day you want the sun to come up? (also, you could add one and divide by two to get the values between [0.0 .. 1.0] )

e.g.

brightness = (sin(x - timeAtDawn) + 1)/2;

This would give realistic interpolation between light and dark, I think. Oh, you'll have to convert the hour value from [0 .. 23] to range from [0 .. 2pi] to get the value of x (and for figuring timeAtDawn)... but that should be as easy as scaling it (2pi/23).

Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

Halsafar

205

Author

July 11, 2005 02:21 PM

Is X the current time in milliseconds?
Thus time at dawn would be at 17:00, 17*60*60*1000 = ms at dawn.

I never thought of using sin for it...
Thats smart tho, it will allow for an up/down curve without any massive calculations and if.. statements.

Halsafar

205

Author

July 11, 2005 07:27 PM

I am not quite understand how I would sin the time of day.
Sure, sin of any number between 0-90 will be between 0....1 and 90-180 will be 1...0 which is perfect, but what unit to I relay this to when using time of day.

Time of day, in what unit would I replace x with and timeOfDawn in the last reply.

void*

292

July 11, 2005 07:39 PM

well, I was thinking that x would be the current number of hours, (not milliseconds) which you could get from the time() function I mentioned in my above post, after converting from seconds. Or, more conveniently, the tm->tm_hour value you get from localtime() (which automatically adjusts to the time zone of your computer).

Really, look at the time.h header that I mentioned before... it would make things much easier on you (and reduce a lot of unnecessary computation). Especially if you'd like to map it to "Real Time" ... Also, using a performance counter to gauge large-scale time is not recommended.

But yeah, you could use milliseconds; the scaling factor to convert to radians would be different, but still easy to compute. Good luck with your project.

Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

Halsafar

205

Author

July 11, 2005 07:50 PM

Yes I shall take a look at it.

But, it is not going to change the fact I need a good value for x.

I'm sure if I stare at this long enuf I'll figure it out.

Halsafar

205

Author

July 11, 2005 08:03 PM

Yah, it works nicely, the only problem is the units.
I am just simply using the hour and minutes and it fades up and down nicely but way to fast. In a 24hr period it'll go up and down almost each hour.

m_fSunlightAmount = (sin((fHour*fPerHour + fMinutes*fPerMinute) + fSunDownHour) + 1)/2;

void*

292

July 11, 2005 08:08 PM

Quote:
I am not quite understand how I would sin the time of day.
Sure, sin of any number between 0-90 will be between 0....1 and 90-180 will be 1...0 which is perfect, but what unit to I relay this to when using time of day.

oh, remember sin() and cos() take radians as input, not degrees. So, it would be the hours value between dawn = 0, then dusk = pi = 3.14159..., and dawn again at 2pi = 6.28318... Or, if you wanted time to progress faster, you could make an entire day pass each hour. Then, at x:00 would be dawn, x:15 could be high noon, x:30 could be dusk or twilight, x:45 could be midnight, then (x+1):00 would again be dawn.

You could really scale these however you want, to acheive the values for x and timeAtDawn. Just remember that the period of sine is 2pi and scale that to whatever period in hours/minutes that you want.

Greenspun's Tenth Rule of Programming: "Any sufficiently complicated C or Fortran program contains an ad-hoc, informally-specified bug-ridden slow implementation of half of Common Lisp."

Earth Time -- Game Time

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Earth Time -- Game Time

This topic is closed to new replies.

Popular Topics

Recommended Tutorials

Reticulating splines