Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 14 Feb 2007
Online Last Active Today, 07:16 AM

#5176140 What you think of my Depth Pass AA?

Posted by Hodgman on 26 August 2014 - 12:04 AM

Some of the FXAA versions are freely downloadable, so implement them as well and do some head-to-head comparisons.


Your screenshot looks good, but it's a very simple case. You'll have to test on a bunch of other scenes to see how well it compares.


Unfortunately nVidia has decided to sell TXAA as middleware, so you need to sign an NDA to get any info on it at all.


Epic have spoken about their temporal-AA solution here: https://de45xmedrsdbp.cloudfront.net/Resources/files/TemporalAA_small-59732822.pdf

#5175890 free private SVN with biggest disk space?

Posted by Hodgman on 24 August 2014 - 06:34 PM

If you don't have a static IP, there's a few free dynamic DNS services out there who will give you a static domain name that redirects to your dynamic IP.

#5175750 free private SVN with biggest disk space?

Posted by Hodgman on 23 August 2014 - 11:41 PM

Yep, most flexible free solution is to host it yourself laugh.png Leave a PC on 24/7 running the SVN daemon, and tell your router to forward the SVN ports on to that PC.


Alternatively, it's free to rent a private host in the amazon cloud with 5GB of storage (for the first 12 months).


[edit] as pointed out below this can be as expensive as renting a server/service -- A 250W PC * 0.15c/kWh * 24hrs * 30days = ~$27/month -- so check your utility rates and look into low-power PCs to use as the server :D

#5175719 Rendering commands container implementation dilemma

Posted by Hodgman on 23 August 2014 - 06:53 PM

I do the same giallanon - allocate from a stack of bytes, each command is variable-sized with an ID byte on the front, keeping a pointer to the first item allocated lets you later iterate them in FIFO order, and for next frame you just reset the stack-alloc's cursor back to zero for fast reuse.

#5175607 Indiscrete Logic

Posted by Hodgman on 23 August 2014 - 02:40 AM

Obviously I am not welcome here.

You're welcome to post. You've received confused responses because your post is confusing.


There is no question posed in your post. Are you looking for advice on how to apply for a patent? Do you want to stimulate discussion about the idea that you linked to? Do you just want to explain the idea and see what people think of it? What's the intention behind that post - what kind of responses are you looking for?


On a discussion forum, you have to either ask a question or give some kind of indication for what kind of discussion you're looking for. If you just dump a whole bunch of information in a post, you'll get replies asking you why you posted... which is what you've got.

A blog or a journal is fine for just dumping information on, but a forum assumes a question or discussion topic.

#5175586 Intel crash

Posted by Hodgman on 22 August 2014 - 08:27 PM

You can try passing your shader code through the refence compiler - it's supposed to be the gold standard for whether your GLSL code is valid or not.

#5175583 DXT normal map compression

Posted by Hodgman on 22 August 2014 - 08:11 PM

Is the internal ATI/NVIDIA format adding Green channel bytes and how many? Because it is the same Green/Alpha packing the only difference could be that they do something like DTXNormal = [4][8][4][Alpha].

Are you taking about the end of the tutorial where they mention ATI2/3DC? As posted above, this format is also known as BC5 - so you'll be able to find info on it under that name.
It doesn't store 4 channels, only 2!
So you get 8bit green & 8bit alpha, without wasting bits on red/blue like you do with the DXT5 trick.

The way this works with the shader is, the channels are called Luminace and Alpha (not green and alpha). When you sample from the texture, the shader receives float4(L,L,L,A) - Luminace is copied into R, G & B, which is handy because as mentioned in the tutorial, it's then compatible with he same shader code as "DXT5-swizzle" normal maps.

#5175577 So... C++14 is done :O

Posted by Hodgman on 22 August 2014 - 07:52 PM

*In practice* int is still 32bit on *most* x86-64 compilers


#5175484 So... C++14 is done :O

Posted by Hodgman on 22 August 2014 - 08:35 AM


But that's the point. Something as simple as a vector, shouldn't have different versions. It shouldn't be possible to write a significantly better version by using compiler specific features. That undermines C++ as a portable language.

Pardon me? C++, a portable language? Name mangling, type-size-differences, compiler/os/cpu-specifics, DLL-hell? You *can* make portable C++-code, but there is certainly not a standard-solution, and I definately wouldn't call C++ a "portable" language. Granted, giving a default STL implementation would make it a tad bit more portable by default, but thats appearently NOT what C++ aims at - to be portable without some amount of dedication, that is.

Ironically, we write our game engines in C++ because it happens to be one of the most portable languages, next to C. To port a game written in anything else to a new platform, you'd first have to port that language's runtimes, which are probably C/C++ code laugh.png

Sure, the native binaries aren't portable (DLLs aren't a C++ feature, but a compiler feature), but vast majority of source code is portable without issue.

#5175365 So... C++14 is done :O

Posted by Hodgman on 21 August 2014 - 05:40 PM

Isn't that the difference between implementation-defined and undefined?
The former will do something predictable, but not specified here, whereas the latter has no guarantees at all?
Signed shifts or overflows etc are implementation-defined IIRC.

#5175246 DeltaTime and acceleration

Posted by Hodgman on 21 August 2014 - 06:30 AM

What you're doing here is called "numerical integration" -- integrating a function by summing up small steps, instead of solving an equation analytically (e.g. o=u*t+1/2*a*t^2)

The particular technique you're using is "Eulers method". It's one of the most common in games, but yes, does give different answers depending on your step sizes.

You can actually notice in many games that the distance you can jump depends on your frame rate!!!
As above, a foolproof solution to make it deterministic is to choose a fixed simulation time-step.

You can also look into alternative integration schemes, such as RK4.

#5174668 So... C++14 is done :O

Posted by Hodgman on 19 August 2014 - 04:22 AM

Why would you use any of those examples when the idiomatic version from the past 2 or 3 decades still works, is understood by everyone, and generates the same ASM? :lol:
std::vector<Class*> vValues;
for( int i=0, end=vValues.size(); i!=end; ++i )
I agree with Frob's post on language bloat. New features are nice, but duplicated/redundant features for the sake of being modern are unecessary.

#5174620 Checkstyle

Posted by Hodgman on 18 August 2014 - 10:17 PM

laugh.png "The best way to get a bad law repealed is to enforce it strictly"
Demonstrating that the rules are broken by creating unreadable code that passes the readability guidelines seems a fair demonstration!

As for line lengths, while you can rotate monitors by 90° without too much effort these days, most guys I know work on an unrotated 16:10 or 16:9 monitor, so long lines are actually not that bad.

90º monitors / 9:16 aspect FTW!! I use a 1920*1080 and a 1440*2560.
Also, when using a 16:9 aspect, I always split the IDE down the middle so I can see two files at the same time cool.png

No need to strictly stick to the traditional 80 characters (as derived from when we coded via terminals), but it's still a good idea to resort to line-breaks after some point. 

#5174423 Why the texture blurred ? I need it keeps the same resolution of the source i...

Posted by Hodgman on 18 August 2014 - 05:57 AM

Are you trying to display it at actual size (one texture-pixel = one screen-pixel), or stretch it over the whole window?

If the first, you need to very carefully place your vertices at the corners of the screen pixels, which means shifting the vertices up+left by half a screen pixel.

If the second, you have to blur it, because you're resizing...

#5174369 Overhead with gl* Calls

Posted by Hodgman on 17 August 2014 - 11:37 PM

That being said, any thread making a gl* call will be halted while the CPU queries the GPU, waiting for a response. Is this correct so far?
No. Most gl calls will just do CPU work in a driver and not communicate with the GPU at all.

The GPU usually lags behind the CPU by about a whole frame (or more), so GPU->CPU data readback is terrible for performance (can instantly halve your framerate). glGet* functions are the scary ones that can cause this kind of thing.


Most gl functions are just setting a small amount of data inside the driver, doing some error checking on the arguments, and setting a dirty flag.

The glDraw* functions then check all of the dirty flags, and generate any required actual native GPU commands (bind this texture, bind this shader, draw these triangles...), telling the GPU how to draw things. This is why draw-calls are expensive on the CPU-side; the driver has to do a lot of work inside the glDraw* functions to figure out what commands need to be written into the command buffer.

These commands aren't sent to the GPU synchronously -- instead they're written into a "command buffer". The GPU asynchronously reads commands from this buffer and executes them, but like I said above, the GPU will usually have about a whole frame's worth of commands buffered up at once, so there's a big delay between the CPU writing commands and the GPU executing them.