Eclipse->Preferences. Java->Compiler->Errors/Warnings

Expand 'Potential programming problems'.

Second option down is 'Assignment has no effect (eg. if (x = y)).

For me, that was set to 'ignore' by default, but you can change it to generate an error or a warning. The first thing I do when I setup a new Eclipse install is go through these check and crank most of them into errors. By default Eclipse's settings are quite permissive, but IMHO there's some super helpful ones in there (even if they're not *technically* errors at times).

Yeah, you can totally tell that Mirror's Edge was made in UE3. 

Most UE games look like UE games because they use the default shaders and crank the specular levels up to 11 because that's what's currently in vogue. There's no reason for every UE game to look like Gears Of War, as Mirror's Edge proves.

I think he's expecting pass-by-reference behaviour with the drawTree1 bool. But I'm too tired to properly explain it with all the proper cavets and terminology, so I'll just say go google how Java handles primitives vs. objects as method parameters.

I would probably have gone with 16x16x16 or 32x32x32 chunks and had some kind of sparse array in the height dimension, that would address the common complaint of the fixed build height.

Having said that it would make general streaming and caching more complicated. And the reason MC has chunks of 16x16x128 is a sound one - you can't load faster than the player can fall, so it has to have the whole vertical slice loaded in case. So it's only in hindsight that I think the chunk size is a bit awkward, and it's not a *huge* problem really.

As someone who's spent a lot of time on a minecraft renderer, you probably just want to stick with removing internal edges and don't bother with merging faces.

It's tempting when you've got a 'simple' world, but as you add more and more gameplay it becomes progressively harder to manage. It's just too damn handy to do some thing per-vertex (eg. minecraft does it's fake AO lighting via vertex colours), as well as making it easier to do texture atlas/layer tricks to get richer surface detail. And of course it means that you have to do more work when you change a single block in your world.

The biggest rendering drag I found was that even after frustrum culling a minecraft-style world has lots of underground caves that are still considered visible. That can mean you're drawing twice or three times as many polys as you need.

You *should* be able to do something about that with occlusion queries, but I never got around to trying it. Minecraft doesn't IIRC, but that's probably because it's awkward 16x16x128 world structure makes it a bad fit.

That does make sense, and I was expecting the runtime to be somewhat larger than that. I'll hopefully get a chance to try porting it to my runtime soon, and I'll let you know how smoothly it goes. I think if you're expecting people to use one runtime as a reference and port it then there's probably quite a lot you can do in that runtime to make it easy to port. But you won't notice until people start trying to do that, so we'll see how it goes.

What kind of external features does the runtime need? Does it spit out things like drawQuad() to libgdx or does it create geometry and hand that off? Any other dependencies/libraries/functionality I should be aware of?

Likewise. It has too much of a 'second system syndrome' smell to me, where it's allegedly going to fix all the problems of both Swing and AWT, as well as having a scripting language and a gui tool, whilst simultaneously trying to be a flash-beater, Unity-beater and OpenGL-beater. Oh and it's internal to Oracle so it could implode and vanish without any warning.

Maybe it'll be good, but the odds aren't looking healthy.

Have you tried using quaternions?

If you want sequenced music (which is the common reason for wanting midi) then there are several better alternatives like .xm or .s3m, some of which have open source players already available. They support more feature than midi which will make your music guy happier. And you don't tie yourself to a VM release.

My 2p for Java2d - it's a powerful and flexible drawing API which produces high quality images with near pixel-perfect accuracy between platforms.

You'll notice that nowhere in the above sentence does the word 'fast' appear. For the J2D team, 'fast' is not on their list of priorities, only that the performance is 'adequate'.

Warning, personal opinion:

Universities don't necessarily want to see portfolio work in the area that you're applying for. They want to see that you're someone they can teach the course to and you'll achieve a good result for them. That means they don't necessarily care if you took CS at A-level, but instead are more interested in if you've got a good foundation (which for CS means good Maths results, and additional sciences help too).

Alongside that they're interested in seeing people who can teach themselves, and who have enough determination to not quit the course after a year. This is where your personal projects come in - emphasise quality over quantity - don't have tens of little games that aren't polished, try and focus on one or two bigger ones that you've worked on for quite a while.

If all else fails, be nice. People reading/interviewing for uni places are human too. 

I tried the editor and it seems pretty good, so I'm thinking about writing a runtime for the animations produced - any ideas on how this would be best done? How final is the actual file format at the moment? Is there any documentation on how the runtime should behave?

Porting over the libgdx runtime sounds like a good start, but I'm worried I'll have to constantly update it if there's new features etc. going in. Particularly if there's no actual documentation, just a 'de facto' standard of whatever-the-libgdx-runtime-does. (It'd be Ruby all over again!  )

I suspect that a game library as GPL won't get many people using it - most people don't want to open source their game just to use a library.

...in which case, you need a comment that says which way 'up' your 2d coord system is. Because top/bottom will change depending on if you're going with origin-at-top-left-of-screen vs. origin-at-bottom-left-of-screen. 

For 2d, I usually go for (x,y) is the corner closest to the origin. That's more 'normal' compared to most 2d APIs in my experience.

For 3d, (x,y,z) as the center of the box makes most sense IMHO. The symmetry tends to make code for 3d tests like ray intersection cleaner and more consistent. I assume that's what Roquen is getting at, it's kinda hard to explain without doing a fully worked example with both approaches.

Either way make sure you put a comment in your variable declarations saying what's what. Ascii diagrams in your class declaration are a big win when someone comes along later trying to decipher what you've done.

While I generally agree, when I was doing Tectonicus and suddenly ended up with loads of users, I found a major version number really handy. People generally understand that '0.xxx' means 'not quite finished and probably buggy'. And when I did a major breaking change that meant everyone had to change their config files and scripts etc. it was really handy being able to switch from 1.xxx to 2.xxx.

Other than the major version, the minor was just an incremented number as you say.

I have a manually updated number in an ant build script that I just increment, but I also export the svn revision number and burn that into the jar as well. The manual number covers 'big' changes and proper releases, the svn number is there so that I can easily see if someone's using a bug-fixed version or not. And also because sometimes I forget to update the manual number.

RPS had a post about it recently:

http://www.rockpapershotgun.com/2012/12/05/wurm-welcome-wurm-online-emerging-from-six-year-beta/

Why would you need an 'app' for a web page? Android phones already have perfectly servicable browsers. Serving up slightly modified html / css for mobile user agents should be good enough (although I'm sure Riven has better things to do).

App-ification of everything on the web is going to slowly kill the *proper* web at this rate.

If you're getting an artist to create and assign atlas coords manually you're wasting their time. Why would you want them doing that when they could be making your game look more awesome with better art?

Why not generate the atlases automatically? You can do it either at compile-time with a tool or at runtime. Search for bin-packing algorithms if you want to see how it could be done.

I don't believe Eclipse has a plugin for that yet. Maybe try Netbeans?

The Ariane 5 incident is a *lot* more complicated than "a lazy programmer". The integer overflow is just one piece of a big chain of events that caused the overall failure.

Most interestingly, the code was correct when originally written. The situation couldn't occur on the hardware it was written for, and only later was the same code reused on a different hardware where the error was now possible. You could equally pin the blame on hardware engineers for not having sufficient documentation to describe the differences or on testing for not fully exercising the functionality of the system as a whole. But pinning blame in a complicated failure like that is neither helpful nor interesting.

It's been a while since I read the full investigation report into Ariane 5. Have you read it? I would recommend it for anyone who wants an insight into how tiny errors (both technical and people) can propagate and grow.

I think we're talking at cross purposes, because it seems you have a very different definition of 'one shot' to me. 

Not in my world. Pretty much any big game released these days has *tons* of legacy code knocking about in it, often going back to the previous hardware generation. Games haven't been one-shot deals for at least a decade, probably longer.

Because at the time I was compositing the shadows into the framebuffer alpha, and doing it all with FF pipeline. A no-alpha greyscale version makes sense if you're doing it with modern render-to-texture and shaders.

Bresenhams is not really appropriate since it may jump over solid cells or around corners. A specific visibility algorithm (like the ones saifix linked to) give much better results.

I ended up adapting the Wolf3d cell scanning algorithm.

Back when I looked into it, IKVM required the full CLR runtime, whereas to get on XBox you were restricted to the Compact Runtime. So you can use IKVM to get something working with XNA, but it'll only work on desktop, not XBox (which is kinda the point).

It's really hard to compare Eclipse and VS, primarily because the experience using them is vastly different depending on what language you're using. 'Eclipse' usually just means Eclipse for java dev, which is pretty damn slick. Eclipse for C++ is a whole other beast.

Similarly for VS. The VS C++ debugger is great, but the VS C++ code editor is abysmal. It's clunky to navigate, it's code completion and syntax highlighting is often flat out wrong, and it has an annoying tenancy to lock up the whole app when it scans the code. Everyone ends up resorting to something like Visual Assist to make it usable. VS C# on the other hand is a completely different beast - the editor is much more functional, but the debugger is IMHO worse (and worse than Eclipse's Java debugger).

Of course like most MS tools it also really depends on what the rest of your environment looks like. VS is great if you're living and breathing the MS stack all day, but will kick and fight if you ever try and use it in a different way or with different tools. Eclipse, Netbeans, etc. are much more comfortable in letting you integrate different tools and plugins. So even comparing the two versions with relevant languages, your experience varies hugely depending on what other stuff you're doing.

TL;DR version: saying "Eclipse sucks, VS is much better" (or the reverse) is a nearly worthless statement unless you also qualify what languages, toolset, environment, source control, app and functionality you're developing with/in.

Xbox -> XNA.
Vita -> Playstation Mobile (previously known as Playstation Suite)

http://en.wikipedia.org/wiki/PlayStation_Mobile

Even if your vertex normals are similar it often helps to re-normalize in the fragment shader. The difference isn't that much when you're doing nice smooth diffuse lighting, but for something like specular highlights you'll only get the nice, tight, sharp highlights if you re-normalize.