So, we know that Halo Wars is coming, that's one; we know that Peter Jackson is still working on his Halo-related game project, that's two. Bungie has said that they're not done with the halo franchise, and that they have 2-3 projects in the works, they're being cheeky with the are-they-aren't-they, but I think its safe to assume that's three; Gearbox is rumored to be working on the 4th installment (which, honestly I hope isn't true), but that could be four; Halo 3 has yet to appear on PC, but it surely must be coming, and that makes five.
The Halo series is one of my all-time favorites -- Just ahead of Half-life series, and in a dead-heat with the Ninja Gaiden series (NES through 360) -- The universe has a lot of leg left, there's a pretty rich history to dig into and a lot of mystery left to explore. The tie-in with Marathon. The Arbiter's story. The now-fractured Covenant (assuming some survived on their own home-worlds) and their power-vacuum. The Chief and where he wakes up next. Or will he be lost to the enemy?
The source material can support plenty more games without getting stale, the question is whether any studio outside of Bungie can apply the same touch that they have. Despite the fact that a lot of people around here will say that Halo isn't anything special, its simply not the case; Bungie has developed a very special recipe with the Halo series -- its a combination of subtle things you may not have even noticed being quietly slip-streamed in many other popular shooters since as well as not so subtle things. It took things piece-meal from shooters that had come before, shined them up and melded them into something cohesive and great.
Besides, any real Bungie/Halo fan knows that there must be precisely 7 Halo projects in the works.
Are you looking at the same screens as me? Because the shots in the article look like utter shit. Its no wonder nVidia wants you to believe that ray tracing is 10s of years away; its because they can't do it.
They're doing *just* 3 bounces, and they run at "up to" 30fps at 1920x1080 resolution. The shadows are hard, and the lighting is flat, everything looks washed out, and its due to the lighting (ie, the rays) not the textures.
And to what glorious setup do we owe this marvel? Just *4* of their highest-end, workstation-class Quadro GPUs (which probably run 1-2 grand apiece, or about $450 apiece for consumer equivalents.) All this is interfaced to a pretty serious machine, of course... Color me impressed. No seriously, but don't forget to pick my jaw up off the floor first *rolls eyes*.
ATI's Cinema demo was far more impressive, and looks awesome by comparison. It was running at 1280x720 (roughly 1/2 the pixels as 1080p) but was running at around 60fps with anti-aliasing -- virtually running at the same resolution as the nVidia demo, but twice as fast...
And to what *insane* amount of AMD graphics hardware and muti-socket, multicore AMD processors do we owe this ungodly power to? A *single* Radeon 4870 and a standard workstation.
Actually, ATI was a good move. They may have overpayed, but the logic is sound.
To compete with intel, which is the basis of your claim, AMD needed in-house chipsets so that they can offer package deals on the core logic like intel does. The graphics were needed because the writing on Intel's wall was clear: We're going after the streaming computing market, and we're going to piggy-back that on the GPU (Larabee). nVidia has done the same, and has not been bashful about stating how their ultimate goal is to make the CPU unimportant.
Buying ATI gave them all of these things, and has been fruitful (look at x4800 vs GTX 200 and the wonderful 780g chipset). Right now, ATI is the bright-spot in the company.
Even if they had foregone the ATI purchase, and even if they had made a competitive processor (which frankly is impossible on that timescale anyhow) they would still be facing Intel's chipset bundling strategy and have no technology to compete with nVidia's existing or Intel's upcoming stream computing platforms -- They'd simply be in a different kind of hurt.
Download nLite and slim down a version of windows 98. I had an old, old laptop (Pentium 100 w 16MB EDO) which had been running Windows 95. Since the default install of 98 was taking a large portion of the drive (only 1.2 GB or so) I decided to upgrade to an nLite'd 98se install.
The install only consumed about 200mb of disk space, IIRC, without doing anything drastic; you can cut it down more by doing things like installing the Win95 exporer instead of the Win98 one. Boot times are about 10, maybe 15 seconds -- and that's with a 100Mhz pentium, 16megs of ram, and an old, slow laptop hard drive (probably 1/4 the speed of even a 5400rpm desktop drive.) After stripping off the unneeded cruft, Win98 is pretty responsive and stable.
Heck, if you don't need to run explorer for your app you can shave off some significant processing and ram overhead. I knew a guy who set up two partitions of Win98 on his laptop -- one was standard, the other was nLite'd to the bare-minimum it took to run CounterStrike. As you can guess, that partition booted straight into fullscreen CS. He said that overall performance increased 5-7 fps. If you just need to run a couple non-GUI apps, this might be the way to go.
The PS3's implimentation of the PPE core doesn't have VMX128 like the PPE cores in the 360 do -- In fact, its the only real difference between the two cores themselves.
The best comparison I've heard as to the power of the PS3 PPE core alone is that a single PPE core (here referring to those in the 360) running two threads is roughly twice as fast as the original Xbox's Pentium 3 processor (with 256k L2) which ran at 733Mhz. So a rough comparison to Intel-land gives us something similar to a 1.5 Ghz P3 -- Not bad, but its no 2Ghz Dothan, not by a shot...
Tom Forsyth is a lesser-known name in graphics but, having read his blog and exchanging emails with him on a couple occasions, I assure you all that he really knows his stuff.
He's been a graphics programmer on early game consoles, software engines, video codecs, and other modern things. The man knows 3D and has mapped it to some low-end and odd-ball hardware. I'm sure he's gotten his head around Larrabee quite nicely.
Here's a good one to pull on your least favorite C or C++ programmer (or which can be applied suitably to other languages) -- find a critical, though little run for loop and locate the cursor just after the closing parenthesis ')'. next, hit tab about 20 times. Finally, enter the following ";// loves teh cock!!!1!
bonus points for depraved creativity of the comments following the semi-colon.
This works best if you can do it from their station while they're away or if you have "raw" access to the file, because version-control (check-in/check-out) logs will betray you:)
Actually, the new Via architecture shares a lot more in common with the Core 2 -- Its out-of-order, spends a lot of die space on speculation, has a fairly wide execution pipe, has something similar to the Intel's uOp-fusion and much more cache than the old C7. Its also prepped to go dual-core, but the company says that'll probably only happen once they go to 45nm. This has basically nothing in common with Silverthorn, which goes back to in-order, narrow execution pipe and smaller caches in the interest of saving die-space and power envelope. Of course, Via's chip is still focused on low-power, so it doesn't scale past 2ghz (at least at 65nm, they say) but its probably comparable to Core 2 on a clock-for-clock, core-for-core basis, give or take 20% or so.
The Summary kind of has it backwards, Via's new chip competes more closely with Core 2, while Intel's Silverthorn competes more closely with Via's C7 chips.
In terms of code quality, I wouldn't put Carmack on too much of a pedestal. Performance? Yes, he's quite good with that... but I've heard obtuse, poorly commented code referred to as "Carmackian" on more than a few occasions.
If there is a reason for the PS3 being delayed (and who says it is?), it might have something to do with the fact that the Source engine was written against DirectX. The PS3 uses OpenGL for graphics and has other APIs for things such as sound, controllers etc. Consequently the engine needs a virtual rewrite irrespective.
I fear that you are showing your utter ignorance of game development my friend. Yes, Half-Life 2 was written against Direct3D primarily, and now it will have to be ported to one of the PS3's graphics APIs; Either their OpenGL|ES + extensions or their (proprietary, by the way) lower-level API that nearly all boxed retail games have utilized. In all probability, its not porting D3D to OpenGL, but porting D3D to this low-level API. That being said, however, the specific portion of the game which deals with graphics is not a large portion of the code, maybe 10-15 percent at most. The portion of the graphics code which deals directly with the API is maybe half of the overall graphics code. Somehow you've managed to imply that porting 5-10 percent of the code requires a virtual re-write -- an implication that, frankly, falls on its face.
And who says they need SPUs, or that even if they did that they'd be utilized significantly in a game engine which has been predominantly single threaded throughout most of its life?
Who says that the engine needs to be multi-threaded and use the SPUs? Its the PS3s system architecture that really demands it. The PPU (the single PowerPC core in the PS3, and the same as the 3 in the Xbox 360) is very underpowered. Its the rough equivalent of a 1.5Ghz Pentium 3m despite the fact that its clocked at 3ghz. Next you have to consider that some of that PPU power is designated as reserved by the system software which runs in the background, and that, due to the design of the PPU you must have at least 2 active threads to reach anywhere near peak performance -- Its an in-order dual-threaded processor, meaning that when one thread stalls (memory access, for instance) the other thread executes until it stalls or the other thread can resume. In short, the only way to get good performance from the PS3 is to use enough threads to keep the PPU happy, and to offload anything you can to the SPUs -- offloading is not at all optional for any modern game.
Perhaps Valve should have the foresight to make their engine more portable to begin with rather than bitch that a system (be it Linux, Mac, PS3, Wii or whatever) DARES to not use Microsoft proprietary APIs.
I've already touched on the fact that, in all likelihood, valve will be porting from one proprietary API to another. Even assuming that it had been targeted at OpenGL on the PC, there would still be some amount of porting involved in targeting the OpenGL|ES + extensions found on the PS3 -- easier, yes, but still no free lunch.
But I think this last statement reveals your true motivation: you're steamed that valve didn't support OpenGLin half-life 2. I'm a huge supporter of OpenGL, especially with all the changes coming in 3.0 and Mount Evans (not to mention OpenGL|ES, which is awesome) because I agree with, and support, the philosophy of open standards. That said, in terms of retail software, OpenGL is really very much a theoretical standard, while DirectX is a practical standard. By this I mean that a fairly average user is far more likely to have heard of DirectX and perhaps even know its general purpose than they are OpenGL. Add in the fact that Windows PCs are something like 90% of the desktop market, it becomes the de-facto standard in terms of what platform retail software should target first.
The reason there is a Halo 3 is because Halo 2 sold something north of 5 million copies and was the most popular game on Xbox live all the way until Gears of War, even now it continues to fare well. Here's another fun factoid -- the number of matches of Halo 2 played on Xbox live would overflow a 32bit value, or more than about 4.3 million matches.
Halo 2 came about for the same reason: Halo 1 was incredibly popular.
Yes, Halo is Microsoft's main "system seller" -- much like Nintendo's Mario, Sega's Sonic, or Sony's... Kratos, most recently, I suppose. But all of these mascot-style characters and franchises survive solely on their own popularity with a rather fickle public, the world of video games is littered with mostly-forgotten and abandoned former or hopeful mascots.
Adding another renderer certainly does not nearly double the work. These days, a game is 75% assets or more. Code is typically less than 25% of the development effort and the renderer alone is a small portion of that. While graphics are a focal point, you can safely say that the renderer is less than 10% of the overall effort, even in titles known for pushing the graphics envelope.
Also, no one uses DirectInput either. Even Microsoft officially recommends that developers use the standard messaging system to process keyboard and mouse input. Its only use is with gamepads, joysticks and such -- but no one uses those to play games, particularly FPS games, on the PC, so DirectInput's role is limited at best. It's present, occasionally, if the devs were nice enough to support those kinds of devices, but traditionally its been little more than an afterthought handed off to some intern or entry level developer.
Another point, if I'm not mistaken, is that Carmack has said that the Xbox 360 is the Primary Target Platform going forward -- not the PC. It makes sense, consoles are where the sales volume is at. A hit console game can sell 10-20 times the volume of a hit PC game. The PS3 and gamer-level PCs are close enough, technically speaking, to make porting a straight forward effort.
Carmack has also explicitly praised the incarnation of Direct3D found on the Xbox 360 as his current favorite graphics API. While I don't think the days of Carmack's stalwart support of OpenGL are over, the days of his disdain for Direct3D certainly are.
I really fail to see how you were modded informative, since your post was nothing more than an uninformed rant. I, personally, am an OpenGL supporter, especially given the changes coming with OpenGL 3.0 and the following iteration but I'm still going to call you out on your utterly uninformed post. Sorry.
There's no sense in bringing the Foleo to market when its up to 3 times the price of Asus's EEE and less than half a machine. As much as I like the idea of computing devices on less-typical architectures like ARM, MIPS or PowerPC, I can't foot that bill in the face of superior and cheaper x86 based technology. It just doesn't make sense.
I'm sure they thought that they *really* had something before they revealed it. I'm also sure that they crapped themselves the minute the EEE and VIA's competitor was announced.
Intel and AMD have a cross-licensing agreement that was reached as part of a settlement (anti-trust against Intel I believe) to promote cross-compatibility. Basically, the instructions are up for grabs even though each company's implementations are kept secret. One will introduce an enhancement, then the other will integrate it into their core when they can.
MMX/3DNow! are the early SIMD instructions which used FPU resources to reduce cost and maintain drop-in compatibility with Operating systems (The OS stores FP registers on a task switch, while it would not have known about any new register sets.)
SSE has its own set of registers, instruction encoding, etc so it doesn't interfere with the floating point unit (You can't mix FP and MMX code without a considerable performance hit) but to make use of SSE the OS had to be updated to support it.
As we've read here, bit designations have no real broadly-accepted definition and its more a matter of what marketing slaps on the chip.
The 68000 is a chip capable of performing 32bit arithmetic, but only able to load 16 bits at a time, therefore, it was most efficient to rely on 16bit values when possible (even though the extra 16 bits allowed you to do some neat tricks.) Later revisions of the 68000 exposed the entire 32bit data bus without changing the general architecture of the core. Those are clearly 32bit systems through and through. The fact that the 68000 had a 16bit memory bus is really more of a function of a) 16bit memory being popular at the time, and b) had they gone to a wider bus they would have needed to move to a package with more pins (as later versions did) rather than the 64pin DIP which is far easier to work with than SMT or PGA packages.
Intel sells the 386ex for embedded designs, which is a 32bit core with a 16bit address bus also. It helps keep the pin-count low, thereby reducing design and manufacturing complexity of the supporting system board.
I think that the fairest way is to consider throughput -- If you have a 32bit core, but a 16bit memory bus then I'd classify it as a 16bit system. On the other hand, if that 16bit memory bus runs twice as fast as the CPU core (thereby being able to supply 32bits per CPU cycle) then its fair to call it a 32bit system. If you re-double that again, now the CPU core is the bottleneck, and you've still got a 32bit system.
Modern caches muddle this up a bit, because the bus width between the registers and cache can be different than the width between the cache and main memory (then again, they might also run at different speeds). Here, its fair to use the width between registers and cache since its closer to the CPU - even though the bandwidth between cache and main memory may be a limiting factor.
Its possible that features from DirectX 10 could be implemented on WinXP (indeed, most (all?) Direct3D 10 features are supported on XP through OpenGL extensions if your hardware supports it and you have the right drivers.) but make no mistake that it would *not* be the same Direct3D 10 we know from Windows Vista.
One of the major goals for D3D 10 (and going forward) was to release OEMs from legacy baggage, a not-insignificant portion of which stems from the Win2k/XP display driver model which is simply not equipped to provide the facilities that both Vista and the graphics cards themselves need. There's also a signifigant "slimming" of the API (removal of the fixed-function pipeline, cap bits, etc.) which, BTW, is the exact same direction that OpenGL is going.
What really would be the better solution? Creating two distinct next-gen 3D APIs for the XP and Vista lineages? I'm sure the IHVs would love that. Bring the XP D3D10-alike into Vista, continuing the status-quo of legacy-burdened software? Thats very forward-thinking. Hack a version of Vista's D3D 10 onto XP but having wildly different performance characteristics and losing all the benefits that stem from the new driver model? The software devs are just itching for yet another scenario to optimize for, I'm sure.
Simply put, its possible to support most D3D10 features on XP, but it is *not* possible to create a single next gen Direct3D API that supports both Vista and XP without making severe concessions to performance and/or feature set. Sometimes you just have to cut the cord.
Re:One month from release and still not done
on
Halo 3 Almost Done
·
· Score: 2, Insightful
Gameplay is always the last thing to be tacked down on any game, so this isn't indicative of any problems whatsoever. They're not making sweeping changes at this point, its all spit and polish -- fine tuning. Something as small as moving a weapon spawn-point a few meters in-game can really alter the outcome of a multi-player game, or the number, type and placement of grenades can drastically change how you approach a campaign map.
Finalizing gameplay is a bit like making a collage, you lay out all the pieces and see how it looks, you fine tune and look again, repeat until you're satisfied, then glue it all down -- of course, through the magic of software you can continue to fine-tune after its out in the wild as well.
Its standard practice that gameplay isn't in its final form until a week, or even days, before being sent off for manufacture.
Re:Disappointed with E3 Screenshots
on
Halo 3 Almost Done
·
· Score: 2, Insightful
There's no predicting, at a million pre-orders when last reported, the game is already a qualified hit and we're just over a month out. Assuming an average price of $80 USD (regular @ 60, special @ 70 and collectors @ 130) its generated roughly 100 million in sales just on pre-orders thus far. Halo 2 sold something like 1.5 million pre-orders, and I expect halo 3 to top that, ending between 1.5 and 2.5 million pre-orders when it's all said and done. Add in walk-in sales for the first month, and you're looking at something that may be approaching a quarter billion dollars in sales. Add to that the fact that its going to be a system-seller going into a Christmas where the the PS3 lineup is still pretty weak (the 360 library is comparatively strong in the months leading into Christmas) and the Wii which is still largely unavailable due to high demand (not to mention that it doesn't really compete for the 360/halo audience -- then again, it is Nintendo and they do have a strong holiday lineup as well so they'll be able to sell every Wii they can produce.)
Also, the E3 Halo footage was still Beta content, we know that it looks better by now and also that its a smooth 60 fps. I'm not sure whether Killzone was in-game footage or not (I know that there was a hoopla earlier over their use of pre-rendered footage) and we also don't know if it was running at the desirable 60 FPS mark. Thus far, I have yet to see anything on the PS3 which tops the 360 graphically and doubt we ever will (the 360's GPU technology is a generation ahead of the PS3s after all, and was designed for the console, rather than a PC part tacked on late in the design process when they discovered that multiple Cell processors didn't provide the graphics power they desired at a cost they could stomach.)
My one prediction for this holiday season is that the 360 and Wii will widen their respective leads over the PS3
Its currently a sad fact that the game's industry is becoming more and more anonymous in many ways. There are so incredibly few "superstar" game developers - Miyamoto, Carmack, Wright, Kojima, Itagaki... If I spent some time thinking, I could probably come up with 10 or so names that have some notoriety outside of very small circles. Smaller devs are being assimilated by the big players, team sizes are growing nearly exponentially with each new generation. Its becoming a commodity business, where faceless masses simply provide a product; and it takes a great deal of personality out of the industry.
On top of that, the publishing model works much like the music industry -- The publisher fronts money to the devs, and they don't see a profit until their royalties have paid off the development in full, sometimes with interest. Thats why there's so little innovation, and thats why a single bad title can fold a studio.
And to that I again agree. School cannot prepare a student for every possible situation they may meet. But there are Core Skills, such as teamwork and a certain amount of experience with largish/complex code, that all positions require and that all graduates should leave school with -- and we are falling short of that to an extent that no one should be comfortable with. These core skills are just as necessary as all the theory (which gives them the tools to become proficient in all the possibilities that school simply can't account for.) It definitely is a tough balance.
At any rate, I think we would all agree in principal that the higher-ed (and even down into the k-12 system, in regards to our generally lack-luster reading/math/science skills) could be doing more to better prepare graduates.
I think you've missed my gist again. This has nothing to do with my particular expectations, it has to do with a lot of grads not having all the skills that the workforce needs them to in order to hit the ground running -- I fully expect that they should have to learn the details of their new position(just as I did, and just as I will in any new field), but I *do* assert that they should not have to be brought up to speed on basics, or to the realities of working on a team or on large code-bases. Most grads do not have these skills, even though they are an essential part of the profession they are entering. I'm saying that their education most likely failed to provide them with these skills, and that they did not seek them out themselves. The program I attended spent a significant amount of time building these team skills by developing several complex applications in groups (2 semester-long projects in the first year, and 1 year-long project for each of the subsequent years) under the guidance of professionals.
This isn't about some superiority complex, or necessarily blaming the grads, what I'm really trying to get across is that there is a gap between the skills that the workplace needs new entrants to posses and the skill-set that much of the higher education system here in the States seems to provide. The expectations of the industry at large should really set the gold standard for what and "average" programmer should be, and in turn, that is what the higher education system should strive to meet, if not exceed.
This isn't me looking down from my perch, I've only been in the workforce for about 18 months now and I just turned 24 in June. Every manager and HR person I've spoken with laments the state of the typical CS graduate; I've observed this to be a common thread through each of the fields within the industry that I've been exposed to.
Perhaps this argument is all semantics though. I might have been better off avoiding the term "average." In hindsight its too open to interpretation and not really descriptive of the concept I'm attempting to convey.
Actually, required apprenticeships are exactly the type of thing I'm talking about. Large group projects overseen by professionals are also good (This is what my school did.)
The thing is that, in the states, apprenticeships and even internships are not required or even all that common. They're not always required, so many simply don't do them. Only the good students who want to go the extra mile. I'm not saying that school should try to emulate the "real world" but it is their responsibility to prepare their students for it -- if that means requiring internships/apprenticeships before someone is allowed to graduate, then so be it. Required internships/apprenticeships are much more common in other parts of the world.
Slashdot Mirror
DNF will undergo is 6th "ground-up" re-write.
Launch date will be pushed back accordingly.
So, we know that Halo Wars is coming, that's one; we know that Peter Jackson is still working on his Halo-related game project, that's two. Bungie has said that they're not done with the halo franchise, and that they have 2-3 projects in the works, they're being cheeky with the are-they-aren't-they, but I think its safe to assume that's three; Gearbox is rumored to be working on the 4th installment (which, honestly I hope isn't true), but that could be four; Halo 3 has yet to appear on PC, but it surely must be coming, and that makes five.
The Halo series is one of my all-time favorites -- Just ahead of Half-life series, and in a dead-heat with the Ninja Gaiden series (NES through 360) -- The universe has a lot of leg left, there's a pretty rich history to dig into and a lot of mystery left to explore. The tie-in with Marathon. The Arbiter's story. The now-fractured Covenant (assuming some survived on their own home-worlds) and their power-vacuum. The Chief and where he wakes up next. Or will he be lost to the enemy?
The source material can support plenty more games without getting stale, the question is whether any studio outside of Bungie can apply the same touch that they have. Despite the fact that a lot of people around here will say that Halo isn't anything special, its simply not the case; Bungie has developed a very special recipe with the Halo series -- its a combination of subtle things you may not have even noticed being quietly slip-streamed in many other popular shooters since as well as not so subtle things. It took things piece-meal from shooters that had come before, shined them up and melded them into something cohesive and great.
Besides, any real Bungie/Halo fan knows that there must be precisely 7 Halo projects in the works.
Are you looking at the same screens as me? Because the shots in the article look like utter shit. Its no wonder nVidia wants you to believe that ray tracing is 10s of years away; its because they can't do it.
They're doing *just* 3 bounces, and they run at "up to" 30fps at 1920x1080 resolution. The shadows are hard, and the lighting is flat, everything looks washed out, and its due to the lighting (ie, the rays) not the textures.
And to what glorious setup do we owe this marvel? Just *4* of their highest-end, workstation-class Quadro GPUs (which probably run 1-2 grand apiece, or about $450 apiece for consumer equivalents.) All this is interfaced to a pretty serious machine, of course... Color me impressed. No seriously, but don't forget to pick my jaw up off the floor first *rolls eyes*.
ATI's Cinema demo was far more impressive, and looks awesome by comparison. It was running at 1280x720 (roughly 1/2 the pixels as 1080p) but was running at around 60fps with anti-aliasing -- virtually running at the same resolution as the nVidia demo, but twice as fast...
And to what *insane* amount of AMD graphics hardware and muti-socket, multicore AMD processors do we owe this ungodly power to? A *single* Radeon 4870 and a standard workstation.
Don't believe me? Look for yourself:
http://www.youtube.com/watch?v=BzquM5Td6bM&NR=1
http://www.tgdaily.com/content/view/38145/135/
Actually, ATI was a good move. They may have overpayed, but the logic is sound.
To compete with intel, which is the basis of your claim, AMD needed in-house chipsets so that they can offer package deals on the core logic like intel does. The graphics were needed because the writing on Intel's wall was clear: We're going after the streaming computing market, and we're going to piggy-back that on the GPU (Larabee). nVidia has done the same, and has not been bashful about stating how their ultimate goal is to make the CPU unimportant.
Buying ATI gave them all of these things, and has been fruitful (look at x4800 vs GTX 200 and the wonderful 780g chipset). Right now, ATI is the bright-spot in the company.
Even if they had foregone the ATI purchase, and even if they had made a competitive processor (which frankly is impossible on that timescale anyhow) they would still be facing Intel's chipset bundling strategy and have no technology to compete with nVidia's existing or Intel's upcoming stream computing platforms -- They'd simply be in a different kind of hurt.
Download nLite and slim down a version of windows 98. I had an old, old laptop (Pentium 100 w 16MB EDO) which had been running Windows 95. Since the default install of 98 was taking a large portion of the drive (only 1.2 GB or so) I decided to upgrade to an nLite'd 98se install.
The install only consumed about 200mb of disk space, IIRC, without doing anything drastic; you can cut it down more by doing things like installing the Win95 exporer instead of the Win98 one. Boot times are about 10, maybe 15 seconds -- and that's with a 100Mhz pentium, 16megs of ram, and an old, slow laptop hard drive (probably 1/4 the speed of even a 5400rpm desktop drive.) After stripping off the unneeded cruft, Win98 is pretty responsive and stable.
Heck, if you don't need to run explorer for your app you can shave off some significant processing and ram overhead. I knew a guy who set up two partitions of Win98 on his laptop -- one was standard, the other was nLite'd to the bare-minimum it took to run CounterStrike. As you can guess, that partition booted straight into fullscreen CS. He said that overall performance increased 5-7 fps. If you just need to run a couple non-GUI apps, this might be the way to go.
The PS3's implimentation of the PPE core doesn't have VMX128 like the PPE cores in the 360 do -- In fact, its the only real difference between the two cores themselves.
The best comparison I've heard as to the power of the PS3 PPE core alone is that a single PPE core (here referring to those in the 360) running two threads is roughly twice as fast as the original Xbox's Pentium 3 processor (with 256k L2) which ran at 733Mhz. So a rough comparison to Intel-land gives us something similar to a 1.5 Ghz P3 -- Not bad, but its no 2Ghz Dothan, not by a shot...
Is it a coincidence that the probable release of both of these is around 2012?
Tom Forsyth is a lesser-known name in graphics but, having read his blog and exchanging emails with him on a couple occasions, I assure you all that he really knows his stuff. He's been a graphics programmer on early game consoles, software engines, video codecs, and other modern things. The man knows 3D and has mapped it to some low-end and odd-ball hardware. I'm sure he's gotten his head around Larrabee quite nicely.
Here's a good one to pull on your least favorite C or C++ programmer (or which can be applied suitably to other languages) -- find a critical, though little run for loop and locate the cursor just after the closing parenthesis ')'. next, hit tab about 20 times. Finally, enter the following "; // loves teh cock!!!1!
bonus points for depraved creativity of the comments following the semi-colon.
This works best if you can do it from their station while they're away or if you have "raw" access to the file, because version-control (check-in/check-out) logs will betray you :)
Actually, the new Via architecture shares a lot more in common with the Core 2 -- Its out-of-order, spends a lot of die space on speculation, has a fairly wide execution pipe, has something similar to the Intel's uOp-fusion and much more cache than the old C7. Its also prepped to go dual-core, but the company says that'll probably only happen once they go to 45nm. This has basically nothing in common with Silverthorn, which goes back to in-order, narrow execution pipe and smaller caches in the interest of saving die-space and power envelope. Of course, Via's chip is still focused on low-power, so it doesn't scale past 2ghz (at least at 65nm, they say) but its probably comparable to Core 2 on a clock-for-clock, core-for-core basis, give or take 20% or so.
The Summary kind of has it backwards, Via's new chip competes more closely with Core 2, while Intel's Silverthorn competes more closely with Via's C7 chips.
In terms of code quality, I wouldn't put Carmack on too much of a pedestal. Performance? Yes, he's quite good with that... but I've heard obtuse, poorly commented code referred to as "Carmackian" on more than a few occasions.
I can't help feeling like the DS would make an awesome phone.
Then your Nintendo Whoredom truly knows no bounds...
If there is a reason for the PS3 being delayed (and who says it is?), it might have something to do with the fact that the Source engine was written against DirectX. The PS3 uses OpenGL for graphics and has other APIs for things such as sound, controllers etc. Consequently the engine needs a virtual rewrite irrespective.
I fear that you are showing your utter ignorance of game development my friend. Yes, Half-Life 2 was written against Direct3D primarily, and now it will have to be ported to one of the PS3's graphics APIs; Either their OpenGL|ES + extensions or their (proprietary, by the way) lower-level API that nearly all boxed retail games have utilized. In all probability, its not porting D3D to OpenGL, but porting D3D to this low-level API. That being said, however, the specific portion of the game which deals with graphics is not a large portion of the code, maybe 10-15 percent at most. The portion of the graphics code which deals directly with the API is maybe half of the overall graphics code. Somehow you've managed to imply that porting 5-10 percent of the code requires a virtual re-write -- an implication that, frankly, falls on its face.
And who says they need SPUs, or that even if they did that they'd be utilized significantly in a game engine which has been predominantly single threaded throughout most of its life?
Who says that the engine needs to be multi-threaded and use the SPUs? Its the PS3s system architecture that really demands it. The PPU (the single PowerPC core in the PS3, and the same as the 3 in the Xbox 360) is very underpowered. Its the rough equivalent of a 1.5Ghz Pentium 3m despite the fact that its clocked at 3ghz. Next you have to consider that some of that PPU power is designated as reserved by the system software which runs in the background, and that, due to the design of the PPU you must have at least 2 active threads to reach anywhere near peak performance -- Its an in-order dual-threaded processor, meaning that when one thread stalls (memory access, for instance) the other thread executes until it stalls or the other thread can resume. In short, the only way to get good performance from the PS3 is to use enough threads to keep the PPU happy, and to offload anything you can to the SPUs -- offloading is not at all optional for any modern game.
Perhaps Valve should have the foresight to make their engine more portable to begin with rather than bitch that a system (be it Linux, Mac, PS3, Wii or whatever) DARES to not use Microsoft proprietary APIs.
I've already touched on the fact that, in all likelihood, valve will be porting from one proprietary API to another. Even assuming that it had been targeted at OpenGL on the PC, there would still be some amount of porting involved in targeting the OpenGL|ES + extensions found on the PS3 -- easier, yes, but still no free lunch.
But I think this last statement reveals your true motivation: you're steamed that valve didn't support OpenGLin half-life 2. I'm a huge supporter of OpenGL, especially with all the changes coming in 3.0 and Mount Evans (not to mention OpenGL|ES, which is awesome) because I agree with, and support, the philosophy of open standards. That said, in terms of retail software, OpenGL is really very much a theoretical standard, while DirectX is a practical standard. By this I mean that a fairly average user is far more likely to have heard of DirectX and perhaps even know its general purpose than they are OpenGL. Add in the fact that Windows PCs are something like 90% of the desktop market, it becomes the de-facto standard in terms of what platform retail software should target first.
The reason there is a Halo 3 is because Halo 2 sold something north of 5 million copies and was the most popular game on Xbox live all the way until Gears of War, even now it continues to fare well. Here's another fun factoid -- the number of matches of Halo 2 played on Xbox live would overflow a 32bit value, or more than about 4.3 million matches.
Halo 2 came about for the same reason: Halo 1 was incredibly popular.
Yes, Halo is Microsoft's main "system seller" -- much like Nintendo's Mario, Sega's Sonic, or Sony's... Kratos, most recently, I suppose. But all of these mascot-style characters and franchises survive solely on their own popularity with a rather fickle public, the world of video games is littered with mostly-forgotten and abandoned former or hopeful mascots.
Adding another renderer certainly does not nearly double the work. These days, a game is 75% assets or more. Code is typically less than 25% of the development effort and the renderer alone is a small portion of that. While graphics are a focal point, you can safely say that the renderer is less than 10% of the overall effort, even in titles known for pushing the graphics envelope.
Also, no one uses DirectInput either. Even Microsoft officially recommends that developers use the standard messaging system to process keyboard and mouse input. Its only use is with gamepads, joysticks and such -- but no one uses those to play games, particularly FPS games, on the PC, so DirectInput's role is limited at best. It's present, occasionally, if the devs were nice enough to support those kinds of devices, but traditionally its been little more than an afterthought handed off to some intern or entry level developer.
Another point, if I'm not mistaken, is that Carmack has said that the Xbox 360 is the Primary Target Platform going forward -- not the PC. It makes sense, consoles are where the sales volume is at. A hit console game can sell 10-20 times the volume of a hit PC game. The PS3 and gamer-level PCs are close enough, technically speaking, to make porting a straight forward effort.
Carmack has also explicitly praised the incarnation of Direct3D found on the Xbox 360 as his current favorite graphics API. While I don't think the days of Carmack's stalwart support of OpenGL are over, the days of his disdain for Direct3D certainly are.
I really fail to see how you were modded informative, since your post was nothing more than an uninformed rant. I, personally, am an OpenGL supporter, especially given the changes coming with OpenGL 3.0 and the following iteration but I'm still going to call you out on your utterly uninformed post. Sorry.
but I'll say it again.
There's no sense in bringing the Foleo to market when its up to 3 times the price of Asus's EEE and less than half a machine. As much as I like the idea of computing devices on less-typical architectures like ARM, MIPS or PowerPC, I can't foot that bill in the face of superior and cheaper x86 based technology. It just doesn't make sense.
I'm sure they thought that they *really* had something before they revealed it. I'm also sure that they crapped themselves the minute the EEE and VIA's competitor was announced.
Intel and AMD have a cross-licensing agreement that was reached as part of a settlement (anti-trust against Intel I believe) to promote cross-compatibility. Basically, the instructions are up for grabs even though each company's implementations are kept secret. One will introduce an enhancement, then the other will integrate it into their core when they can.
MMX/3DNow! are the early SIMD instructions which used FPU resources to reduce cost and maintain drop-in compatibility with Operating systems (The OS stores FP registers on a task switch, while it would not have known about any new register sets.)
SSE has its own set of registers, instruction encoding, etc so it doesn't interfere with the floating point unit (You can't mix FP and MMX code without a considerable performance hit) but to make use of SSE the OS had to be updated to support it.
As we've read here, bit designations have no real broadly-accepted definition and its more a matter of what marketing slaps on the chip.
The 68000 is a chip capable of performing 32bit arithmetic, but only able to load 16 bits at a time, therefore, it was most efficient to rely on 16bit values when possible (even though the extra 16 bits allowed you to do some neat tricks.) Later revisions of the 68000 exposed the entire 32bit data bus without changing the general architecture of the core. Those are clearly 32bit systems through and through. The fact that the 68000 had a 16bit memory bus is really more of a function of a) 16bit memory being popular at the time, and b) had they gone to a wider bus they would have needed to move to a package with more pins (as later versions did) rather than the 64pin DIP which is far easier to work with than SMT or PGA packages.
Intel sells the 386ex for embedded designs, which is a 32bit core with a 16bit address bus also. It helps keep the pin-count low, thereby reducing design and manufacturing complexity of the supporting system board.
I think that the fairest way is to consider throughput -- If you have a 32bit core, but a 16bit memory bus then I'd classify it as a 16bit system. On the other hand, if that 16bit memory bus runs twice as fast as the CPU core (thereby being able to supply 32bits per CPU cycle) then its fair to call it a 32bit system. If you re-double that again, now the CPU core is the bottleneck, and you've still got a 32bit system.
Modern caches muddle this up a bit, because the bus width between the registers and cache can be different than the width between the cache and main memory (then again, they might also run at different speeds). Here, its fair to use the width between registers and cache since its closer to the CPU - even though the bandwidth between cache and main memory may be a limiting factor.
Its possible that features from DirectX 10 could be implemented on WinXP (indeed, most (all?) Direct3D 10 features are supported on XP through OpenGL extensions if your hardware supports it and you have the right drivers.) but make no mistake that it would *not* be the same Direct3D 10 we know from Windows Vista.
One of the major goals for D3D 10 (and going forward) was to release OEMs from legacy baggage, a not-insignificant portion of which stems from the Win2k/XP display driver model which is simply not equipped to provide the facilities that both Vista and the graphics cards themselves need. There's also a signifigant "slimming" of the API (removal of the fixed-function pipeline, cap bits, etc.) which, BTW, is the exact same direction that OpenGL is going.
What really would be the better solution? Creating two distinct next-gen 3D APIs for the XP and Vista lineages? I'm sure the IHVs would love that. Bring the XP D3D10-alike into Vista, continuing the status-quo of legacy-burdened software? Thats very forward-thinking. Hack a version of Vista's D3D 10 onto XP but having wildly different performance characteristics and losing all the benefits that stem from the new driver model? The software devs are just itching for yet another scenario to optimize for, I'm sure.
Simply put, its possible to support most D3D10 features on XP, but it is *not* possible to create a single next gen Direct3D API that supports both Vista and XP without making severe concessions to performance and/or feature set. Sometimes you just have to cut the cord.
Gameplay is always the last thing to be tacked down on any game, so this isn't indicative of any problems whatsoever. They're not making sweeping changes at this point, its all spit and polish -- fine tuning. Something as small as moving a weapon spawn-point a few meters in-game can really alter the outcome of a multi-player game, or the number, type and placement of grenades can drastically change how you approach a campaign map.
Finalizing gameplay is a bit like making a collage, you lay out all the pieces and see how it looks, you fine tune and look again, repeat until you're satisfied, then glue it all down -- of course, through the magic of software you can continue to fine-tune after its out in the wild as well.
Its standard practice that gameplay isn't in its final form until a week, or even days, before being sent off for manufacture.
There's no predicting, at a million pre-orders when last reported, the game is already a qualified hit and we're just over a month out. Assuming an average price of $80 USD (regular @ 60, special @ 70 and collectors @ 130) its generated roughly 100 million in sales just on pre-orders thus far. Halo 2 sold something like 1.5 million pre-orders, and I expect halo 3 to top that, ending between 1.5 and 2.5 million pre-orders when it's all said and done. Add in walk-in sales for the first month, and you're looking at something that may be approaching a quarter billion dollars in sales. Add to that the fact that its going to be a system-seller going into a Christmas where the the PS3 lineup is still pretty weak (the 360 library is comparatively strong in the months leading into Christmas) and the Wii which is still largely unavailable due to high demand (not to mention that it doesn't really compete for the 360/halo audience -- then again, it is Nintendo and they do have a strong holiday lineup as well so they'll be able to sell every Wii they can produce.)
Also, the E3 Halo footage was still Beta content, we know that it looks better by now and also that its a smooth 60 fps. I'm not sure whether Killzone was in-game footage or not (I know that there was a hoopla earlier over their use of pre-rendered footage) and we also don't know if it was running at the desirable 60 FPS mark. Thus far, I have yet to see anything on the PS3 which tops the 360 graphically and doubt we ever will (the 360's GPU technology is a generation ahead of the PS3s after all, and was designed for the console, rather than a PC part tacked on late in the design process when they discovered that multiple Cell processors didn't provide the graphics power they desired at a cost they could stomach.)
My one prediction for this holiday season is that the 360 and Wii will widen their respective leads over the PS3
Its currently a sad fact that the game's industry is becoming more and more anonymous in many ways. There are so incredibly few "superstar" game developers - Miyamoto, Carmack, Wright, Kojima, Itagaki... If I spent some time thinking, I could probably come up with 10 or so names that have some notoriety outside of very small circles. Smaller devs are being assimilated by the big players, team sizes are growing nearly exponentially with each new generation. Its becoming a commodity business, where faceless masses simply provide a product; and it takes a great deal of personality out of the industry.
On top of that, the publishing model works much like the music industry -- The publisher fronts money to the devs, and they don't see a profit until their royalties have paid off the development in full, sometimes with interest. Thats why there's so little innovation, and thats why a single bad title can fold a studio.
And to that I again agree. School cannot prepare a student for every possible situation they may meet. But there are Core Skills, such as teamwork and a certain amount of experience with largish/complex code, that all positions require and that all graduates should leave school with -- and we are falling short of that to an extent that no one should be comfortable with. These core skills are just as necessary as all the theory (which gives them the tools to become proficient in all the possibilities that school simply can't account for.) It definitely is a tough balance.
At any rate, I think we would all agree in principal that the higher-ed (and even down into the k-12 system, in regards to our generally lack-luster reading/math/science skills) could be doing more to better prepare graduates.
I think you've missed my gist again. This has nothing to do with my particular expectations, it has to do with a lot of grads not having all the skills that the workforce needs them to in order to hit the ground running -- I fully expect that they should have to learn the details of their new position(just as I did, and just as I will in any new field), but I *do* assert that they should not have to be brought up to speed on basics, or to the realities of working on a team or on large code-bases. Most grads do not have these skills, even though they are an essential part of the profession they are entering. I'm saying that their education most likely failed to provide them with these skills, and that they did not seek them out themselves. The program I attended spent a significant amount of time building these team skills by developing several complex applications in groups (2 semester-long projects in the first year, and 1 year-long project for each of the subsequent years) under the guidance of professionals.
This isn't about some superiority complex, or necessarily blaming the grads, what I'm really trying to get across is that there is a gap between the skills that the workplace needs new entrants to posses and the skill-set that much of the higher education system here in the States seems to provide. The expectations of the industry at large should really set the gold standard for what and "average" programmer should be, and in turn, that is what the higher education system should strive to meet, if not exceed.
This isn't me looking down from my perch, I've only been in the workforce for about 18 months now and I just turned 24 in June. Every manager and HR person I've spoken with laments the state of the typical CS graduate; I've observed this to be a common thread through each of the fields within the industry that I've been exposed to.
Perhaps this argument is all semantics though. I might have been better off avoiding the term "average." In hindsight its too open to interpretation and not really descriptive of the concept I'm attempting to convey.
Actually, required apprenticeships are exactly the type of thing I'm talking about. Large group projects overseen by professionals are also good (This is what my school did.)
The thing is that, in the states, apprenticeships and even internships are not required or even all that common. They're not always required, so many simply don't do them. Only the good students who want to go the extra mile. I'm not saying that school should try to emulate the "real world" but it is their responsibility to prepare their students for it -- if that means requiring internships/apprenticeships before someone is allowed to graduate, then so be it. Required internships/apprenticeships are much more common in other parts of the world.