Back in the heady days of… erm, the past, when I wrote the OpenGL 3.2 post I didn’t think I’d ever be adding support for OpenGL 2.1 back in, or revisiting the mess that is multiple OpenGL version support.

Skip to right now though and I’ve got a PR in adding in support for OpenGL 3.x + 2.1 which is getting reviewed piecemeal and I’m playing whack-a-mole with the various issues that arise from it.

OpenGL 2.1 seemed like a logical place to start for this. Not because I want to see it back but because I wanted an existing code base that has previously worked to update rather than write a new one from scratch. It was also important to determine how much of pain the mixing of OpenGL version would be. The answer to that last part turns out to be very painful, at least using glLoadGen.

What I wanted was to have everything namespace’d and separated so that the GL2.1 renderer only had access to OpenGL 2.1 functions and extensions, likewise for GL3.x but this proved to be much more complex than I like.

The final goal is to have support for other renderers but right now I’m trying to wrack my brains for the dregs of energy needed to switch away from glLoadGen to… well that’s the problem.

• GLEW still has the same problem that caused me to switch away from it and the maintainer seems determined not to merge anyones repeated attempts to fix it.
• GLee appears 100% dead in the water.
• libEpoxy – I’m starting to evaluate this now but it looks like yet another slightly overly complex library and there’s no discussion of multi-version GL support.
• glBinding – looks bureaucratic.

There’s limited time in the evenings to do this in and a tonne of other projects in Pioneer to be digging through. It is so disheartening that it’s all in this fucking mess and that’s before I go into a rant about how poorly manufacturers support older graphics chipsets by backporting feature and support. nVidia outshine the rest here massively but even they can’t push technical fixes back onto some of the older chips.

Back to the coal face

Some time ago I tried slapping a texture of the Earths clouds onto a sphere around Pioneers planets. It didn’t look awful but it was a static texture meant for just the Earth itself and having a selection of high-resolution textures to pick from would look very repetitive uncomfortably quickly.

As usual in a thread like that I immediately got asked why it wasn’t better, why aren’t I doing like X,Y or Z, etc but the idea is still bubbling away in my head. The thread itself was really just to gather resources and ideas rather than to track anything.

Now I have a small gallery of test images based on some noise based shaders which update over time but look rubbish.

See, from the ground:

From orbit:

To get better looking clouds, ones that look like they’re generated by the planets surface and properties, you need to analyse that planets geography and the energy inputs/sinks.

There are a couple of interesting pages like the Stainless and Dungeon League sites who really dig into and iterate through ideas to produce some very interesting results.

Heat & Friction

2D normalised wind direction

I fairly sure that I can combine them already to get some interesting results but I hope that more than using them raw like this I can do some more processing to generate evaporation, rainfall (precipitation), rain-shadow style maps that will look even more compelling.

Right now I am basing the number of “bands” of weather on the Earth’s global atmospheric circulation which will not hold true for other worlds, so having some way of determining the number of “cells” to divide a planets circulation into will be necessary. Take Jupiter as an example, it has numerous “cells” which all have different gases being mixed into them giving it that distinctive layered look. Depending on the planets size, rotational velocity, atmospheric density, viscosity, heat absorbtion, angle of inclination to the nearest star(s), etc there could be anything from 1 to 100’s of cells dividing up the atmophere.

That would be something amazing to see, different on each and every world with corresponding weather systems and biomes.

That still won’t be the end however as all of this so far is excruciatingly slow to generate, requiring as it does a decent level of heightmap detail.

Generating those heightmaps is the most expensive single process in Pioneer, which is why the development of the multi-threaded processing made such a big difference.

Some simplifications, optimisation and cleverness will be required before this can ever make it into the game proper.

PS: IN parting I should also add that working on this came about because I needed to generate from of this data for the new JSON driven terrain generation system and because of the XFrontier forum thread which just looked too damned good to pass up.

I just merged in my changes to update Pioneer to use OpenGL 3.2 on Windows/Linux/OSX and since I haven’t posted about anything in a while now seemed like a good time to describe those changes, and why I’ve made them.

Pioneer has been using OpenGL 2 for many years now, it even supported the fixed–function–pipeline until not long ago and it’s rendering system has stopped Pioneer from being ported to run on mobile class devices which typically use OpenGL ES. It used methods that have become deprecated including the matrix stacks, built-in lighting and texture coordinate structures and had several performance sapping calls to glGet* functions.

Over time I have removed all of the glGet* function calls, which improved performance and consistency but put off the really big rewrite to refactor everything to use our own matrix stacks, lighting and texturing for a long time. Eventually the lure of modern Vertex Array Objects tempted me and I bit, sadly this broke the OSX version of the game and I didn’t even notice for a few weeks.

This was the straw that broke the camels back. I knew that OpenGL 3.2 would work on OSX/Linux and Windows for most people from experiments/rewrites I had done, but struggling along with all of the old crud and extensions was taking up a lot of time and making it almost impossible to progress.

Perhaps a better coder could have found the magic combination of incantations required to make everything work across of them and retain the OpenGL 2.x setup we had but I am only human so that Sisyphean task could go and kiss my ass.

There will be no talk of the “future” in this post since I’ve learnt my lesson that discussing it just means it gets sidetracked and won’t happen within anything like the timeframe I thought it would. Of course these changes means that there will be bugs, there will be performance issues and opportunities, there will be features that people will magically want adding in zero time ;) and so on and so forth. We’ll just have to deal with them as they occur.

NB: I have removed the links to the older 2.x compatible executables as they were removed from the download page at some point.

Andy

After taking a look at the awesome No Man’s Sky videos and artwork I decided that enough was enough: Pioneers terrain engine must die!

Now I’ve been “meaning” to do something about it for several years, and I have done bits of work too it over the years: reduced it’s memory footprint drastically, refactored it internally, multi-threaded it with a job system, numerous optimisations etc. There’s some things though that I’ve just left well alone.

That time is over: yesterday I merged some work-in-progress code that takes the underlying GeoSphere code and splits it into 3 classes: BaseSphere, GeoSphere and GasGiant.

In future there will be more splits because Stars are still rendered with the GeoSphere system meant for CONSTRUCTING PLANETS! That won’t do at all.

It also means separate shaders, materials and all manner of other technical bits which means that the way gas giants are generated and rendered can now start to diverge drastically and rapidly without worrying about breaking the way that stars or rocky planets are created. Even just doing this much has taken a surprising amount of time mostly because I do this as a hobby and don’t have a lot of opportunity to dedicate too it. Also my real job tends to leave me without an awful lot of spare mental capacity at the end of a day.

Progress s progress though and there’s  couple of other things coming up.

1. I’ve been working on implementing terrain texturing, which you can read about on the forum, and am currently writing the system to manage to tiles and build the texture atlas.
2. GPU generation of gas giant textures, hopefully allowing for less CPU work and bigger textures, possibly updating them in realtime someday in the future.
3. Placing instanced detail objects – think trees, rocks, grass etc – this ones very very early work though don’t expect it … for a long time!

I haven’t forgotten the Oculus Rift stuff either, it’s just a little bit down the priority list.

Oh and I am now on Twitter, although I haven’t figured out why yet.

Yes progress, real progress!

That there is a video of the Intro menu being rendered onto a quad, and the 2nd video is of the ingame GUI/HUD being rendered onto a Quad.

The things that I DON’T show are the messed up sector/system view screens, or the projected city/planet/object names which go all over the place and the Quad isn’t centred because I’ve just been hacking in it’s position without a care in the world :)

I should have been in bed about an hour ago, g’night!

Pretty, better in motion but I haven’t gotten a way to record yet :)

Seems I haven’t updated since September.
Well I got a new job, I’m now working on Unreal Engine 4 via my employer Pitbull Studios.

Still doing Pioneer stuff, I’ll post a review of work done and work to do some time soon-ish.

Wow time really flies when you’re … um, reading books and going to the gym more often?

Ok so I have been doing some programming on Pioneer; fixed up the solutions & projects for VS 2012 & 2013 Preview (I could do VS2010 too but am not touching 2008!) to deal with latest changes, fixed the GLEW changes to get it all building and compiling and then took up the Oculus Rift integration again – that’s a bit hairy that stuff since I’m having to modify a LOT of stuff in Pioneers rendering process.

Anyway the result so far is the following;

• distortion shader working,
• head tracking working,
• rendering two cameras to a framebuffer working.

So all done huh? Nope, not by a long shot.

There’s a lot of other stuff that needs to be done to get a 3D projection + FOV + view offsets for each eye and a few other bits before we actually get a working 3D view and I haven’t worked through all of that yet since I’ve been busy with time consuming other stuff.

Unexpectedly, probably only to me, some of it is just stuff that didn’t used to take much time at all but is now quite time consuming.

Take going to the gym, this is what it used to work out like:

• Leave work & walk to gym (11 mins)
• Get changed (3-ish mins)
• Exercise (30 mins)
• Shower and get dressed (10-ish mins)
• Hurry back to work stopping at Tescos (15 mins)

I think that in truth that used to usually take about 1 hour and 15 minutes, sometimes longer if we’d been doing leg work and I couldn’t walk as fast on the way back. Now however I’m coming in from Beeston which entails an extra train journey, and because I don’t choose when the trains run I have to catch them based on which one gets me there _before_ my session with my personal trainer. This means that I’m getting in quite a bit earlier, but that I’m travelling for much longer and due to the scheduling granularity of the trains… well, I left the house at 11:30am and got home today at 15:00pm just to do a 30 minute session. I could have gotten home earlier today, but decided that since I’d be missing one train anyway I got a haircut (I’m male, so if it takes more than 10 minutes to cut my hair then something is wrong). So I could have shaved 30 minutes off that (Train schedule) but even so it’s around the 3 hour mark to go to the gym just once.

Everything has scaled similarly though, popping out to get milk was to the nearby Tesco Express and less than 10 minutes but now involves walking across Beeston to the big 24 hour Tescos (or further for Sainsburys) because that’s the nearest one that does the Lactofree stuff. I’ve also been getting to the doctors (knee injury and anxiety attack stuff), dentists (keep flossing!!!) and the talking therapy place for an assessment (I’m not mad, might want to work on my confidence in a couple of months – quitting was the right thing to do apparently!).

At first I was worried about how this was going ot impact on two of my stated goals from the previous post:

1. Work through some UDK tutorials – the new job is on Unreal Engine 4 so I think getting a footing in the tech’ will be good for me,
2. Work through Frank D Luna’s D3D 11 tutorials but convert them to OpenGL 4.0 – Been meaning to do this for a while, it’s a good ramp up and parallels these SlimDX posts,

…but screw that, I’ve really really really (emphasis!!!) needed this downtime to get myself sorted and simply running into yet more challenging stuff and then freaking out about that wasn’t going to help anyone least of all me.

My plans haven’t changed, I still want to dive into the UDK stuff – I have it all installed and a selection of tutorials ready, I’ve just pushed the start of it back until this weekend or Monday. That takes the pressure off me for doing the Pioneer Oculus Rift integration which is acting like a pressure valve and gentle reentry into doing some coding again for fun.

Now though I’m going to go and tidy up downstairs before Danni gets home. She’s started at a secondment to a new primary school which is in Special Measures. It’s taking a lot of her time and mental capacity, everyone there is under tremendous pressure, so I’m trying to suck less at the housework. Of course I come from a position of sucking _utterly_ to begin with but I am getting less awful :)

Andy

To shard, or not to shard? Is the wrong question.

I came across a bit hard on sharding in my last and have rightly been called on it a couple of times so I’m just going to quickly clarify.

When You Should Have a Shard:

You will be have various “shard“s your game at least two in fact.

Read the rest of this entry »

Space game MMOs… A brain dump:

I’ve been inspired to brain dump by a post on the Paragon forum.

To quote:

“Will multiplayer be instanced or MMO style?
If MMO will players be able to transverse to other servers/galaxy’s with their ships,equipment and credits?“

Now, leaving aside the question of what they might mean behind instancing, lets instead think about how a space game like Paragon, not Pioneer note, Paragon might choose to implement an MMO gameplay model.

NB: Paragon is a sort of daughter project to Pioneer. It’s forked from the Pioneer codebase and occasionally pulls in work we do. However Paragon has it’s own developers, development and game specific code, scripting, storyline and art. I’ll be discussing these things from being a Pioneer developers point of view.

Read the rest of this entry »