BlackAura

You're doing it wrong. Not that I can blame you - unless you take the time to work it out, or find someone else to tell you, it's easy to have trouble finding resources.

The key is knowing where they are, and the best way to get them. Diamonds are only near the bottom of the map, and the best way to find them is to dig long tunnels just above the lava layer. You take a few iron tools and some basic equipment with you, dig a long tunnel until you've broken half of your iron pickaxes, then dig a parallel tunnel back to where you started. You'll pick up enough iron to replace all the tools you broke and then some, a lot of coal, and a reasonable amount of rarer materials.

It's still time consuming, but tends to be much more effective than wandering around caves or digging randomly.

Or you could cheat, and use some mod that helps you find ore. There were mods that add xray vision, or auto maps that can show the position of hidden ores.

Or just use creative mode, if you just want to build stuff.

This isn't unique to PHP, by any means. Visual Basic was much the same, even in later versions where you actually could write well designed code if you knew what you were doing. The IDE, documentation and design of the language encouraged you to make bad design decisions, much like PHP.

.Net languages aren't immune to this either, particularly Windows.Forms and ASP.net. To write decent code in those, you basically have to fight the IDE and the framework every step of the way. ASP.net MVC makes it much easier to write good code, at the cost of being harder to user if you don't already know what to do. Your average newbie can't just point and click until he's half way there.

PHP has decent frameworks, like Symfony. They make it much easier to do the right thing, and harder to do the wrong thing, at the cost of being more difficult to learn.

Props to the Symfony team though. They're still trying to make something good out of PHP long after most other decent developers abandoned the platform on favour of something less newbie-driven. It helps a lot to have that kind of framework available, just in case I have to use PHP for something.

Edit: Accidentally said that ASP.Net MVC encouraged bad code, but meant it encouraged good code.

Mac OS 10.8 takes up something like 13GB in total, including swap space. The recovery partition on a new Mac is tiny, containing just enough to download the install image over WiFi.

Granted, not entirely comparable - 10.8 doesn't contain nearly as much legacy cruft as Windows does, but that's still a far cry from the 40GB taken up by Windows on the Surface Pro. A 64GB Macbook Air would have something like 45GB useable.

Windows also tends to grow over time in ways that Mac OS doesn't, because Windows was built around the idea that you have ample hard drive space available. So you have restore points, backups of replaced system files from updates, caching of installed update packages and MSI packages, multiple versions of nearly every system library just in case some application really really needs one specific version... They all provide useful functionality, but were designed around having huge hard drives, where Windows taking up 50GB wouldn't be a big deal. Same thing with the separate swap and hibernate files - potentially more reliable but still chews through disk space that you might not be able to spare on a small SSD.

Frankly, complaining that developing for Direct3D requires just the DirectX SDK, and that developing for OpenGL requires some combination of other libraries is a stupid complaint. It's the kind of complaint that only complete newbies might have - anyone with any idea about what they're doing will not have a problem with it.

Not that it's hard, anyway. You don't need any actual libraries to use OpenGL. You just need up-to-date headers, and a way to link to the system's OpenGL library. The easiest way to get those is to use an extension loading library, which provides those headers, links to OpenGL at run-time (same thing that Direct3D does) and makes all of the available extensions available automatically.

Complaining about libraries like GLUT, GLFW, or SDL is completely irrelevant. If you were using Direct3D, you'd be writing windowing code directly on top of the Win32 API, which you can still do with OpenGL. If you want to use one of these libraries to handle the platform-specific windowing and OpenGL setup, you can. You don't have to - even in portable games, you can still just write your own platform-specific windowing and OpenGL setup code.

So the development setup and libraries are different. So what? It's fairly simple to work out for anyone but a complete beginner. On platforms like iOS or Mac OS X, OpenGL is actually trivial - everything you need is included in the platform's SDK. Same with Android. Same, to an extent, with Linux. OpenGL is only really awkward on Windows, and you can guess who's to blame for that.

But there are plenty of legitimate complaints about OpenGL.

The API is much more complex than Direct3D. There are dozens of ways to do things, with no way to tell which is the best way (short of looking at what Direct3D is doing, and copying that). Behaviour and performance is inconsistent between driver vendors, versions of driver from the same vendor, and across platforms. Some OpenGL drivers (Intel's on Windows, until very recently) are effectively unusable, or don't expose all of the hardware's functionality that Direct3D does. There are lots of legacy issues to carefully creep around, and they can still bite you even if you're not using the legacy features. The shader compilers aren't consistent between different vendors, and are often incredibly slow. Linking shaders is kind of clumsy. Since the API and drivers are much more complex, it's more common to run into severe performance issues caused by the driver than it is with Direct3D (and consoles are better than Direct3D in this regard, because their graphics drivers are so thin that they essentially don't exist).

Even picking a decent subset of OpenGL to use is a pain. Do you use OpenGL 2.x and ignore large chunks of it to get a reasonable API, and broad support? Do you go for OpenGL 3.x or 4.x instead? Which version? Which set of extensions? It's dead easy for OpenGL ES, though - 1.x (fixed function) or 2.x (shaders), neither of which carry around the legacy crap that OpenGL still carries.

Dealing with all of that is the problem with using OpenGL, not working out how to link to it.

Oh, and documentation. That really is shocking, mostly because the majority of documentation or guidelines you might find are written for OpenGL 1.x, and are completely obsolete.

There are some good beginner-level guides to getting started with modern OpenGL:

http://www.arcsynthesis.org/gltut/ (OpenGL 3.3) http://duriansoftware.com/joe/An-intro-to-modern-OpenGL.-Tab... (OpenGL 2.0, not using the legacy stuff)

There's a bit of a difference, though.

For one, there wasn't any viable competition at the time. Your options were GCC, or a commercial compiler. If you actually needed access to the source code of the compiler for any reason, GCC was your only option.

So, when it became clear that the FSF and the community wanted to take GCC in different directions, the obvious choice was to fork GCC. The fork developed far more rapidly than the original, draining developer time (and users, for that matter) from GCC mainline. Basically, at the point where the FSF anointed egcs as the new GCC, the original GCC project was already dead.

Things are a bit different nowadays.

There are already disagreements between what people wanted to do with GCC, and the FSF. Especially around the tool support the article talked about - the FSF are against reorganizing GCC so that parts can be used as a library for political reasons. They were against plugins for the same reason originally. They have been resisting any attempts to clean up or modernize the codebase (they've been doing it, but very slowly, because it takes the steering committee a long time to... erm... steer).

There's an alternative - Clang / LLVM, which is built around that kind of tool support, has less niche stuff to get in the way, cleaner, simpler codebase, no legacy stuff. A good few GCC developers have jumped behind that instead, rather than trying to work against the FSF, and Clang isn't having the kind of problems attracting new developers that GCC is.

At this point, it does look like GCC is in trouble. The problem is that there might not be anything that anyone can do about it. As with all large projects with a long history, GCC has a hell of a lot of inertia, and it would take massive effort to shift the direction of the whole project, and make the changes that need to be made, especially considering that they can't just stop and spend a couple of years refactoring (which would definitely kill GCC).

We won't know until we get there.

Generally, the performance of a video codec is held back by available hardware performance more than anything else.

The specifications of a video codec generally specify the decoder, but not the encoder. The decoder specification is intended to be implementable on hardware or software, so it can be played back in real-time, either now or in the immediate future. If some compression technique is available, but can't be done real-time, it can't be used. If a compression technique could be done real-time but only if limits are placed on it, then limits will be placed on it.

The encoder has to generate a bitstream that the decoder will decode, so it's limited by the decoder's capabilities. To an extent, it's limited by available algorithms (see how much better a modern h.264 encoder is compared to the original ones), and by encoding performance (particularly if you need to encode in real time, but even offline encoders can only be so slow before they become useless), and the quality / compression performance tends to get better with time. It's still limited mostly by the decoder, though.

This example is for audio codecs, but LAME actually generated higher-quality MP3s than all of the first generation of AAC encoders, entirely because it had smarter encoding algorithms. For that matter, XVID tended to produce videos that rivaled, and occasionally surpassed, the first generations of h.264 encoders. Despite that early lead, both LAME and XVID were overtaken once the AAC and h.264 encoders matured, because they were still limited by the decoders they were targetting.

There's probably still a long way to go just adding complexity to the decoder, even if we don't invent any new techniques. Eventually, it'll get to the point where you could increase the limits on the decoder, but you'll end up using far more power, and getting no noticeable improvement.

So, the limit would be the point when nobody can come up with any new techniques, encoders can perfectly measure perceptual quality (and therefore make perfect decisions about what techniques to use to get the best combination of bitrate vs quality), and improving existing techniques has a high cost and very low return.

I don't think we're anywhere near there, yet.

Lossless codecs, on the other hand, definitely do have a hard theoretical limit, because they can't discard data like lossy codecs can.

Good point. Their tool is obviously useful, even though something like this might not be the best use case for it.

The HUD thing - it looks like they screwed up the post-processing effects somehow. As far as I remember, the original game did apply post-processing effects to the HUD. Probably something to do with OpenGL not getting a decent way to do render-to-texture until 2005, so they'd have had to use the previous frame's render buffer. It wasn't that noticeable in the original though.

Worse, they didn't actually get a 15% speedup. They reduced the frame time from 16.7ms (around 60FPS) to 15.3ms (around 65 FPS), which is only a speedup of something like 7%.

They didn't seem to mention how much they're actually utilizing the remaining cores either. From the look of it, they've basically parallelized a couple of loops in the renderer. That strikes me as being the wrong way to go about this, especially considering that modern AAA games apparently break everything down into tasks, and run the separate tasks in parallel (idTech5 apparently does this, for example).

It actually does use it's own heap allocator, with some additional allocators built on top of it. I don't know if it also uses the system / libc allocator for anything, but I'd be surprised if it did.

Aside from glQuake (which used a custom allocator for most of the game, but used malloc quite often in the GL renderer), all of id's other engines used custom allocators for everything.

Edit: just skimmed the white paper. They were talking about the custom allocator which was, of course, not thread safe, because it was designed for a single threaded game engine. Replacing that with an allocator designed for parallel usage (tcmalloc for example) would have helped, but so would having separate allocation pools for different threads (which you might do for a game engine designed for multithreading). Instead, they made the allocator thread safe, using their tool to analyze it, and then sprinkling it with mutexes. That would probably be why it was a bottleneck.

Not really. The lighting in Half Life 2 was based on static lightmaps. They were very fancy lightmaps, which enabled them to use techniques such as normal mapping or specular reflections, which are normally incompatible with lightmaps, but they were static lightmaps nonetheless.

It has some dynamic lighting effects, the same way Quake did them (modifying the lightmaps). It could also do projected shadows and self-shadowed objects using shadow maps, but not on world geometry.

I believe that the current source engine has some kind of dynamic lights. Either that, or Portal 2 did a fantastic job of faking them.

Still, that was 2011. Doom 3 came out in 2004, and exclusively used dynamic lighting, without a static lightmap in sight.

I just went and did some more digging around. Looks like you're right - the method in question was present in OpenJDK's java.util.Arrays first, and seems to have been copied into the TimSort implementation.

Just a bit of background:

Those lines of code are from OpenJDK's TimSort implementation. It was written by Joshua Bloch, who was actually working for Google at the time, and contributed to OpenJDK. He later re-used the same code for Android's implementation of this same function.

In order for this to be a copyright violation, Bloch would have had to assign exclusive ownership over the code to Oracle.

Quoting from the relevant section of the Oracle Contributor Agreement:

"You hereby assign to us joint ownership", and "grant to us a perpetual, irrevocable, non-exclusive, worldwide, no-charge, royalty-free, unrestricted license to exercise all rights under those copyrights". However, "each of us can do all things in relation to your contribution as if each of us were the sole owners".

So, Bloch still owns this the copyright in this code, and is free to do whatever he wants with it. All he did was grant Oracle the same rights to that code that he has, so that Oracle can do whatever they want with it as well.

So, not copyright infringement. Oracle's own contributor agreement makes that very clear.

Edit: Added references

List of signatories of the Oracle Contributor Agreement (Google cache, because the main site is down at the moment):

http://webcache.googleusercontent.com/search?q=cache:6zsMkHa...

http://sca.java.net/CA_signatories.htm

Oracle Contributor Agreement:

http://www.oracle.com/technetwork/oca-405177.pdf

Your experience with logs doesn't invalidate the point the author was trying to make. Storing your logs in your production database is a stupid idea.

You're already doing what he was suggesting anyway - storing your logs somewhere other than your application database.

They're dropping the NPAPI (Netscape Plugin API) version on Linux.

Chrome currently ships with both an NPAPI version of Flash, and a PPAPI (Pepper - basically a replacement plugin API developed by Google, as an offshoot of NaCl) version. The PPAPI version will still be updated, so when the next version of Flash comes out, Chrome will just use the PPAPI version.

But the PPAPI version will only be shipped with Chrome, and only Chrome / Chromium support PPAPI plugins. Any Linux users using any browser other than Chrome will basically be out of luck.

The SNES sound hardware was a little bit more complicated than that.

It has a control CPU, and it's own RAM, with no access to the contents of the cartridge, or to main RAM. Obviously, you have to emulate all of that accurately, or the code that controls the sound output might not work correctly.

The actual hardware is more complicated than just a sample mixer. It's implemented as a custom DSP, which does sample decompression, high quality resampling, mixing, has an envelope generator, several effects (programmable FIR filter, echo, panning), and a noise generator.

Older SNES emulators didn't really emulate any of this. They treated it as if it were a simple sample playback device. This worked OK for most games, because they didn't use those features. However, when a game actually used those features, everything sounded wrong.

Later, they started supporting the effects, but nobody understood how the DSP was actually implementing those effects, so they didn't sound quite right. They just implemented stuff that sounded about right on the games they were testing on. Reverse-engineering all the hardware, so this stuff could be emulated accurately, took a very long time.

Right now, the SNES audio hardware is completely understood. We have several emulators that are perfectly accurate, both in terms of timing, and output. For example:

http://www.slack.net/~ant/libs/audio.html#snes_spc

Both ZSNES and bsnes use that library, and I believe that Snes9x is nearly as accurate now.

That said, I don't think anyone's actually dumped the DSP's program code.

I doubt there would be one.

On modern graphics hardware, backface culling is done by the hardware itself. It would help if this demo were anywhere close to the limits of the hardware, which it isn't.

Instead, it's likely to be limited by the JavaScript code that runs it. Backface culling wouldn't help here.

riyela is probably referring to the way Minecraft itself draws the world. If you have a solid block floating in free space, Minecraft draws all six faces of that block. However, if you have two solid blocks touching, Minecraft doesn't bother drawing the faces between them. It only draws the faces that are exposed to air (and are, therefore, visible), so it doesn't need to draw nearly as many faces.

That should get a decent performance improvement.