next »

[Abadox]

Thanks for the food for thought everybody.

[Polly]

Can't that be solved by adjusting the positions of objects by the delta of time elapsed when the render function is called?

Sure, that's possible. Personally i prefer to not decouple them so input stays as snappy as possible.

Also, check out this article on Mario Kart 8, which displays a duplicate frame every 64 frames ( not sure if this has been patched since ). This effectively means it's running at 59fps on a 60fps display .. even though that's only a marginal difference it's still noticeable.

[ProgramGamer]

Also, check out this article on Mario Kart 8, which displays a duplicate frame every 64 frames ( not sure if this has been patched since ). This effectively means it's running at 59fps on a 60fps display .. even though that's only a marginal difference it's still noticeable.

I have worked so hard to find a solution to this and Nintendo can just afford to not worry about it???

[InfiniteStateMachine]

Can't that be solved by adjusting the positions of objects by the delta of time elapsed when the render function is called?

Sure, that's possible. Personally i prefer to not decouple them so input stays as snappy as possible.

Also, check out this article on Mario Kart 8, which displays a duplicate frame every 64 frames ( not sure if this has been patched since ). This effectively means it's running at 59fps on a 60fps display .. even though that's only a marginal difference it's still noticeable.

Yeah I feel the same. So much that I've never really tried it. I just wasn't sure if I was missing something where that method wouldn't work.

As for the mario kart thing. I don't think it's the same issue but Bloodborne would have a problem where it would periodically re-render the same frame. I just looked it up and apparently it's considered some type of bug.

Though its 30fps average is technically correct, Bloodborne often produces two unique frames followed by two duplicates – rather than one after another – creating a perception of frame-rate drops throughout. It’s not smooth in motion at all as a result, and frame-time updates swing erratically between 16ms and 66ms – and sometimes higher. It’s an unfortunate oversight by From Software. However, we have seen both Bungie [with Destiny] and EA Gothenburg [with Need for Speed: Rivals] react to the issue in each case, correcting their games soon after launch. We hope this will be the case for Bloodborne as well.
Read more at 

http://www.gamerevolution.com/news/bloodborne-the-old-hunters-suffers-from-frame-pacing-issues-8-months-after-games-launch-35591

[Sik]

Probably the bigger issue these days is that you have people who will complain if you don't make your game run at 144FPS on their 144Hz monitor.

You could still theoretically cheat though by running the game logic at 60FPS but interpolating the states between two frames when rendering. It still runs fast enough that you can't notice any input lag or the like, but it looks like it's running at a higher logic framerate than it really does.

[oahda]

Here's a little discussion I found on framerate stuff, dunno if it helps you. http://www.cplusplus.com/forum/general/108295/

[InfiniteStateMachine]

Probably the bigger issue these days is that you have people who will complain if you don't make your game run at 144FPS on their 144Hz monitor.

You could still theoretically cheat though by running the game logic at 60FPS but interpolating the states between two frames when rendering. It still runs fast enough that you can't notice any input lag or the like, but it looks like it's running at a higher logic framerate than it really does.

Yikes. Yeah I'd dare say 144hz update might be a bit much.

Right now when I write a game of my own on my own framework I just lock everything at and dont even bother with render interpolation. My games are simple so performance isn't an issue.

I wonder how long that will still be ok to do. Maybe in the future I could look into setting the fixed step at runtime to be equivalent to the refresh rate.

Here's a little discussion I found on framerate stuff, dunno if it helps you. http://www.cplusplus.com/forum/general/108295/

Thanks for the link. Still reading it as it branches into even more links :D

[powly]

... which results in a noticeable amount of stuttering.

This is exactly what I need that citation on -- "noticeable" seems to be a very flexible thing. But with the frame interpolation and a high enough (you can obviously also go larger; something ridiculous like 1000Hz game logic if perf isn't a problem?) fixed update interval you get the nice framerate independent properties while not having to code everything with respect to a delta time. You also avoid wonky side effects from lower or higher framerates like floats losing precision or rounding differently on different setups and keep everything deterministic which always feels less dirty -- to me, at least.

[Polly]

This is exactly what I need that citation on -- "noticeable" seems to be a very flexible thing.

See for yourself. Below are two versions of the same demo ( rotating wireframe sphere ) ..

60 fps demo / 60 fps video
50 fps demo / 60 fps video

Make sure to watch the videos using a player that supports playback at 60fps and don't forget to set your display to 60 Hertz!

[ThemsAllTook]

I have a 144hz display, and it looks super amazing when I find a game that works on it. I wish there were more. 60hz updates with visual interpolation sounds like a fine solution to me.

[oahda]

Are any devkits for older, but relatively new, consoles available freely today (or even brand new consoles that aren't locked down behind paywalls like many are) so that I can play around with them, practicing console development without intending it seriously, just to learn a bit about it?

So something like Xbox 360 rather than Dreamcast when it comes to age, but preferably something even newer. Needs to support C++ (preferably C++14 at that!). I do have an Ouya but I was thinking more regular consoles. And not mobile devices, already know how to deal with iOS and Android.

[zilluss]

You can register for Nintendo as of now!
https://developer.nintendo.com/register

[oahda]

You can register for Nintendo as of now!
https://developer.nintendo.com/register

Ooh. Can I actually play around for free tho? Like, can I use my own 3DS for example? Or do I have to pay for a special devkit one?

And most importantly, does this mean that I could put 3DS or Wii U code in my open source engine without Nintendo getting angry? And do you know how they deal with rendering? I suppose I can't use OpenGL on them, can I? And what version(s) of C++ do they support? My engine is C++14...

EDIT:
Nope... Found the answer to one important question on their developer portal now:

You will require special hardware to develop and test your 3DS applications. The hardware description pages explain the various types of development hardware available. You should choose your hardware based on the needs of your team and projects.

At least one IS-SNAKE-DevKit unit is required to develop an application. You can choose from a variety of sets that include different numbers of licenses for the various features of the hardware.

So sorry, Nintendo consoles don't fall under the definition of what I was asking for. :/ I wanted to get up and running with a console I've got at home right away, with no money spent at all. The documentation seems too bad to allow for playing around without being serious too. Thanks anyway.

[ProgramGamer]

The Nintendo thing is still neat though.

[oahda]

Yeah, a dev unit seems to be somewhat reasonably priced at least, so maybe in the future, but of course even more reasonable would be to use one's personal console for dev too. :c And I guess one would need to order those special flashcards as well as possibly even a writer for them to do anything anyway? And then perhaps some middleware? And stuff... There's too much on the pages, I wouldn't dare order a thing before someone had told me explicitly what I needed.

Also can't figure out how to set a custom password on the portal...

[zilluss]

I'm currently testing if C++14 is possible. I hope there's a compiler flag. Anyway, it's good that this stuff is more freely available, because porting a game from C++14 to C++11 or lower because you found out Console X doesn't have modern tools would be a nightmare.

If a devkit is too expensive you can always 'unlock' your retail 3DS 

[voidSkipper]

I haven't done any console dev for quite some time (not existing consoles at least), but you used to be able to develop for DSLite using an r4 flash cart and the DevKitARM (or DevKitNDS was it?) toolchain for C.

I don't know if that's too old for you, or if it's something you can still do on modern Nintendo handhelds.

Also, obviously this won't create something you can legally sell - just grey-area homebrew. Great fun if you're just looking to play around, though.

[InfiniteStateMachine]

I'm currently testing if C++14 is possible. I hope there's a compiler flag. Anyway, it's good that this stuff is more freely available, because porting a game from C++14 to C++11 or lower because you found out Console X doesn't have modern tools would be a nightmare.

If a devkit is too expensive you can always 'unlock' your retail 3DS 

C++11 is still a stretch for modern consoles (thanks to a certain straggler...).

Sony loans out stuff often to small developers but you probably need to have a real project you are building towards.

Xbone is supposed to have their rollout at some point where you are supposed to be able to use your home console as a devkit. I think there's a limited rollout already with some odd restrictions. You might want to get used to C++/CLR if you go that route...

[oahda]

Hm... The old version of my engine is C++11 and not C++14. I only started using 14 while beginning my refactoring a few days ago. Maybe I should revert before it's too late. But 14 adds so much sugar and it's already two years old, with the next standard possibly just a year away... :c Why can't people keep up? It's not like their old dev stuff and libs and so on would be rendered incompatible if they decided to allow programs compiled as C++1x, is it?

Real pity big companies aren't indie-friendlier yet. Apple removed the dev cost for just playing around on one's iOS devices now, and has always used regular devices for dev. Why can't Nintendo, Sony and Microsoft? It's a much bigger risk for indies, and it would be great to be able to just mess around with it first to see if one even feels up to task before investing in it...

[InfiniteStateMachine]

I think it's just the amount of work required to maintain a compiler. Often it's some weird privately made C++ compiler. The good news is a lot of manufacturers are starting to go the route of clang so in the near future things should get a lot better.

The thing about the consoles is traditionally they have more ram so you can load a bunch of debug stuff. They also have other small hardware changes that make debugging a lot easier. Once again though. Looks like that trend will change. The xboxone AFAIK is the same as the devkit.

What C++14 stuff do you use?