> When the polygon counts do get high enough, there will be no looking back.
Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way. The higher the number of polygons in a character, the more time an artist has to spend painting the skin weights and mapping the UV coords. The relationship between the number of polygons and the asset creation time is exponential. Double the poly count, and expect the modelling/uv mapping alone to take 4 or 5 times longer. The time taken for skinning and blend shape authoring is normally an even bigger time increase. The simple fact of the matter is that there are only 1 or 2 games companies on the planet that are big enough to be able to generate assets of that size. Rockstar are probably the best positioned to generate assets of this size, however if GTA4 took 5 years to produce, do you really think they'd be willing to start a GTA title that took 20 years to develop? Because that's effectively what you are assuming they are going to do.....
As GPU performance increases the one thing game developers *wont* be using it for is increased poly counts, because there are other limiting factors that you have conveniently forgotten. Let's take the example of a character made from a 1million vertex mesh (verts are a better metric than polys). We have 3 floats per vertex, 3 floats per normal, 3 floats per bi-normal, and probably 5 UV/colour sets averaging 3 floats per vertex. Then lets be a little bit restrictive and use only 4 skin weights per vertex (1 int + 1 float). All in all that adds up to 32 floats + 4 ints, or 144 bytes per vertex. That's about 137Mb for the geometry data alone. That of course assumes you don't need any padding or alignment in that data (which could increase that size by 30% or so). Add to that the indices for your 1million triangles (3 ints per tri, 12bytes) - another 11Mb or so. Now then. Lets compute our skinning deformation for each vertex. Essentially this is a weighted linear sum of transformed vectors. We have 1 million verts, each with 4 vertex weights. That means we have to transform 4 vertex positions by 4 matrices, and not forgetting that the bi-normals and normals also need to be rotated. That's a total of 12 vector transforms that need to be performed per vertex, and then the result is a weighted sum of those transformed vec3's. Having deformed your million verts, you then need to update your PVS/spatial hierarchy and *then* you can start the rendering phase. The problem with all of this is not GPU/CPU horsepower (we have it in abundance), but it's simply having enough memory available to be able to firstly store the data set, and more importantly it has to be fast enough to keep the CPU/GPUs fed with data during this process. It's that latter part that is the problem right now.
Since raytracing doesn't speed up the geometry deformation problem, it doesn't help with the biggest limiting factor which is memory bandwidth. This is one area where rasterisation wins. Since you have to access every poly anyway, why not render that triangle at the same time? The extra CPU/GPU ops required to do that are effectively free since you are providing a bit more work for the GPU to perform when it would otherwise be waiting for the next triangle to be sent to the cache. Obviously time spent shading the triangles isn't free, however modern GPU's are very good at early rejection, and if you have at least some rudimentary form of PVS and occlusion testing, the problem is largely moot imho.
At least once a month I hear this same tired argument about raytracing, and have done for over a decade now. Raytracing has never beaten reyes in the filmFX industry, and I don't see it ever winning out in the games industry either. ILM/Pixar/Dreamworks/Framestore/MPC have hundreds of thousands of compute nodes available to them, but none of them has been able to get raytracing to a point where the image quality/performance ratio beats r
After my 3rd cycle was stolen in a year, I spray painted my new bike bright pink, put spokey-dokeys on it, and attached a large rainbow flag to the back. I've now managed to keep the same bike for over a year! (Admittedly, I now get a lot of people shouting words like 'gay' and 'bender' when i cycle past. In hindsight I should have probably thought about that before welding the flagpole on.... )
It seems to me that most of the people with iPads are getting exactly the features they want or enough of the features they want that the ones they don't have don't matter.
Just wait until the specs of the iPad2 are released. Those iPad owners who are happy with their iPads now, will be gutted when they see that the iPad2 is half the size and can make phone calls....;)
Perhaps there would be better reception for all of these new OGL iterations if they saved up some worthwhile features before putting them into the spec, and just leave the new stuff as extensions until they have a nice upgrade to show.
Features like a unified way of being able to load and save compiled shader objects? Features like setting multiple viewports for rendering (thus allowing you to dynamically render the 6 faces of a cube-map in a single render pass)? Features like multiple scissor rectangles? Features like the ability to create shader dlls (of sorts via glProgramPipeline)? Features like double precision shader support?
It's one of the most sane set of features I've seen in a point release for some time.... Sure they aren't headline grabbers, but boy do us devs want them!
I suppose there is no way to make such comparison now as almost nobody writes games which can run both.
Most studios who develop for consoles can.... Once you've added DX9 / DX10 / DX11 code paths, adding GL & libGCM really isn't that hard.
Nostalgia aside, from what I've been hearing from devs who had contact with DX and then picked up OGL, OGL API seems way more elegant and easier to deal with...
GL4.1 is a lot cleaner than OpenGL before 3.2 (which was a horror!), that much is true. However DX probably still pips it in terms of API cleanliness.
opengl may be available on a lot of platforms but who cares it's not like you can port crysis from pc to an iphone in a day just because it's in opengl(I know it's not in opengl, it's just an example)
So, you install a brand new ATI/Nvidia card into your WinXP box. Want geometry shaders? Want tesselation? Want DX11 features on Vista? You're going to need to use OpenGL. The single biggest advantage that OpenGL has right now is windows support.
I'm not a game developer but I think that directx/opengl can easily be abstracted by the engine to use whatever is best on the platform it runs, something like Qt, and I think valve is doing that with the source engine right now
Correct. It's how most devs approach the problem. I for one have made a set of OpenGL classes that exactly mirror the D3D11 interface. It's really not hard to do. The only thing you have to worry about is porting shaders between HLSL/GLSL (which is actually trivial), although you can always use cg if you want an even easier life....
There are cases where OpenGL makes sense, but if your target is Windows and you want features like Tesselation, it doesn't make any sense to cripple yourself for the sake of possible ports down the road.
Get with the times lad! OpenGL 4.1 is now better featured than D3D11. Just thought you might like to know.....
FYI: Porting between one or the other API is trivial, just so long as you've wrapped the calls nicely.
AMD have been much better on the driver front than Nvidia recently. Thanks for the hard work to all the chaps at AMD i say! It's much appreciated, keep it up!
The PS3 does not use OpenGL ES directly. It has a software wrapper for openGL (psGL), however no one tends to use it because it's slower than libGCM. Same applies to the Wii. Having said that, this whole debate about which API is more portable is just a touch silly. Unlike in years gone by, there really isn't much to choose from between any of the 3D graphics API's. They all work in more or less the same way, and all have more or less the same features. Writing a platform specific wrapper really is a fairly trivial to do these days.....
They pretty much already have. Google Intel AVX - looks almost identical to the larrabee instruction set but with 256bit regs instead (with room for expansion in future). I'm assuming (possibly incorrectly) that they may in future open up the Intel graphics chips (which are now mounted on the i3/i5's) as some form of extended 512bit vector unit..... (no one really wants an Intel graphics chip for DX/OGL support, so you've got to ask why they've put them there?). It would at least go some way to solving the problem of adding multiple cores anyway.....
So it is with (stereoscopic) 3D as well - don't like it? Don't watch it - there's certainly zero -technical- reason you can't watch just the left view, just the right view, or a per-scene decision (not specced, afaik) of which view to take.
No, but there are some serious artistic reasons why you wouldn't want to do that. The left and right video streams will be skewed to one side - rather than centred on the image that the original cinematographer was looking at through his/her viewfinder. I really don't see the merit in viewing an entire film that was shot correctly using the rule of thirds, for that to become a film adhering to a rule of four fiths.
...... and the new tech still suffers from the exact same problems as the old tech, motion sickness. You are forced into focussing into a single point in the image, at a specified depth, by the director / cinematographer. Now if you can show me 3D technology that tracks the motion of my eyes, focusses the images correctly at the point where my eyes are trying to look at, then maybe, just maybe, I wont vomit on the people in front of me next time I go to the cinema to watch a 3D film.....
Havok is fairly good at throwing boxes around. It can also create ragdolls - but they are of the lifeless kind. You can also optionally buy 'Havok Behaviour' which is essentially an animation blending engine (which most games companies either have, or wish to use another middleware engine - eg morpheme). So *if* you've bought licenses to both Havok and Havok behaviour, you can animate a character, put it into a ragdoll, and to some extent blend the animation results with the results from the physics engine - but it's not great by any stretch of the imagination.
Digital Molecular Matter adds another layer over the top of Havok to provide the ability to shatter objects in the scene based on realistic material properties (i.e. glass shatters, metal will bend and tear, rubber will bounce back into shape). This stuff just isn't possible with the basic Havok package - you can get HavokFX for some particle/fluid effects, but that simply does not compare to the realism offered by DMM (and would also require a great deal of developer effort to come close to the DMM results)
Euphoria is slightly different. I guess you could refer to it as a physics engine, but that's selling the tech short imho. Basically we developed it to bridge the gap between animation engines and physics engines. One big problem when working with physics, is that it's easy to end up in situations where the character gets stuck, or is simply put into a situation where the animation engine is unable to recover. For example, the character gets knocked over, their arm gets stuck under a bus, and a fat guy ends up pining their legs to the floor. Without euphoria, the traditional way of doing things would be to play a 'standup' animation, or author numerous animations to deal with the possibility of these problems occurring. The problem here is that simply playing an animation will remove the character from the physics simulation. Depending on how you do that, the character will either end up penetrating through the bus/fat guy, or the bus and the fat guy will end up being catapulted off into the distance. Not exactly realistic!
With euphoria we've essentially inserted nervous and muscular systems into the characters which, when combined with AI, gives the character an awareness of his environment, and the ability to get himself out of those nasty situations. So using the previous example, with euphoria enabled, he'd notice the bus, attempt to free his hand first, then either wait for the fat guy to move, or attempt to struggle free before blending back into animation. There are numerous uses for the tech in game, and the vast majority are extremely subtle. For example, when a stuntman falls/rolls down a hill/stairs/whatever, he'll normally be using his ams and legs to continue that motion in an overly exaggerated way. A realistic fall would simply be a nasty looking thud, and it actually looks aesthetically 'wrong' to the average gamer (because we've become accustomed to seeing stuntmen on TV/film). Euphoria offers a nice simple way of solving this problem by making ragdolls act a lot more like stuntmen, so that the artists on a game can 'direct' how the character falls (instead of relying on physics alone)..... This video gives a nice overview of the tech.... (note: all animation data in the video is generated from euphoria only!)
So in answer to your original question, they could just use 1 engine, but by using 3 they can make their games much more interactive........
Pardon? The gameplay may not be 10,000x more complicated, but I can assure you the game engine code certainly is. Our last title required the following things just to get a character walking around:
- a quaternion based animation blending and transitioning engine (and more importantly the tools to author the animation networks)
- Inverse Kinematics, aim/orient/point constraints
- 1000's of animation takes (our last title used approx 3000 animations per character)
- A rigid body representation for the physics engine, including joint limit set ups etc.
- A way to blend and transition back and forth between animation and physics (simple ragdolls aren't good enough anymore)
- The geometry & textures need to be authored by an artist(s)
- Vertex & Pixel Shader to render the character.
- Particle systems to generate smoke near the characters feet.
- A lodding system where number of bones in a character, geometry detail, etc can by changed dynamically.
- This data needs to hook into the collision, AI, and networking systems.
All of that has to run on the PS3, which means you need to use the SPE's (and the code most be heavily vectorised to make use of the altivec instruction set). This means all of that body of work has to be split up into lots of 256Kb chunks (for both code and data) so that you can schedule them to run on the SPEs. Finally you get to the really easy bit, rendering the data. That volume of work would take a team of 10 programmers about 3 or 4 years to complete.
Now lets compare that to how you'd do that for a 2D NES/SNES/Gameboy game:
- get an artist to draw some sprites.
- blit correct sprite to screen.
That should take an experienced programmer no less than half a day to write that. Art assets are certainly increasing in complexity, but the code complexity has exploded to another level completely.
because publishers are more inclined to say "she'll be right, we can patch it after release."
All games have to go through extensive QA testing, both in house, at the publishers, and at microsoft/sony/nintendo before the game gets gold status ready for release. This process alone can take anywhere from 6 months to 3 years. Unfortunately despite game teams best efforts, we can't catch all of the bugs, so patching a game after release has become a necessity.... I can assure all game teams want to get all bugs before a game is released. If you don't, you get bad reviews, and your sales suffer....
str and ptr are word/dword/qword aligned (depending on the system). However the value of ptr addresses some memory that is not aligned. Nowt wrong with that.....
I used to work as a lecturer about 5 years ago or so. As for the first point, that was true to an extent at that time because labour had re-classified all courses by dropping them a funding bracket (losing approx £1000 to £3000 per student - co-incidentally the same amount as the top up fees they were trying to push through at the time!). You had to jump through about 10 levels of bureaucracy before you could fail someone, simply because jobs were on the line if the funding for that student was cut.
Having spoken to some of my old colleagues recently, it would appear that the situation has now reversed. Staff cuts, combined with an increased intake of students (most profitable courses have doubled intake over the last 5 years), are now forcing lecturers to trim the numbers early as an attempt to maintain course quality (by ensuring that their workload does not spiral out of control).
To be fair I only knew it from a porting project. I am not THAT old... I am young enough to remember when C was new and exciting... no we did NOT ride dinosaurs to work.
Slashdot Mirror
> The complexity of rasterisation is (very) roughly O(number of polygons * number of lights).
Doesn't deferred rendering improve that though?
> When the polygon counts do get high enough, there will be no looking back.
Academic fairy land. Polycounts will never get high enough. There is a physical limit on how many polygons a animator/modeller/rigger can actually handle in a sane way. The higher the number of polygons in a character, the more time an artist has to spend painting the skin weights and mapping the UV coords. The relationship between the number of polygons and the asset creation time is exponential. Double the poly count, and expect the modelling/uv mapping alone to take 4 or 5 times longer. The time taken for skinning and blend shape authoring is normally an even bigger time increase. The simple fact of the matter is that there are only 1 or 2 games companies on the planet that are big enough to be able to generate assets of that size. Rockstar are probably the best positioned to generate assets of this size, however if GTA4 took 5 years to produce, do you really think they'd be willing to start a GTA title that took 20 years to develop? Because that's effectively what you are assuming they are going to do.....
As GPU performance increases the one thing game developers *wont* be using it for is increased poly counts, because there are other limiting factors that you have conveniently forgotten. Let's take the example of a character made from a 1million vertex mesh (verts are a better metric than polys). We have 3 floats per vertex, 3 floats per normal, 3 floats per bi-normal, and probably 5 UV/colour sets averaging 3 floats per vertex. Then lets be a little bit restrictive and use only 4 skin weights per vertex (1 int + 1 float). All in all that adds up to 32 floats + 4 ints, or 144 bytes per vertex. That's about 137Mb for the geometry data alone. That of course assumes you don't need any padding or alignment in that data (which could increase that size by 30% or so). Add to that the indices for your 1million triangles (3 ints per tri, 12bytes) - another 11Mb or so. Now then. Lets compute our skinning deformation for each vertex. Essentially this is a weighted linear sum of transformed vectors. We have 1 million verts, each with 4 vertex weights. That means we have to transform 4 vertex positions by 4 matrices, and not forgetting that the bi-normals and normals also need to be rotated. That's a total of 12 vector transforms that need to be performed per vertex, and then the result is a weighted sum of those transformed vec3's. Having deformed your million verts, you then need to update your PVS/spatial hierarchy and *then* you can start the rendering phase. The problem with all of this is not GPU/CPU horsepower (we have it in abundance), but it's simply having enough memory available to be able to firstly store the data set, and more importantly it has to be fast enough to keep the CPU/GPUs fed with data during this process. It's that latter part that is the problem right now.
Since raytracing doesn't speed up the geometry deformation problem, it doesn't help with the biggest limiting factor which is memory bandwidth. This is one area where rasterisation wins. Since you have to access every poly anyway, why not render that triangle at the same time? The extra CPU/GPU ops required to do that are effectively free since you are providing a bit more work for the GPU to perform when it would otherwise be waiting for the next triangle to be sent to the cache. Obviously time spent shading the triangles isn't free, however modern GPU's are very good at early rejection, and if you have at least some rudimentary form of PVS and occlusion testing, the problem is largely moot imho.
At least once a month I hear this same tired argument about raytracing, and have done for over a decade now. Raytracing has never beaten reyes in the filmFX industry, and I don't see it ever winning out in the games industry either. ILM/Pixar/Dreamworks/Framestore/MPC have hundreds of thousands of compute nodes available to them, but none of them has been able to get raytracing to a point where the image quality/performance ratio beats r
Are they hosting the website on an A500?
The statue of liberty....
After my 3rd cycle was stolen in a year, I spray painted my new bike bright pink, put spokey-dokeys on it, and attached a large rainbow flag to the back. I've now managed to keep the same bike for over a year! (Admittedly, I now get a lot of people shouting words like 'gay' and 'bender' when i cycle past. In hindsight I should have probably thought about that before welding the flagpole on.... )
Yeah sorry for that, I promise to keep the discussion factual from now on.....
Every time you lock a D3D11VertexBuffer, Steve Bullmer drowns a kitten! Use OpenGL, the only 3D graphics API recommended by Peta!
It seems to me that most of the people with iPads are getting exactly the features they want or enough of the features they want that the ones they don't have don't matter.
Just wait until the specs of the iPad2 are released. Those iPad owners who are happy with their iPads now, will be gutted when they see that the iPad2 is half the size and can make phone calls.... ;)
Perhaps there would be better reception for all of these new OGL iterations if they saved up some worthwhile features before putting them into the spec, and just leave the new stuff as extensions until they have a nice upgrade to show.
Features like a unified way of being able to load and save compiled shader objects? Features like setting multiple viewports for rendering (thus allowing you to dynamically render the 6 faces of a cube-map in a single render pass)? Features like multiple scissor rectangles? Features like the ability to create shader dlls (of sorts via glProgramPipeline)? Features like double precision shader support?
It's one of the most sane set of features I've seen in a point release for some time.... Sure they aren't headline grabbers, but boy do us devs want them!
I suppose there is no way to make such comparison now as almost nobody writes games which can run both.
Most studios who develop for consoles can.... Once you've added DX9 / DX10 / DX11 code paths, adding GL & libGCM really isn't that hard.
Nostalgia aside, from what I've been hearing from devs who had contact with DX and then picked up OGL, OGL API seems way more elegant and easier to deal with...
GL4.1 is a lot cleaner than OpenGL before 3.2 (which was a horror!), that much is true. However DX probably still pips it in terms of API cleanliness.
opengl may be available on a lot of platforms but who cares it's not like you can port crysis from pc to an iphone in a day just because it's in opengl(I know it's not in opengl, it's just an example)
So, you install a brand new ATI/Nvidia card into your WinXP box. Want geometry shaders? Want tesselation? Want DX11 features on Vista? You're going to need to use OpenGL. The single biggest advantage that OpenGL has right now is windows support.
I'm not a game developer but I think that directx/opengl can easily be abstracted by the engine to use whatever is best on the platform it runs, something like Qt, and I think valve is doing that with the source engine right now
Correct. It's how most devs approach the problem. I for one have made a set of OpenGL classes that exactly mirror the D3D11 interface. It's really not hard to do. The only thing you have to worry about is porting shaders between HLSL/GLSL (which is actually trivial), although you can always use cg if you want an even easier life....
There are cases where OpenGL makes sense, but if your target is Windows and you want features like Tesselation, it doesn't make any sense to cripple yourself for the sake of possible ports down the road.
Get with the times lad! OpenGL 4.1 is now better featured than D3D11. Just thought you might like to know .....
FYI: Porting between one or the other API is trivial, just so long as you've wrapped the calls nicely.
AMD have been much better on the driver front than Nvidia recently. Thanks for the hard work to all the chaps at AMD i say! It's much appreciated, keep it up!
The PS3 does not use OpenGL ES directly. It has a software wrapper for openGL (psGL), however no one tends to use it because it's slower than libGCM. Same applies to the Wii.
Having said that, this whole debate about which API is more portable is just a touch silly. Unlike in years gone by, there really isn't much to choose from between any of the 3D graphics API's. They all work in more or less the same way, and all have more or less the same features. Writing a platform specific wrapper really is a fairly trivial to do these days.....
They pretty much already have. Google Intel AVX - looks almost identical to the larrabee instruction set but with 256bit regs instead (with room for expansion in future). I'm assuming (possibly incorrectly) that they may in future open up the Intel graphics chips (which are now mounted on the i3/i5's) as some form of extended 512bit vector unit..... (no one really wants an Intel graphics chip for DX/OGL support, so you've got to ask why they've put them there?). It would at least go some way to solving the problem of adding multiple cores anyway.....
So it is with (stereoscopic) 3D as well - don't like it? Don't watch it - there's certainly zero -technical- reason you can't watch just the left view, just the right view, or a per-scene decision (not specced, afaik) of which view to take.
No, but there are some serious artistic reasons why you wouldn't want to do that. The left and right video streams will be skewed to one side - rather than centred on the image that the original cinematographer was looking at through his/her viewfinder. I really don't see the merit in viewing an entire film that was shot correctly using the rule of thirds, for that to become a film adhering to a rule of four fiths.
...... and the new tech still suffers from the exact same problems as the old tech, motion sickness. You are forced into focussing into a single point in the image, at a specified depth, by the director / cinematographer. Now if you can show me 3D technology that tracks the motion of my eyes, focusses the images correctly at the point where my eyes are trying to look at, then maybe, just maybe, I wont vomit on the people in front of me next time I go to the cinema to watch a 3D film.....
The bigger question is: why in the future, do all people insist on shipping goods using packing technology from the 1800's..... ?
Havok is fairly good at throwing boxes around. It can also create ragdolls - but they are of the lifeless kind. You can also optionally buy 'Havok Behaviour' which is essentially an animation blending engine (which most games companies either have, or wish to use another middleware engine - eg morpheme). So *if* you've bought licenses to both Havok and Havok behaviour, you can animate a character, put it into a ragdoll, and to some extent blend the animation results with the results from the physics engine - but it's not great by any stretch of the imagination.
Digital Molecular Matter adds another layer over the top of Havok to provide the ability to shatter objects in the scene based on realistic material properties (i.e. glass shatters, metal will bend and tear, rubber will bounce back into shape). This stuff just isn't possible with the basic Havok package - you can get HavokFX for some particle/fluid effects, but that simply does not compare to the realism offered by DMM (and would also require a great deal of developer effort to come close to the DMM results)
Euphoria is slightly different. I guess you could refer to it as a physics engine, but that's selling the tech short imho. Basically we developed it to bridge the gap between animation engines and physics engines. One big problem when working with physics, is that it's easy to end up in situations where the character gets stuck, or is simply put into a situation where the animation engine is unable to recover. For example, the character gets knocked over, their arm gets stuck under a bus, and a fat guy ends up pining their legs to the floor. Without euphoria, the traditional way of doing things would be to play a 'standup' animation, or author numerous animations to deal with the possibility of these problems occurring. The problem here is that simply playing an animation will remove the character from the physics simulation. Depending on how you do that, the character will either end up penetrating through the bus/fat guy, or the bus and the fat guy will end up being catapulted off into the distance. Not exactly realistic!
With euphoria we've essentially inserted nervous and muscular systems into the characters which, when combined with AI, gives the character an awareness of his environment, and the ability to get himself out of those nasty situations. So using the previous example, with euphoria enabled, he'd notice the bus, attempt to free his hand first, then either wait for the fat guy to move, or attempt to struggle free before blending back into animation. There are numerous uses for the tech in game, and the vast majority are extremely subtle. For example, when a stuntman falls/rolls down a hill/stairs/whatever, he'll normally be using his ams and legs to continue that motion in an overly exaggerated way. A realistic fall would simply be a nasty looking thud, and it actually looks aesthetically 'wrong' to the average gamer (because we've become accustomed to seeing stuntmen on TV/film). Euphoria offers a nice simple way of solving this problem by making ragdolls act a lot more like stuntmen, so that the artists on a game can 'direct' how the character falls (instead of relying on physics alone)..... This video gives a nice overview of the tech.... (note: all animation data in the video is generated from euphoria only!)
So in answer to your original question, they could just use 1 engine, but by using 3 they can make their games much more interactive........
Yeah, I admit, a little before my time... (I'd have been a spotty teenager writing crappy code on an amiga back then)..... ;)
- a quaternion based animation blending and transitioning engine (and more importantly the tools to author the animation networks)
- Inverse Kinematics, aim/orient/point constraints
- 1000's of animation takes (our last title used approx 3000 animations per character)
- A rigid body representation for the physics engine, including joint limit set ups etc.
- A way to blend and transition back and forth between animation and physics (simple ragdolls aren't good enough anymore)
- The geometry & textures need to be authored by an artist(s)
- Vertex & Pixel Shader to render the character.
- Particle systems to generate smoke near the characters feet.
- A lodding system where number of bones in a character, geometry detail, etc can by changed dynamically.
- This data needs to hook into the collision, AI, and networking systems.
All of that has to run on the PS3, which means you need to use the SPE's (and the code most be heavily vectorised to make use of the altivec instruction set). This means all of that body of work has to be split up into lots of 256Kb chunks (for both code and data) so that you can schedule them to run on the SPEs. Finally you get to the really easy bit, rendering the data. That volume of work would take a team of 10 programmers about 3 or 4 years to complete.
Now lets compare that to how you'd do that for a 2D NES/SNES/Gameboy game:
- get an artist to draw some sprites.
- blit correct sprite to screen.
That should take an experienced programmer no less than half a day to write that. Art assets are certainly increasing in complexity, but the code complexity has exploded to another level completely.
because publishers are more inclined to say "she'll be right, we can patch it after release."
All games have to go through extensive QA testing, both in house, at the publishers, and at microsoft/sony/nintendo before the game gets gold status ready for release. This process alone can take anywhere from 6 months to 3 years. Unfortunately despite game teams best efforts, we can't catch all of the bugs, so patching a game after release has become a necessity.... I can assure all game teams want to get all bugs before a game is released. If you don't, you get bad reviews, and your sales suffer....
And another post from someone who doesn't understand pointers...... The pointer is aligned. The address isn't.
Sorry for being a pedant, but they are aligned......
const char* str = "some string";
const char* ptr = str + 1;
str and ptr are word/dword/qword aligned (depending on the system). However the value of ptr addresses some memory that is not aligned. Nowt wrong with that.....
I studied a batchelor of arts in animation. I was taught more about programming than the CS guys were....
I used to work as a lecturer about 5 years ago or so. As for the first point, that was true to an extent at that time because labour had re-classified all courses by dropping them a funding bracket (losing approx £1000 to £3000 per student - co-incidentally the same amount as the top up fees they were trying to push through at the time!). You had to jump through about 10 levels of bureaucracy before you could fail someone, simply because jobs were on the line if the funding for that student was cut.
Having spoken to some of my old colleagues recently, it would appear that the situation has now reversed. Staff cuts, combined with an increased intake of students (most profitable courses have doubled intake over the last 5 years), are now forcing lecturers to trim the numbers early as an attempt to maintain course quality (by ensuring that their workload does not spiral out of control).
To be fair I only knew it from a porting project. I am not THAT old... I am young enough to remember when C was new and exciting... no we did NOT ride dinosaurs to work.
:p
a Model-T Ford?