TTimo es_core low latency framework for high fps games?

Discussion area about developing or extending OGRE, adding plugins for it or building applications on it. No newbie questions please, use the Help forum for that.
Harley
Gnoblar
Posts: 1
Joined: Mon May 13, 2013 1:17 pm

TTimo es_core low latency framework for high fps games?

Post by Harley »

Anyone looking into to implementing es_core into mainline OGRE 3D graphics engine as option to enable for first person shooter games?

Sound like es_core technology could be perfect to use in all rendering engines used by first person shooters and other high fps games!


es_core is an new experimental framework for low latency, high fps multiplayer games, and is being developed by Timothree Besset, (a.k.a. TTimo on this and other forums), formerly of id Software.

As I understand it, right now es_core should already be possible to get it to work with any game engine that can use the OGRE rendering engine, (like for example many SDL based games does), but as es_core is open sourced and "AS IS" licensed this framework could be ported to the rendering engine for any game engines, as all the code is royalty-free / public domain under that "AS IS" license. Or you could choose to just copy the concept idea for this to your own rendering engine as the method is not under any software patent.

Would be very nice to have es_core implemented nativly into OGRE rendering engine, that way it can simply be enabled via a parameter option for those who want to use it. Disabled by default of course since it is really only of use in applications that require very high frame rates and low latency, and where low latency is more important than rendering accuracy, like it is for VR HMD (Virtual Reality Head Mounted Dispalys) such as the Oculus Rift VR headset.


C++ source code to built it available for Windows, Linux, and Mac OS X on GitHub as open source here:
https://github.com/TTimo/es_core

Please read http://ttimo.typepad.com/blog/2013/05/e ... games.html for a better general introduction and some background about this project.


Checkout these very involved blog posts by Michael Abrash and John Carmack on the importance of low latency in games made for VR headsets like the Oculus Rift:

http://blogs.valvesoftware.com/abrash/l ... ar-and-vr/

http://www.altdevblogaday.com/2013/02/2 ... trategies/


I first heard about today in this article about es_core on phoronix.com who tried to sum up this new framework like this:
http://www.phoronix.com/scan.php?page=n ... px=MTM3MDU
TTimo Announces Experimental Framework For New Games
Posted by Michael Larabel on May 12, 2013


Timothree Besset, perhaps better known amongst Linux gamers as "TTimo" and the former main "Linux guy" at id Software, has announced es_core. The purpose of es_core is to provide an experimental framework for low-latency, high-FPS multi-player games.

Besset described in a blog post. Here's the key of what es_core is all about:

This got me thinking about how I would approach this, and what my ideal engine framework would look like. We are talking PC-centric, mouse and keyboard gaming here. High end GPU, multicore CPU, 120 Hz display and low latency, high precision input.

Renderer eye candy should never get in the way of a smooth game simulation. A sudden dip in renderer fps should never mean that you are going to miss that jump, or that your mouse handling is going to turn you around in a slightly different way than usual.

The technology foundation for a project like this is extremely important. Unity and UDK are amazing engines, but they are general purpose in nature, and they made compromises to that end which make them ill-suited.

So I decided to put some code together to explore the subject. There's just enough stuff now that I feel it's worth putting it out to get some feedback. I've named this es_core, you can find the project on github.


With this experimental framework, Ogre is being used as the renderer, SDL2 is supported, and input is sampled in its own dedicated thread. All threaded communication is being done by message passing built on ZeroMQ.

You can check out the early code on GitHub with support for Windows, Linux, and OS X
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 535

Re: TTimo es_core low latency framework for high fps games?

Post by Kojack »

I was just thinking of posting this, having read it on the oculus forums. :)

I haven't looked into the project yet, but it does sound interesting. Plus any use of ogre (especially in situations where unity and udk are described as not suitable) gets my attention. :)

For integrating into ogre itself, that's a bit early. By the sound of it, es_core is currently an experiment, he's looking for feedback on the methods used. But in the future it could be useful.
TTimo
Gnoblar
Posts: 8
Joined: Wed Dec 28, 2011 9:39 pm

Re: TTimo es_core low latency framework for high fps games?

Post by TTimo »

Hey guys :)

I don't know if there is anything to integrate between es_core and Ogre3D. I looked at several renderers for es_core, and I picked Ogre for a few reasons: I like the non-nonsense API, the focus on being strictly a renderer, and the active community.

I am looking for feedback, and contributors for es_core. I'm trying to shape it as a fun playground to iterate on ideas and solve a few nagging problems. Right now I'm mostly interested in problems that are not at renderer level, but more general to multiplayer and netcode, and to game code architecture. How to write solid game code and iterate fast with it. But I can think of a number of Ogre-focused things that would be quite awesome to look at:

[*] Make es_core a "grab and go" framework for new Ogre-based projects. OIS seemed a bit old and crufty which is why I picked SDL. I would like to see a GLFW backend as well. The thread split + interpolated renderer may be a bit much for folks looking for a simple structure to start with, that could be simplified. The code shows how SDL and Ogre can integrate on the three main desktop platforms though, which wasn't trivial to get done: http://www.ogre3d.org/forums/viewtopic.php?f=2&t=53359

[*] Speaking of which: Ogre's OSX initialization could be improved so integration is more inline with other platforms. Far as I could tell there was no support for an externally managed OpenGL context there.

[*] Occulus Rift! That would be a great addition. I have a devkit, but I haven't really done anything with it. If someone is working on Ogre + Occulus Rift support, I would love to get es_core together with his improvements.

[*] Adding input sampling and view setup even later in the render work. At the end of the scene setup, or even as part of the GPU work. I've written a small comment about that here: http://ttimo.typepad.com/blog/2013/05/e ... 118861970c

[*] Feeding larger test scenes, that have a decent CPU and GPU cost to be 'representative'.

There's plenty of other possible directions for es_core, but they aren't as specific to Ogre. One thing for instance would be to improve the timing of the render thread and explore options for not being constrained to vsync.
User avatar
Kojack
OGRE Moderator
OGRE Moderator
Posts: 7157
Joined: Sun Jan 25, 2004 7:35 am
Location: Brisbane, Australia
x 535

Re: TTimo es_core low latency framework for high fps games?

Post by Kojack »

[*] Occulus Rift! That would be a great addition. I have a devkit, but I haven't really done anything with it. If someone is working on Ogre + Occulus Rift support, I would love to get es_core together with his improvements.
Already in the works: http://www.ogre3d.org/forums/viewtopic.php?f=5&t=76970
Although I've put it on pause for now while I wait for my rift (maybe in 1-2 months from now, based on current shipping rates). It's getting hard to develop for it without having any idea what it's like to use, just relying on other people to test for me.
User avatar
sparkprime
Ogre Magi
Posts: 1137
Joined: Mon May 07, 2007 3:43 am
Location: Ossining, New York
x 13

Re: TTimo es_core low latency framework for high fps games?

Post by sparkprime »

Isn't this just about not letting the rendering thread block the input and game logic?