| |
| |
| |
|
Page: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17
Comments:
<0> you just contradicted yourself.
<1> + graphics are not part of the gameplay, still
<2> he said 'in realtime', NineVolt
<1> The gameplay is the game rules
<0> you just said it can be done but you'd run really slow. and then you said it can't be done.
<1> Not how you play
<2> NineVolt - "cant do it in realtime" == "cant be done"
<0> i didn't hear the "in realtime"
<1> rdragon: he's just a bit stupid, last 3 things he told me he looked dumb, but I'll go for a 4th one ;)
<1> [22:13.50] <@Ashe`> In realtime
<1> Of course that's been the point for the last 15 minutes
<1> But you're just "special"
<1> So now that you understand gameplay = game rules and not "huh my game is slow I can't play it"
<1> You might understand that because you can't simulate the rules
<1> You can't play the game
<0> i disagree still.
<1> Doesn't matter, you're wrong
<0> you can sacrifice frames per second if you're doing software gfx rendering
<0> just like you can sacrifice physics accuracy if you're doing software physics.
<1> You sacrifice accuracy = you modify the game behavior
<1> So they can't play together
<0> depends what the physics is used for.
<2> NineVolt you're missing the point by a bit
<1> A "slight" bit
<0> i was under the impression that it's only used on the client side for prediction
<1> ...
<0> i.e. to make the game look nicer.
<1> That's pretty sad
<2> the point is that with hardware physics, you can do a LOT MORE physics simulation - to the point where the experience is completely different than anything you could do reasonably in software. that's the point.
<0> rdragon : just like with hardware gfx acceleration.
<0> i don't see the difference, i'd say they're parallels.
<1> And graphics don't affect the game behavior
<1> Having a nice water reflection doesn't change anything to the game
<0> [15:08] <0> people with high end gaming systems don't have any sort of advantage against people playing at 1fps.
<1> Except it's pretty
<0> i don't believe you.
<2> right - graphics rendering is p***ive - it just observes the simulation
<2> physics is actually part of the simulation
<3> so... the game's box will say "requires a physics card" and if one dumb **** doesn't read the label he just can't play and gets his money back
<0> or the guy running at 64x48 has just as much an advantage as the guy running at 1600x1200
<2> you can get rid of the rendering completely, and still have the same game
<0> sure.
<1> Game speed doesn't change the game behavior either
<2> if you get rid of the physics - not the same game
<1> Nor resolution
<2> it's quite different
<1> Nor the keys you use to move your characters
<1> Nor the volume of the music
<1> Physics changes the behavior
<0> i'd say that graphics does too, but whatever.
<2> you could say that
<2> and you'd be wrong
<1> Ok, graphics does: if you don't have reflection, you won't see the mirror so you won't see the ennemy behind you and the behavior changes
<1> There, happy?
<1> I had to find an example for you
<3> well.. unless you count the fact that your crosshair has pixel-precision, you're wrong
<0> or if your computer ****s and you're running at literally 1 fps, your control over the motion of your character is much more coarse than someone who isn't suffering from that issue.
<1> A game's behavior doesn't change when running at 1 or 500 fps
<2> NineVolt you've missed the point, again
<0> are you operating on some strange definition of the word 'behavior'?
<1> Behavior = what happens in the simulation
<1> You get 1 fps
<0> on the server side?
<1> After 5 frames, you'll have advanced by 1 meter
<4> I wouldn't even call it a game anymore at 1 fps
<1> (so 5 seconds)
<3> the simulation is exactly the same at 1 fps, just a lot slower
<1> You get 500 fps, after 2500 frames you'll have advanced by 1 meter
<1> Same thing
<1> Server/client side doesn't matter here
<1> Just ***ume it's a single player game
<0> Ashe` : at 500fps, if you press up, left, up, you will have moved forward, left, and forward.
<1> Same at 1fps
<0> at 1fps, you'll be lucky to have moved forward. you probably won't have moved laterally.
<1> Input is queued
<1> Say hi to DirectInput
<0> in all games?
<3> in all games.
<1> Well, since all games use DirectInput
<0> that's news to me.
<2> NineVolt you did move the same, you just don't see it the same because your rendering ****s
<1> You even get a timestamp
<1> And an order
<1> Just to make sure you get the keys right
<0> interesting.
<0> so your argument re: physics ***umes the physics is done client side, yes?
<1> ...
<2> again, ***ume a single player game
<0> in which case consistency between clients would be required.
<1> Ok don't pay attention to the other players
<3> talking of which, I haven't finished cod2
<1> There's only you
<3> later
<2> it's a different game if you can't model the physics correctly - things don't bounce and smash off walls in the same way
<1> You have a new game
<1> You have no PhysX card
<1> The game's physics is pretty simple
<1> A box falls directly down
<0> i don't see how game 'behavior' would be affected if the simulation physics were done server side, and the client side physics was only for prediction
<1> Now you have the PhysX card
<1> The box falls, bounces, etc, and might even get in the way of the ennemy in front of you
<1> That changes the behavior of the game
<0> right.
<1> Now, you have that new game
<1> No PhysX card
<1> And a ****ty graphics card
<1> You run at 1fps
<1> You get to that same point, the box falls straight down
<1> Just as if you had a good graphics card
<1> (the box might look ugly though :D)
<0> i love to hate you :P
<1> Welcome to my fan club
<1> "fan" that is
<5> Yeah.. fan the flames. ;)
<2> heh
<0> but the discrepancy between your crappy client side physics and the real server side physics would be resolved within a moment or two anyway
<0> so the behavior of the game would be unchanged, short of some lack of aesthetic quality.
<0> ***uming the server runs the real physics.
<2> this has little to do with server/client...
<0> which as far as i know is how most fps do it.
<1> You wouldn't see the box falling, you'd shoot the ennemy behind, the bullets would hit the box and you wouldn't even notice
<0> not really. if the physics is done server side and the only reason it exists on the client side is for prediction, you could do away with the physics on the client side entirely.
<2> although I think it would be hard to broadcast an accurate physics simulation from the server, with little physics being done on the client
<1> Then 3 seconds later the box appears
<0> you'd just have a really crappy game, but the behavior would be the same.
<1> + you can't transmit the animation needed by physics simulation without swallowing the bandwidth
<2> right
<0> animation?!
<0> that's not part of the game behavior.
<1> Moving an object is not part of a game?
<1> What is it then?
<0> you can still move objects.
<0> you just won't be able to see them move for a little while.
<1> Moving an object = animation
<1> You won't see it and the client won't know it either
<0> no, moving an object = translation
<1> ...
<0> seeing an object moving = animation
<2> NineVolt not seeing objects where they really are is a big, big problem in a fast paced game, like a shooter
<0> wasn't that the argument i was using with video cards?
<0> you claimed that running at 1fps doesn't affect game behavior. even though you can't see things happening, they still happen.
<0> same argument.
<1> Updating objects position is not part of rendering nor physics
<2> no, we said it doesn't affect the simulation
<1> And animation != rendering
<1> Animation = animating
<1> Moving bones
<1> So it's nice, you know what a translation is, but you don't know how to multiply vectors, remember?
<0> so moving an object that has no skeleton isn't animation?
Return to
#c++
or
Go to some related
logs:
bnc boti
#linux
#linux
fedora dell gx520
chenobol
#chatzone
#java
#AllNiteCafe
xlendija
#linuxhelp
|
|