• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
donguow

Transmission latency - OpenGL

10 posts in this topic

Hi all,

I got a problem and hope someone here can help me out. I have a server which performs rendering according to the request from the client and then sends the rendered image back to the client. Currently, the server just simply sends every single image to the client at a time so it introduces significant delay. Is there any way to stream data from the server to the client that can reduce the transmission latency?

I will really appreaciate your help!
Dong
0

Share this post


Link to post
Share on other sites
Unless you are talking about client and server as defined by the OpenGL specification (which I assume you're not since then you wouldn't be sending images), then this has nothing to do with OpenGL. Moving to the networking forum.
0

Share this post


Link to post
Share on other sites
Latency cannot be changed, it's limited by speed of light these days.

What can be increased is bandwidth.

Instead of sending requesting a single image and waiting for response, request 10 images and as they are received, keep requesting more. Such mechanism is used even in local applications, both OGL and DX support multiple buffers. While one is being displayed on screen, the other is waiting and the third is being drawn to.

If you cannot request more, then there is no solution, except changing the physical configuration of the server.
0

Share this post


Link to post
Share on other sites
You can encode the raw frames with some sort of video compression. How well that works depends on what you're rendering. Most video compression is based on differences between frames - if you have a fairly static scene with little movemen (like a cursor on the desktop) it will help dramatically. If you are rendering something like a first person point of view, not so much (because moving even slightly will change the entire frame).
0

Share this post


Link to post
Share on other sites
[quote name='turch' timestamp='1327940502' post='4907676']
Most video compression is based on differences between frames - if you have a fairly static scene with little movemen (like a cursor on the desktop) it will help dramatically. If you are rendering something like a first person point of view, not so much (because moving even slightly will change the entire frame).
[/quote]

Video compression will drastically increase latency. The higher the compression, the worse the latency.

Ideal temporal video compression would take all frames into consideration, which means waiting for all frames to be generated before they can be analyzed for compression.

Size of each image itself doesn't impact latency beyond some basic factors, it's only a factor of bandwidth.
0

Share this post


Link to post
Share on other sites
[quote name='Antheus' timestamp='1327941155' post='4907683']
[quote name='turch' timestamp='1327940502' post='4907676']
Most video compression is based on differences between frames - if you have a fairly static scene with little movemen (like a cursor on the desktop) it will help dramatically. If you are rendering something like a first person point of view, not so much (because moving even slightly will change the entire frame).
[/quote]

Video compression will drastically increase latency. The higher the compression, the worse the latency.

Ideal temporal video compression would take all frames into consideration, which means waiting for all frames to be generated before they can be analyzed for compression.

Size of each image itself doesn't impact latency beyond some basic factors, it's only a factor of bandwidth.
[/quote]

You are correct, I misread the question as one of bandwidth :D
0

Share this post


Link to post
Share on other sites
It depends on whether the latency is introduced by bandwidth limitations, or by latency limitations.
If the latency is introduced because it takes a long time to send the image because bandwidth is limited, then compression can decrease latency. (Note: B-frames, that need to see "the future," are unlikely to be a good match for real-time video compression)
However, the problem is so vague that I don't quite understand how to answer it. What is the service? What does the client do, an what does the server do? What data does the client send to the server? What does the client do with the data it receives from the server?
0

Share this post


Link to post
Share on other sites
Hi all,

What's I am testing now is on a single machine, both client application and server application are on the same PC. So bandwidth is not really a big issue, I think. Of course, if we have better hardware, the processing time can be reduced.

To make it a litle bit clearer, I will briefly discribe my system as follows:

Suppose I have two machines, one is server and the another one is client. The server stores a database of 3D models and will be responsible for performing rendering when the client requests. For example, for thin clients which oftent lack graphics processing units, it's impossible to perform rendering by itself or for pretty big and complex models it may take quite long to process at the client so it could be better if we offload the computational workload to the server.

My idea is that the server renders the 3D model and save the result as an image file (let's say a bitmap file) and then sends it to the client. So the client wont do anything except sending the request to the server and displaying the image on the screen. This way is quite simple to implement but yields quite low performance. Like every move of the user, it has to send a request to the server and then wait for the update.

I just think that there should be a smarter way to do this. I have read a paper, and what people have done is to generate a live video while the server is rendering and then stream video data to the client to be displayed. The paper did not mention very detail how to implement that so it just gave me the basic idea. And to be frank, I am not familier with video coding/encoding so just hoping that someone here can help me to figure it out.

Thank for your help,
Dong
0

Share this post


Link to post
Share on other sites
[quote name='donguow' timestamp='1327983755' post='4907873']
This way is quite simple to implement but yields quite low performance. Like every move of the user, it has to send a request to the server and then wait for the update.[/quote]
Yes, there is no way around it. To render a new image, you need to wait for input.

[quote]I have read a paper, and what people have done is to generate a live video while the server is rendering and then stream video data to the client to be displayed.[/quote]

Games keep going, whether user presses a button or not. So to render next frame, they don't need to wait for user input. But reactions to key presses will still be delayed by time needed to send the events and update the state.


To understand your poor performance, measure the time needed to:
1) register input on client
2) send this input to server
3) generate the image
4) send this image to client
5) display image on client

Sending a raw 1024*768*4 image over 52mbit LAN (wifi, usual home router) takes ~0.5 second.
Sending same image compressed as JPEG (~200kb) takes only 0.03 seconds, but also requires server to compress the image and client to decompress, which takes some time as well. So compression will take a total of T_compress + 0.03s + T_decompress time to send.

Steps 1-5 must take less than what is perceptible to human eye. 30 FPS would be very good. Or, 1s/30 = 0.033s. So all steps, 1-5 must take less than 0.033 seconds. In above example, the JPEG image would simply be too big, despite compression unless everything else takes 0 time.


These are the hard limits that must be addressed first. Once you ensure that your server is capable of performing full roundtrip at desired framerate, then you can start thinking about other optimizations, should they still be needed.

OnLive had to develop custom hardware to tackle this problem, but they also deal with high latency of WAN. But it's doable.

What such services cannot do, is render in advance. Anything that depends on user input (key press, mouse move), cannot be reliably predicted, so those will always be constrained by physical limits.
1

Share this post


Link to post
Share on other sites
Thank Antheus, the above steps are very straightforward to locate the bottleneck. I will check it out. I did think of using compression techniques to deal with transmission latency. I will be highly appreaciated if you can point me to some tutorials or examples of how to implement it.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0