• Advertisement

Matias Goldberg

  • Content count

  • Joined

  • Last visited

Community Reputation

9610 Excellent

1 Follower

About Matias Goldberg

  • Rank

Personal Information


  • Twitter
  1. User authentication without storing pw's

    That is because there is a high amount of high profile companies using extremely poor security practices. Yahoo! had their passwords stolen which were stored using MD5. LinkedIn was using unsalted SHA-1. They failed at basic security implementations that should be embarrassing given their size. Any strong password implementation should use salted bcrypt2 passwords, and the password exchange every time you login must happen adding extra randomized salts. Thus the passwords are never exchanged in plain text, the hashed password exchange is never the same twice (thus preventing spoofing) and if the passwords database gets stolen, it would take significant time (years) to crack them. The problem with emailing tokens is that emails are sent in plain text format and ping with a lot of servers. It's SO easy to steal them without you ever knowing (and without having to hack your email credentials in any way). I don't want this topic to become political, but that's why the investigation about Hillary Clinton is so important: she store confidential information in her private email account. Regardless of why she did it or whether she should have done that, doing that is extremely insecure. Basically, sending emails is is the equivalent of shouting extremely loud in public. Everyone knows. You can use public/private key encryption for emails, however that creates the problem of telling people to send you their public keys, which you'll have to keep in a database that can get stolen. Yes, stealing a public key is worthless. But I could argue so is stealing a salted bcrypt2 hashed password. Also if hackers manage to steal your private key, they can now impersonate you. Yeah, you can try to revoke your private key. But so can you ask the users to reset their passwords.
  2. The way I approached this was by conceptually splitting the textures into "data" and "metadata". Metadata is resolution, pixel format, type information (e.g. is this a cubemap texture?). Metadata is usually the first thing that gets loaded. So whenever I need it, I can call texture->waitForMetadata(); which will return when background thread gets that information. Or I can register a listener to get notified when metadata is ready. Of course management can get more complex: Do you want metadata to get prioritized? (RIP seek times) or are you willing to wait for 30 textures that come before to finish both their data and metadata before the texture you want gets to load the resolution from file? or maybe you want to design your code so that UI textures get loaded first? A complementary solution is keeping a metadata cache, that gets stored into disk so you can have this info available immediately on the next run. When the metadata cache becomes out of date, your manager updates the cache when it notices the loaded texture didn't match what the cache said. You could also build the cache offline. If you rely on the metadata never being wrong, then you need to write some sort of notification & handling system (tell everyone the data has changed and handle it, or abort the process, notify the user and run an offline cache tool that reparses the file; or look at timestamps to check what needs to be updated, etc)
  3. Semi Fixed TimeStep Question.

    Suppose you minimize the application so everything stops; 30 seconds later the application is restored. The counter will now read that you're lagging behind 30 seconds and needs to catch up. Without the std::min, and depending on how your code works, either you end up calling update( 30 seconds ) which will screw your physics completely; or you end up calling for( int i=0; i<30 seconds * 60fps; ++i )update( 1 / 60 ); which will cause your process to become unresponsive for some time while it simulates 30 seconds worth of physics at maximum CPU power in fast forward. Either way, it won't be pretty. The std::min there prevents these problems by limiting the time elapsed to some arbitrary value (MAX_DELTA_TIME) usually smaller than a second. In other words, pretend the last frame didn't take longer than MAX_DELTA_TIME, even if it took more. It's a safety measure. Edit: Just implement the loops talked by gafferongames in a simple sample, and play with whatever you don't understand. Take it out for example, and see what happens. That will be far more educational than what we can tell you.
  4. what is the appeal of fps games?

    Mass Effect was a shooter, but it wasn't a first person shooter. It's a Third Person Shooter, such as the likes of Tomb Rider, Just Cause, GTA, Hitman, etc. Not quite the same beast. Yup. It's good to point it out because the user base usually takes a great pride in the "realism" from such games (it's the users? the marketing? I don't know), when the reality is that "realism" isn't fun. Reality means a bullet travelling at super sonic speed you first get hit then hear the sound coming. A fun game means sound is simultaneous with impact so the player knows where the bullet is coming from in order to shoot back.
  5. DX11 Resolving MSAA - Depth Buffer to Non MSAA

    In my experience sampling from an MSAA surface can be very slow if your sampling pattern is too random (i.e. I attempted this at SSAO and SSR, didn't go well). I'm not sure why, whether it's because of cache effects or the GPU simply not being fast at it. But likely for your scenario that's not a problem. If you're doing this approach using a regular colour buffer (instead of a depth buffer) would be better. Depth buffers have additional baggage you don't need (Z compression, early Z) and will only waste you memory and cycles. Btw if you're going to be resolving the MSAA surface, remember an average of Z values isn't always the best idea. That won't work because the water still needs the depth buffer to avoid being rendering on top of opaque objects that should be obstructing the water. However as MJP pointed out, you can have the depth buffer bound and sample from it at the same time as long as it's marked read-only (IIRC only works on D3D10.1 HW onwards). This is probably the best option if all you'll be doing is measuring the depth of the ocean at the given pixel. Cheers
  6. DX11 Trying to finding bottlenecks in my renderer

    You're still not using the result. printf() rData[0] through rData[3] so it is used. And source your input from something unknown, like argv from main or by reading from a file; else the optimizer may perform the code at compile time and hardcode everything (since everything could be otherwise be resolved at compile time rather than calculating it at runtime). Sure. I can save you some time by telling you warp and wavefront are synonims. A warp is how NVIDIA marketing dept calls them, a wavefront is how AMD's marketing dept calls them. You can also check my Where do I start Graphics Programming post for resources. Particularly the "Very technical about GPUs." section. You may find the one that says "Latency hiding in GCN" relevant. As for bank conflicts... you got it quite right. Memory is subdivided into banks. If all threads in a wavefront access the same bank, all is ok. If each thread access a different bank, all is ok. But if some of the threads access the same bank, then things get slower. I was just trying to point out there's always a more efficient way to do things. But you're doing a videogame. At some point you have to say "STOP!" to yourself, or else you'll end up in an endless spiral of constantly reworking things out and never finishing your game. There's always a better way. You need to know when something is good enough. I suggest you go for the vertex shader option I gave you (inPos * worldMatrix[vertexId / 6u]). If that gives you enough performance for what you need, move on. Trying Compute Shader approaches also restricts your target (e.g. older GPUs won't be able to run it) which is a terrible idea for a 2D game.
  7. DX11 Trying to finding bottlenecks in my renderer

    I got confirmation from an AMD Driver engineer himself. Yes, it's true. However don't count on it. The driver can only merge your instancing into the same wavefront if several conditions are met. I don't know the exact conditions, but they're all HW limitation related. i.e. if the driver cannot 100% guarantee the GPU can always merge your instances without rendering artifacts, then it won't (even if it were completely safe given the data you're going to be feeding, but the driver doesn't know that a priori, or it would take a considerable amount of CPU cycles to determine so). When it comes to AMD, access to global memory may have channel and bank conflict issues. NVIDIA implements it as huge register file, so there's always a reason...
  8. DX11 Trying to finding bottlenecks in my renderer

    You don't have to issue one draw call per sprite/batch!!! Create a const buffer with the matrices and index them via SV_VertexID (assuming 6 vertices per sprite): cbuffer Matrices : register(b0) { float4x4 modelMatrix[1024]; //65536 bytes max CB size per buffer / 64 bytes per matrix = 1024 // Alternatively //float4x3 modelMatrix[1365]; //65536 bytes max CB size per buffer / 48 bytes per matrix = 1365.3333 }; uint idx = svVertexId / 6u; outVertex = mul( modelMatrix[idx], inVertex ); That means you need a DrawPrimitive call every 1024 sprites (or every 1365 sprites if you use affine matrices). You could make it just a single draw call by using a texture buffer instead (which doesn't have the 64kb limit). This will yield much better performance. Even then, it's not ideal, because accessing a different matrix every 6 threads in a wavefront will lead to bank conflicts. A more optimal path would be to update the vertices using a compute shader that processes all 6 vertices in the same thread, thus each thread in a wavefront will access a different bank (i.e. one thread per sprite). Instancing will not lead to good performance, as each sprite will very likely will be given its own wavefront unless you're lucky (on an AMD GPU, you'll be using 9.4% of processing capacity while the rest is wasted!) See Vertex Shader Tricks by Bill Bilodeau.
  9. DX11 Trying to finding bottlenecks in my renderer

    I skimmed through very long thread just to find only the last post (Mekamani's) point it out. You're multiplying each vertex against a matrix from your CPU, no threading. Taking 40ms for doing 40k matrix multiplications per frame for a single core sounds about correct. That's your problem.
  10. Unreal State of Custom and Commercial Engines as of 2017/2018

    If we go backwards in time, you'll find a lot of games were made in Unreal Engine 3. Nowadays there's more of UE4 games (specially indie) because the license price went down from >$50.000 to "free" until you sell enough then they get 5% cut out of gross sale. There were also a lot of games using RenderWare. The names have changed, but the practices haven't. Many games use canned engines, some games still use their own home-grown engine. It's just that games made with canned engines have a recognizable stamp on it, while home-made engines just won't mention it unless they're doing heavy marketing on that, or plan on selling the engine to others. You rarely hear that, for example, Divinity: Original Sin 1 & 2 were made with home-grown engines. The Witcher also uses in-house engine. Also having powerful engines like UE4 & Unity become "free" (they're not really free, but still easily accessible) rather than costing tens of thousands of dollars made them more popular around users that would otherwise have been unable to make a game at all.
  11. Adding to that, you have the costs of clothing, make up, lighting, photo shooting sessions. If something needs to be changed or added then you need to shoot lots of pictures again. If during that time the actor changed shape (e.g. got fatter / more fit) then you need to reshoot everything. Lost a prop? reshoot everything again. Midway was a referent when it comes to HD live-action photo shoots (Mortal Kombat, and also their lesser known Batman Forever, that style for that kind of game... let's say it didn't work out well). There's a reason they don't do that anymore. It does not scale. Mortal Kombat 3 Ultimate & MK Trilogy were already pushing it a lot with their endless palette swaps of scorpion and sub zero (+ the cyborg palette swaps). Also actors sueing the company didn't help (it doesn't matter whether they won or not, or whether they were right; either way it was a lot of legal trouble). The most common lawsuit reasons were that the actors claimed they signed for their look-alike to appear in Mortal Kombat 1, but not in the subsequent games. The TL;DR of this thread is: you can do it, but it's a terrible idea.
  12. Yes. Everyone has cleared up that his is a HW limitation. But I don't think nobody has hinted the obvious: You can create more than one view. The most common scenario is for manually managing memory: creating a large pool, and then having different meshes / const buffers / structured buffers living as views to subregions of it. You just can't access all of it all at once. Though for example if you have a 6GB buffer, you could create 3 views of 2GBs each and bind them all 3 to the same shader.
  13. You need to use R16G16B16A16_SNORM. SINT is when you use the raw signed integer values, and you must declare your variable as int4. The values will be in range [-32768;32767] since they're integers. SNORM is when the integers are mapped from range [-32768;32767] to the range [-1.0;1.0] and your variable must be declared as float4.
  14. ACES and Uncharted Inverse Tone Mapping

    Eye adaptation happens after step 3. Steps 1-3 is not about tonemap correctness, it's about correct AA. After step 3, you have antialiased colour data you can tonemap and eye adapt as you like.
  15. ACES and Uncharted Inverse Tone Mapping

    You cheat: Apply a trivial reversible tonemap operator before AA Resolve AA Apply the reverse of the tonemap operator in step 1 Now apply the tonemap you wanted (Uncharted, ACES, whatever).
  • Advertisement