Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Offline Last Active Yesterday, 02:36 PM

#5286316 Best laptop for game development?

Posted by on 11 April 2016 - 10:21 AM

Both the Dell Inspiron 15 7000 series and Dell XPS 15 are excellent laptops. The Lenovo Y700 seems to be a great choice as well. In either case, I would opt for a dedicated GPU model if you can. I would not touch MSI again.


Of the laptops you listed just now... the T540 has a dedicated GPU so I would probably put that at the top of the list.

#5284557 When would you want to use Forward+ or Differed Rendering?

Posted by on 31 March 2016 - 07:47 PM

Crudely speaking, the cost of rendering in forward is N objects * M lights. This means that heavily lit geometrically complex environments get very expensive. Deferred was developed because the cost of rendering for that approach is N objects + M lights. Lighting in deferred is very cheap, even thousands of them if they're small. I've used deferred pipelines in the past to run dense particle systems with lighting from every particle and stuff like that. The downside is massive bandwidth requirements, alpha blending problems, anti-aliasing problems, and material limitations.


Forward+ and its variations were developed to get the benefits of cheap lighting in deferred, but without all of the other problems deferred has. While bandwidth use is still pretty high, it tends to cooperate much better with more varied materials, alpha blending, and AA. It also leverages compute tasks for better utilization of GPU overall. In general, I would tend to encourage Forward+/tiled forward as the default rendering pipeline of choices on modern desktop/laptop hardware, unless you have a specific reason not to.

#5283934 What happens if gpu reads and cpu write simultaneously the same data ?

Posted by on 28 March 2016 - 03:50 PM

I found the documentation on it: https://github.com/GPUOpen-LibrariesAndSDKs/LiquidVR/raw/master/doc/LiquidVR.pdf

It's actually being called Late Data Latch and the whitepaper has a brief explanation:


The Late Data Latch helps applications deal with this problem by continuously storing frequently updated data, such as, real-time head position and orientation matrices, in a fixed-sized constant buffer, organized as a ring buffer. Each new snapshot of data is stored in its own consecutive data slot. The data ring buffer has to be large enough to ensure the buffer will not be overrun and latched data instance will not be overwritten during the time it could be referenced by the GPU. For example, if data is updated every 2ms, a game rendering at 100fps should have more than 50 data slots in the data ring buffer. It is advised to have at least twice the minimum number of slots to avoid data corruption. Just before the data is to be consumed by the GPU, the index to the most up-to-date snapshot of data is latched. The shader could then index into the constant buffer containing the data to find the most recent matrices for rendering.

#5283741 OpenGL Check if VBO Upload is Complete

Posted by on 27 March 2016 - 12:15 PM

apitest shows how to issue a fence and wait for it. The first time it checks if the fence has been signaled. The second time it tries again but flushing the queue since the driver may not have processed the copy yet (thus the GPU hasn't even started the copy, or whatever you're waiting for. If we don't flush, we'll be waiting forever. aka deadlock)
Of course if you want to just check if the copy has finished, and if not finished then do something else: you just need to do the 'wait' like the first time (i.e. without flushing), but using waiting period of zero (so that you don't wait, and get a boolean-like response like OP wants). We do this in Ogre to check for async transfer's status.

So can you use a fence to test for the actual status of a BufferSubData call uploading to server? And that works consistently across platforms without issuing a draw call against that buffer? After all the driver must do a full copy of the buffer to somewhere in-core at the point of call, but what the rube goldberg machine does after that is anyone's guess.



Calling glDraw* family of functions won't stall because it's also asynchronous. I can't think of a scenario where the API will stall because an upload isn't complete yet.

It'll stall if it gets caught in a situation where it can't continue dispatching frames without finishing a pending operation. I don't remember seeing this happen with buffer uploads, but I've seen it many, many times with shader recompiles. Whether this is because shader recompiles are a long goddamn process, or they have to happen in the main thread, or it just runs up against the limit of buffered frames, or some combination thereof, I'm not sure. It seems conceivable that a large upload followed by lots of dispatched frames could conceivably trigger the same effect.

#5283665 OpenGL Check if VBO Upload is Complete

Posted by on 26 March 2016 - 09:57 PM

Meaning that if you update the VBO then call draw, the result will appear to be sequential/serialized..they WILL happen in the order submitted.

We're not talking about logical ordering or things appearing serialized. There's a ton of operations in GL that are deferred internally, which in turn will cause runtime hitches when the driver decides to actually commit operations. Buffer uploads, texture uploads, and especially shader (re)compiles are the prime suspects here. This is not an imaginary problem for anyone who has actually shipped a game on a GL pipeline.


Issuing a dummy draw call - and potentially a fence or glFlush/glFinish/SwapBuffers - is the only way to combat this problem of runtime hitches. 

#5283626 OpenGL Check if VBO Upload is Complete

Posted by on 26 March 2016 - 04:38 PM


Because the OpenGL spec doesn't recognize the transfer as asynchronous, per se, there's no way to check. The only option is to force it to wait by issuing a dummy draw call. There are a variety of other things that can also be deferred and lead to hitching in-game, and so it's standard practice to issue dummy draw calls for these things. Getting rid of all this is one of the big improvements in the new APIs (DX12/Vulkan).


Ah, I see! In that case, I may just set a time-out and only try to render after half a second or something; this won't be noticeable. Problem with DX12 is that one can't support Linux,  which for me is a crime if one can avoid it. Vulkan looks promising. Thanks for letting me know though.


It's not necessarily on a timer. Sometimes the driver simply can't be bothered to finish the upload until you actually issue a draw call.

#5283621 OpenGL Check if VBO Upload is Complete

Posted by on 26 March 2016 - 04:09 PM

Because the OpenGL spec doesn't recognize the transfer as asynchronous, per se, there's no way to check. The only option is to force it to wait by issuing a dummy draw call. There are a variety of other things that can also be deferred and lead to hitching in-game, and so it's standard practice to issue dummy draw calls for these things. Getting rid of all this is one of the big improvements in the new APIs (DX12/Vulkan).

#5282493 GIT vs Mercurial

Posted by on 21 March 2016 - 07:46 PM

I hate both. But I hate Git less and there's a large community based around it, GitHub being ground zero. For ease of use and all around sanity, Subversion is still vastly superior. Subversion also goes ballstic and then implodes on most branch merges, though. Git will hassle you constantly, about inane bullshit they could've easily fixed. Once in a while it will detonate more seriously. But the issues are manageable, and you gain a very capable and flexible version control system. Light history editing (particularly commit messages) and sane merges are fantastic to have. Git's also finally starting to grapple with large file management seriously, but another option is simply to run those things out of Subversion.


Mercurial doesn't support partial/cherry picked commits, on purpose. You have to play games with shelving extensions and other nonsense. I assume this is great for web developers or something. As far as I'm concerned, this is so far out of touch with normal software development that I refuse to deal with it.

#5282397 Math I need to know to make shaders

Posted by on 21 March 2016 - 12:28 PM

Computational geometry is the missing piece in what people have listed so far. Also consider robotics courses, as they are excellent primers in handling coordinate transformations.

#5282278 Efficient resource manager for OpenGL in C++?

Posted by on 20 March 2016 - 11:44 PM

I'm getting the feeling everybody's not on the same page about what a "resource manager" is.

#5282275 Too good to be true?

Posted by on 20 March 2016 - 11:29 PM


1. Buy RPG Maker MV for $80.
2. Craft an RPG storyline over the course of several months - say $10k worth of labour.
3. Make a RPG using premade assets.
4. Throw in a couple of songs not in the kit for flavor.
5. Release it on the App Store, because you can legally release games made with the kit even using the kit's assets AFAIK - just read the terms
6. Probably make zero dollars, since about eight million games are published per second and you did no marketing



#5282274 Efficient resource manager for OpenGL in C++?

Posted by on 20 March 2016 - 11:19 PM

I just store them in a vector, and pass the array index around inside an opaque handle ¯\_(ツ)_/¯ Also keep a map around for string to index lookups. Right now indexes are never reused, makes it easier to track use-after-delete.


Of course things get rather a lot more complex with streaming.

#5282204 Object Space Lightning

Posted by on 20 March 2016 - 04:48 PM

I went over the presentation yesterday, and it's fascinating. I'm all in favor of exploring alternative approaches to shading, and this is definitely a very different set of trade-offs. That said, I don't get the comparisons to REYES and overall it seems like a very special purpose, application-specific approach to rendering. They spend a good amount of time talking about fixing it to work for terrain, after all. What on earth would happen to it if you gave it general purpose world geometry, like you'd see in a Battlefield game? And as you correctly mentioned, it's terribly sensitive to the structure of texture space for the models you feed it.


I simply can't see it as a basis for a general purpose rendering pipeline.

#5282145 How secure is it to host a server from home?

Posted by on 20 March 2016 - 10:08 AM

<Obligatory Clinton joke>



Although I have absolutely no idea if it is secure to do it from home.

The physical location of the machine is entirely unimportant. Security is about configuration, surface area, patches, and monitoring. Securing a server is difficult but it's a good skill to learn, particularly when it's unlikely that anyone actually wants to hack you. But:



Is there a possibility of someone "hacking" into my machine and having access to files in it just by knowing the ip of the machine? 

Absolutely yes.


Our code server is configured with an absolute minimum number of services, and the services that do run are running off non-standard ports. Root logins are disabled, and other logins are only for whitelisted usernames and only via private key authentication. Access to the server itself is based off whitelisting, and there are a few misc tools like fail2ban running that monitor for suspicious activity. Most of these choices are focused around minimizing the surface area for an attack, and making it difficult to even find the server. The more a server has to advertise itself to the world and provide services, the harder these things get.

#5281694 DBA still a 1099 or no

Posted by on 17 March 2016 - 10:25 AM

You should probably seek professional advice. That said, the long and short of it is that you should expect a 1099-MISC and the money will be taxed as personal income on a single tax return. Remember, DBA is an alias for you personally. It makes no difference which account the money lives in, and the concept of paying yourself from the DBA is nonsense. You seem to think that maybe a DBA is some kind of LLC-lite and it absolutely isn't. It is not even a separate entity. The DBA just says: "dear IRS, sometimes I'm Bob and sometimes I'm Dave, but they're both me so don't separate the two."


Note for the future that the core identifying value is your tax ID number, which in the case of a DBA is your social security number. A separate return requires a separate tax ID, which in turn involves a somewhat elaborate registration process.