Just a quick quick update to show that things are progressing well:

Sven and I decided to keep a "developer's diary" of sorts - not just "We're Close!" news posts, but actual descriptions of what we're doing and what we're thinking, etc.

So, today: deferred shading (I'm writing as I go). Well, "proper" deferred shading. Since we started the new engine (not the old "Disorder" engine), I've had a very loose deferred shading system in place that rendered lighting as a screen-space quadrilateral. This will cause much overdraw for lights that don't cover the whole scene, and it gets rid of deferred shading's main advantage: lots and lots of dynamic lights

Off to the optimization! In general, you would render the lights as convex geometry the size of the light's radius of influence. Lots of people use spheres, but we're going to just use a box. The extra bit of overdraw is minimal, and we get to use 6 polygons for a box per light instead of 100s for a sphere per light.

Off to implementing!


Yay! We now have our little light cube. And the lighting is completely incorrect, and weird looking, too! Well, that's because I'm making the light cube simply 100% white, which is not actual light. Something interesting to note, however: notice the "SSGI" (screen-space-global-illumination or more rather a "coloured SSAO hack") Just Works out of the box, no matter what the light is and where it comes from

... and trouble. Direct3D is fine, but OpenGL has the cube moving in weird directions when the camera rotates. Luckily, I was quick to know what caused it: OpenGL sometimes requires render targets to be flipped upside-down. Weird, but then again everything with rasterization can be considered weird Posted a thread on the Ogre forums about it, did a quick search on the Ogre source, found the answer, posted the answer to my own thread within 10 minutes, fixed it, and life is good

Next: make the light cube do actual lighting. That's all for now, I will edit my post once that is done! Be patient for a bit now, an edit should be up soon (today)

Edit:
Well, we got correct ray calculation:


As well as correct UV calculation:


Edit2:
And we now have correct lighting:


And after clipping the fragment if it's out of the light's bounds:


(the red tint is the "light cube", just for debugging)

Edit3:
Debug build, 1k lights (pretty much all in view):

30 FPS is not too bad considering the # of lights and the fact that this is a debug build (release builds are faster).

I thought I should post a status update especially meant for all the Linux people (like myself!): Right now, installing Portalized and its development environment is a simple one-liner in Arch Linux to make it work pretty much out of the box. Needless to say, we fixed the Lua and Luabind trouble and are back actually developing features.

Screenshot to make you believe:

Looks a bit crappy thanks to .jpg :/

Don't forget to check out our ever-so-fresh media collection in case you have not been up-to-date with Portalized for some time.

On another note, our active community member and tester Eriksrocks has been busy making some smileys for Portalized. Enjoy:
-snip-
Check this thread on the forums for updates!

Hey everybody,

please note that you will have to update your RSS feeds because I just happily made some changes in order to improve compatibility with RSS readers like Google Reader.

The new paths are:
News feed: http://www.portalized.org/portalized-news-rss.xml
Forums feed: http://www.portalized.org/portalized-forums-rss.xml

EDIT: To keep everybody happy, I decided to add some screenshots from the most recent build:

Yay, everybody get excited!

We decided what needs to be done for our first public release:

• Portals! Of course, in a game with a name like this, these guys need to be in. WIP 90%
• Triggers. This enables setting winning conditions and the like. WIP 10%
• Wall walking. Everybody likes this. WIP 50%
• Gravity tinker-kit. Better put on a helmet. WIP 20%
• Customalized prototype. You guys haven't heard about this one yet, I think. It'll be the customization platform for Portalized. WIP 50%
• Lots o' props. So you can play with some objects. WIP 20%
• Cross-platform testing & packages. So everybody can enjoy it the same way. WIP 80%
• Some levels. To show off the games current state of capabilities. WIP 30%

We will keep you guys updated in this thread. Maybe Eriks will do some videos and nice pics when the source becomes available to him

Shortly before going on vacation, Eriksrocks put together another video, this time demonstrating time manipulation in the Editor.
Thanks Eriks and nice vacation.

Thanks to our loyal tester Eriksrocks, we present to you a video peek at the editor. Please take everything you see with a lot of distance because it obviously is not a finished product, yet it works quite well. Here you go:



Special thanks to Eriksrocks.

So people said they want technical news... well, then, we'll give you technical news

Today the first level format has been finished. Basically, you go into the editor, do stuff, click on the "save" toolbar button, a file dialog pops up, you type in the name of the level, and save it. Whenever you want to load it, you click on the "load" toolbar button, a file dialog pops up, you select the level you want to load, and it loads . This seems like elementary functionality, but designing a well-formed, efficient, flexible, backward-compatible and future-proof level format can be very tough. You want it to never break for older levels, yet at the same time, you want new types of entities and information to be able to be stored effortlessly.

So, the solution? Google Protocol Buffers. Basically, you script the level format in a C-like language, have the Google Protocol Buffer compiler compile it into C++ code, and then you use that C++ code to load/save information. "But you can do that easily just by opening a file and writing raw data to it." Yes, you can. But then you need to think about how to arrange the data, how to place it efficiently, how to keep it backwards compatible when you change something, and how to make it flexible enough that you can easily add stuff without shifting everything else around. Google Protocol Buffers solve all of these issues very nicely.

The very first "test" level that actually works contains 4 props and is under 1KB.

Before I begin, this is not meant to be an anti-ATI rant. This entry should only give you guys some insight into what kind of problems we're confronted with.

So, this is what Portalized regularly looks like on Nvidia:

And this is what it usually looks like on ATI: or this or this or this or this

But it certainly never looks quite as intended!

We have done a LOT of testing (thanks Eriks!) but so far we just weren't able to pin down the issue and quite frankly we don't currently care. If we did nothing but try to fix the ATI issue, development would grind to a halt. We do not have the expertise OR the hardware to track this down now so if there are any experienced ATI developers in the audience, help would be highly appreciated.

On related news, our editor is almost complete.