I', not assuming that it's all about graphics at all. I do not think that the animation system of Uncharted could be done on the XB360 while leaving a game intact. I do not think that the damage seen in Forza 2 could be done on the Wii. I do not think that Little Big Planet could be done on the Wii. Could the physics of Crysis be done on the XB360? Probably not.
April NPD: Despite GTA, Wii Outsells PS3, 360 Combined
- Thread starter esmufc07
- Start date
I', not assuming that it's all about graphics at all. I do not think that the animation system of Uncharted could be done on the XB360 while leaving a game intact. I do not think that the damage seen in Forza 2 could be done on the Wii. I do not think that Little Big Planet could be done on the Wii. Could the physics of Crysis be done on the XB360? Probably not.
Xbox probably could yes, Ps2 would struggle to keep the framerates. On the God of War 2 front, I've never played it nor seen it in action, so I won't insult your intelligence by going off of screenshots
And pissed off 66% of their userbase by taking the rumble out. It's a strange thing is the hardcore gamer.
Xbox probably could yes, Ps2 would struggle to keep the framerates. On the God of War 2 front, I've never played it nor seen it in action, so I won't insult your intelligence by going off of screenshots
It's mostly solid, probably the second best display of what the PS2 is capable of. Most people do not like the PS2 because it's different. It doesn't have a GPU as such, rather a pixel pusher.
You are talking advanced techniques. Uncharted isn't just about the animation, in fact while it looks pretty what does it actually do to the gameplay?
You'll have to explain to me what about LBP can't be done, since I know little of the game.
Forza could be done easily on the Wii, the damage model isn't anything really pushing.
As for Crysis, it's not DX10 on the 360, but apart from that I fail to see how the physics couldn't be pulled off on either the 360 or PS3
Gameplay starts and ends with what you can control, not with how you control it. I can make a game, say a FPS, and I can adapt that to control with a mouse and keyboard, a controller, a joystick, a light gun, etc. The gameplay itself remains the same, it's simply enriched by a certain control mechanism.
Let us go back a bit, and look at one of the first truely good FPSs. Say Operation Wolf. Did you ever play it with the Uzi mounted on the arcade case? Did it work when it was on the Amiga with a Joystick? It did, just not as well. Would Street Fighter work wel, with the Wiimote? I doubt it. Did it work as well with the controllers of the SNES as it did with the sticks and buttons of the arcade? No!
As you know I've always maintained the PS2 was capable of more. Unfortunately Sony didn't really help matters with their API and software support. The PS3 seems better, but they still fall behind Nintendo and MS for 3rd party support.
We are arguing about the same thing it seems. Player immersion is all important and the controls are the key to achieving this.
That doesn't stop new controllers on machines taking that a step further though, just like the revolutionary N64 controller (still one of the best ever made).
With the Wii, it's obviously a case of the controls and the controller being central focus, and I still don't see how that can be considered a bad thing.
Of course you are correct. However, we aren't arguing about the same game across a number of systems, since every games needs to be reworked for the Wii controls. That's down to developers, and quite frankly although it's hit and miss, it has been more hit.
Plus, standard controllers have been about for what 30-odd years? The remote has only been about for 2, I think we can allow for a little more room to expand.
Firstly, DX10 means nothing, it's an API, you keep bringing this up. DX10 simply asks that a particular feature set is available to the API. It does not mean that the hardware is poor because it may not have a particular feature, in fact it may have features outside of what DX10 asks for and thus cannot be accessed through DX10. I do not think that the XB360 an do the physics in Crysis and still run the game. I'm not talking about the graphical representation of the physics here.
As for Uncharted, then the animation system adds to the immersion, it makes it believable. Do you think that a developer such as Naughty Dog would have spent so much time on it otherwise? On the artificial intelligence level, the way that the enemies deal with you is very clever indeed.
LBP uses a lot of physics, the way things in the world react to what you and the environment do. This is not graphics, and Broadway could possibly do it, but then you wouldn't have a game. I'm sorry, but a single core PPC at 700Mhz can not even pull 1/5 of the work a single XB360 core at 3.2GHz can, and the XB360 has three of them. If you are arguing that a 700Mhz single core can provide as much processing power on the artificial intelligence and physics level that a tripple core running at 3.2Ghz can, then something is wrong.
I think that they have changed this now, although it's not the best. Come on, you must have contacts, you must be able to get access to the documents under NDA?
I'd love to get a Devkit, but my wife would kill me if I spent 1,200 quid on one.
Keep bringing what up exactly? You completely went off on a tangent I wasn't heading down. All I was pointing out is to my knowledge, the only change so far been reported is the switch back to DX9. Nothing about the physics.
However, you've obviously studied them more than me, so what exactly is it that you don't think the 360 can achieve? I'm intrigued.
Fair enough, however that doesn't mean it couldn't be done on the Wii. Obviously not at the same level, but even though the animation system undoubtedly couldn't be done, I'm not so sure about the A.I.
You know that's not what I'm arguing, and you keep pointing out rudimentary stuff to me about API's and physics no having graphical representations, for what reason?
I don't need a lecture in computer graphics and physics, what I am asking though, is what about the physics don't you think can be achieved on the Wii? Even if slightly scaled down, I don't see why LBP is so advanced that it couldn't be done on the last generation of machines? Again, I know little about that game so I'm asking, not assuming.
I think that they have changed this now, although it's not the best. Come on, you must have contacts, you must be able to get access to the documents under NDA?
I'd love to get a Devkit, but my wife would kill me if I spent 1,200 quid on one.
I've had a peak at them in the flesh, but haven't got an electronic version. Probably could get hold of some if I dug deep enough.
They seem better, but it's still a bit of a chore to get anything out of them. The problem, as we've discussed before, is because of the cost of development programmers switching projects is rife and there's never enough time to sit and study thoroughly what's going on under the hood. API's make life so simple, too simple in fact, and the Sony versions are notoriously bad when compared to the others.
As for the dev kit, that would be a dream. At the moment, XNA seems the best way to get into the next generation of consoles (getting a model up and running on an actually 360 shall be a lovely feeling, reminiscent of my first PS1 sprite flying around!). I see a definite inroads there, and who knows if you manage to sell a product maybe you could push for a PS3 version too
This is the point however, that many new types of controllers have been introduced and failed. Wiimote is perfect as a pointing device, which is why I find it strange that TVs have not taken the idea up. I'm sure that it's not a patent issue. As for the tilting mechanism, it seems from reviews/previews that Wipeout HD is the first game on the PS3 that its use actually works. Standard control mechanism however?
No! It makes no sense. Wiimote to me is a less fiddly form of the old VR kits, you just don't need the headset. It's perfectly suited to very narrow gameplay styles such as Wiisports that allow the novice gamer to become immersed in a very inimmersive set of very simple games. You can argue as much as you like, but it's Wiisports and WiiFit that probably take up/will take up the majority of Wii use. These are very simple on the gameplay level, and are driven by the control mechanisms. Good for Nintendo, it sells, just like the DS, Brain Training, Cooking Mama, it's not actually driving that much, it's not pushing the envelope at all. Pro Evo is different is does, but it's a rare title.
If, IF, this control mechanism is so great, then we will see it used outside of the Wii. We will see it for TV, we will see it on the PC, but we won't. That's my point. From an HCI perspective it is a gimmick, and a money spinning one, but it's not a longer term solution IMO because it does not work in a universal manner as well as more "standard" control mechanisms across the board. This is why it is a gimmick.
I've had a peak at them in the flesh, but haven't got an electronic version. Probably could get hold of some if I dug deep enough.
They seem better, but it's still a bit of a chore to get anything out of them. The problem, as we've discussed before, is because of the cost of development programmers switching projects is rife and there's never enough time to sit and study thoroughly what's going on under the hood. API's make life so simple, too simple in fact, and the Sony versions are notoriously bad when compared to the others.
As for the dev kit, that would be a dream. At the moment, XNA seems the best way to get into the next generation of consoles (getting a model up and running on an actually 360 shall be a lovely feeling, reminiscent of my first PS1 sprite flying around!). I see a definite inroads there, and who knows if you manage to sell a product maybe you could push for a PS3 version too
It runs on the PC right? It is .Net after all? This is the beauty of this, but obviously, full XB360 games do not use this. Probably the difference is not that much TBH, I suppose that the runtime environment running on a single core is perfectly good enough. I do not know, as I do not have a XB360.
As for the Cell, well, developers better get used to the idea, because it is the future. Developers like Valve who refuse togo along this line are in for a very large shock. Mike Acton in his views in threads that you have read that I have quoted makes this very clear. We do not need to dig into the technical aspects of Cell to know this. GPUs and traditional CPUs are converging, and they are doing so in a highly parallel fashion. If we look at how well the Cell model works in the scientific field, it's clear that it's perfectly suited to gaming.
Contrary to your thoughts, I wish that Sony had not used a standard GPU.
Firstly, chips don't shine.
Also, I'm not exactly sure to what you mean by gameplay, are you referring to the core mechanics, or using the term in the wider sense? If the former, then again, neither a chip nor a controller actually add to that; if the latter then both can do so, as that would include aspects such as immersion into the game, making the experience believable or making you feel that you are part of it, but this includes a wide range of elements from control, to intelligence, to physics, to realistic graphics and sound. The point is that there are many games that run on the XB360 and the PS3 that simply can not be done on the Wii, it simply is not powerful enough. There is however nothing on the Wii that can not be done on a PS3 equipped with a PS Eye - but then we are collecting extra bits of plastic again.
The immersion is greater when the physical action you do is replicated on screen, it doesn't matter how pretty the graphics just hitting a button isn't new, flicking the right list to throw a lasso then tugging back to rip shields off bad guys is.
You seem to think the Wiimote is restrictive, I suspect its a lot more flexible then a standard game pad, and the nunchuck is part of the Wiimote, you get one with the system, selling them separately makes Nintendo more money.
It'd be a bit daft playing guitar hero on a controller that didn't half way function like a guitar.
The Wii fit board measures weight, did you expect that to be built into the Wiimote?
I'm not sure, maybe we will see it in the future?
For a start, there's no argument that Wiisports is probably still the most played. However, what of all the other tennis games, boxing games and golf games released? They (mostly) all play better than on control pads, and Pro Evo is not unique.
Godfather handles better on the Wii, so does pretty much all the FPS's (starting from COD2), Mario Galaxy is also a wonderful example of a platformer working beautifully with the motion sentive controls, so is the GTA inspired No More Heroes.
Resident Evil 4 is awesome with the control scheme, also (for the beat-em-ups) if you put a little effort into it, Dragon Ball Z is pretty darn nifty with the way you can shoot fireballs and the like with actually thrusting the remote/nunchuck forward.
For driving games, both games like Mario Kart and Need for Speed work well with the remote, again much more enjoyable experiance than a control pad.
Harry potter is also an example of a very good, and fresh control mechanism which really excels on the Wii.
There's plenty more, and like I say some are hit and miss, but for the most part games that are actually re-worked for the Wii, and not just quick conversion with simplistic motion controls, are as fun as and in a lot of cases, better to play than their big-brother rivals.
Ahh, see this is where we come a bit closer in line. I'm not claiming it's so "great". In fact, there are plenty of cases where it could even be seen as gimmicky, but only because of poor software by 3rd party developers, and in which case I'd say it's the actual control scheme that's gimmicky, not the controller itself (see Marvel heroes:Ultimate Alliance).
All I'm arguing is that it's not a gimmick from my point of view, because it's not a add-on, it's a new control scheme and one that could and should reignite the way games are made and played. If even a few titles come out of it that are uniquely brilliant and fun to play, rather than the same old button mashing, then I fail to see how that's a bad thing.
If anything, from my own designer point of view, I'd love to get my hands on it and really put it to good use.
I'll let you know next weekend when I've set up a test and run it on both the PC and 360. I suspect you are right though.
I couldn't agree more. Once it's settled down and developers realise they have to change their ways, it will all be much better. But you know how stubborn programmers can be
My thoughts? I'm not sure I'm really that bothered either way. As I've said before, I've no serious interest in the technology behind the machines. Well, not in the study everything and know everything about it kind of way.
You have more than once brought up DX10. It's a feature set defined by Microsoft, nothing more. OpenGL also defines a feature set for whichever version. Just because something is DX10 capable, does not mean that it's better than something OGL v3 capable. Do you think that full on XB360 developers go through DX? I suppose they do, the very name of the machie comes from it.
I'm a bit of a hardware freak, I've always liked to tinker with the metal, and I like assembler. I'll go off on another tangent here, so at least allow me a second, but you can be Object Oriented with assembler. OO is a concept model, not a language, it binds code and data together (Object Based), and then allows reuse and change (Object Oriented). All of this can be done in assembler, however it is much more complicated due to its level. When do you think that complexity should be removed or thinned down at the detriment of performance? Surely this is down to the quality and education of your team? The problem is that you can write shite assembler, and shite assembler becomes more complex. I'm positive that a G++ compiler can produce better assembler than some people trying to hand craft it. This IMO however does not mean that we should not try. It's not difficult to write, just difficult to manage, which is down to tools. Talking about XNA however and .Net, is that those are as far away as you can get. Do you really think that a good set of assembler tools will cause that much more effort than a set of XNA tools? It's all about codebases here, in the end it all ends up in binary. And yes, I have coded a 6502 in hex. Unix changed this, everything is C, give it to the compiler.
At the end of the day, you can write code that will work on XB360, Wii, and PS3. They all share the same base processor. Recompile and you are done. Use Open GL, use a Open GL->DX translator, you have something. Doesn't work does it?
I meant "your thoughts" in the sense that you prefer a standard API to get at the hardware, DX for example, a certain feature set that you can just say "do this". We see GPUs going towards general processing tasks, and we see CPUs going towards vector processing tasks. Would a Cell (minus PPU) with ROPs have been that much more difficult than an nVidia RSX? Would 8 SIMD units at 3.2Ghz offer less than the 48 unified shaders of the Xenos at 500Mhz?
I know what the DirectX API is and how it works. Christ, I've been developing PC projects well before it. Oh and the 360 is DirectX, while the Wii is something very closely related to OpenGL.
I know all this, remember I've worked on the GBC and GBA. You are probably miles better at assembler than I'll ever be, that's because I've turned to games at an early age and I've lost the technology interest for the design aspect.
That of course doesn't make me less of a programmer, it's more that I'm now attuned to getting the results required at the quickest possible pace. Hence the reason that while working by myself, I prefer C over anything else because I've always worked in a OO way with it, but my own way and not forced as such.
DirectX and OpenGL provide the best of both worlds in reality. I'm not a graphics programmer as such, so they are perfect for me. Therein lies the problem though, and what you are talking about.
I do believe that people being "educated" nowadays are even more further away from the technology than even I am. I've at least had to squeeze that extra k out of a machine that just doesn't want to give it. Hell, even the GBA is far to easy to work with considering it's components.
Fair enough. I wouldn't say I prefer to program with an API, it's just become such that since most of my work is as a one man programming team, I've neither the time nor expertise to keep up. It's a shame, because I loved getting deep into the spectrums, the gameboys and the PS1's of this world.
I liked the original PS1 API, because it did give you a high-level access to the machine, but left it completely open for you to delve underneath. The problems really started with the PS2 and the Vector units, because not only was it a new set-up, but Sony didn't seem to know what they wanted from the API. Hence the reason even experienced first-party developers took a huge amount of time to finally start delving deep.
I'm very anal, I have a bit of C code from 1992 to deal with dates. When I taught C and C++ at University in 1997, I used it as a base for challenge to the students. All I asked for was a way to compare dates, less than, greater than, equal. Every single one of them came up with massive functions. I taught these people, and was expecting more, yet it all came out as long functions. I was disappointed and gave them all a B.
I don't think Sony themselves knew what to do with them. I think that it was obvious that the VX units were necessary, just that they didn't know where to put them. The PS2 hardware is very odd indeed in its distribution, you have one chip having to do bits for another. At least with the PS3, one part does not have to "help" the other part, it's just beneficial if it does.
Haha, yeah I can well imagine that. I'm a bit more old school, self taught from the speccy/C64 days.
My old partner in crime is pretty much like you, really had a deep interest in the machines themselves and hated API's. You want to see some of the things he did with the GBA cpu, absolutely amazing stuff. Of course, a super-clever compression technique is useless without the graphics and game to go on top, as I used to enjoy pointing out
He once described me as a weird programmer. Set in my ways and old school, but with more respect for the software than the hardware and as such I don't care how I get to the goal, as long as the goal is something worth the effort. He was right!
I suppose I should pay more respect to my tools, but that doesn't mean I'm sloppy in any way shape or form. I'm very anal about my work.
I'll try to find the code. It's only dates, but quite obvious in my mind.
This is a little bit more of a drawn out version of it, but, in bold.
Code:
#define BEFORE -1 /* Date and Time comparison values */
#define EQUAL 0
#define AFTER 1
#define MONTHSINYEAR 12 /* Number of months in one year */
#define HOURSINDAY 24 /* Number of hours in one day */
#define MINSINHOUR 60 /* Number of minutes in one hour */
#define SECSINMIN 60 /* Number of seconds in one minute */
#define MAXYEAR 4095 /* maximun allowable year */
#define MINYEAR 1900 /* minimum allowable year */
#define FEBRUARY 2
#define LEAPYEAR 4 /* allows checking of a leapyear */
#define JANDAYS 31
#define FEBDAYS 29
#define MARDAYS 31
#define APRDAYS 30
#define MAYDAYS 31
#define JUNDAYS 30 /* days in each month */
#define JULDAYS 31
#define AUGDAYS 31
#define SEPDAYS 30
#define OCTDAYS 31
#define NOVDAYS 30
#define DECDAYS 31
#define DATESEP '.' /* Character used to seperate date fields in a string */
#define TIMESEP ':' /* Character used to seperate time fields in a string */
/*
** 32 bit Datatype for storing standard dates
*/
[B]typedef struct date
{
unsigned day : 5; /* Gives 5 bits 0 - 31 for storing the day of the month */
unsigned month : 4; /* Gives 4 bits 0 - 15 for storing the month of the year */
unsigned year : 12; /* Gives 12 bits 0 - 4095 for storing four digit years */
}date;[/B]
/*
** 32 bit Datatype for storing standard times
**
** This datatype is NOT capable of storing additive times. The whole function
** of this datatype is to store real world times. It is not possible to store
** negative times within this datatype.
*/
typedef struct daytime
{
unsigned hours : 5; /* Gives 5 bits 0 - 31 for storing hours */
unsigned minutes : 6; /* Gives 6 bits 0 - 63 for storing minutes */
unsigned seconds : 6; /* Gives 6 bits 0 - 63 for storing seconds */
}daytime;
/*
** Array to store the days in each month
**
** This array is used as a lookup table by check_date to evaluate
** the days in the months aginst the date given.
**
*/
static int monthdays[] =
{
JANDAYS,
FEBDAYS,
MARDAYS,
APRDAYS,
MAYDAYS,
JUNDAYS, /* used to store the days in each month */
JULDAYS,
AUGDAYS,
SEPDAYS,
OCTDAYS,
NOVDAYS,
DECDAYS
};
/*
** Variables holding a date and time initialised to NULL
*/
static date NULLDATE = {0,0,0};
static daytime NULLTIME = {0,0,0};
Code:
/****************************************************************************************/
/* */
/* datecmp Compares two dates */
/* */
/* Author : WeasteDevil */
/* Date : 04/01/93 */
/* */
/* Synopsis : datecmp(a,b) */
/* */
/* int datecmp(date,date); */
/* */
/* */
/* Function : This macro compares two dates stored in the variables a and b. */
/* */
/* The relative collating sequence of the dates is indicated */
/* by the return value, as follows : */
/* */
/* Value Meaning */
/* ----- ------- */
/* BEFORE -1 The first date is below the second */
/* EQUAL 0 The dates are equal */
/* AFTER 1 The first date is above the second */
/* */
/* */
/* Results : The return value indicates the relative collating sequence of */
/* the dates, as indicated above. */
/* */
/****************************************************************************************/
[B]
#define datecmp(dt1,dt2) (dtoi(dt1) < dtoi(dt2) ? BEFORE : dtoi(dt1) > dtoi(dt2) ? AFTER : EQUAL)[/B]Is that nice, or not?
Indeed. What were your students doing then? Bubble sorting or something?
I glanced at it at first, but did you not accidentally include your real name?
Possibly. 
It's basically taking a date and sticking it into an unsigned 32 bit integer. You can then compare it as an integer. The other option is to store a date in a struct and then use ifs to go year, month, day, etc. Very poor.
When I was working on the GBA games, it was amazing the amount of times I had to mention look-up tables and using integers for macro purposes. feck sake, I remember explaining to some particularly dumb guy, (back in my Gamedev.net days) who was applying for an intern position, about using bit shifting to move bitmaps around the screen because of not being able to use floating points. Whoosh.
Ahh, memories.
The trouble is, they do not know about bits nowadays.
To bring this discussion full circle, there's a decent about of bits used for storage on the Wii remote to transport player profiles around.
Very handy
16KB is it not? Wonderful!
When is Paddy Power going to feck off?
I believe some of this is used for the players profiles (Mii's) and the rest is freely usable like storing player button configurations (handy for games like Super smash brothers).
It's a decent addition, much like the speaker. I love how it makes a swooshing sword noise when you swing it in Zelda
I dunno, if I really get a free £20 bet for betting a tenner, I might just take them up on it!
I'm sure that it adds wonderfully to your 7.1 surround sound system.
I don't trust them, I'm going to use my missus' credit card number just in case.