Plan for Pat Wilson
by Pat Wilson · 12/09/2004 (9:05 pm) · 15 comments
NOTE: This postmortem was written about two-and-a-half months ago, so some things are not very current. I just never got around to posting it
-------------------------------------------------------------------------
When Jeff said that GarageGames wanted me to lead the charge to bring Marble Blast onto the Xbox, it was Tuesday June 8th, my second day as an intern at Firaxis Games, and I had just finished moving to Maryland. June 26th was the first day of work on Marble Blast for the Xbox at GarageGames.That was three months ago, and getting from there to here was an interesting trip.
First Steps
The first part of development was spent getting the darn thing to run on the Xbox. No graphics, just make it compile. In order to get Torque to compile and link on the Xbox, all of the OpenGL and OpenAL calls had to be removed. More importantly, OpenGL calls which modified the state of Torque (matricies, etc) had to be noted so that they could be replaced with Direct3D calls. I had a bit of a head start, because I used the Direct3D 9 version of Marble Blast which we put together for GDC 2003. That version of Marble Blast was done by Mark Frohnmayer, Brian Ramage, and myself in about three weeks. It is not pretty code. After making Marble Blast compile for the Xbox, I began back-porting the Direct3D 9 calls to Direct3D 8. This was pretty straightforward, but there are some key differences between Direct3D 9 and Direct3D 8, and some key differences between PC Direct3D 8 and Xbox Direct3D 8. To name a few, there is no R8G8B8 format for the Xbox. They have X8R8G8B8, and A8R8G8B8. It was a great feeling the first time the Marble Blast GUI came up on the TV.
It may not have looked like much, but all the important things were there. Displaying Torque GUI controls, and displaying textures. That was the easy part, the next task was to get the game running and playable.
By July 5th, the game was running...in it's own special way.
As you can see...it doesn't look much like Marble Blast, but you could play the game in expert mode. (Expert mode means, you can't see the level because it doesn't render, but you can collide with it. That seperates the men from the boys in Marble Blast.) After another day, this was the status.
Improvement for sure. By June 16th the game was loading all resources and displaying all of the graphics, and it looked like this
I re-enabled shaders, and learned some important things about Xbox shaders. I was using CG to output my shaders to version 1.1, and the Xbox and the PC use different registers for data. For example, the T0, the first texture coordinate register, is different on the Xbox than it is on the PC. This provided at least a day of confusion, and then it happened again later in development with Normals being in a different register. The first shader work looked like this
Controls and Interface
So it's starting to look great. But how does it play?I went through four versions of the input before I was satisfied with how the controls felt. Marble Blast is using non-linear control for the analog input. Basically this is how the Xbox analog stick works. For each axis, (X and Y) a value between 32767 and -32767 is recorded. I then scaled this to be between -1.0 and 1.0. With analog controls, there is also a dead zone. This means that the output value can be in this region even though the user is not touching the stick. For the Xbox controler, this is around 24%, so effectivly 24% of the controler input I had to discard as unrelyable. After that, the input must be re-scaled, because otherwise, the user will push on the stick, and it will record values up to 0.24, and then at 0.25 it will jump forward because all of the sudden the input value is 0.25, when in reality, it's just bairly above the threshhold to be useable. So I rescaled the input from 0.24 1.0 as a new value between 0.0 and 1.0 (and -1.0 and 0.0 respectivly). After this the control felt much more smooth, but that was not enough. When you want to move a little bit in a game, you will push the stick a little bit, and each milimeter counts as you try to be as precise as possible. However, when you want to go fast, you want to go FAST. So what does this mean? Well I wanted to use a function to modify the input so that if the user put a little pressure on the stick, only a VERY little movement occurred, and the movement would scale non-linearly. I tried a few different functions, and settled on X^e, which was actually the simplest function I tried. As you play Marble Blast on the Xbox you will notice that you get a very high level of precision, and the controls just feel "right". This is the reason.
Mark Frohnmayer put in a great "ramp-up" acceleration feature into the camera, and it's completely un-noticable to the user. The only way you could see it is if you saw the old camera. Basically, what happened was if you slammed the stick all the way, the camera would spin quickly and it was very disorenting. People, at first, have a tendancy to over-control things, and so a new user would spin the camera around and get scared of it. Mark's changes made it so if they did the same thing, the camera would rotate slowly at first, then ramp-up in speed. This ramp-up took less than a second, but it made a world of difference.
The Marble Blast interface went through about 3 or 4 iterations as well. We had very limited screen space with which to display all the information we needed to show. The Xbox runs, normally, at 640x480 resolution. However, there is an area of the screen which is not relyable across all televsions. The "Safe Area" is about 30 pixels in from the top and bottom, and 40 pixels in from the sides. With this safe area, our screen real-estate was cut even more. A lot of work was done to make everything as easy as possible to use, and friendly to look at while still displaying the needed information to the user. Mark also did a great job here of letting the user select levels with the analog stick in a very natural way. When the user holds down the analog stick in a direction, it will change levels, slowly at first, then again ramping up in speed. This lets them avoid having to go doink-doink-doink with the stick each time they want to change levels.
Xbox Live
The next huge task was how to make use of the Xbox Live resources we had, within the constraints of the Xarcade system. For a regular Xbox Live game, you are issued 100 Scoreboards and you can do whatever you want with them. This would have been great for Mable Blast because we have 100 levels, this way each user could be ranked based on their time. Xarcade, however, allowed us to have one scoreboard. Many, many solutions were worked out over lunch between myself, Ben Garney and Josh Williams. Ranging from the elaborate, inserting false Xbox Live users and having them store sorting data in the table. To the downright bizzare: making a long button-combination to turn an Xbox into a score server so that other users would message it to get score information. In the end, we conceded, and had rankings based on a global score which your time effected. Figuring out how many points you should get for a time on a level was another problem to which Mark Frohnmayer, Alex Swanson and I discussed a few times, before we arrived at the final implementation.
Disaster struck when we were informed that we could not make Xonline calls, but instead had to use only Xarcade calls. A Xbox Live scoreboard is a database table table with one row per user ranked, and a set number of columns. Each column can store a set amount of data. My plan was to take 50 columns, and use each one to store two high-scores for Marble Blast. After a good deal of daily phone calls and lobbying on the Xbox Live Arcade development mailing list, they extended the API so we could write raw data to 50 columns, a very convenient number.
Live Arcade Requirements
One of the requirements for Xbox Live Arcade games is that all of the data must fit inside the executable. Those of you who are familiar with the PE (Portable Executable) format which Windows uses will know what I am talking about when I say Data Sections. For those of you who aren't, a Data Section is data packed inside the executable which is not marked as executable code, you can load that data into memory. The Xbox implements this same thing, but there is a problem, which I will get to shortly. Torque, as some of you may know, supports loading resources from Zip files. So the solution to this problem seemed easy, embed zip files into the executable with sections. The problem, however, was way more complicated than this. Loading a section means that the section is placed into memory. The Xbox has 64 megs of RAM, peroid. This is shared memory with the video card as well. Marble Blast runs, in the GUI at around 40 megs on the Xbox. In order to load a resource, a 16mb zip file would have to be loaded into memory, memory would be allocated to uncompress this file (~2MB) the file would then be copied into memory. That bairly works in the GUI within 64 megs, and it would NOT work as more resources got loaded into the game. A solution had to be found, otherwise, game over.
The solution I arrived at was to use sections to store the data, that worked fine. The problem came when the data needed to be loaded into memory. So, the obvious soulution was, never load the data into memory. Clearly the Xbox had a way of knowing where in the file to look for the data to load it into memory, so there must be a way of finding the offset of the data in the executable file. After some work I found out how, and I modified the platform file I/O layer to support virtual files which were packed inside the executable, all of this was completely transparent to the resource manager and Torque in general. When the game asks for "D:\marble.zip" the file I/O layer checks a table of virtual files which it extracted from the XBE header. It will find "D:\marble.zip" mapped to a section named "TQ_ZIP1". It will then check the offset in the XBE for this area of data, and find out how long it is. It then opens its own executable and changes the file pointer to the start of "TQ_ZIP1" so that when the resource manager starts reading, it is reading the zip file, and it is none the wiser. It also stores a virtual offset in that file so that when the zip loading code seeks back and forth in the file, it thinks it is working on a regular file which starts at offset 0 and ends at the length of the file. All in all, this is the solution I am most proud of in the whole project.
Shaders
The final version of the shaders were done by Brian Ramage who is truly a god among men. As you can see from the final screenshots of the game, we have specular highlights interacting with our bump maps, which Brian implemented with a two-pass environmental-bump map. This is what the final version of the shaders looks like:
Art
The textures took a lot of work by Alex Swanson to make them look good on a TV. The display range of a TV is not 0-255 for each color, like a computer monitor. It is 16-238, all of the colors had to fit in the NTSC safe range. This meant, basically, toning down everything. This resulted in some color shifts, and so it really just took a lot of tweeking.
Fun Bugs
There were a lot of fun bugs in Marble Blast one of the more interesting ones was a file-handle leak. When Torque opens a demo recording, it would use ResourceManager->openStream to open the file stream, however, it would use the delete operator to free that stream. The Resource Manager allocates a sub-stream for zip resources, so this resulted in a file-handle leak which would crash the game after many hours of sitting on the start screen playing demos.
There were numerous memory leaks which made me very greatful for the awesome Torque memory library. The memory library in Torque is very, very useful and if you have never taken the time to examine the functionality in it, it is well worth your time. I used it to find a GPU memory leak by tracking the pointers to the vertex buffers to see which ones were not getting freed.
Performance
Mark Frohnmayer put in a lot of work on the performance of the stencil shadows. We really felt that the shadows made the game look way, way better than without them, and we really wanted to keep them in. Mark's work enabled us to run with stencil shadows on all the levels at a consistant framerate of 60fps.
Closing
Marble Blast for the Xbox was an awesome project. It was amazing to see how much time and work it took to take a finished game...and I'll say that again, a FINISHED game, and make it a finished game for a console. We learned so much about console development from this project which we plan on using in future games so that we can make the transition to console even easier. Even today, three months later, I still get a thrill from seeing my work on a TV screen. One of the people we had test the game said that the game was just so much cooler, just because it was on a TV with a controler instead of on a PC with a mouse and keyboard, and I agree.
We put a huge amount of effort into making this game shine. Jeff would come in almost daily and say, "Ship it, damn it!" and shake his head when I mentioned wanting to re-do the particles for some effect just to make it look a little bit better. The camera changes that Mark put in were in the final two weeks of development and they did wonders twords making the game more newbie-friendly. Every single GUI was analized to see if we could make it better. Every option was examined to see if we could remove it. We wanted to have the interface be as simple as possible, with as few screens as possible, and as few options as possible.
Will our work let us go to the bank? We don't know yet, but the work that Mark, Brian, Alex and myself put in to Marble Blast has already "paid off" in experience and the pride of seeing our game, the first indy game on the Xbox, have testers at Microsoft and Oberon raving about it, and we are excited to see how it will do once it is released.
-------------------------------------------------------------------------
When Jeff said that GarageGames wanted me to lead the charge to bring Marble Blast onto the Xbox, it was Tuesday June 8th, my second day as an intern at Firaxis Games, and I had just finished moving to Maryland. June 26th was the first day of work on Marble Blast for the Xbox at GarageGames.That was three months ago, and getting from there to here was an interesting trip.
First Steps
The first part of development was spent getting the darn thing to run on the Xbox. No graphics, just make it compile. In order to get Torque to compile and link on the Xbox, all of the OpenGL and OpenAL calls had to be removed. More importantly, OpenGL calls which modified the state of Torque (matricies, etc) had to be noted so that they could be replaced with Direct3D calls. I had a bit of a head start, because I used the Direct3D 9 version of Marble Blast which we put together for GDC 2003. That version of Marble Blast was done by Mark Frohnmayer, Brian Ramage, and myself in about three weeks. It is not pretty code. After making Marble Blast compile for the Xbox, I began back-porting the Direct3D 9 calls to Direct3D 8. This was pretty straightforward, but there are some key differences between Direct3D 9 and Direct3D 8, and some key differences between PC Direct3D 8 and Xbox Direct3D 8. To name a few, there is no R8G8B8 format for the Xbox. They have X8R8G8B8, and A8R8G8B8. It was a great feeling the first time the Marble Blast GUI came up on the TV.
It may not have looked like much, but all the important things were there. Displaying Torque GUI controls, and displaying textures. That was the easy part, the next task was to get the game running and playable.By July 5th, the game was running...in it's own special way.
As you can see...it doesn't look much like Marble Blast, but you could play the game in expert mode. (Expert mode means, you can't see the level because it doesn't render, but you can collide with it. That seperates the men from the boys in Marble Blast.) After another day, this was the status.Improvement for sure. By June 16th the game was loading all resources and displaying all of the graphics, and it looked like thisI re-enabled shaders, and learned some important things about Xbox shaders. I was using CG to output my shaders to version 1.1, and the Xbox and the PC use different registers for data. For example, the T0, the first texture coordinate register, is different on the Xbox than it is on the PC. This provided at least a day of confusion, and then it happened again later in development with Normals being in a different register. The first shader work looked like thisControls and Interface
So it's starting to look great. But how does it play?I went through four versions of the input before I was satisfied with how the controls felt. Marble Blast is using non-linear control for the analog input. Basically this is how the Xbox analog stick works. For each axis, (X and Y) a value between 32767 and -32767 is recorded. I then scaled this to be between -1.0 and 1.0. With analog controls, there is also a dead zone. This means that the output value can be in this region even though the user is not touching the stick. For the Xbox controler, this is around 24%, so effectivly 24% of the controler input I had to discard as unrelyable. After that, the input must be re-scaled, because otherwise, the user will push on the stick, and it will record values up to 0.24, and then at 0.25 it will jump forward because all of the sudden the input value is 0.25, when in reality, it's just bairly above the threshhold to be useable. So I rescaled the input from 0.24 1.0 as a new value between 0.0 and 1.0 (and -1.0 and 0.0 respectivly). After this the control felt much more smooth, but that was not enough. When you want to move a little bit in a game, you will push the stick a little bit, and each milimeter counts as you try to be as precise as possible. However, when you want to go fast, you want to go FAST. So what does this mean? Well I wanted to use a function to modify the input so that if the user put a little pressure on the stick, only a VERY little movement occurred, and the movement would scale non-linearly. I tried a few different functions, and settled on X^e, which was actually the simplest function I tried. As you play Marble Blast on the Xbox you will notice that you get a very high level of precision, and the controls just feel "right". This is the reason.
Mark Frohnmayer put in a great "ramp-up" acceleration feature into the camera, and it's completely un-noticable to the user. The only way you could see it is if you saw the old camera. Basically, what happened was if you slammed the stick all the way, the camera would spin quickly and it was very disorenting. People, at first, have a tendancy to over-control things, and so a new user would spin the camera around and get scared of it. Mark's changes made it so if they did the same thing, the camera would rotate slowly at first, then ramp-up in speed. This ramp-up took less than a second, but it made a world of difference.
The Marble Blast interface went through about 3 or 4 iterations as well. We had very limited screen space with which to display all the information we needed to show. The Xbox runs, normally, at 640x480 resolution. However, there is an area of the screen which is not relyable across all televsions. The "Safe Area" is about 30 pixels in from the top and bottom, and 40 pixels in from the sides. With this safe area, our screen real-estate was cut even more. A lot of work was done to make everything as easy as possible to use, and friendly to look at while still displaying the needed information to the user. Mark also did a great job here of letting the user select levels with the analog stick in a very natural way. When the user holds down the analog stick in a direction, it will change levels, slowly at first, then again ramping up in speed. This lets them avoid having to go doink-doink-doink with the stick each time they want to change levels.
Xbox Live
The next huge task was how to make use of the Xbox Live resources we had, within the constraints of the Xarcade system. For a regular Xbox Live game, you are issued 100 Scoreboards and you can do whatever you want with them. This would have been great for Mable Blast because we have 100 levels, this way each user could be ranked based on their time. Xarcade, however, allowed us to have one scoreboard. Many, many solutions were worked out over lunch between myself, Ben Garney and Josh Williams. Ranging from the elaborate, inserting false Xbox Live users and having them store sorting data in the table. To the downright bizzare: making a long button-combination to turn an Xbox into a score server so that other users would message it to get score information. In the end, we conceded, and had rankings based on a global score which your time effected. Figuring out how many points you should get for a time on a level was another problem to which Mark Frohnmayer, Alex Swanson and I discussed a few times, before we arrived at the final implementation.
Disaster struck when we were informed that we could not make Xonline calls, but instead had to use only Xarcade calls. A Xbox Live scoreboard is a database table table with one row per user ranked, and a set number of columns. Each column can store a set amount of data. My plan was to take 50 columns, and use each one to store two high-scores for Marble Blast. After a good deal of daily phone calls and lobbying on the Xbox Live Arcade development mailing list, they extended the API so we could write raw data to 50 columns, a very convenient number.
Live Arcade Requirements
One of the requirements for Xbox Live Arcade games is that all of the data must fit inside the executable. Those of you who are familiar with the PE (Portable Executable) format which Windows uses will know what I am talking about when I say Data Sections. For those of you who aren't, a Data Section is data packed inside the executable which is not marked as executable code, you can load that data into memory. The Xbox implements this same thing, but there is a problem, which I will get to shortly. Torque, as some of you may know, supports loading resources from Zip files. So the solution to this problem seemed easy, embed zip files into the executable with sections. The problem, however, was way more complicated than this. Loading a section means that the section is placed into memory. The Xbox has 64 megs of RAM, peroid. This is shared memory with the video card as well. Marble Blast runs, in the GUI at around 40 megs on the Xbox. In order to load a resource, a 16mb zip file would have to be loaded into memory, memory would be allocated to uncompress this file (~2MB) the file would then be copied into memory. That bairly works in the GUI within 64 megs, and it would NOT work as more resources got loaded into the game. A solution had to be found, otherwise, game over.
The solution I arrived at was to use sections to store the data, that worked fine. The problem came when the data needed to be loaded into memory. So, the obvious soulution was, never load the data into memory. Clearly the Xbox had a way of knowing where in the file to look for the data to load it into memory, so there must be a way of finding the offset of the data in the executable file. After some work I found out how, and I modified the platform file I/O layer to support virtual files which were packed inside the executable, all of this was completely transparent to the resource manager and Torque in general. When the game asks for "D:\marble.zip" the file I/O layer checks a table of virtual files which it extracted from the XBE header. It will find "D:\marble.zip" mapped to a section named "TQ_ZIP1". It will then check the offset in the XBE for this area of data, and find out how long it is. It then opens its own executable and changes the file pointer to the start of "TQ_ZIP1" so that when the resource manager starts reading, it is reading the zip file, and it is none the wiser. It also stores a virtual offset in that file so that when the zip loading code seeks back and forth in the file, it thinks it is working on a regular file which starts at offset 0 and ends at the length of the file. All in all, this is the solution I am most proud of in the whole project.
Shaders
The final version of the shaders were done by Brian Ramage who is truly a god among men. As you can see from the final screenshots of the game, we have specular highlights interacting with our bump maps, which Brian implemented with a two-pass environmental-bump map. This is what the final version of the shaders looks like:
Art
The textures took a lot of work by Alex Swanson to make them look good on a TV. The display range of a TV is not 0-255 for each color, like a computer monitor. It is 16-238, all of the colors had to fit in the NTSC safe range. This meant, basically, toning down everything. This resulted in some color shifts, and so it really just took a lot of tweeking.
Fun Bugs
There were a lot of fun bugs in Marble Blast one of the more interesting ones was a file-handle leak. When Torque opens a demo recording, it would use ResourceManager->openStream to open the file stream, however, it would use the delete operator to free that stream. The Resource Manager allocates a sub-stream for zip resources, so this resulted in a file-handle leak which would crash the game after many hours of sitting on the start screen playing demos.
There were numerous memory leaks which made me very greatful for the awesome Torque memory library. The memory library in Torque is very, very useful and if you have never taken the time to examine the functionality in it, it is well worth your time. I used it to find a GPU memory leak by tracking the pointers to the vertex buffers to see which ones were not getting freed.
Performance
Mark Frohnmayer put in a lot of work on the performance of the stencil shadows. We really felt that the shadows made the game look way, way better than without them, and we really wanted to keep them in. Mark's work enabled us to run with stencil shadows on all the levels at a consistant framerate of 60fps.
Closing
Marble Blast for the Xbox was an awesome project. It was amazing to see how much time and work it took to take a finished game...and I'll say that again, a FINISHED game, and make it a finished game for a console. We learned so much about console development from this project which we plan on using in future games so that we can make the transition to console even easier. Even today, three months later, I still get a thrill from seeing my work on a TV screen. One of the people we had test the game said that the game was just so much cooler, just because it was on a TV with a controler instead of on a PC with a mouse and keyboard, and I agree.
We put a huge amount of effort into making this game shine. Jeff would come in almost daily and say, "Ship it, damn it!" and shake his head when I mentioned wanting to re-do the particles for some effect just to make it look a little bit better. The camera changes that Mark put in were in the final two weeks of development and they did wonders twords making the game more newbie-friendly. Every single GUI was analized to see if we could make it better. Every option was examined to see if we could remove it. We wanted to have the interface be as simple as possible, with as few screens as possible, and as few options as possible.
Will our work let us go to the bank? We don't know yet, but the work that Mark, Brian, Alex and myself put in to Marble Blast has already "paid off" in experience and the pride of seeing our game, the first indy game on the Xbox, have testers at Microsoft and Oberon raving about it, and we are excited to see how it will do once it is released.
About the author
#2
12/09/2004 (9:16 pm)
Simply amazing! Great writeup as well! 
#3
" All in all, this is the solution I am most proud of in the whole project."
very nice..
you are a true programmer
there is something zen about file parsing code.
12/09/2004 (10:32 pm)
congratulations guys, thanks for the post mortem Pat very informative" All in all, this is the solution I am most proud of in the whole project."
very nice..
you are a true programmer
there is something zen about file parsing code.
#4
This write-up is excellent! Between this and the other write-up on MarbleBlast's original development, we could have a great start on a nice little mini-book detailing the development of a successful indie title, offering tips and advice on how to proceed along the way. Nice job. :)
12/10/2004 (3:00 am)
Pat, it was pretty incredible how quickly you got stuff up and running on the XBox. I remember Jay teasing you every day of the project, even during the first couple weeks, saying "is it done yet?". :) And we were all always impressed with how close you were to actually being able to answer "yes". The first time all the graphics displayed properly was very beer-worthy. Then, it was great to see Mark and Brian come on to help in some key graphics and control areas. Very cool to see all you guys in action.This write-up is excellent! Between this and the other write-up on MarbleBlast's original development, we could have a great start on a nice little mini-book detailing the development of a successful indie title, offering tips and advice on how to proceed along the way. Nice job. :)
#5
12/10/2004 (3:28 am)
Great read Pat, thanks for taking the time to write that up :) 
#6
I'm extremely proud of MB on the X-Box. Everybody at GG pulled together to help make this an incredible product. It feels wonderfully polished, is lots of fun, looks great, and provides XB players with a game play they have not yet experienced. All at a fraction of the budget that a front line title uses for, oh, say pizza for the developers during their $10-20MM development.
Watching Pat grow from one of our first Associates, to a two time GG Intern, to a full-on game developer and full time GG spark plug has been a lot of fun as well. It would be hard to understand how much fun it is to work around here unless you could participate for a while. We work hard, don't make much money, but it is more fun than I have ever had in this business. Work is creative, flexible, and varied. One minute we may be debating a game or technology feature, the next we are yelling about politics, other people's games, or the world in general. Take a look at the times of these posts. Josh is 3AM, and mine is going to be around 5:06AM, and I have been here for an hour.
This stuff can be fun!
12/10/2004 (5:06 am)
Gee thanks, Pat. Makes me sound like a suit:)I'm extremely proud of MB on the X-Box. Everybody at GG pulled together to help make this an incredible product. It feels wonderfully polished, is lots of fun, looks great, and provides XB players with a game play they have not yet experienced. All at a fraction of the budget that a front line title uses for, oh, say pizza for the developers during their $10-20MM development.
Watching Pat grow from one of our first Associates, to a two time GG Intern, to a full-on game developer and full time GG spark plug has been a lot of fun as well. It would be hard to understand how much fun it is to work around here unless you could participate for a while. We work hard, don't make much money, but it is more fun than I have ever had in this business. Work is creative, flexible, and varied. One minute we may be debating a game or technology feature, the next we are yelling about politics, other people's games, or the world in general. Take a look at the times of these posts. Josh is 3AM, and mine is going to be around 5:06AM, and I have been here for an hour.
This stuff can be fun!
#7
Will we be able to buy MB for the XBox? I'd purchase a license [buy the game, whatever] right here and now, if I could...
Gary (-;
12/10/2004 (10:22 am)
I'm really impressed, that's amazing work.Will we be able to buy MB for the XBox? I'd purchase a license [buy the game, whatever] right here and now, if I could...
Gary (-;
#8
12/10/2004 (7:40 pm)
You will be able to buy Marble Blast over Xbox Live Arcade once it is released on said service.
#9
12/10/2004 (8:59 pm)
Very cool. I believe that virtual file system you came up with is the same way people are coding for the GBA. 
#10
12/12/2004 (4:31 pm)
Shame I don't own an xbox :\
#11
I was hoping to buy it for someone who doesn't have [and has made adamantly clear she does not want] xbox live.
Thanks,
Gary (-;
PS Love the "expert mode" reference.
12/13/2004 (2:18 pm)
Pat: Oh :-(I was hoping to buy it for someone who doesn't have [and has made adamantly clear she does not want] xbox live.
Thanks,
Gary (-;
PS Love the "expert mode" reference.
#12
12/13/2004 (4:31 pm)
Yeah. We wish it was in a box too, Gary, but it ain't so.
#13
12/13/2004 (8:55 pm)
Good job getting it working on the XBox, seeing you had all those hurdles to overcome. Interesting there was no mention of the TSE ? 
#14
12/15/2004 (7:01 am)
thanks for postint this pat. I been waiting a while to read this.
#15
12/16/2004 (3:41 pm)
TSE was not used for Marble Blast because we already had a version of Marble Blast working in DX 9.0, and that version of MB was actually where TSE started. 
Torque 3D Owner Jay Barnson
One of the things PC game developers don't realize about console development is that "Title Safe" area. It really mucks with your UI arrangement :) Still, if nothing else, the consoles are a heck of a lot easier to test.