client and server), versus synchronizing rendered frames with physics ticks (implied by 'netcode'). 'the netcode can be synced with the framerate'I think also he has misunderstood people talking about synchronous netcode (wrt. Even so tear is only a minor annoyance compared to the other possibles here. where at a higher refresh rate you cannot rely on vsync to prevent tear. His point just seems to be about syncing against image tear, (where multiples are appropriate). It's not as though Doom3's 60fps means we have to watch it at 60Hz. 60Hz is a non sequitur given monitor refresh is completely unrelated. Refresh rates are not the issue when it comes to the 60fps, and the 'rumour' about 60fps vs. Of course it might be, but there is no logical reasoning to say it is for sure. With that in mind you cannot infer simply because it is using D3 rendering, that the limit is still in place. The netcode has been completely re-written. There is no per-poly, and things are back to as they were with hitboxes. With this in mind you should remember that movement and netcode is now based on a Q3 base. ![]() The reason for needing synchronous netcode is mostly because of the per-poly collision detection and using 60fps is the highest acceptable given factors like server CPU use, and netcode bandwidth. In comparison, if Q3 had been synchronous netcode we'd have run at 20fps (remember the sv_fps default?). The reason for the 60fps was that the game was synchronous in MP. However, Q4 game is not based on purely on the D3 physics, but as Todd said 'a more robust version of it'. To do so with any alternative approach would add (1000/60) a 16ms lag to movement and rendering, which would be very noticable. John C's point is more about interpolating frames between these physics ticks. What is disappointing is that many Q3 mods have developed ways to combat the FPS-dependant physics issues without capping players' FPS. In Doom, the same player inputs will produce the same motions, no matter what the framerate is." A fixed tic rate removes issues like Quake 3 had, where some jumps could only be made at certain framerates. To quote John Carmack: "The game tic simulation, including player movement, runs at 60hz, so if it rendered any faster, it would just be rendering identical frames. For those who are able to hit the cap, it is recommend to use vsync (which is a triggered refresh after every rendered frame) or to use a rate which has a divisor of 60 (60hz, 120hz) for the smoothest gameplay. ![]() This has nothing to do with monitor rates all monitor refresh rates will be allowed. The 60 FPS cap was hardcoded and cannot easily (and probably will not) be changed. This is consistent with any game that uses the Doom 3 engine. Ingame framerate will be a maximum of 60 FPS. There seems to be some confusion on what this means, so I'll try to clarify: Yes, Quake 4 will have a upper limit of 60 FPS.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |