I'm in the middle of the lighting implementation. Here's a little screenshot from the 360 version:
Please excuse the crude lighting setup, this is for testing so it needs to be somewhat exaggerated. The model is from Drakensang, so it isn't actually modelled to be displayed upclose like this.
Showing posts with label Xbox360. Show all posts
Showing posts with label Xbox360. Show all posts
12 Sept 2007
14 Aug 2007
First Render: Xbox360
Ok, here's the Tiger example scene on the 360:
Visually not very impressive, just as the last screen. The point is that the basic Nebula3 render loop is now also running on the 360 (complete with asynchronous resource loading), side by side through exactly the same highlevel code and from the same source-assets as the PC-version.
It took me a bit longer then planned because of the 360's tiled rendering architecture, and because the rendering code is *not* just a straight port from the PC version (you pretty much can do this on the 360, it's just not as optimal as using the more 360-specific APIs).
Because of the tiled rendering I had to do a few basic changes to the CoreGraphics subsystem in order to hide the details from the higher level code:
CoreGraphics now gets hinted by the higher level rendering code what the rendered stuff actually is, for instance, depth-only geometry, solid or transparent geometry, occlusion checks, fullscreen-posteffects etc...
The second change is that RenderTargets have become much smarter. A RenderTarget object isn't just a single rendering surface as in Nebula2, instead it may contain up to 4 color buffers (with multisampling if supported in the specific configuration) and an optional depth/stencil buffer, it has Begin()/End() methods which mark the beginning and end of rendering to the render target (this is where the rendering hints come in, to let the RenderTarget classes perform platform-specific actions before and after rendering).
A render target now also knows how to resolve its content most efficiently into a texture or make it available for presentation. Traditionally, a render target and a texture was the same thing in Direct3D. So you could render to a render target, and when rendering was finished the render target could immediately be used as a texture. This doesn't work anymore with multisampled render targets, those have to be resolved into a non-multisampled texture using the IDirect3DDevice9::StretchRect() method. On the 360 everything is still a little bit different depending on the rendering scenario (720p vs. 1080p vs. MSAA types). So the best thing was to hide all those platform-specifics inside the RenderTarget object itself. A Nebula3 application doesn't have to be aware of all of these details, it just sets the current render target, does some rendering, and either gets a texture from the render target for subsequent rendering, or presents the result directly.
I also started to work on a "FrameShader" system. This is the next (simplified) version of Nebula2's RenderPath system. It's basically a simple XML schema which contains a description of how a frame is exactly rendered. It has 2 main purposes:
Visually not very impressive, just as the last screen. The point is that the basic Nebula3 render loop is now also running on the 360 (complete with asynchronous resource loading), side by side through exactly the same highlevel code and from the same source-assets as the PC-version.
It took me a bit longer then planned because of the 360's tiled rendering architecture, and because the rendering code is *not* just a straight port from the PC version (you pretty much can do this on the 360, it's just not as optimal as using the more 360-specific APIs).
Because of the tiled rendering I had to do a few basic changes to the CoreGraphics subsystem in order to hide the details from the higher level code:
CoreGraphics now gets hinted by the higher level rendering code what the rendered stuff actually is, for instance, depth-only geometry, solid or transparent geometry, occlusion checks, fullscreen-posteffects etc...
The second change is that RenderTargets have become much smarter. A RenderTarget object isn't just a single rendering surface as in Nebula2, instead it may contain up to 4 color buffers (with multisampling if supported in the specific configuration) and an optional depth/stencil buffer, it has Begin()/End() methods which mark the beginning and end of rendering to the render target (this is where the rendering hints come in, to let the RenderTarget classes perform platform-specific actions before and after rendering).
A render target now also knows how to resolve its content most efficiently into a texture or make it available for presentation. Traditionally, a render target and a texture was the same thing in Direct3D. So you could render to a render target, and when rendering was finished the render target could immediately be used as a texture. This doesn't work anymore with multisampled render targets, those have to be resolved into a non-multisampled texture using the IDirect3DDevice9::StretchRect() method. On the 360 everything is still a little bit different depending on the rendering scenario (720p vs. 1080p vs. MSAA types). So the best thing was to hide all those platform-specifics inside the RenderTarget object itself. A Nebula3 application doesn't have to be aware of all of these details, it just sets the current render target, does some rendering, and either gets a texture from the render target for subsequent rendering, or presents the result directly.
I also started to work on a "FrameShader" system. This is the next (simplified) version of Nebula2's RenderPath system. It's basically a simple XML schema which contains a description of how a frame is exactly rendered. It has 2 main purposes:
- grouping render batches into frame passes (e.g. depth pass, solid pass, alpha pass) and thus eliminating redundant per-batch state switches (state which is constant across all objects in apass is set only once)
- easy configuration of offscreen rendering and post effects without having to recompile the application
23 Jun 2007
Status Update...
Busy...
Working on the Xbox360 is total joy. Unfortunately I can't go into details because of NDA. I did some work on the original Xbox already, so it's not all new to me, but I was once again pleasantly surprised how painless the XDK setup is. All you have to do is plug-in some cables, double-click the installer, and after the installation ends (10..15 minutes) you're ready to compile and remote-debug the samples inside Visual Studio. Very impressive. The APIs basically offer everything a game programmer ever needs (and misses on the PC), the documentation is excellent. There's a wealth of high level APIs, but it's absolutely possible (and relatively painless) to go down to the metal if needed. Both is very important on a console. When the high level APIs are missing, too much time is wasted reinventing wheels (I guess that's one of the reasons why ports from the 360 to PS3 often take so long), and the low level stuff is necessary for optimizing performance-critical code (which is usually not possible or worthwhile on the PC because of all the different hardware configurations).
At the moment I only have 2 or 3 hours daily and the weekends to actually work on Nebula3, but despite that it's coming along nicely.
The Nebula3 Foundation Layer is already up and running on the 360. This is not a quick "just-fix-the-compile-errors" port", but a "proper" port which makes use of the 360's specialties. I had to take 2 things out, and move into a new "Add-On Layer": the HTTP stuff and the Database subsystem. The only other things that needed to be fixed were some data alignment issues and (naturally) byte order issues in the BinaryReader/BinaryWriter classes. I'll add some testing and benchmarking classes next week and then move on to the Render Layer.
Considering the differences between the 2 platforms (different byte order, 32 bit vs. 64 bit, different compiler back ends), everything was completely painless. The usual first experience when bringing code to a new platform is looking at pages of compiler warnings scrolling by. On the 360 SDK most of Nebula3 compiled and ran out of the box on warning level 4 without warnings.
I really wish MS would bring ALL the high level XDK APIs and tools over to Windows! They already started with XACT, XInput and PIX, but there's so much more cool stuff on the 360 that's missing on the PC and which would make a PC game programmer's life so much easier...
PS: Prince Of Persia Classic rocks. Best Arcade game ever :)
Working on the Xbox360 is total joy. Unfortunately I can't go into details because of NDA. I did some work on the original Xbox already, so it's not all new to me, but I was once again pleasantly surprised how painless the XDK setup is. All you have to do is plug-in some cables, double-click the installer, and after the installation ends (10..15 minutes) you're ready to compile and remote-debug the samples inside Visual Studio. Very impressive. The APIs basically offer everything a game programmer ever needs (and misses on the PC), the documentation is excellent. There's a wealth of high level APIs, but it's absolutely possible (and relatively painless) to go down to the metal if needed. Both is very important on a console. When the high level APIs are missing, too much time is wasted reinventing wheels (I guess that's one of the reasons why ports from the 360 to PS3 often take so long), and the low level stuff is necessary for optimizing performance-critical code (which is usually not possible or worthwhile on the PC because of all the different hardware configurations).
At the moment I only have 2 or 3 hours daily and the weekends to actually work on Nebula3, but despite that it's coming along nicely.
The Nebula3 Foundation Layer is already up and running on the 360. This is not a quick "just-fix-the-compile-errors" port", but a "proper" port which makes use of the 360's specialties. I had to take 2 things out, and move into a new "Add-On Layer": the HTTP stuff and the Database subsystem. The only other things that needed to be fixed were some data alignment issues and (naturally) byte order issues in the BinaryReader/BinaryWriter classes. I'll add some testing and benchmarking classes next week and then move on to the Render Layer.
Considering the differences between the 2 platforms (different byte order, 32 bit vs. 64 bit, different compiler back ends), everything was completely painless. The usual first experience when bringing code to a new platform is looking at pages of compiler warnings scrolling by. On the 360 SDK most of Nebula3 compiled and ran out of the box on warning level 4 without warnings.
I really wish MS would bring ALL the high level XDK APIs and tools over to Windows! They already started with XACT, XInput and PIX, but there's so much more cool stuff on the 360 that's missing on the PC and which would make a PC game programmer's life so much easier...
PS: Prince Of Persia Classic rocks. Best Arcade game ever :)
13 Jun 2007
Subscribe to:
Posts (Atom)