...and you wonder why the majority of professional engineering organizations have no wish of being associated with software developers, or having software engineering as a recognized engineering field.
Quite a few states and provinces, as well as countries, require all professional engineers to be licenced to provide a minimum level of competence and to avoid unprofessional conduct.
In software there is the luxury of solving some problems via this trial and error practice since the typical cost of failure is low. At times the cost of simply trying a possible solution without validation is lower than not; then using trial and error is acceptable. Except for the most rudamentary of tasks, this is usually not the case -- in software development or otherwise.
There is a large difference between live flight tests in aeronautics versus pure software test cases. There are people's lives at stake in the case of flight tests, regardless of whether the vehicle is manned or not. It is not acceptable to have such a cavelier attitude towards developing systems that can put lives at risk.
Taking the attitude that development is a simple cycle of repetitive tests with incremental improvements is flippant at best. There are costs associated with each failure, and engineers have a professional as well as moral obligation to keep these costs at a minimum.
Our ability to create aeronautic vehicles has improved beyond simply having to try an idea to see whether it works. Writing a off catastrophic rocket failure as just another test cycle is reckless at best, incompetent and a malice act at worst.
Not India, but most certain South Korea. Quite a great deal of Japanese animation is done in Korea; though many North Americans would like to think that anime is strictly from Japan. High profile projects such as Macross Zero, Naruto, amongst many others have benefit from foreign collaborations.
In fact, many of the smaller animation studios must look for partners internationally due to limited local resources, lack of funding, tight schedules, and a host of other issues.
Even the high budget North American fare uses animation studios in Korea; as many already know, the Simpson's is animated in South Korea.
On the subject of iPod: I agree that the Toshiba 1.8" hard drives are more expensive than the typical laptop hard drives that competitors with similar storage capacities typically use, but I question whether you actually are basing your argument on information availible to you, or simply guessing.
The Toshiba 1.8" drives used in iPods are not availible to consumers as far as I know. I have only seen them availible on a direct to manufacturer basis. Subsequently, how did you come about the prices for those particular drives, and if you do have the prices, what are they?
Also, the Toshiba 1.8" drives are used to some, granted very few, iPod competitors.
On iPod Mini: The IBM Microdrives found in iPod minis are found in several non-Apple portable music players -- some that are similar in weight, though larger than the iPod mini (I would randomly guess that would be due to the use of larger Li-ion cells).
I would cite the Nomad MuVo 4.0GB device as an example. It's lighter than an iPod mini, smaller than an iPod, with longer playtime on a single charge, using exactly the same hard drive, and does have a decent interface -- all for significantly less than an iPod mini.
I stand by all my points; though I'll only address the mathematical point: The proof you indicated is a proof of triangulation. Triangulation only applies to closed 2D polygons. We're dealing with 3-space polygons who's cartesian projection does not always form a polygon or set of polygons. Subsequently the statement inquestion is indeed false.
On the subject of triangulation, there are many finite polygons who's triangulation requires an infinite number of triangles to construct. Subsequently, realtime 3D polygon based applications restrict what polygons can be presented and often incorporate failure cases.
The point is that treatments of mathematical subjects, including computer graphics and the article in question, should be presented with at least a minimal degree of rigor. I wouldn't expect proofs, but I do expect at least accurate and fairly precise statements.
Gamecube has fixed-function configurable shaders, which are the precursor to modern programmable shaders.
You are correct in that the shaders do operate both per a vertex, and per a pixel, but the original parent is entirely correct -- these are non-programmable.
"Most 3D objects are made from triangles. A triangle is given by three points in space. If they are modeled as polygons, by the time they are drawn on the screen (rasterised)..."
Rasterization is the process by which an aribtrary mathematical representation is converted into a raster image (an image composed of a grid of orthogonal display elements). Rasterization is not when something is drawn on the screen....then they are split into triangles for simpler rendering (Due to the mathematics that states that any polygon can be formed by multiple triangles)."
Complex representations of three dimentional objects are not split into triangles for simpler rendering, they are split into triangles because it allowed for faster rendering.
There is no statement in mathematics that claims any polygon can be formed by multiple triangles. Furthmore, this claim is false.
"The whole process of rendering takes each triangle in 3D world space, and projects them onto the screen as 2D triangles."
This claim is false. If you are projecting three space triangles onto a cartesian plane, they do not necessarily become triangles. Lines, points, and nothing at all are not triangles.
"The most basic method of lighting is simply giving each triangle a flat colour, and by no coincidence at all, this is called Flat Shading."
This is not lighting -- it is called shading. The process of selecting the actual colour of the polygon would be considered a rudamentary lighting model, not simply the assignment of a colour. Again, shading and lighting are independant.
"Cel shading techniques can make use of the fast rendering speed to save some processing power for the pencil outlines, so it's still a relevant shading method. I, Robot was one of the first games to take advantage of this technology."
As before, the ambiguity of the last statement is enjoyable -- "I, Robot" was one of the first games to use 3D polygonal representations. It was not one of the first games to use flat shading, nor cell shading (given that it does not use cell shading).
"The next shading technique, which was common in the later days of the PlayStation, is named Gouraud Shading:..."
Gouraud shading was first presented by Henri Gouraud in 1971 and has been common in games well before PlayStation.
"...by working out the colour at each vertex, and interpolating this colour between the vertices across the triangle whilst rendering, it will give an approximate idea of how the triangle should be shaded."
Gouraud shading takes the averaged surface normals at each vertex and performs a lighting computation (originally a Lambertian diffuse calculation) upon them. The resulting vertex colours are then interpolated along the edges of triangle, then the triangle is filled by interpolating between each set of edge pixels per a scanline.
"Unfortunately, because the colours are worked out at the corners and mixed across, shadows in the middle of the triangle will be completely missed."
The production of shadows has nothing to do with Gouraud shading, or shading at all.
"Also, when using large triangles, the effect can seem quite unnatural, and it's especially noticeable in Metroid Prime when moving around in Morph Ball mode."
The problem with Gouraud shading is that it restrict light sampling to vertices taken from the world geometry. The accuracy of the shading is then directly proportional to the vertex density of the world geometry. It also performs poorly at oblique junctions. Another issue is the Gouraud shading is not perspective correct.
"Games such as Silent Hill 2, however nice the shadow generation is, still only use this basic shading model, and it's very noticeable with the 'squares' since the light hits the vertices (corners) in turn, the light tends not to spread slowly across the triangles."
Writing cross platform code doesn't quite work like that, even with a library available for all the platforms you are targetting.
I thought I made it abundantly clear that XNA and reference implementations are entirely different issues and do not at all equate. XNA is simply an SDK of sort taking care of common tasks and providing a solid base to reduce development time. Reference designs are a different issue which Allard also discussed in the article.
If you are refering to my points on reference designs, rather than misconstruing my contents on XNA being a reference design, the whole point of most reference designs is that they are not cross-platform at all -- look up the definition of and historical use of reference designs in the computer industry as a whole. Most reference design implementations of standards are created so that others can simply clone most of the system to create virtually identical implementations. Otherwise why bother with a reference implementation when you could simply provide the specifications and hope for the best?
Even if MS did provide a royalty-free, IETF or ISO-standardised spec and provided base libraries across all the platforms you are interested (and wake me up if that ever happens!) you are still facing time spent moving your current project to a new platform.
Again, I do not disagree at all, and think I was rather clear that most reference implementations are not meant to simply provide base libraries and cross platform systems to support an entirely different platform, but rather to provide a complete platform itself. If you are refering to a reference design that is not created for this purpose, then it really has nothing to do with the topic at hand since the article very direction indicates this is the type of future they are looking at.
Cross platform is more than just a buzzword - you really need to think ahead with your data structures, your communication mechanisms between threads/processes and your approach to designing the whole project early in the design so you don't get screwed over by changes in pointer sizes as you switch from 32 bit to 64 bit platforms or changes in endian-ness as you port from x86 to PowerPC.
Since when did do you change fundamental processor architecture when you buy a reference implementation and the supporting systems? Do you honestly think that someone purchases ARM core designs and reference implementations so that they they can change the architecture and instruction set so much as they would be incompatible? At most you'll see licencees extending the instruction set, but otherwise there will only be small changes like modifying the trace cache, optimizing i-RAM access times, or reducing power consumption.
On the subject of really needing to think to create crossplatform code, what exactly do you believe developers are being paid for? Not thinking? Cross platform development is just another problem to be confronted.
The problem a lot of developers for Windows platforms have is that they do not have to think about multi-platform portability because essentially every Windows platform they are likely to run on looks like x86. At least open source developers who post their sources on Sourceforge are likely, sooner or later, to have a PowerPC owner try and compile the sources and send the developer a problem report, so if they haven't considered portability right at the start, they stand some chance of being exposed to another platform earlier in development before a lot of code is set in stone.
What does this have to do with anything? I guess I'll contribute some random irrelavent information as well:
I have written commercial non-open source code which had to compile with three different compilers, operates on two entirely different 32-bit architectures and one 16-bit variant, with two operating systems (of which one is indeed Windows), and was highly performance critical as well.
Does this have anything at all to do with the discussion at hand? No.
This has very little to do with porting games at all -- XNA doesn't particularly make it much easier to port a game to a different platform. The author of the article on Eurogamer makes some far fetched comments to that effect; which seems to indicate he has no idea what development is like, or what XNA will really provide.
The whole point of XNA is provide a solid common library, which focuses on common game development tasks. This allows different platforms to very easily interoperate, but does not make it significantly easier to port games to other platforms. For instance, making a set of games that share the same game world and are all Live aware becomes quite simple, but porting a Xbox version of that same game to PC does not suddenly become a simple task.
I don't see how people are jumping to the conlusion that providing XNA and reference designs is economically infeasible. Certainly Microsoft would like to create a reference design platform in the future. Yes, Microsoft thinks this can start with with XNA. Yes, it's a good idea.
The whole pointing in having a reference design is to increase interoperability, reduce development time, and reduce development cost. If another company makes a device using a reference design, it won't take your suggested 3 months to port a game to run on this new device -- it will take zero months, zero weeks, zero days, zero hours... no time at all since it will run on that device immediately.
You don't have to rewrite anything in a PC game to have your game run a different manufacturer of GeForce 4 cards -- it works on the reference design boards, it works on Asus boards, it works on Hercules Guillemot boards, and it works on everyother board based on the NVIDIA reference design. Does this fact suddenly make NVIDIA foolish for abandoning their board manufacturing business in favour of performing just the design tasks and chip fabrication? ATI seems to be following a similar plan these days as well -- platform and reference design work.
If Bob decides to buy and use a reference design for MasterBlasterSuperConsole, he's essentially creating a MasterBlasterSuperConsole -- not another platform. Say the original MasterBlasterSuperConsole designers still sell their version of the MasterBlasterSuperConsole and everyone likes Bob's MasterBlasterSuperConsole better. The consumers proceed to buy more of Bob's than the original by a large margin. Are the designers of the original sitting on the street crying? No, they're taking in a killing from Bob's MasterBlasterSuperConsole since he has to pay the original designers a very significant percentage of his profits to them. Is Bob upset? Not really, he didn't have to design much -- just copy the reference design and add a few tweaks here and there.
There are a lot of companies that operate in this fashion -- ARM in one of the largest microprocessor developers in the world without even selling microprocessors. IBM also licences out it's microprocessor designs to other companies (the Power architecture seen in PowerPC, amongst others, is a good example). Ericsson isn't loosing any sleep from becoming increasingly a design house, providing specifications and reference designs to companies that specialize in mass production. There has literally thousands of companies that do business in this very fashion with great success.
Microsoft and Sony have been doing this for decades in various different industries -- it's one of the reasons they have been so exceptionally successful. I wholely agree with Allard, it's just a matter of when this will happen.
The Fedora Core 2 schedule release schedule indicates that this the final Core 2 release.
The core was supposed to be released for mirrors on the morning of May 14th, then the open release will be announced on May 18th. Presumably there should be sufficient mirrors to manage to the load by then.
I'm am Jack's complete lack of surprise. Really, who didn't see this coming? Most online games have been heading in this direction for quite awhile now, with several game development studios working on similar solutions (Valve's Steam, Microsoft's Xbox Live Tsunami, etc).
I find it more surprising that no MSN Messenger integration occured in the initial offering of Xbox Live. Furthermore, it wasn't surprising, but somewhat disapointing that Xbox Live communication was performed on a per a game basis -- thus support varies per a game, while some games have no Xbox Live communications at all. I'm certain it alleviated a lot of software maintenance and OS deployment issues for Microsoft, but it has some obvious disadvantages.
So what does this have to do with AOL's integration of IM with the Matrix Online? Well, I predict AOL's IM integration into the Matrix Online: the IM clients will be standalone applications. For example, when you launch the Matrix Online, it will force your current IM client offline then launch it's own custom IM stack. I have a hard time believing AOL has a nice clean portable IM stack, which they can simply throw over to Monolith Productions, or an IM service in the works.
The more likely scenario is that they are making a slightly customized version of their IM stack, which places AOL in the interesting position of maintaining two stacks. Or, more likely, in maintaining their current IM client and occationally doing updates to Monolith's IM stack... until it slips their minds.
I think it's fairly safe to say that NWN2 and BG3 are not in the works at this time, which means we won't see these titles for quite a long time if they ever appear....
Georg Zoeller, Designer, Bioware: "Combined with the fact that we are indeed not going to reveal NWN 2 on E3 (because we are not working on a sequel to NWN), and the other incorrect/badly researched "news" I found on this site ("Bioware is secretly working on BG3", "Bioware releases free community expansion pack", "Bioware announced they work on three original titles, NWN2?") it is pretty safe to say that you can disregard this newspost. I don't know what Trent really said, but whatever it was, it was almost certainly mangled up very badly in translation.
So again, we are not working on NWN2 and we are not working on another expansion pack for NWN, through we are working on other things to support NWN in the future (see Witch's Wake forum for details)."
Stanley Woo, QA, Bioware: "Since we currently have no plans to make an NWN2, it would be highly unlikely that Trent would be talking about it at E3. This has been discussed on the HotU board as well, with the explanation being that the translation is incorrect. There has also been mention of GameStar being, perhaps, an unreliable source of accurate information."
Until the early to mid 1990s, Cobol was the most used programming language for over 30 years. I didn't actually realize this was the case until it was pointed out by Al Aho during a guest lecture. Interestingly enough, the current predominant language, based upon number of users, is Visual Basic; not C or C++, not Java... Visual Basic. A good deal of scientific computing is still done with Fortran 90/95.
On the subject of Windows NT, the Windows 2000/XP executive and microkernel architecture is fundamentally identical as in NT4.0. Where else have you seen this executive and microkernel archtiecture? Xbox for one, and soon on a PowerPC platform (or rather again since Microsoft did have a build of NT for PowerPC awhile back). Like it or not, NT4.0 is highly successful modern OS, which lives on to this day.
Ummm... those two articles you're linking to are in reference to previous developments around a month ago, not the current event, which is what loftydog was referring to.
Since when was Valve or the Half-Life property average? Scott Miller from 3D Realms said, "The highest royalty 3D Realms has executed is 70%, for a project in which we owned the license, and self-funded." Let's stop and think about for a second -- 70%.
You don't need to sell nearly 4,000,000 copies to recoup $40,000,000 US if you have decent royalties, along with engine licencees.
The Source engine currently has one known licencee, which has a game scheduled for release at the end of this year: Troika Games with Vampire: The Masquerade - Bloodlines.
Given the media released to date, Troika seems quite far into the development cycle -- which is rather siginficant given that Troika started work on the game with the Source engine in December of 2001. So, if there was delays and stalling, it wouldn't be because they didn't have something to give this other company you heard about (unless that company asked for the Source engine far more than 2 years before it was launched) -- it would because they didn't want to give that company.
"Granted, they were a really small company, so maybe they didnt look interresting, but it would have been the same cash in the end, right?"
I think that is rather significant. If I were Valve, I would want all the initial licencees to have reasonably high quality products -- or better still, high quality products that are high profile. A smaller development house might be able to muster enough for the engine, but can it deliver a product that Valve can trust to showcase the engine?
On another note, are you sure that this really small company could actually meet the price tag Valve wished? The Unreal Warefare engine runs at $750,000 US with an additional $100,000 US for each additional platform, or $350,000 US with an additional $50,000 US for each additional platform plus 3% royalties. Quake II's engine reportedly costed between $400,000 US plus 10% royalties, to a hefty $1,000,000 US. Even the aging Quake engine, which is now operating under the GPL, has a $10,000 US price tag if you wish to not operate under the GPL. All these fees are non-recoupable.
Given the development cost of the Source engine, I wouldn't at all be surprised if it cost more than the Unreal Warfare engine.
From the FAQ: What will combat be like? Combat will be intense and spectacular, with over 300 animations for each martial art and weapons style.
Read it again -- the FAQ states that the game has "over 300 animations for each martial art and weapons style" which seems impressive. However, consider all the annimations that will simply be variations, idle animations, basic movement, and that number sounds a lot less impressive.
Prince of Persia used over 700 animations just for the Prince's very small set of moves. 300 animations does not at all equate to a large variety of motion.
Xbox Live games and the Xbox Live dashboard both use the Live API, of which the VoIP audio codecs have not significantly changed. The Live API VoIP framework has been rolled into the XDK for a long time now. Subsequently the implementations of VoIP are virtually identical between Xbox games as well as the Xbox Live dashboard.
What differences do occur, are usually in the networking code and initial VoIP settings. It's upto the developer to decide the compression window size for voice data, and how to deal with the VDP stream. Subsequently, voice performance will differ somewhat based upon processor usage, the bandwidth requirements of the game, and the applications network stack. However, they all use the same VoIP audio codecs, engine and protocols.
The point being that the difference in voice quality are due to the specific applications requirements, and not the implementation (unless the developers can't even use the voice framework correctly -- which I find very hard to believe). If bandwidth and processor resources are abundant, you can simply increase the granularity of the voice compression window and almost magically you have better voice quality.
The corrollary of all this is that there is no mess to fix. Any voice quality variance is due to very intentional decisions on how to use the provided VoIP framwork, or variance introduced by the network environment itself.
Antidotally, I haven't particularly had any problems with voice quality while using dashboard in comparison to that in games. I find both to be acceptable at best, which is to say about the same as most other VoIP applications used over a home connection.
I would hope the intention would be to finally integrate MSN Messenger functionality into Xbox live allowing users to communicate seamlessly between the desktop environment (via MSN Messenger's VoIP capabilities) and Xbox Live. Voicemail would be kind of nice too I suppose.
Most game developers, and a host of non-game developers, have been thinking about better communication integration for quite sometime now. The utility of communication services is directly proportionate with the number of users. Subsequently, it makes a lot of sense to try to increase your user base. Similar efforts have been made in Valve's Steam, and if you want a far older example look at how wireless text messaging systems have evolved -- communicating between wireless phones, landline phones, and desktop computers may not be ubiquitous, but it's certain availible.
It sounds terrible in comparison to chatting in a game! Voices are heard gurgled and staticky even with a first party microphone (for those who don't go on XBox Live, most third party microphones are horrible). I hope that this time around the new features are better.
Xbox Live uses the same VoIP system via dashboard as it does in game. Microsoft purchased the Waterloo based Shadow Factor in 1999 to integrate their VoIP technology into DirectX as well as other MS products. You now see the same technology in DirectX, MSN Messenger, and Xbox Live.
Then, how about adding some card games or board games for the people to play while chatting?
As strange at idea kind of sounds, MS has signed a recent deal with the makers of the Catan series of game for the creation of electronic versions. I somewhat doubt it'll make it's way onto Xbox given the target demographic, but you never know.
Slashdot Mirror
...and you wonder why the majority of professional engineering organizations have no wish of being associated with software developers, or having software engineering as a recognized engineering field.
Quite a few states and provinces, as well as countries, require all professional engineers to be licenced to provide a minimum level of competence and to avoid unprofessional conduct.
In software there is the luxury of solving some problems via this trial and error practice since the typical cost of failure is low. At times the cost of simply trying a possible solution without validation is lower than not; then using trial and error is acceptable. Except for the most rudamentary of tasks, this is usually not the case -- in software development or otherwise.
There is a large difference between live flight tests in aeronautics versus pure software test cases. There are people's lives at stake in the case of flight tests, regardless of whether the vehicle is manned or not. It is not acceptable to have such a cavelier attitude towards developing systems that can put lives at risk.
Taking the attitude that development is a simple cycle of repetitive tests with incremental improvements is flippant at best. There are costs associated with each failure, and engineers have a professional as well as moral obligation to keep these costs at a minimum.
Our ability to create aeronautic vehicles has improved beyond simply having to try an idea to see whether it works. Writing a off catastrophic rocket failure as just another test cycle is reckless at best, incompetent and a malice act at worst.
Not India, but most certain South Korea. Quite a great deal of Japanese animation is done in Korea; though many North Americans would like to think that anime is strictly from Japan. High profile projects such as Macross Zero, Naruto, amongst many others have benefit from foreign collaborations.
In fact, many of the smaller animation studios must look for partners internationally due to limited local resources, lack of funding, tight schedules, and a host of other issues.
Even the high budget North American fare uses animation studios in Korea; as many already know, the Simpson's is animated in South Korea.
Or, it could have been there since November 7th, 2003 like they stated. Mac OS has had WMP releases before WMP 9, and Mac OS X, as well.
I live in Canada -- $50 US will buy you a small spacefaring vessel here.
On the subject of iPod:
I agree that the Toshiba 1.8" hard drives are more expensive than the typical laptop hard drives that competitors with similar storage capacities typically use, but I question whether you actually are basing your argument on information availible to you, or simply guessing.
The Toshiba 1.8" drives used in iPods are not availible to consumers as far as I know. I have only seen them availible on a direct to manufacturer basis. Subsequently, how did you come about the prices for those particular drives, and if you do have the prices, what are they?
Also, the Toshiba 1.8" drives are used to some, granted very few, iPod competitors.
On iPod Mini:
The IBM Microdrives found in iPod minis are found in several non-Apple portable music players -- some that are similar in weight, though larger than the iPod mini (I would randomly guess that would be due to the use of larger Li-ion cells).
I would cite the Nomad MuVo 4.0GB device as an example. It's lighter than an iPod mini, smaller than an iPod, with longer playtime on a single charge, using exactly the same hard drive, and does have a decent interface -- all for significantly less than an iPod mini.
I stand by all my points; though I'll only address the mathematical point:
The proof you indicated is a proof of triangulation. Triangulation only applies to closed 2D polygons. We're dealing with 3-space polygons who's cartesian projection does not always form a polygon or set of polygons. Subsequently the statement inquestion is indeed false.
On the subject of triangulation, there are many finite polygons who's triangulation requires an infinite number of triangles to construct. Subsequently, realtime 3D polygon based applications restrict what polygons can be presented and often incorporate failure cases.
The point is that treatments of mathematical subjects, including computer graphics and the article in question, should be presented with at least a minimal degree of rigor. I wouldn't expect proofs, but I do expect at least accurate and fairly precise statements.
Gamecube has fixed-function configurable shaders, which are the precursor to modern programmable shaders.
You are correct in that the shaders do operate both per a vertex, and per a pixel, but the original parent is entirely correct -- these are non-programmable.
Good article? It's terrible:
...then they are split into triangles for simpler rendering (Due to the mathematics that states that any polygon can be formed by multiple triangles)."
"Most 3D objects are made from triangles. A triangle is given by three points in space. If they are modeled as polygons, by the time they are drawn on the screen (rasterised)..."
Rasterization is the process by which an aribtrary mathematical representation is converted into a raster image (an image composed of a grid of orthogonal display elements). Rasterization is not when something is drawn on the screen.
Complex representations of three dimentional objects are not split into triangles for simpler rendering, they are split into triangles because it allowed for faster rendering.
There is no statement in mathematics that claims any polygon can be formed by multiple triangles. Furthmore, this claim is false.
"The whole process of rendering takes each triangle in 3D world space, and projects them onto the screen as 2D triangles."
This claim is false. If you are projecting three space triangles onto a cartesian plane, they do not necessarily become triangles. Lines, points, and nothing at all are not triangles.
"The most basic method of lighting is simply giving each triangle a flat colour, and by no coincidence at all, this is called Flat Shading."
This is not lighting -- it is called shading. The process of selecting the actual colour of the polygon would be considered a rudamentary lighting model, not simply the assignment of a colour. Again, shading and lighting are independant.
"Cel shading techniques can make use of the fast rendering speed to save some processing power for the pencil outlines, so it's still a relevant shading method. I, Robot was one of the first games to take advantage of this technology."
As before, the ambiguity of the last statement is enjoyable -- "I, Robot" was one of the first games to use 3D polygonal representations. It was not one of the first games to use flat shading, nor cell shading (given that it does not use cell shading).
"The next shading technique, which was common in the later days of the PlayStation, is named Gouraud Shading:..."
Gouraud shading was first presented by Henri Gouraud in 1971 and has been common in games well before PlayStation.
"...by working out the colour at each vertex, and interpolating this colour between the vertices across the triangle whilst rendering, it will give an approximate idea of how the triangle should be shaded."
Gouraud shading takes the averaged surface normals at each vertex and performs a lighting computation (originally a Lambertian diffuse calculation) upon them. The resulting vertex colours are then interpolated along the edges of triangle, then the triangle is filled by interpolating between each set of edge pixels per a scanline.
"Unfortunately, because the colours are worked out at the corners and mixed across, shadows in the middle of the triangle will be completely missed."
The production of shadows has nothing to do with Gouraud shading, or shading at all.
"Also, when using large triangles, the effect can seem quite unnatural, and it's especially noticeable in Metroid Prime when moving around in Morph Ball mode."
The problem with Gouraud shading is that it restrict light sampling to vertices taken from the world geometry. The accuracy of the shading is then directly proportional to the vertex density of the world geometry. It also performs poorly at oblique junctions. Another issue is the Gouraud shading is not perspective correct.
"Games such as Silent Hill 2, however nice the shadow generation is, still only use this basic shading model, and it's very noticeable with the 'squares' since the light hits the vertices (corners) in turn, the light tends not to spread slowly across the triangles."
Writing cross platform code doesn't quite work like that, even with a library available for all the platforms you are targetting.
I thought I made it abundantly clear that XNA and reference implementations are entirely different issues and do not at all equate. XNA is simply an SDK of sort taking care of common tasks and providing a solid base to reduce development time. Reference designs are a different issue which Allard also discussed in the article.
If you are refering to my points on reference designs, rather than misconstruing my contents on XNA being a reference design, the whole point of most reference designs is that they are not cross-platform at all -- look up the definition of and historical use of reference designs in the computer industry as a whole. Most reference design implementations of standards are created so that others can simply clone most of the system to create virtually identical implementations. Otherwise why bother with a reference implementation when you could simply provide the specifications and hope for the best?
Even if MS did provide a royalty-free, IETF or ISO-standardised spec and provided base libraries across all the platforms you are interested (and wake me up if that ever happens!) you are still facing time spent moving your current project to a new platform.
Again, I do not disagree at all, and think I was rather clear that most reference implementations are not meant to simply provide base libraries and cross platform systems to support an entirely different platform, but rather to provide a complete platform itself. If you are refering to a reference design that is not created for this purpose, then it really has nothing to do with the topic at hand since the article very direction indicates this is the type of future they are looking at.
Cross platform is more than just a buzzword - you really need to think ahead with your data structures, your communication mechanisms between threads/processes and your approach to designing the whole project early in the design so you don't get screwed over by changes in pointer sizes as you switch from 32 bit to 64 bit platforms or changes in endian-ness as you port from x86 to PowerPC.
Since when did do you change fundamental processor architecture when you buy a reference implementation and the supporting systems? Do you honestly think that someone purchases ARM core designs and reference implementations so that they they can change the architecture and instruction set so much as they would be incompatible? At most you'll see licencees extending the instruction set, but otherwise there will only be small changes like modifying the trace cache, optimizing i-RAM access times, or reducing power consumption.
On the subject of really needing to think to create crossplatform code, what exactly do you believe developers are being paid for? Not thinking? Cross platform development is just another problem to be confronted.
The problem a lot of developers for Windows platforms have is that they do not have to think about multi-platform portability because essentially every Windows platform they are likely to run on looks like x86. At least open source developers who post their sources on Sourceforge are likely, sooner or later, to have a PowerPC owner try and compile the sources and send the developer a problem report, so if they haven't considered portability right at the start, they stand some chance of being exposed to another platform earlier in development before a lot of code is set in stone.
What does this have to do with anything? I guess I'll contribute some random irrelavent information as well:
I have written commercial non-open source code which had to compile with three different compilers, operates on two entirely different 32-bit architectures and one 16-bit variant, with two operating systems (of which one is indeed Windows), and was highly performance critical as well.
Does this have anything at all to do with the discussion at hand? No.
This has very little to do with porting games at all -- XNA doesn't particularly make it much easier to port a game to a different platform. The author of the article on Eurogamer makes some far fetched comments to that effect; which seems to indicate he has no idea what development is like, or what XNA will really provide.
The whole point of XNA is provide a solid common library, which focuses on common game development tasks. This allows different platforms to very easily interoperate, but does not make it significantly easier to port games to other platforms. For instance, making a set of games that share the same game world and are all Live aware becomes quite simple, but porting a Xbox version of that same game to PC does not suddenly become a simple task.
I don't see how people are jumping to the conlusion that providing XNA and reference designs is economically infeasible. Certainly Microsoft would like to create a reference design platform in the future. Yes, Microsoft thinks this can start with with XNA. Yes, it's a good idea.
The whole pointing in having a reference design is to increase interoperability, reduce development time, and reduce development cost. If another company makes a device using a reference design, it won't take your suggested 3 months to port a game to run on this new device -- it will take zero months, zero weeks, zero days, zero hours... no time at all since it will run on that device immediately.
You don't have to rewrite anything in a PC game to have your game run a different manufacturer of GeForce 4 cards -- it works on the reference design boards, it works on Asus boards, it works on Hercules Guillemot boards, and it works on everyother board based on the NVIDIA reference design. Does this fact suddenly make NVIDIA foolish for abandoning their board manufacturing business in favour of performing just the design tasks and chip fabrication? ATI seems to be following a similar plan these days as well -- platform and reference design work.
If Bob decides to buy and use a reference design for MasterBlasterSuperConsole, he's essentially creating a MasterBlasterSuperConsole -- not another platform. Say the original MasterBlasterSuperConsole designers still sell their version of the MasterBlasterSuperConsole and everyone likes Bob's MasterBlasterSuperConsole better. The consumers proceed to buy more of Bob's than the original by a large margin. Are the designers of the original sitting on the street crying? No, they're taking in a killing from Bob's MasterBlasterSuperConsole since he has to pay the original designers a very significant percentage of his profits to them. Is Bob upset? Not really, he didn't have to design much -- just copy the reference design and add a few tweaks here and there.
There are a lot of companies that operate in this fashion -- ARM in one of the largest microprocessor developers in the world without even selling microprocessors. IBM also licences out it's microprocessor designs to other companies (the Power architecture seen in PowerPC, amongst others, is a good example). Ericsson isn't loosing any sleep from becoming increasingly a design house, providing specifications and reference designs to companies that specialize in mass production. There has literally thousands of companies that do business in this very fashion with great success.
Microsoft and Sony have been doing this for decades in various different industries -- it's one of the reasons they have been so exceptionally successful. I wholely agree with Allard, it's just a matter of when this will happen.
The Fedora Core 2 schedule release schedule indicates that this the final Core 2 release.
The core was supposed to be released for mirrors on the morning of May 14th, then the open release will be announced on May 18th. Presumably there should be sufficient mirrors to manage to the load by then.
I'm am Jack's complete lack of surprise. Really, who didn't see this coming? Most online games have been heading in this direction for quite awhile now, with several game development studios working on similar solutions (Valve's Steam, Microsoft's Xbox Live Tsunami, etc).
I find it more surprising that no MSN Messenger integration occured in the initial offering of Xbox Live. Furthermore, it wasn't surprising, but somewhat disapointing that Xbox Live communication was performed on a per a game basis -- thus support varies per a game, while some games have no Xbox Live communications at all. I'm certain it alleviated a lot of software maintenance and OS deployment issues for Microsoft, but it has some obvious disadvantages.
So what does this have to do with AOL's integration of IM with the Matrix Online? Well, I predict AOL's IM integration into the Matrix Online: the IM clients will be standalone applications. For example, when you launch the Matrix Online, it will force your current IM client offline then launch it's own custom IM stack. I have a hard time believing AOL has a nice clean portable IM stack, which they can simply throw over to Monolith Productions, or an IM service in the works.
The more likely scenario is that they are making a slightly customized version of their IM stack, which places AOL in the interesting position of maintaining two stacks. Or, more likely, in maintaining their current IM client and occationally doing updates to Monolith's IM stack... until it slips their minds.
On a thread in the Bioware forums. There are more comments from people who work at Bioware, but I think those two comments were the most succinct.
I think it's fairly safe to say that NWN2 and BG3 are not in the works at this time, which means we won't see these titles for quite a long time if they ever appear....
Georg Zoeller, Designer, Bioware:
"Combined with the fact that we are indeed not going to reveal NWN 2 on E3 (because we are not working on a sequel to NWN), and the other incorrect/badly researched "news" I found on this site ("Bioware is secretly working on BG3", "Bioware releases free community expansion pack", "Bioware announced they work on three original titles, NWN2?") it is pretty safe to say that you can disregard this newspost. I don't know what Trent really said, but whatever it was, it was almost certainly mangled up very badly in translation.
So again, we are not working on NWN2 and we are not working on another expansion pack for NWN, through we are working on other things to support NWN in the future (see Witch's Wake forum for details)."
Stanley Woo, QA, Bioware:
"Since we currently have no plans to make an NWN2, it would be highly unlikely that Trent would be talking about it at E3. This has been discussed on the HotU board as well, with the explanation being that the translation is incorrect. There has also been mention of GameStar being, perhaps, an unreliable source of accurate information."
For all those who have no idea what he's talking about, the Puma reference is from an episode of Red Versus Blue.
Until the early to mid 1990s, Cobol was the most used programming language for over 30 years. I didn't actually realize this was the case until it was pointed out by Al Aho during a guest lecture. Interestingly enough, the current predominant language, based upon number of users, is Visual Basic; not C or C++, not Java... Visual Basic. A good deal of scientific computing is still done with Fortran 90/95.
On the subject of Windows NT, the Windows 2000/XP executive and microkernel architecture is fundamentally identical as in NT4.0. Where else have you seen this executive and microkernel archtiecture? Xbox for one, and soon on a PowerPC platform (or rather again since Microsoft did have a build of NT for PowerPC awhile back). Like it or not, NT4.0 is highly successful modern OS, which lives on to this day.
Damn -- put the wrong link... as I was saying, the current event.
Ummm... those two articles you're linking to are in reference to previous developments around a month ago, not the current event, which is what loftydog was referring to.
Since when was Valve or the Half-Life property average? Scott Miller from 3D Realms said, "The highest royalty 3D Realms has executed is 70%, for a project in which we owned the license, and self-funded." Let's stop and think about for a second -- 70%.
You don't need to sell nearly 4,000,000 copies to recoup $40,000,000 US if you have decent royalties, along with engine licencees.
The Source engine currently has one known licencee, which has a game scheduled for release at the end of this year: Troika Games with Vampire: The Masquerade - Bloodlines.
Given the media released to date, Troika seems quite far into the development cycle -- which is rather siginficant given that Troika started work on the game with the Source engine in December of 2001. So, if there was delays and stalling, it wouldn't be because they didn't have something to give this other company you heard about (unless that company asked for the Source engine far more than 2 years before it was launched) -- it would because they didn't want to give that company.
"Granted, they were a really small company, so maybe they didnt look interresting, but it would have been the same cash in the end, right?"
I think that is rather significant. If I were Valve, I would want all the initial licencees to have reasonably high quality products -- or better still, high quality products that are high profile. A smaller development house might be able to muster enough for the engine, but can it deliver a product that Valve can trust to showcase the engine?
On another note, are you sure that this really small company could actually meet the price tag Valve wished? The Unreal Warefare engine runs at $750,000 US with an additional $100,000 US for each additional platform, or $350,000 US with an additional $50,000 US for each additional platform plus 3% royalties. Quake II's engine reportedly costed between $400,000 US plus 10% royalties, to a hefty $1,000,000 US. Even the aging Quake engine, which is now operating under the GPL, has a $10,000 US price tag if you wish to not operate under the GPL. All these fees are non-recoupable.
Given the development cost of the Source engine, I wouldn't at all be surprised if it cost more than the Unreal Warfare engine.
From the FAQ:
What will combat be like?
Combat will be intense and spectacular, with over 300 animations for each martial art and weapons style.
Read it again -- the FAQ states that the game has "over 300 animations for each martial art and weapons style" which seems impressive. However, consider all the annimations that will simply be variations, idle animations, basic movement, and that number sounds a lot less impressive.
Prince of Persia used over 700 animations just for the Prince's very small set of moves. 300 animations does not at all equate to a large variety of motion.
Blame my spell checker. Relax -- this is a messageboard.
Xbox Live games and the Xbox Live dashboard both use the Live API, of which the VoIP audio codecs have not significantly changed. The Live API VoIP framework has been rolled into the XDK for a long time now. Subsequently the implementations of VoIP are virtually identical between Xbox games as well as the Xbox Live dashboard.
What differences do occur, are usually in the networking code and initial VoIP settings. It's upto the developer to decide the compression window size for voice data, and how to deal with the VDP stream. Subsequently, voice performance will differ somewhat based upon processor usage, the bandwidth requirements of the game, and the applications network stack. However, they all use the same VoIP audio codecs, engine and protocols.
The point being that the difference in voice quality are due to the specific applications requirements, and not the implementation (unless the developers can't even use the voice framework correctly -- which I find very hard to believe). If bandwidth and processor resources are abundant, you can simply increase the granularity of the voice compression window and almost magically you have better voice quality.
The corrollary of all this is that there is no mess to fix. Any voice quality variance is due to very intentional decisions on how to use the provided VoIP framwork, or variance introduced by the network environment itself.
Antidotally, I haven't particularly had any problems with voice quality while using dashboard in comparison to that in games. I find both to be acceptable at best, which is to say about the same as most other VoIP applications used over a home connection.
I would hope the intention would be to finally integrate MSN Messenger functionality into Xbox live allowing users to communicate seamlessly between the desktop environment (via MSN Messenger's VoIP capabilities) and Xbox Live. Voicemail would be kind of nice too I suppose.
Most game developers, and a host of non-game developers, have been thinking about better communication integration for quite sometime now. The utility of communication services is directly proportionate with the number of users. Subsequently, it makes a lot of sense to try to increase your user base. Similar efforts have been made in Valve's Steam, and if you want a far older example look at how wireless text messaging systems have evolved -- communicating between wireless phones, landline phones, and desktop computers may not be ubiquitous, but it's certain availible.
It sounds terrible in comparison to chatting in a game! Voices are heard gurgled and staticky even with a first party microphone (for those who don't go on XBox Live, most third party microphones are horrible). I hope that this time around the new features are better.
Xbox Live uses the same VoIP system via dashboard as it does in game. Microsoft purchased the Waterloo based Shadow Factor in 1999 to integrate their VoIP technology into DirectX as well as other MS products. You now see the same technology in DirectX, MSN Messenger, and Xbox Live.
Then, how about adding some card games or board games for the people to play while chatting?
As strange at idea kind of sounds, MS has signed a recent deal with the makers of the Catan series of game for the creation of electronic versions. I somewhat doubt it'll make it's way onto Xbox given the target demographic, but you never know.