Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 29 Jul 2001
Offline Last Active Yesterday, 09:54 PM

#5258554 Help with specs for laptop

Posted by on 22 October 2015 - 01:00 PM

I'm going to make this really super simple: Start with the Dell Inspiron 15" 7000 series. You don't have to choose this particular machine, but it's an excellent baseline for the Skylake laptops that are now coming out in terms of both price and features. One neat touch on this particular machine is that it ships with a single 8 GB SO-DIMM and an empty slot for whenever you feel like upgrading. All of the laptops are now in the process of upgrading to Intel Skylake (aka "Intel 6th gen Core") so it's probably best to wait for that to roll out everywhere. It'll take through the end of the year for all of the manufacturers to update. The aforementioned Inspiron is out of the gate early and seems to be awesome. Might even take a look at the Amazon SSD equipped version.


Looking for something with a more robust build and premium appointments? Dell XPS 15. Smaller? Inspiron 13 or XPS 13. More gaming-oriented? Probably the Lenovo Y50, although we're still waiting on a Skylake version. Want the coolest, expensivest, fanciest thing on the block? Surface Book.

#5257165 Warning for glVertexAttribPointer

Posted by on 13 October 2015 - 09:48 PM

First things first. Since you are using C++, why are you using horrible C casts? There is static_cast and reinterpret_cast. They show intent much clearer, are easier to locate when searching a document and actually avoid some of the potential pitfalls of C casts.

Then, a way to solve the warning is to use

static_cast<const char*>(0) + size
Or, if the editor decides to mangle my template again turn a null pointer into a const char* pointer and add your offset. Good old pointer arithmetic will then deal with the rest.


In this particular case, I don't see the point of making a stink about it. OpenGL's the one doing an abusive integer-pointer cast and there's no particular ambiguity about what's happening, or particular potential for unexpected behavior. So C or C++ style cast, do whatever. Hilariously enough, your idea of adding to a zero pointer? Undefined behavior. Whoops. It's just a messy thing to do in the first place.

#5256578 Do you use friend to avoid security problems ?

Posted by on 10 October 2015 - 02:51 PM

I mean, as long as you're complaining about implementation in headers, you might as well also complain about templates which force implementation in headers.

"As long as we're complaining about Alzheimer's, we might as well also complain about cancer."

At this point you're not complaining about public/private/protected, you're just complaining about the header and compilation unit system which has long outgrown its usefulness and is being replaced with proper modules in a future C++ version once they nail down the spec.

Just to be clear, my claim is that private/protected semantics have no value in C++ as it exists today. Yes, the compilation model got us here. But as long as we're living with that, I simply reject any idea that these features accomplish anything but a false feel-good sense of "ah, totally encapsulated". Encapsulation in C++ requires polymorphic interfaces or pImpl, period. (Or in some cases, stripped headers, which are a messy game to play.) Once you apply these techniques, access semantics no longer have any meaning anyway.



Heck, the C# and Java code that love so much requires you to put interface and implementation in the same file. You can't even hide your code in the same way the C header/source system does. The only time you don't see the entire implementation is when you are dealing with a library and only have the compiled metadata to go against.

I've seen this complaint many times over the years - there is no file in these languages that sums up the public interface without the implementation details, unless of course you write up a polymorphic interface and implement it separately. The ability to see the public interface is instead consigned to IDE based metadata or code analysis tools. I have mixed feelings about this. But in the course of practical and professional work, the C++ version has created far more problems for me while the C# version is inconvenient at worst. Of course this leads back to the C++ compilation model, which is a disease that goes far beyond something as trivial as private/protected.


At the end of the day, I can't think of an instance across 15 years of personal and professional C++ development work where I've avoided a single bug or mistake by marking variables as private. The borderline cases are easily dealt with by naming convention. Since client code is bound by the compilation model to the total definition of the class anyway, you just don't get the expected benefits.


The primary goal of the post is to secure the end user of the API but the part about attacks was not bad.

No idea what you're talking about.

#5256574 Do you use friend to avoid security problems ?

Posted by on 10 October 2015 - 02:01 PM

Private is very important in that it lets you provide a clean API to end users that allow you to modify the internals with minimal recompilation and preserve class invariants. Protected has a few useful applications (for holding an interface's destructor for example if you don't want someone destroying an object via the interface).

Except we're talking about C++, which immediately and catastrophically fucks this up by making the private internals part of the header anyway. So then we end up with tricks ranging from vanilla polymorphic interfaces to pImpl idiom variations, rendering the whole exercise pointless.

Like others have said, access semantics, like other things in the language, are there to protect the programmer from making mistakes and to help enforce good code design

And the moment you inflict friend, we're not talking about good code design anymore, we're talking about continuing hacks where the core design has already gone awry. It's worth noting that a number of modern languages get by just fine without access semantics. My argument is they may get along better without them and that the very use of access semantics represents total failure of encapsulation in C++. Why? Because even if I can't access the internal details of a class, I can see them just fine due to other encapsulation-puncturing issues in the language. That serves to bind clients to implementation details anyway, in the absence of pImpl type techniques. Lacking the relevant semantics forces you to deal with the interface/implementation divide directly. This is not the case in Java or C#, which implement sane module systems and let you alter implementations without impacting clients.


If you consider C++ private/protected semantics relevant to your code design, it's time for a redesign.

#5256483 Do you use friend to avoid security problems ?

Posted by on 09 October 2015 - 11:42 PM

I honestly think private/protected are worthless features in C++. They serve some purpose in module-based languages like Java or C#, but their basic use in C++ is just not particularly compelling.

#5256258 C# Garbage Collection and performance/stalls

Posted by on 08 October 2015 - 01:07 PM

The Microsoft .NET runtime offers significant control over when and how the garbage collector runs: https://msdn.microsoft.com/en-us/library/System.GC_methods(v=vs.110).aspx

#5255937 What's the best system on which to learn ASM?

Posted by on 06 October 2015 - 08:35 PM

Get yourself a Raspberry Pi2B or a BeagleBone Black.  These are ARM boards -- the ARM processor is way simpler than the x86 even though they're of the same relative vintage (ARM is RISC, x86 is Swiss Army knife).  In addition to learning ASM, you can futz with blinkenlights so you can really feel close to the metal.  Learn to love the smell of rosin-core solder, it's the smell of victory.

This is the way to go. Most of the other suggestions are useless - while Z80s, 6502s, 68ks are kinda cute to play with, they have no relevance to modern development or modern processor design. x86 is extremely useful and relevant but also complicated and psychotic. MIPS was relevant once and continues to be a popular university choice, and resources are readily available. The trouble is just that very few MIPS chips are out there and what is generally lives in highly constrained embedded systems so it's just not a very real-world skill.


ARM strikes a great balance of being a nice, modern design that is highly relevant to work today, but still fairly straightforward to learn.

#5255452 The f***ing horrible nfl madden games!

Posted by on 03 October 2015 - 08:50 PM

It would not be legal under any circumstances to use real teams, real players, real mascots, etc, if that's what you're asking.

#5255367 Vulkan is Next-Gen OpenGL

Posted by on 03 October 2015 - 10:56 AM

Don't get me wrong - I am ALL ABOUT the new APis from a technical standpoint. But I'm not living in AAA world these days and practical reality is that writing a render pipeline for a market that maxes out at 22% is just a bit rough. Now it's very helpful that Win10 is free and everyone wants to get the hell out of Win8. But the real key point is that it's very difficult, outside of a few select high budget things, to really design around the new APIs. Oxide's been talking about this, where you really start leveraging the added capabilities in a way that is more extensive than simply writing multiple render pipelines, and those changes feed all the way up to your game design.


FWIW I am shipping a Metal pipeline game in a few weeks - which is more about the structure of Apple's platform than anything - and that's not designed around the new rendering API either. I still have to maintain GL ES paths for a wide swath of old devices and that means the rendering changes are low hanging fruit with a lot of old assumptions and limitations still preserved.

#5255297 HDR gamma correction

Posted by on 02 October 2015 - 10:37 PM

HDR images are already linear, yes. The only images that need gamma correction are sRGB images (typically 8 bpc), which are your "normal" images in common image formats. Essentially you can just tell the API that the textures are sRGB and the GPU will handle the correction for you.

#5254606 Mac to buy for app development?

Posted by on 29 September 2015 - 09:39 AM

The Macbook Pro Retina is easily a solid choice if you're also going to use it as a day-to-day laptop. I ran out of memory trying to do development on the older 8 GB model MBP, but I don't know how big or heavy your stuff is. (I didn't feel like ours was big, but...)

#5254049 What is more charged?

Posted by on 25 September 2015 - 03:21 PM

I agree with the above. Buuuut if we're talking about the best paid game dev jobs, it's going to be highly capable system architects well versed primarily (but not exclusively) in C++ and various low level technologies like DirectX 12, GL/Vulkan, etc. People with deep and heavily mathematical knowledge of graphics and/or physics probably do best, as they're very difficult to replace. The web and engine-specific guys just don't merit the same levels of compensation.

#5252792 DirectX高级动画制作(Jim Adams)

Posted by on 17 September 2015 - 07:29 PM

Google translate: I purchased this book (DirectX Advanced Animation) when I lost this book 's CD , give me a copy?

#5250653 High Quality Light Trails

Posted by on 04 September 2015 - 10:36 PM

Some background info here: http://www.fxguide.com/featured/art-directing-effects-for-infamous-second-son/

GDC slideset here: http://www.gdcvault.com/play/1020158/The-Visual-Effects-of-inFAMOUS

#5245824 PI or not to PI ?

Posted by on 11 August 2015 - 02:37 PM

The PI term comes from normalizing the light response to 1 - essentially it's the product of a surface area integration over the hemisphere. If you don't have it, your surface will reflect pi times the correct amount of lumens back out. If you want to make sure your lighting is properly energy conserving, you can do the divide by pi when submitting the diffuse color to the shader instead of in the shader itself.