Sidecars ! May 2018 !
ps4 version cost 60€ and have 30 fps gameplay
pc version cost 25€ and have 60+ fps gameplay
now choose
I'm glad that I cannot tell the difference between 30 and 60 fps. Not everybody can.
Sidecars ! May 2018 !
Try playing a 60 frames per second game, like GTsport , record it with the ps4 video recorder, then watch it back, and cringe at the sheer horrible jerkyness of 30 frames...I bought an external 60 frames recorder because the ps4 cannot record gameplay at 60, I was well miffed the pro cannot either..
Lucky the persons who doesnt perceive the difference between 60fps vs 30fps gameplay, sad for the (small?) rest of the world LOL
60fps should be the minimum and fixed framerate on every console game.
Its not only about the eye hurting quality its also the high input lag resulting from the low framerate. GTA5 on console is like playing drunk, and so it is on every 30fps game. Input lag and bad quality while movement.
This would be great .It would be hilarious if they make that a co-op mode, with your wingman in the sidecar shifting his weight around.
So there is a helmet cam. Show pic, please.More opinions from me. Since this seems to be turning out to be the best - or at least the most fun - motorcycle game I've ever played (Tourist Trophy was so long ago that I can't really say if it would still hold up).
I didn't think I would particularly care for most of the nine shorter tracks - particularly the three that are very short at only 2.5 to 3.1 km - but I pretty much love all of them (the 2.5 km docks/town track is the weakest, but not bad).
Track layout is mostly good to great, and just as important to me they just feel much more alive than most tracks in particularly sim or semi-sim racers with (despite maybe not holding up 100% to scrutiny in still shots) beautiful countryside landscapes and villages, and different lighting and cloud formations depending on the three times of the day you can choose.
I still enjoy the crash cameras - even after countless dozens of crashes. The brief rag doll cutscenes can be pretty hilarious at times, the funniest I've seen so far was the camera pointing backwards and staying just in front the bike as it slid along the ground, while the rider in the background slammed into a road sign and fell down like something out of a roadrunner cartoon .
I'm not qualified to talk about driving physics. Definitely doesn't feel like a pure arcade racer to me (aside from the immense sense of speed in helmet cam), more like something between DriveClub bikes (which I loved as well) and Ride 2 (which I kinda, sorta enjoyed a little bit).
So I'm pretty much thoroughly satisfied with anything but the very limited bike selection, but of the ones that are included I very much enjoy so far around half of them (others have trickier handling and I haven't bothered much with them yet).
Now I think I'll get started on the career mode.
That would be awesome in GT!Looks great, imagine if we had this track on GT sport aswell wow, I know people said they saw polyphony at the track a while back..
So there is a helmet cam. Show pic, please.
Considering the massive popularity of the consoles it's obviously not a deal breaker for most people. Those who need 60 fps in every game will need a gaming PC, because it's safe to say that most developers are likely to continue choosing visual fidelity at 30 fps over pared back visuals (comparatively) at 60 fps on consoles. The PS4 Pro and XBox One X are probably only an exception at the moment because they have versions of the same games, with the next proper console generation I imagine we'll be back at a graphics boost at 30 fps.
Regarding input lag, as far as I'm aware input delay is not tied to framerate in all games, particularly racing games?
" If you’re playing your games at 30 FPS then the amount of time your display is sitting on one frame is 33.3 milliseconds. This means that when you move your mouse to aim at a target, it will take at least 33.3 milliseconds before you even start to see the cursor move. This delay is halved to 16.65ms at 60 FPS and so on. Of course this is without considering other factors such as networking latency (in multiplayer games) and monitor response time which can add additional latency. " from here : http://www.technologyx.com/featured/understanding-frame-rate-look-truth-behind-30v60-fps/
Dont get me wrong, im not try to make this TT game bad.
It's only because of 30fps in a racing game, which is a no go criteria.
In a game, the output only changes when the GPU pushes a frame out of the buffer. That is your framerate. Sometimes it's a complete frame, sometimes it contains information from two successive frames (tearing) - the latter only when the game is late delivering its frames to the display. The display's response time is only a measure of how quickly the hardware pixels can change output. The screen cannot display info it has not yet been given.That quote doesn't sound right to me.. the refresh rate isn't linked to input - all other things being equal - if your display is due to refresh in 5ms time, and you've just moved the mouse, you will see that happen on the next refresh (i.e. in 5ms time), if it refreshed 1ms ago, then yeah - you'll have to wait, at most 32ms, where with 60fps you'd only have to wait 15ms. But the way that article is written makes is sound as though it takes 33ms from any action to display it. I'm not expert, but that doesn't sound like how it works.
In a game, the output only changes when the GPU pushes a frame out of the buffer. That is your framerate. Sometimes it's a complete frame, sometimes it contains information from two successive frames (tearing) - the latter only when the game is late delivering its frames to the display. The display's response time is only a measure of how quickly the hardware pixels can change output. The screen cannot display info it has not yet been given.
That means anything that is supposed to respond to player input won't register any changes until the frame is updated on the display.
To get to the point you brought up, the input is usually only polled at the framerate, i.e. it is sampled at the point of frame setup, and never looked at again until the next frame. Then you have to wait for the scene to be drawn and put to the display. So by the time you get to see any change, your input could well have changed as well, but the game cannot keep restarting the drawing process every time the input changes between its frame output targets, else you'd never see anything useful. Of course, it's worth wondering precisely why your input would have changed (in any meaningful way) when you have not been presented with any new information (on the screen) since the last frame.
Sometimes games resample the input later in the frame, depending on where in the drawing process it is, or at several intervals during a frame, to get a better idea of what the player expects, and to "feed forward" that info to the next frame - this can reduce apparent (or sometimes actual) latency.
EDIT: Sometimes, the game logic is "threaded" separately from the graphics, and it could easily be the case that the current frame is actually being drawn based on the last frame's physics, AI, general game "state machine" etc. output, adding a whole extra game tick of delay to certain aspects of what you see.
VR stuff has required a real close look at this kind of thing, and there are even technologies developed to warp finished frames to better match the latest input (i.e. head position) which may have changed since the frame was first begun to be drawn. This could have useful applications in general, in terms of reducing perceived latency and improving the sense of connectedness, outside of VR.
In most sims it was long (long) ago discovered that "decoupling" the physics from the renderer was extremely beneficial to the overall fidelity, simply because higher-frequency and phase-related information is better preserved between steps in the actual simulation. I.e., you want fast physics simulation to get objects to land where they're supposed to land, but generally graphics can't keep up, so you have to draw the results at a slower rate.That makes sense. I'd assumed that input sampling and calculation of 'mechanical' stuff in the environment would be done at a set speed... with the graphical output not being directly linked. This was under the assumption that things that make a complex physics engine, and things that make for a complex rendering process aren't the same things.
FWIW, on topic, so far I've not been finding the FPS of this game to be much of a problem. Could do with 4K on a bigger TV to help make out things in the distance, for me.
A big part of FoV selection is making out important landmarks in the distance, e.g. apexes, braking points etc. Is there an option for that?