• Advertisement


  • Content count

  • Joined

  • Last visited

Community Reputation

277 Neutral

About reana1

  • Rank
  1. I don't know OpenGL details, so can't tell you where to look to fix it, but it looks like your green and blue axes are just on top of each other and subtracting to produce black. Try rotating by just 30 degrees and I'd think you'd see part of one of the axes at the top and the bottom with black in between. Also change your background to white (or even better a rarely used color) so you can distinguish between when you are drawing something black as opposed to not drawing anything. There's probably some OpenGL option that's making the line colors mix, but I don't know what it would be called - something about transparency maybe?
  2. Maybe this is old news since I haven't been around much until recently. But I never noticed this before. The edit time stamps seem to be off by a little over -1 hour. For example, at the end of this thread: click My last post was at 1/15/2008 9:40:51 AM And then I edited the post before that and it says [Edited by - reana1 on January 15, 2008 8:31:38 AM] Also, notice kloffy's post after mine is edited before his (and my) post time. EDIT: And here's a little test - maybe it's just that the edits don't do DST right. Or maybe only I see it, but the time zones is the only setting I see in my options. EDIT2: A failed test - I'll wait a bit, but may have to leave soon.
  3. Quote:Original post by ZeHa Let's assume there are two people standing besides each other. The first one starts walking immediately at constant speed. The second one starts at the same time, but walks very slow and slowly accelerates to reach the other one. If in the end both people should walk a) in the same speed and b) at the same position, it's clear that the second person needs to walk faster than the other one right before the point where he reaches the same position as person one. I think that's a good and imaginable description of the problem, maybe it can also help. One thing I was thinking to mention was that in terms of this example, if the constant velocity they both reach at the end is your max speed (vMax), then notice that the second guy has to exceed vMax for a while to "catch up". You could still do this with the weighting, you just have to adjust the curve instead of being linearly decreasing. You could ramp up earlier and then drop faster later. The total area under the curve just has to stay the same when plotting the x versus t (I think - I'd have to make some plots - anyhow fancier stuff is possible too). Even if you don't want to let players/objects move faster than vMax, you might want to allow it to be displayed (or estimated) that way if it looks/performs better.
  4. Quote:Original post by ZeHa Maybe there would still be a different solution, it might be possible to update the velocity at the "critical point" to match the velocity that is gained at the frame before (when the object was still in acceleration mode) to create a seemless transition between acceleration mode and "finally walking at constant speed" mode... The (a => 0) thing is a bit bad written, actually => should be an arrow and simply say "when 'a' becomes zero" ;) because if I use the basic formula (the one with "0.5 * a * dt * dt" at the end), as soon as the acceleration stops (meaning that "a" becomes zero), then of course the X position would be immediately change to some X value that the object has already passed before (since the last part of the formula will then also be zero). I hope it's now a bit clearer ;) I see what you meant now. That's one thing I'd forgotten about is you have an additional constraint of limiting the velocity. This doesn't make sense with my first set of equations since velocity is constant (it'd never reach any limit). In the second set, I think you can just apply some limits and it'd work. But it seems basically you want a simpler way of estimating velocity that still gives you smooth motion when you hit the top speed. The only thing I can think of is to include some weighting terms to reduce the effect due to acceleration when approaching the top speed. So the weighting would be 0 when you are at v0 and 1 when at vMax (or vice-versa) and will ramp between the two when in between. But then it seems like it's getting complicated again and maybe not worth the trouble. Well, here goes something: Given all your initial conditions: t0, x0, v0, a0 You should be able to predict when the velocity would hit the max speed assuming constant acceleration. So do that and get a tf (final time). Then adjust the weightings based on how close you are to tf. At tf (vMax), you need to get: (note a0=0 now) [1] x = x0 + vMax*dt + 0.5*0*dt*dt And at the first step t0+dt1 (v0), you want: [2] x = x0 + v0*dt + 0.5*a0*dt*dt So [3] x = x0 + vMax*dt + (tf-t)/(tf-t0-dt1)*(v0-vMax)*dt + 0.5*(tf-t)/(tf-t0-dt1)*a0*dt*dt Note, dt1 is just the dt on the first step. When t = tf, the third and fourth terms of [3] are zero, leaving equation [1]. When you are at the first step after an update t=t0+dt and the ratio in the third and fourth terms is one, reducing to equation [2]. In between the start and terminal velocity times, the third and fourth terms should ramp down linearly to 0. [EDIT: Actually, the weightings are linear, the terms themselves aren't.] Of course now you don't really have constant acceleration, but maybe that's what you want to smoothly approach your limit. Not sure how this would work in practice though - just an idea. For cases where you wouldn't actually hit the limit between updates from the server, maybe something else would be more accurate. I'd have to simulate this some to see if it's worth any thing - but I'll let you play with that if you choose to. ;) [Edited by - reana1 on January 15, 2008 8:31:38 AM]
  5. Quote:Original post by ZeHa One other thing, do you think it might be a good idea to mail the author of the article (not only for asking about the problem, also for telling him about the mistake in the picture)? Not sure - I considered it, in particular I was interested in his source since it seemed like he was just quoting parts from the DIS algorithms (which you'd think would be freely available since it's some sort of US government standard). But it is 10 years old. Too bad I don't see a "comments on articles" option like GameDev. Hmm, never mind looks like someone's gone down this path VERY recently: http://www.gamedev.net/community/forums/topic.asp?topic_id=477945 Try posting (or getting this moved) in(to) the Networking forum. There's gotta be someone that's done this. I'll probably look more tomorrow in between work. EDIT: left out part of a sentence - added in bold [Edited by - reana1 on January 14, 2008 6:50:39 PM]
  6. Quote:Original post by ZeHa First of all, what does this little bold "r" mean? Is it just "this is a vector"? Or does it mean something else? I wondered the same thing and thought it was a typo. I don't recall ever seeing that notation (and can't find it in a quick search). I thought maybe it was just a type problem (i.e. the equation writer meant for it to be a little arrow, but some program that doesn't do arrows drew an "r"). Which, also makes me question whether there's a missing power of 2 off the last time diff. Normally, I'd expect 1/2*a*(t-t0)^2 for the last term (I see you've noticed that too now). Unfortunately, his code example has no acceleration to confirm that. I tried finding his source (the DIS algorithms), but couldn't find it online. Here's a paper extending the basic DIS dead reckoning, and they use 1/2at^2 - so I'd bet it's a typo in the Gamasutra article image. http://ieeexplore.ieee.org/iel5/6213/16596/00766164.pdf http://ducati.doc.ntu.ac.uk/uksim/journal/issue-1/Lee-Turner/B-S%20Lee.pdf As far as your other comment about it just being a constant velocity, I think even using the squared term, the velocity should be updated at some point otherwise you are basically saying your clients will assume a constant velocity between updates. Let me just talk myself through this since I may be missing something too. But here's what I gather: You are talking about something like a client and server, where the server controls the true object's state (pos, vel, acc). The server will update the state of object occasionally to clients (these are t0, x0, v0, a0). In between updates you want to use dead reckoning on the various clients to estimate the object's current state (t, x, v, a). So each client needs an estimate of object state (pos, vel, acc): [Note: I broke the deltas into seperate terms dt, dx, dv hoping that it might make some things clearer, but I'm not sure if it really does. I guess it was to highlight what the delta is relative to (_0 or _Prev).] Time change: dt = t - t0 Position estimate: dx = v0*dt + 0.5*a0*dt*dt x = x0 + dx Velocity estimate: dv = a0*dt v = v0 + dv Acceleration assumption (constant): a = a0 The above is I think how you've been doing it and the only thing that changes each time step is t. Everything is "dead reckoned" relative to the last update (at t0). So you're right if you just use those equations, you're assuming constant velocity in the position estimate over all the time steps between updates. Maybe in some applications that's good enough - not sure. But you can see the velocity estimate would change (with non-zero a0). So I think you just need to keep a local client estimate of velocity and update relative to the last estimate (instead of at t0). So you'd instead do it this way: Time change: dt = t - tPrev Acceleration assumption (constant): a = a0 Velocity estimate: dv = a0*dt v = vPrev + dv Position estimate: dx = v*dt + 0.5*a0*dt*dt x = xPrev + dx Save Prev values: tPrev = t vPrev = v xPrev = x Now t, tPrev, vPrev, and xPrev all are updated each time step, and the calculations are relative to your previous estimate (at tPrev). At some point server will come back and update again with correct state and you'll have to compensate or just reset the _Prev terms to the updated state (_0 terms). Like I said, I haven't done networking stuff though (maybe I'm making things too complicated - or simple for that matter). So I may be missing something. This seems reasonable to me though. The negative here for you may be that recreating the position is not as simple as before where you just needed one equation relative to t0 and you could compute what your algorithm would predict for the position at any time. Now you need to go through the cycle to re-estimate it again. It's still repeatable, but you'll need to know the dt's at each time step (but that variation may be small enough you can assume a constant). But given a list of dt's, you can recreate this estimate by running the dt's through a loop. Reading back over this I wonder if I'm just suggesting the same as I originally did before I understood your need. And I'm getting confused (plus being interrupted by work). So for what it's worth there's my possibly incoherent thought process on this. Hope it helps. P.S. I didn't follow your last concern (when a => 0) that you posted while I rambled this long thing out. :)
  7. It's been a while since I registered, and I get the affiliated Game Developers magazine too. So it's hard to say what I get due to Gamasutra alone or due to the magazine subscription (or due to someone else entirely that knows I'm intereseted in Game design). But generally, all I get are things advertising game conferences and occasionally some book. I think they do have a way to opt out if you want to (check the privacy policy). They also generate lots of survey info, but I think that comes from the magazine subscription where they periodically ask you a TON of info (it's voluntary).
  8. Ah, sorry I didn't get your real goal. I understand what you're looking for now (or better at least). I don't have an answer though. I had some guesses, but better to find someone that knows than me accidentally mislead you. :) I haven't done any networking type things. I did some looking though and "client-side prediction" or "lag compensation" might be good google terms. Here's a link that gives the concept (though maybe you already have that part down): click And here's a nice article on Gamasutra that may have your answer (just have to get an account - but worth it): click If no one else replies, try posting/searching in the networking forum maybe.
  9. Quote:Original post by ZeHa Now, as you can see, the difference for X between frame 4 and 5 is over 1000, but to frame 6 it's only 600, and that is the reason for the speed "loss". But I just don't know how to make a real, working integral version of my "Dead Reckoning"-like getX()-function. Also, you don't have a speed loss from frames 5 to 6, you have an acceleration loss. You've reached the max speed so your position can only change at a constant 600 meters every time step. The problem is that you are recomputing the position relative to t=0 every time and each time making the velocity over the time since t=0 constant, but larger. For example, in frame 4 your equation for x says you've been traveling at 24 m/s since t=0, but that's not true. You were traveling at 18 m/s in frame 3. So you need another variable to save last position since velocity is not constant anymore. newX = oldX + newSpeed*(newTime-oldTime) I don't think you can use timeDiff for newTime - oldTime either, since I think you are saying timeDiff is time since you started moving. You need to know the amount of time that you've been traveling at the newSpeed (which is 1 frame or 20 ms in your example). Also, use units when you are trying to figure things out. e.g. accel can't have units of ms - it must be length/time^2. So you can't do things like compare accel with time or divide a time by accel because you are comparing/dividing units that make no sense to compare/divide. Hope that helps some.
  10. If what you want is to go from 0 to 30 meters/second in 5 frames (100 milliseconds), then your acceleration is 30/100 = 0.3 meters/second^2. You have this in your newSpeed computation in the example you gave, just written as a ratio of current time to final time instead of an acceleration. So "accel" in your code should really be "tf" (final time). For example in frame 1 you have newSpeed = 30 * (20 / 100) = 6 which is the same as newSpeed = (30/100) * 20 = 6 This is as others have shown v = a*t + v0 Where you are computing the speed since t=0 and v0=0. But your example doesn't match your code: newSpeed = this->speed * (timediff / accel) Unless you aren't updating this->speed ever, and it's always 30? If that's so, then you need to change to update this->speed based on newSpeed somewhere. What are xDir and lastTime?
  11. GameDev has it in books section too: click
  12. Great Games Experiment beta invites

    Quote:Original post by James Wiley Hey guys, we've opened up the Great Games Experiment to everyone on GameDev. You can read more about how to sign up in the announcements section. Announcements section of GameDev that is, which makes sense - I'm just slow. :) And thanks!
  13. Voter Fraud?

    Yeah, I agree that this wouldn't seem to be a widespread thing or you'd think we'd hear more about duplicate ballots. But they say every vote counts ... I've not found much about fraud online (I mean there's lots there, but not alot that can be considered facts like you're looking for). It's one of those "dirty little secret" things that noone official would want to comment on (like software companies not listing bugs).
  14. Voter Fraud?

    Hey all, I'm curious what you all think of my situation. Maybe I'm over-reacting, but something seems quite fishy here. I've been trying to find a place to report this, but haven't had much luck for the last hour other that the general state of Maryland Board of Elections e-mail address (info@elections.state.md.us). I guess I may call tomorrow, but they'll probably be a little busy ... Anyhow here's the e-mail I'm composing with all the details (names obscured). Any advice/opinions? Quote: Hello, If there is a better place to e-mail my concerns please let me know. I've been unable to find any specific place to report this, but I've received two ballots at my house. This is the second time this has occurred with the same name (previous time was in 2004 I believe). The other person's name is R.K.P. No P. has ever lived at this address as far as I know. I've lived here since 2002; previous owner was C., and before that was J. The only R.P. around this area I've found searching online is listed as deceased from NJ. I'm not sure if this is normal to simply get ballots sent to wrong addresses or if something more serious is wrong here. I wouldn't think it would happen twice. In addition, I've received some election spam at an e-mail address that I use for junk mail that was also addressed to R.P. I've never associated this address in any way with my name (or the name P.) or my home address or anything that should be able to identify my real name. Yet somehow I've recieved this e-mail from "Senator Mikulski" <George@votegeorgejohnson.com> that was addressed to R.P. So two things seem strange to me here: 1) How am I again being mistaken for R.P. at a place that should have no connection to my voter registration information. 2) How did "Senator Mikulski" obtain my e-mail address in the first place. The only way I can think that would be possible would not seem to be very legal (or at least not ethical). My yahoo e-mail account could be connected to my IP address and from that Comcast could tell who I am, but normally people don't have access to that information. Hopefully, there is a logical explanation to all this, but there seems to be too many strange occurrences to not attempt to find out the cause. Below is my contact information to help you resolve this ... P.S. Do candidates really expect to win votes using phone recordings and e-mail spam? If I vote and see a name I only know as being that annoying spammer, do you think I'm voting for them?
  15. I realize this is "solved", but meant to post this earlier - just gives some nice animations that might give you some ideas. Lots of links there too, but I didn't follow any: http://mathworld.wolfram.com/Ellipse.html
  • Advertisement