Mojang Hardware Stats

General Discussions
#1

Just noticed that Mojang now release their Minecraft user hardware stats here (in all its unprocessed glory so a bit hard to read). Other companies like Valve do this too but this release is much more relevant to the folk here since it includes stuff like Java version, OpenGL version and OS version for all 3 big platforms, etc for millions of game players.

Some rough conclusions we can get from the data include stuff like:

  • About 91% of Minecraft users have computers that support OpenGL 2.0+, meaning we can write games fully with the programmable pipeline (GLSL shaders) and start to safely forget about supporting or having a fallback for the old fixed function pipeline.

  • Intel cards are crap (yes everybody already knew that) and account for the majority of the 9% that don’t support OpenGL 2.0+.

  • Java 5 use has pretty much died with very few users still on that version of Java.

  • OS X 10.4 use is pretty much dead however OS X 10.5 still has significant market share.

I’m sure there are more conclusions that we can make from the data but its a bit of a pain to do it without properly processing the raw data. Do keep in mind that this data is pretty specific to the Minecraft user base and probably not representative of all computer users but still very relevant for Java game developers.

#2

thanks for the link, very interesting.

#3

I pretty much concur with their findings.

Cas :slight_smile:

#4

This makes me happy.

#5

Gotta love Iphones. Made me wait for 5 minutes to load what I thought was a slowly downloaded text file or something only to end up with a 200+MB compressed file I can´t open. Someone apparently decided that showing what you´re about to download was a too advanced feature or something. -____-

Anyway, what´s the stats for OGL 3 and 4?

#6
  • 51% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.0+.
  • 38.8% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.2+.
  • 34.2% of the Minecraft user base have computers with graphics cards capable of OpenGL 3.3+.
  • 19.6% of the Minecraft user base have computers with graphics cards capable of OpenGL 4.0+.
  • 8% of the Minecraft user base have computers with graphics cards capable of running the latest OpenGL version 4.2.
#7

OGL 3.0 hardware = OGL 3.3 hardware. Just need a driver update. >_>

#8

14.8% of Minecraft users are on OpenGL 3.0 to 3.2, considering the registered user base of Minecraft is listed at about 28 million users that is just over 4 million computers that need a driver update :slight_smile:

Even if you get all those computers updated, excluding half your potential user base by supporting such a high version of OpenGL is a bit too much.

#9

The logistics of driver updates is highly bothering. As far as most consumers is concerned, hardware and software are “one thing”. Always aim for the lowest common denominator…

Cas :slight_smile:

#10

It does looks like GL2.0 is a reasonable baseline these days, which is nice. Time to actually finish my shader based 2d renderer.

Are there any existing libraries like Slick that are shader based? All the ones that I can think of off hand are fixed-function.

#11

I’ve finally moved to shaders as well. Only two years after moving to VBOs :slight_smile:

Cas :slight_smile:

#12

First read thread’s title I thought we’re talking about notch’s (and team’s) PC ;D

#13

Libgdx have fixed and shader path for all the rendering stuff. SpriteBatch default shader work almoust anything altought being extremely simple(fast) one.

What are the other features that you seek from shader for 2d? I can’t figure many general things.

#14

Personally I look for a rich set of graphics primitives (ie. not just Sprites + SpriteBatch) which interact well, alongside a flexible geometry pipeline that ideally lets you mix and match geometry types with different geometry formats and shaders with different geometry format requirements.

It’s a hard problem, and one that most 2d libs don’t really attempt to solve. I’ve made good headway but got distracted by writing an actual game so it’s still pretty incomplete. :slight_smile:

#15

Geometry shaders. -_-’

#16

What is are some practical uses of geometry shaders?

I’ve read that it’s not practical for many tasks which you might expect (like point-based particle systems) as it’s not very efficient. I haven’t actually seen a single practical use of a geometry shader – though I’d be interested to see their benefits.

Tessellation shaders, on the other hand… That’s some cool stuff.

#17

Proof? You know, Java is slow too…

#18

One extremely practical use for geometry shaders that would genuinely speed my code up by a considerable amount is drawing sprites. Currently I have to transform every vertex of a sprite’s quad manually in Java before writing all the data out to a VBO. It’s not that Java is massively slow at doing this per se, but the simple fact is that the GPU is probably rather faster at it, operates asynchronously, and I’d only have to write out a fraction of the data using a geometry shader.

The specific way it works is I’d just send the raw sprite info to the geometry shader - position, width, height, rotation angle, scales, vertex colours, etc; and the shader would then expand each one into four vertices. Thus reducing my bandwidth by an order of magnitude and freeing my CPU up to do gamey things.

Granted this is not generally a concern for most people but then I can use upwards of 8000 sprites in a single frame at 60Hz and it starts to become a bit of a bottleneck.

Cas :slight_smile:

#19

Like Cas said, in the case of 2D it allows much more efficient usage of bandwidth since we don´t have to duplicate vertex data or do everything on the CPU. For 3D it´s suitable for algorithms that require visibility of all vertices in a triangle. A very simple example would be flat shading where we need to calculate a normal for each triangle. Since we can´t store multiple normals for each vertex without duplicating vertices it´s a lot more efficient to just calculate the normal in a geometry shader.

Geometry shaders also have other capabilites, like basic 3D rendering. It´s possible to bind a 3D texture (or a 2D texture array) to an FBO and then route triangles to different z-layers of the texture. This also possible with cube mapping, meaning that we can draw to a cubemap in a single pass or render to all cascades of cascaded shadow maps. A new OGL4 feature also allows you to specify the number of invocations of the geometry shader, improving parallelism in the GPU.

#20

This isn’t a comprehensive benchmark but it’s interesting to see the marked difference in CPU usage:

GL_POINTS + geometry shader + vertex arrays: ~18,300 sprites at 60 FPS
GL_TRIANGLES + vertex arrays: ~17,500 sprites at 60 FPS

Can probably be further improved with interleaved arrays and VBOs.

Shader source, for those interested:
http://pastebin.com/R2kexnYJ

Though I wonder how this would hold up on other machines…