Latest: adam_26sep2007.plan
Long time no update, so let me fill you in. I finished the Decrypt beta and it was fairly well received by the gamedev.net community. It is of course a very niche game, but I have had some very enthusiastic responses. I believe once I get some time to do some bug fixing and improvements and add another mission things will take off a bit more for it.
But more to the meat of what is going on now! I'm now working for local company developing a game for a major game console. It's awesome seeing the console side of game development.
Here you can see the first graphics I have got rendering on the our console with code of my own:
What you are seeing here is I have set the "clear color" to green, which is the color the graphics system resets the image buffer with. And I have drawn a polygon (quad) with a texture I stole from some demo in the SDK. I would have used my own texture but the tools to encode it in the proprietary format kept crashing :/
It's been very interesting seeing how the console was designed. I think it's quite genius.
See the Playstation3 and XBox360 went with the approach the computers have gone with. They say, computers are fast enough as a whole that we can sacrifice some processor cycles to gain some developer cycles. Essentially, make it easier and less time consuming for the developer at the cost of run time performance. It's what computers have been doing ever since the first compiler was written. And every time we go another step towards RAD (Rapid Application Development) you always have some one who cries about the lost performance, and in the end the higher level approach proves to win out.
But in this case, the console's designers has a good point. See, for old consoles like the SNES and Sega, you had to code entirely in ASM. Think back on the complexity of some of the games you played on those systems! And they had that all running on hardware that is laughable at best even for the day. Thats why consoles used to be cheap. But then newer consoles like Playstation began to use higher level languages. Now the XBox 360 uses an interpreted languages even (XNA is based on the .NET framework).
SO! (Sorry for being so long winded) MS and Sony have to pack a ton of hardware muscle into their consoles to coupe with the lose of performance and still get the jaw dropping visuals you see.
Mean while, the console's designers thinks the price of these consoles are ridiculous, and the developer should absorb the cost (in terms of development time) and develop closer to the hardware.
Thus cheaper, less powerful hardware can produce at least equal visuals.
Sure the learning curve is steep, that image I posted took 2 days of head smashing to get rendering, but it's more efficient at run time (if only slightly) then say, OpenGL, and DirectX. (That time also has to do with the fact that the documentation is in many cases not even correct. I'd go into more detail but I feel that could breach the NDA.
Any way, if you happen to be interested in console development or game development in general stay tuned, I plan on chronically this process.
- Adam
But more to the meat of what is going on now! I'm now working for local company developing a game for a major game console. It's awesome seeing the console side of game development.
Here you can see the first graphics I have got rendering on the our console with code of my own:
What you are seeing here is I have set the "clear color" to green, which is the color the graphics system resets the image buffer with. And I have drawn a polygon (quad) with a texture I stole from some demo in the SDK. I would have used my own texture but the tools to encode it in the proprietary format kept crashing :/
It's been very interesting seeing how the console was designed. I think it's quite genius.
See the Playstation3 and XBox360 went with the approach the computers have gone with. They say, computers are fast enough as a whole that we can sacrifice some processor cycles to gain some developer cycles. Essentially, make it easier and less time consuming for the developer at the cost of run time performance. It's what computers have been doing ever since the first compiler was written. And every time we go another step towards RAD (Rapid Application Development) you always have some one who cries about the lost performance, and in the end the higher level approach proves to win out.
But in this case, the console's designers has a good point. See, for old consoles like the SNES and Sega, you had to code entirely in ASM. Think back on the complexity of some of the games you played on those systems! And they had that all running on hardware that is laughable at best even for the day. Thats why consoles used to be cheap. But then newer consoles like Playstation began to use higher level languages. Now the XBox 360 uses an interpreted languages even (XNA is based on the .NET framework).
SO! (Sorry for being so long winded) MS and Sony have to pack a ton of hardware muscle into their consoles to coupe with the lose of performance and still get the jaw dropping visuals you see.
Mean while, the console's designers thinks the price of these consoles are ridiculous, and the developer should absorb the cost (in terms of development time) and develop closer to the hardware.
Thus cheaper, less powerful hardware can produce at least equal visuals.
Sure the learning curve is steep, that image I posted took 2 days of head smashing to get rendering, but it's more efficient at run time (if only slightly) then say, OpenGL, and DirectX. (That time also has to do with the fact that the documentation is in many cases not even correct. I'd go into more detail but I feel that could breach the NDA.
Any way, if you happen to be interested in console development or game development in general stay tuned, I plan on chronically this process.
- Adam
Post a Comment
.plan Archive
.plan rss
adam_23feb2010.plan
adam_25sep2009.plan
adam_03may2009.plan
adam_07may2008.plan
adam_20nov2007.plan
adam_02nov2007.plan
adam_12oct2007.plan
adam_03oct2007.plan
adam_26sep2007.plan
adam_31jul2007.plan
adam_17jul2007.plan
adam_05jul2007.plan
adam_31may2007.plan
adam_16may2007.plan
adam_01may2007.plan
adam_28apr2007.plan
adam_11apr2007.plan
adam_08apr2007.plan
adam_03apr2007.plan
adam_31mar2007.plan
adam_29mar2007.plan
adam_29mar2007.plan
adam_26mar2007.plan
adam_04mar2007.plan
adam_27feb2007.plan
adam_08feb2007.plan
adam_02feb2007.plan
adam_01feb2007.plan
adam_28jan2007.plan
adam_27jan2007.plan
adam_26jan2007.plan
adam_22jan2007.plan
adam_18jan2007.plan
adam_06jan2007.plan
adam_28dec2006.plan
adam_22dec2006.plan
adam_17dec2006.plan
adam_14dec2006.plan
adam_28nov2006.plan
adam_26nov2006.plan
adam_24nov2006.plan
adam_11nov2006.plan
adam_02nov2006.plan
adam_31oct2006.plan
adam_25oct2006.plan
adam_19oct2006.plan
adam_16oct2006.plan
adam_09oct2006.plan
adam_28sep2006.plan
adam_24sep2006.plan
adam_21sep2006.plan
adam_23feb2010.plan
adam_25sep2009.plan
adam_03may2009.plan
adam_07may2008.plan
adam_20nov2007.plan
adam_02nov2007.plan
adam_12oct2007.plan
adam_03oct2007.plan
adam_26sep2007.plan
adam_31jul2007.plan
adam_17jul2007.plan
adam_05jul2007.plan
adam_31may2007.plan
adam_16may2007.plan
adam_01may2007.plan
adam_28apr2007.plan
adam_11apr2007.plan
adam_08apr2007.plan
adam_03apr2007.plan
adam_31mar2007.plan
adam_29mar2007.plan
adam_29mar2007.plan
adam_26mar2007.plan
adam_04mar2007.plan
adam_27feb2007.plan
adam_08feb2007.plan
adam_02feb2007.plan
adam_01feb2007.plan
adam_28jan2007.plan
adam_27jan2007.plan
adam_26jan2007.plan
adam_22jan2007.plan
adam_18jan2007.plan
adam_06jan2007.plan
adam_28dec2006.plan
adam_22dec2006.plan
adam_17dec2006.plan
adam_14dec2006.plan
adam_28nov2006.plan
adam_26nov2006.plan
adam_24nov2006.plan
adam_11nov2006.plan
adam_02nov2006.plan
adam_31oct2006.plan
adam_25oct2006.plan
adam_19oct2006.plan
adam_16oct2006.plan
adam_09oct2006.plan
adam_28sep2006.plan
adam_24sep2006.plan
adam_21sep2006.plan