So here we are again, another year is coming to an end and though 2011 wasn’t a very good year, it’s ending even worse than I could’ve imagined. A recent (14th december) personal loss of a very close relative (don’t ask for details, the internet is not the right place to discuss personal stuff) has caused a drastic change to my personal situation. It’s not that I wasn’t prepared for it, but still this was pretty much unexpected and the timing of this event is alos pretty bad with the year ending and a lot of stuff left to do.

So with that change of my whole personal situation I also don’t know when I’ll be able to continue work on “Phase 2″. Actually before the above mentioned stuff happened I was on track to releasing a beta-version to the public in january/february on which I wanted to base several releases upon for better feedback, balancing and bug fixing. But now that I’ll have to take care of a lot of important real-life related issues I sadly can’t tell when I’ll be able to continue working on “Phase 2″. But rest assured, I want to finish it, as I’ve put so much work into it over the last few years and also as the current build on my HD is looking pretty good.

Here are two recent (roughly two weeks old) screenshots of the current build :

As you can see I changed the main user interface again, but only a bit, as it was necessary due to a new game are for “politics”, and also because the old tabs didn’t stand out enough to make navigation easy enough. So with the recent change (only took a few hours) and the new icons the main UI looks a lot like the main menu and is very easy to navigate with the different icons easy to distinguish. The second shot shows some changes to the visuals of several windows, with the icons for different technology / unit types now colored different, a new functionality of the interacitve iconbox UI element used to navigate those windows.

With this in mind it’s possible that there won’t be any news for january and february, so don’t worry if it’s becoming a bit silent over here.

So that’s it for 2011, a year to forget…

I’ve just uploaded a new work-in-progress video from my current version of Projekt “W” – Phase 2. It’s been some time since my last posting on “Phase 2″, and though I didn’t have that much time to work on it I still got a lot of stuff done, and what’s better than showing screenshots of that new stuff? Correct, showing an HD video of it :

As you can see I (once again) redid the whole user interface. Some may think I’m nuts when it comes down to the UI, with having at least half a dozen complete changes to it, but this time I actually had a good reason. You may remember the last arc-shaped user interface that looked just great? The looks sadly couldn’t cover all the problems that design had, so I decided to throw it away in favour of something far more simple. The last design looked good, but wasted a lot of screenspace due to it’s arc shape and also was only able to display one single window at a time, resulting in a very bad and annoying workflow, especially after longer periods of play.
One good example was the new region list, a window with all regions in your posession. Clicking on one of them brings up that region, and in the arc design this caused the region list to disappear due to the nature of that user interface, making regular tasks like managing your reasons very tiresome. With the new design, which is kinda back to the roots it’s now (again) possible to have several windows open. So if you look at the video you’ll see what I mean. You can now have the region list to the left and the region’s window on the right and quickly switch through all your regions and manage them, a perfect workflow.
But that’s not all, as the new design also offers a lot more space for the different windows. The old arc design wasted a lot of space and made it especially hard to display windows with lots of information, like the espionage one. So with this radical different design I’ve got much more space to display important information, increasing usability even more.

And (as also shown in the video) I also redid the main menu, endgame screen and battlefield user interface, so that the game’s user interface now looks seamless. That’s something I’ve been wanting from the very beginning of the development on “Phase 2″‘, but never really achieved with the old user interface designs. But now the game truly feels like it’s made from one piece, especially with the new icons that I created in my 3D modeller.

But it won’t stop here. I did a lot of things behind the scenes to get into a state where I can release at least a beta, though I’m not sure if this will happen 2011, with 2012 being more likely. For example the performance of the user interface was never that good, and now with the possibility to (again) have multiple windows open at the same time I realized that the UI was performing really bad. So I spent weeks optimizing it, taking away a huge part of the CPU limitation that was caused by the user interface. Now many items are rendered via vertex arrays, texture IDs are cached, hit tests are optimized and much more, resulting in roughly 200% performance increase for the user interface.

Thanks to the kind help of damadmax (a user from the delphigl.com forums) I can now also offer a Mac OS X version of glCapsViewer, so all you mac users out there can now start submitting your reports. With Mac OS X now also available the most common operating systems are covered, so hopefully the OpenGL capability database will grow into a valuable source for all OpenGL developers out there.

You can grab the Mac OS X port at the glCapsViewer project page. Also note that the OpenGL capability database now has it’s own subdomain, so if you want to link to it use this URL.

I’ve just released version 0.5 of glCapsViewer, and though the tool itself doesn’t seem that much different from 0.4, the real difference is in what’s behind it. Cause I’ve dropped the simple PHP listing (and searching) of uploaded XML files in favour of a real SQL database. This is not only much faster but allows for a lot of new features, and one these first new features (and propably one of the most important) is the possibility to compare (up to eight) reports in a single page. So you can quickly check their limits as well as what report supports what extension.

Note that I have migrated the old XML-reports into the new database, so if you already uploaded them with one of the old versions there is no need to re-upload. As usual you can access the database here.

If you’re creaing OpenGL apps (no matter if games, apps or demos) that you want to distribute, you often get error reports from user with the oddest things happening on their systems. Recently I distributed a benchmark for “Phase 2″ to some people and after hours of trying to get it working for everybody I noticed that some of the testers had graphics cards that supported shaders (vertex and fragment) but no framebuffer objects, a pretty odd combination.

Back in the days (several years ag)o Tom Nyudens from delphi3d.net (don’t go there, it’s no longer online) had a tool that read out an OpenGL’s implementation details (extensions, max values, etc.) and would store them online so every developer could go there and check what graphics card had which OpenGL capabilites. But sadly that tool along with the database went off when the site went down long time ago.

So I decided to end this deficit by creating such a tool by myself, simply named glCapsViewer. It doesn’t only read out all important OpenGL implementation details but is also able to upload them to a preliminary “database”, so developers can easily check out OpenGL implementation properties online. You can check out the preliminary database over here (not much in there yet, but that’ll hopefully change soon). Feel free to upload your own reports (but please for real hardware only, no need to upload a report for e.g. virtual box GL implementations or MESA) but note that I plan on doing a real database (the current one is just a list generated by the XML reports that have been uploaded) so at some point that database may be wiped (though I hope to integrate the files into the new one instead, only if possible).

An yes, some may have noticed that I actually uploaded a first version of it (created in Delphi) some days ago but decided to wait before announcing it to the public until I added another platform, and that’s what I just did, so here is the official announcement. I ported it over to Lazarus (and FPC), installed ubuntu in a virtual box and created a linux port too. So now you can upload reports from Windows and Linux (i386), other plattforms (like Mac OS) may also become available in the future, but don’t count on it. And yes, this is a first for me after ~20 years of coding, my first own application with a linux port. So now that a lot of people asked for linux versions of the apps/demos/games I did hopefully a lot of linux reports will be uploaded.

In what happens to be a rarity nowadays you’ll now get exactly what you could guess from the caption of this posting. I’ve been working on those three things yesterday and today and thought I might share some of my experience implementing color selection the right way into a complex user interface.

Those of you that coding apps/games/whatever using OpenGL might know that the old selection functionality of OpenGL (which wasn’t that bad at all) is a no-go nowadays, mainly due to the fact that it’s done in software for some time now by all big graphics cards vendors and therefore sadly disqualifies it for a realtime usage. In case you never used it : It had a name stack and a special render mode. So before rendering an object you could push a name (actually an integer) onto the name stack, render the object and go to the next object until you’ve drawn all objects that are selectable in your 3D scene. Then you could simply read back what object was drawn at a certain point in your framebuffer and OpenGL returned the name of it.

But nowadays it’s a no-go due to it’s slowness and so I’ve been using a technique called “color selection” for some time now. It’s a manual way of doing selection on your own in OpenGL (or any other 3D-rendering API) that is fast and easy to use but also has it’s caveats, something I’ll be getting to. It basically works by rendering your objects without lights/shaders/textures and only single-colored and then reading back the color below e.g. your cursor and you then compare it to the stored values for your objects so you can easily get the selected object derived from the color read back from the framebuffer below the cursor.
(left image shows the region, right image shows the color selection image) :

It sounds very simple and if you do it in a basic demo it also is very simple. First you render the color selection parts only (not visible to the eye in your backbuffer), read back the color, get the object selected, clear the scene and then render your normale scene. This works fine for simple cases. But ProjektW is not a simple case.

But take a look at this :

It’s a bit hard to see. But this is a construction spot in the regional view of “Phase 2″. You see a crane with an alpha-masked texture that lets the background “shine” through. And now you also see that the upper part has a red background. And that is one of the aforementioned problems when using color selection in e.g. a complex UI like “Phase 2″ does. Why? Because the window has a callback for rendering the content that is called when the window is visible and in that callback I render (amongst other stuff) the region’s structural preview with all it’s building spots. And So contrary to a simple application I can’t just render the color selection view of the region and delete the framebuffer’s content cause that would erase the whole content of the window that was drawn before (e.g. the background scenery image).

So how do you get around these problems? You need to use some kind of offscreen rendering. For “Phase 2″ I use frame buffer objects when available (if not, just simple render-to-texture). Though here lies another problem that forced me to change how I update the offscreen rendering in “Phase 2″. When you use FBOs you can update them whenever you want, cause your normale framebuffer won’t be affected. But with normal render-to-texture that’s not the case, so you can’t just simply update the texture when e.g. the region is displayed cause that would affect the current framebuffer too, but along with this problem I fixed the above color selection problem too : I do texture (and fbo) updates and color selection before I start rendering the current frame, and that fixes all those problems.

Old way of updating textures and doing color selection :

Render the 3D-Scene in the background (globe, water, sky)

Render GUI

GUI calls the region’s window’s callback for content rendering

Color selection view of region is rendered

Depth buffer is cleared

Normal view of region is rendered

This would cause the above artefacts behind alpha-masked (and translucent) buildings and also would not work with normal render-to-texture (since I want to have an audience as broad as possible I implemented that for older GPUs).

So here is how the rendering now looks :

Update (if necessary ) FBO (or texture) for region’s normal view

Update (if necessary ) FBO (or texture) for region’s color selection view (yes, separate FBOs/textures, cause it’s not always necessary to update them both, this is due to performance reasons)

Render ONLY the color selection part of the region if the window is visible and cursor is hovering above the 3D preview panel

Read back color in framebuffer and get selected building

Clear framebuffer (and depth, stencil and everything else)

Render the 3D-Scene

Render GUI

GUI calls the region’s window’s callback for content rendering

Now just paint a simple quad with the FBO/texture of the region’s normale view where the 3D panel is located

So now with that new way of rendering e.g. the region there are no more artefacts for the color selection of alpha-masked buildings and (not less important) it’s now a lot faster cause I only update the FBO/texture of the region’s view when something has changed instead of rendering the region directly onto the GUI every frame. Hopefully this will help some of you on how to render 3D scenery on-top of a 2D user interafce, as it’s not a trivial task.

As already told (countless times I guess now) I’m still working on the new GUI but I’m making good progress. Only one window needs to be transitioned over to the new GUI before I can call this milestone done and move over to work on other stuff like adding content and functionality. My current plan is to have a version with the new GUI and all features (only one feature of “Phase 2″ is missing) done that I can release for public testing by this yeas end. But since real-life can’t be predicted please don’t count me on this, though I try to squeeze in as many hours for coding as possible to get it done.

So that one window that still needs (only some) work is the “secret agency” (espionage and sabotage for your agents) and that’s what I’m currently working on. The biggest problem with this window is that it includes a lot of different information, and even if I would have the whole screen available it would still be hard to present all of this at once (by “at once” I mean all of the information depending on the selected agent’s location, e.g. enemy region, division, free, etc.). And so after countless (at least a dozen) iterations of that window I finally have something setup that looks great, feels good and is intuitve to use (which is kinda important). In the screenshots below you can see the current version showing agent’s assigned to enemy regions displaying all important informations and the newly created (see bottom of the window) action list. That action list was a lot of work and it had several different iterations throughout the last few weeks, starting out as a plain and boring list of simple text buttons and now it has become a display of some nice icons :

So for that action list I had to create a dozen icons (only for enemy regions, the other agent assignments will need some new icons too). And for most of you this may sound like something that could be done in a few minuts, but it actually took me four days (with ~2h each day). Why you ask? Because it’s really hard to create icons that transport what they intend to use. That’s simple because you only have a very limited space (128x128px, in the game they’re even smaller) to create something that a user will directly recognize. And that task itself isn’t trivial, but you first have to come up with a design before you start creating that icon, and it often happens that you have a good idea and that the icon looks great in big, but when you put it into the game and only see a small represenation it just won’t work, meaning you can start all over. That’s why it often takes me such a long time to create several icons, and I guess everyone who did some small icons by themselves know what I’m talking about. So after finding a nice concept for every single icon that would work on a small space I created them using a 3D modeling application and rendering them with an ink’n'paint shader (think of cel-shading) to give them a nice, high-contrast look. Afterwards (depending on the icon) I also added some stuff in Photoshop and tested how they’d look in the game. So here you go, all of the new icons in one nice image. I hope they’ll transport their funtionality pretty well, though please note that in the game they also have a short caption as well as an extended tool-tip if you hover above them :

Back in the days before I got myself a PS3 I used to upgrade my PC every year. But since then (early 2009) I haven’t really bought any new PC games and thus never felt the need to upgrade my hardware. But well, my HD4850 (512 MB) started to show it’s age, especially when I wanted to play The Witcher 2 (I loved the first one, and the second one seems to be a great RPG too) and realized that even at lowered details and dialed back resolution (which isn’t really nice when you have a big display) the game was chugging along (20~25 fps with a lot of stuttering). So I decided to get me a new graphics card, and after reading through reviews and articles I settled for an Radeon HD6850. The HD4850 was a nice card (except that the cooling fan died, and the one you see in the shot is a replacement one I mounted myself), but for current games it just wasn’t enough anymore, and the new HD6850 has twice the VRAM and it’s cooling fan is even more silent than the already very-silent one on my HD4850 (it’s so silent you have to put your fingers into the fan to see if it’s actually working). And for roughly 135€ it wasn’t too expensive either, especially since it included a free copy of the recently released DIRT3, a game I wanted to buy anyway (I’m really into racing sims/games and own a nice steering wheel ). And yes, The Witcher 2 looks really stunning with this new toy, so hopefully the game itself will be as good as the first one, and DIR3 seems to support DX11, so I’m pretty sure this will look stunning too (especially when you’re used to the low-res 30fps visuals of current console games).

And yes, the HD6850 also supports Shader Model 5.0. So maybe I’ll start digging into this and try out some of this in OpenGL. Especially the new tesselation unit looks interesting. Though I’m still pretty busy with work on “Phase 2″ of Projekt W and I don’t plan on putting any SM5.0 functioanlity into it (maybe I’ll try to apply hardware tesselation to the globe, just to see how it looks).

Odd title, but it perfectly describes my “workflow” when it comes down to the GUI of “Phase 2″. But since the user interface is such a crucial part for a complex strategy game I don’t feel bad when putting hours and hours (and days) into optimizing the interface of a single “window”, especially seing as how horribly one of my old drafts looked. And yes, I really like the current UI. It has a nice flow, looks pretty sleek and has a great usability.

But after the last redesign of some of the “windows” (though they’re no longer freely moveable, so I should better call them areas or screens) several weeks ago I wasn’t 100% satisfied with them anymore after taking a look at them recently. Especially the partitioning wasn’t very well and it was hard to distinguish the different parts of it, e.g. where the current selected tech is displayed and where your active research is located. So I sat down, did some prototyping and finally (hopefully) found a good way of making it easier to distinguish information within the new windows with a new UI element called “header panel”. It’s the one that looks like a table header with an arrow-like captionion part on the left and a normal text (and icon if selected) part on the right. I’ll now use them to separate important parts within a window and to depict important sub-information by indenting and scaling them.

So take a look at the newly re-designed research section. The left one shows the old version, the right one shows the new version :

Though the old version may look nice, I felt that it lacked overview and therefore made it hard to orient yourself and to find the information you’ve been looking for. So the new design with the headers changes this and makes it much easier to navigate through the information presented. Though note that this is still (as usual) work-in-progress, but not much will change anymore.

And I’ve also been reworking the main menu and the result screens. Those two have been on my list for a long time now but I never got around working on them. One problem with the main menu from “Phase 1″ was that it was created for 4:3 displays and therefore looked pretty bad on all (now widely spread, including myself) widescreen displays. So I dumped the whole old design and made a new simple one that is centered and in-line with the rest of the game’s look, also using the day-night transition. It looks more minimalistic, but that’s the “theme” of the whole UI redesign anyway, makin the UI easier to use. And then the result screens : the original ones were done quickly and I never liked them. Back when I made them I actually didn’t had the motivation to do “cool” ones, but instead used the same design for winning and loosing with a slight different header. So I sat down and created new loosing and winning screens (that are now also used in hotseat, instead of the plain boring dialogs of dead nations in “Phase 1″) that fit their purpose, are in line with the new UI-design and are also animated. So if you win you’ll have fireworks and airplanes with colored (depending on your nation) smoke that fly above your head. Also included are more informations than in the old result screens, though I plan on adding even more info here, as there is plenty of space now. But since pictures are worth much more than words, just take a look at them :

And yes, I plan on making a video of all these new UI changes, as especially the result screens look much better in motion. But there are still parts and areas of the UI design that need to be finished before I’ll put them on video. But rest assured, you’ll get a new video in the near future, also showcasing a lof of new stuff concerning manual battles.

Something that has been lacking in “Phase 1″ was replayabilty or better said the motivation to replay the game. This was mainly due to the fact that there was only on single game mode (now called “default”) to choose from in both singleplayer and hotseat games. So basically each game played the same except for maybe the player playind it different or the random factors that change some of the AI’s behaviour.

So for “Phase 2″ I started implementing new game modes as well as the possibility to change some more game settings than in “Phase 1″. This should add a lot of replay motivation, cause the new game modes will change gameplay, how much depends on what mode you choose.

So here is a preliminary list in addition to the default one (the modes below will be in the game, but some of their mechanics will change, and it’s also possible that I’ll ad more modes) :

* Alternate reality
This mode will display an alternate history in which the origins of the nations have been randomly scrambled. This means that e.g. Neweurope will occupy the regions of Übermerica along with the Oceanic Front being located where the Arabian League used to reside. Other than that the mode will mostly play like the default one. Think of it as a mode with random spawn points.

* Last stronghold (aka People’s uprising, not sure of the name yet)
The people were upset with their leaders after they’ve been mistreated for deacdes now with their homes and cities crumbling under endless wars and conflicts. So they started to organize and to dethrone their power-hungry leaders. At the beginning of this mode all leaders have been pushed back to their strongholds (special regions marked in the game’s editor) where the are protected by their last personal guard. So all regions except these strongholds are hold by rebels in the game’s beginning and the players will have to reconquer them. Other than this regional difference the players will have unlocked all military techs and have a nice personal division deployed in their stronghold.

* End of days
The globe has been ravaged by countless centuries of war and environmental damage and is at the verge of a global climate collapse that’s about to destroy al life on earth. But still the leaders of the world’s nation only think about their own advantage and about making a name in the history books of the soon-to-be-gone human race. So different to the default mode all players only have a limited amount of turns to finish their bunker as much as possible to escape  earth’s climate collapses. Right now I plan to replace global project list with a list of different construction parts for the bunker, and the winner who has finished most of them when the game will win. And also earht’s texture will be replaced by a dead and dryed out version of the normal texture.

* Soldier of fortune
This mode will make for a great dynamic and diffifult to predict gameplay. Actually the basics of this have already been layed out in an early design document, but will now be implemented via it’s own game mode. So upon the start of each turn every player/nation will be “awarded” with three bonuses/maluses that’ll be active for this turn. So e.g. you can get bonuses like lower building costs, higher military strength, faster research but you could also be out of luck and get maluses like lower earning, falling stock prices, slow research, etc. There’ll be a pretty long list of bonuses/maluses with each of them having three levels (minimal, normal, high). This mode should add a lot of fun cause it’ll shift away from pure strategy to a bit more luck to rely on.

 

So that’s the preliminary list of planned gameplay modes for “Phase 2″. What do you think? Do you like the modes? Or do you have ideas for totally different modes or just want ot have one of the above modes changed? If that’s the case, just put up a comment.