I once dreamed about writing a Sega Saturn emulator for PS3 and optimize the use of the SPEs to run the Saturn's multiprocessor architecture. Then I woke up from this nightmare.
There's was i believe a Spanish Guy that actually maneged to put a Saturn Emulator(In needed more development and optimization but still) in ps3 and Pitched to sega but that was to late in the PS3 life and i am sure Sega didn't wanted an Emulator like that there's demo videos here in youtube.
I remember someone explaining once that the PS3's Cell was like hiring a bunch of guys to work for you, but rather then being able to tell quickly telling them what they need to do that day when they clocked in, you had to hold a meeting, complete with a power point presentation. But then tools came around that essentially made the powerpoint for you.
Thanks. That really puts it easier terms for people like me. Sony should have done that earlier but they were a little bit slow moving this generation. Still a great system though.
@@brandonmuse5532 "Sony should have done that earlier" the 140 lines of code you need to write a Hello World program ACTUALLY IS a ton of PREDONE work for the programmer(s). It's not even that uncommon to do this style of coding in the games industry, just that such a task would NEVER run on any other than the main thread, so it's kind of a bad example. The REAL problem is PORTING. PS3 exlusives like The Last Of Us or even the 2008 Metal Gear Solid 4 are stunning and I've never heard a serious programmer complain about being able to write SAFE, multithreaded code. WHAT YOU DO HEAR LOTS OF COMPLAINTS ABOUT is rewriting millions of lines of code "just" to gain 10 fps. Nobody wants to DO that and more importantly PAY for that.
@Nathan Peterson You didn't get the context. So how much do you know about programming? Even if you fully understand a programming language, there can be things we call "libraries". They can sometimes be entire game engines or even just a framework for coding for the multithreaded PS3 architecture. These things have to be learned all the time by professional programmers, apart from also having to learn entirely new languages and frameworks for them aswell... Those "meetings" are necessary (what I meant with my previous post) but nothing special at all in the course of a programmers career, even if you just look at a single year. SO... I don't know what you're trying to say - it seems you don't understand much of what you're criticizing
The best PS3 games were developed either by Sony themselves or by one of their subsidiary studios. They knew the architecture and capabilities of their system much better than any third party developer so they could optimize their games very well. Even today, most Sony titles are extremely hard to run on an emulator due to these optimizations. Cell is indeed a pretty strange architecture. No wonder many third party developers hated it. Xbox 360's Xenon was based on Cell's PPE cores, but without the SPUs. It was a much simpler processor.
It's more like the Cell's CPU was somewhat GPU-like. It would be like three PCs. One PC had a balanced CPU and GPU combo, and the other had a weaker CPU but "stronger GPU", provided you knew how to use the SPEs. Now, if you didn't use the SPEs, you basically had a system with both a weaker CPU and a weaker GPU. Getting from PC #3 to PC #2 was the trick
@@youtubeshadowbannedmylasta2629 You do know the development of the Cell began two years before that of the Xenon though do you not. So yes and that's a fact, the 360's Xenon was based on Cell's cores.
That SPE hello world example does a great job of demonstrating the complexity involved in coding for them. That's exactly the kind of content I love from this channel!
Well you have to make a library/framwork and that's it... also/// Hello World is just a printf you don't use directly the Hardware unlike his example (also some library and engine did exist for the PS3 by sony), it's something important to have the hand on low level... I don't see the problems... complaints are mostly from lazy programmers (understandable tho).... try to do that with a PC... with semaphores and threads... can be messy and yet you'll not have this proximity with the hardware. using the printf function in a main as an example is dishonest Remember it was 2006/2007 it was a beast... 8 cores in a time when it was mostly 1 core or sometimes 2 cores... surely Sony have some balls to do that.
@@technite5360”lazy”? Even studios like Naughty Dog, who were a Sony studio who tried more than any other developer to utilise the CELL could not utilise all of it until basically when the PS4 was being released. You severely underestimate how much of a drag it was to bring performance to even the same level of the 360 for the PS3, no less having more performance
@@hayax I have never seen the point of making something more efficient at the severe cost of development speed. Labor is worth more that hardware so it's just not efficient or cost effective to have something more difficult to develop for. This is why I always use the "slowest programming language", Python at work. I've made a whole web app with Python as a backend yet everyone else in my company just wants to use Java, then they take months to make changes to the code and break all kinds of stuff while I take less then a week to do the same. And at the end of they day, the performance difference between my Python app and their Java app is not noticeable at all.
I legit laughed out loud when in the next comparison the Wii u was running at 60fps vs the ps3 at 30. With the amount of deadlines console titles have, there’s absolutely no reason to make it harder to code for. You’re only gimping your own product from its full potential
I LOVE how you actually integrate architecture concepts like Out-of-order execution. As a Computer Science student I really appreciate you taking the time to explain these concepts and not dumb your videos down to make them more accessible. You made me personally interested in building emulators and homebrew.
true, there are always different audiences, and one shouldn't try to please them all at once, since it's downright impossible. He captures the audience that understands (or wants to know about) the most hardcore details and technical specifications about the hardware and code, and shouldn't change it out, there must be plenty already that cater to the less knowledgeable on the subject, and their job is also not to be frown at.
As a recent CS graduate myself, I feel the same way. Seeing actual source code and how it would run was super beneficial from an explanation standpoint.
One even better advantage of OoOE is the "branch prediction", the CPU can start evaluating both branch, and just discard the side that is not taken once known. Will on the in order CPU, a branch is always a pipeline flush ( we had some manual branch hinting bit, but it is not the same and it was static )
to normal people... it mean it take time and money just to made one game for just one system.... while xbox 360 had similar in chip but more friendly to PC port.... Only few game used ps3 at it full power and to ps4 that still too weak....
It should be also mentioned that the memory layout was widely different between them. Both offered 512MBs of memory, but PS3 had a hard divide offering 256MBs for each system and video RAM. While on 360 you could use whole 512MBs for whatever you needed.
you could use graphics memory as a system memory and vice versa, BUT reading gddr memory from cell was extremely slow (like 16MB/s slow) so extra tricks had to be used for that.
The unified memory architecture of the XBox 360 was also one of the reasons PC ports often sucked, as 360 games weren't designed with swapping textures in and out of video memory in mind.
Another literally big issue on the cell was the big pipeline. It pretty much did the same mistake as the pentium 4 CPUs of using a too large pipeline. The "rule" so far was that the bigger the pipeline, more clock you can put but you sacrifice performance as the stalls last longer, and sony designed the Cell CPU to run at 5Ghz. But as with the pentium 4, the transistors themselves were just unable to reach that speed, no matter how much pipeline stages you had, so they got the performance sacrifice without the clock advantage. But at least they didn't designed it for 15Ghz like intel did with the P4.
LBP3 on launch was destroyed by deadlines. Yeah, it could be because it was being pushed to a developer with nothing to do with the franchise, but the game on launch was a trainwreck.
Me: I couldn't care less about why PS3 was hard to develop for. MVG: *Uploads video about Why PS3 was hard to develop for* Me: Wow I was always curious about that!
sony mistake is try to invest a lot of money to get a powerful chip but they keep it going for 10 years that is very long time for this chip before they can get new chip for ps4... which only for 6 years...without 3 years upgrade chip...
ps1 was the shit way btr then any thing out there like snes and stuff ps2 was the shit btr then n64 or what ever was out ps3 same btr then wii but what a waste off time plus ps3 first consule able to boot lunix and link multi ps3 togeter to build super pc
Your explanation of what went on behind the scene in the gaming development world is simply brilliant. Some of the most interesting gaming content on TH-cam. I always look forward to your vids.
@@schrenk-d BIOS has functions for printing null terminated strings. The assembly is pretty small you just set some registers and trigger a software interrupt.
A few more things: - Sony threatened with "consequences" if they released games on Xbox 360 first before Playstation 3 if they needed more development time. (Because it would give the end-user thoughts that may be Microsoft had a 'exclusivity deal' with the publisher) This resulted in many games being delayed while the Xbox 360 version was well and done (and sometimes even leaked in Asia months before release because the "gold" disc was already with the factory) - Sony spend A LOT of money to fly "cell developers" all over the world to third-party big shot developers like Infinity Ward to help development just so that the Playstation 3 version of the game would atleast look equal to the Xbox 360 version. This rarely gets mentioned as Sony kept this (mostly) quiet. - The difference between Forza 2 and Forza 4 is also insane. Developers learned to code for multi-threaded processors during this generation after years and years of single-threaded performing hardware. It's not limited to Playstation 3 only.
True but to deny that the last of us was as close to next gen as we got last gen would be crazy. I've played that game in PS3 and PS4 the only difference is the extra PS4 power gets it to 1080p
The Last of Us on PS4 doesn't look as good as other games of its generation though. It really does look like an upres of a last gen game , just like The Phantom Pain did. Compare it to the other big PS4 games (including the same developer's own Uncharted 4 which is stunning)...
144 lines of code to output hello world from the spu, good lord, my brain hurts just thinking about having to code using those, calling it a nightmare was not an exaggeration, wow.
To be fair, that's because most of the program is boilerplate needed to interface CPUs. It's not like all programs would always take 50 times the amount of code. The biggest problem IMHO is that the game needs to be structured in such a way that different tasks can be run in different CPUs and synchronise everything. Similar to multithreading, although I imagine this would be harder. I can see why studios weren't willing to use those when developing for multiple platforms. There are already other things to think about (different GPU, controls, etc).
Developers can still definitely optimize quite heavily considering the graphics APIs like DX12, Vulkan and even Sony's own are designed to be async/multi-threaded and low level in nature. They allow graphics developers to heavily optimize the graphics/system memory allocation and rendering pipelines. The initial convertion from OpenGL3.2+ to Vulkan for my own game engine ended up being orders of magnitude more code than it's OpenGL 3.2+ codebase. Graphics drivers make no assumptions nowadays about rendering intent and the majority of the work is put on the graphics developer instead (good thing). There is so much pipeline, memory and thread management for savvy GPU developers to take advantage of and optimize. You're right that systems are more indistinguishable from one another, but it definitely doesn't mean that there isn't heavy optimization to be done. Devs will have to be just as cautions to properly take advantage of the GPUs these low level graphics APIs expose. This isn't even mentioning the use of the hardware threads that modern CPUs still have and need to be maintained/synced in a game engine.
At my University's library there's a book solely dedicated on programming on Cell. Well, not only is hard to program for those SPUs but I've also read that if you want to share data between them you have to do it in a circular manner. Basically if you want to send data from SPU 0 to SPU 4 you can't write MOV SPU0 SPU4 (this is not real Power PC assembly, this is just an example, also check the comment below by Tom schleck), but you have to transfer the data on each concurrent SPU until you reach the desired one: MOV SPU 0 SPU1 MOV SPU 1 SPU2 MOV SPU2 SPU3 MOV SPU3 SPU4. What a mess. This aspect was mitigated by the fact that the CPU can send data to whatever SPU you want but still it's a complicated business.
@@Rex-zm7xb They no longer use it in any of their products. Only legacy customers can get support for it. It's similar to the itanium stuff. You can get parts if you pay the crazy support fees but they no longer offer it to new customers.
@@brpadington yeah, in the book the Cell architecture is presented like it is some kind of breakthrough in the super computers market. They even wrote how to install Linux onto the console to install the Homebrew SDK, a few years later Sony pulled the Other Os feature from its console.
Yeah man! Tell me about it 😄 It's said that thing still had untapped potential when it ended so I am literally so curious about it's coding and architecture
Both consoles had the same issue where the proposed hardware was drastically changed later than it should've (adding 3D acceleration hardware to the Saturn, and replacing the second Cell processor with a GPU for the PS3). The PS2 was also a nightmare machine compared to the competition but it was a well thought out nightmare that could play DVDs as well so everyone dealt with it.
As a computer geek i will always love the cell and if the industry had caught on and cells were made it would a very interesting i mean multi core and low latency thats basically were computing has been moving for the last 15 years anyway
Their CPUs were vector/floating point monsters - a very important thing to have in a system designed for graphics, real time physics, animation, and sound. The problem with both CPUs is they lacked other performance metrics more needed in traditional non-gaming computing. Xenon actually still retained some semblance of this, while Cell went full retard on vector performance, because Ken Kutaragi of Sony thought everything could thrown onto floating point and vector engines, building off what the Emotion Engine was in the PS2. A good example of the gaming processing landscape changing, is that a dual core PC CPU from 2005 would struggle to run GTAV as well as the Xenon on 360, which has the same transistor count as a *single core* Athlon 64 w/ 1 MB L2 cache from that same 2005 era. It highlights how vector/floating point dependent games got to run such large, interactive worlds, where as integer and branch prediction performance really wasn't as important
@Transistor Jump The Xbox One and PS4 both use AMD APUs (basically their series with iGPUs) from around the early 2010s. edit: specifically, they use the Jaguar microarchitecture from around 2013... so I was a little off.
@Transistor Jump The PS4 Pro came out in 2016, and 2010 was just an estimate (2013 is still early 2010s). Not to mention they still use iGPUs that are worse than any dGPU today you can get for the same price as the console itself.
It's even more impressive that a group of developers were able to reverse engineer the ps3 and build an emulator for it. even metal gear solid 4 is able to run on RPCS3 at 60 fps at 4k
I was suprised when they made mgs4 playable in just 2 to 3 weeks. Still they have a large amount of work to do with getting other Sony exclusive. God of war 3 and ascension do seem to be coming to playable state.
There should be a major asterisk here: so far it runs at 60 FPS only in some less demanding places only on very powerful CPUs and only on custom builds.
They didn't make MGS4 playable, BSoD's video and the dsoGaming article are clickbait. All the developers and admins are annoyed because it's misleading people into thinking it runs better than it does. The DSOgaming article says it runs at mostly 60fps and yet, they didn't even mention the hardware used. You need to use a custom build which still has crashes from time to time and performance requires a top of the line CPU for even half-decent fps. An overclocked 8700k cannot get 60fps everywhere, its more like 40-50 and will dip below 25fps in some scenes like the REX chase sequence.
If you think about it, one of the reasons Naughty Dog was able to get so much out of the PS3, it was because they were a Sony exclusive studio. They didn't have the pressure on them to release cross platform games and only had to develop for one system. This made a huge difference in helping them push the PS3 resulting in games such as The Last of Us and Uncharted 3
They were also part of the ICE Team which was a team Sony created 2 to 3 years before the launch of the PS3 to help create libraries and learn how to best use the CELL with its SPU's. Because of this, Naughty Dog and also Insomniac are probably by far the two developers that know the most when it comes to programming to get the most out of the CELL. Naughty Dog had 8 to 9 years at this point of CELL programming experience when Last Of US came out so they really had a massive advantage compared to others. Not having to worry about other platforms also helped them like you said.
Not really the devs fault though, especially when other devs have to work on those ports without the original devs supervision. Either they need a lot of money from the publisher or a lot of money and the help of other first-party devs. Short answer: You get what you paid for.
honestly I've always wanted to know how much did Persona 5 took advantage of the PS3s hardware, it was released in 2017 & it's easily one of the best looking games of this generation despite being on a last gen console..
I think almost every game with that kind of art style looks great. For example, look at those 2D art style games from many years ago how great they look. Ni no kuni on the PS3 and much more.
while persona 5 is my favorite game of all time, it's graphics were definitely pretty average. It's the stylish aesthetic that makes the game look really good. Many anime games look way better than persona 5 when it comes to graphics.
The Cell processor was just a precursor to modern GPGPU programming - the CPU was basically meant to offload work onto little programs running on the SPUs much like modern games would offload physics and stuff onto a shader. It's just at the time developers were kind of clueless to this sort of programming so it seemed exotic and hard because their games weren't designed around that sort of pipeline.
Honestly yeah, it's not that Sony gave up to the idea, it's rather that all those SIMD instructions are now baked into the everyday processors we use. To this day it's still hard to write good code that utilizes your hardware fully, and seeing the date that all this debate took place, it occurs to me that devs needed to "git gud". Proper tooling that abstracted away intrisincs might have helped, because even today I'd argue most devs have no idea over how to code with AVX512.
I remember how piss poor early ports were. The 360 killed it on multiplats especially madden. The first madden on ps3 ran at half the speed of the 360 port. Really made that 599 i spent look extremely foolish at the time.
Heh, I'm kind of flattered to part of the chart I made for PS3 backwards compatibility on PS4 at 8:20. That whole post really took off a lot better than I thought it would. 😅
@@ModernVintageGamer imgur.com/gallery/zGJ1v Idk if TH-cam will allow this link but this was the original post I made on Imgur. ^^ Honestly, just a link to that and my alias (SilverAura) will work. I'm too humbled to expect more.
@@Crashandburn999 It's kinda true for most consoles at launch lol. PlayStation 4 was frequently criticised the same way too... and look how that turned out XD
@@Reydriel The ps3 was even worse for it though. The ps4 at least still got all the 3rd party titles releasing on it, the ps3 was a console that devs wanted nothing to do with early on, so it didn't get most 3rd party multi-platform titles until about 2008 or so. There were actually games being released on ps2, xbox, xbox 360, pc, even wii but not ps3.
@@josh18230 Memes aside, the PS3 does have some pretty amazing exclusives from Sucker Punch (inFAMOUS 1&2), INSOMNIAC (Resistance Trilogy, Ratchet & Clank Future Saga), Naughty Dog (Uncharted Trilogy, The Last of Us) and Santa Monica (God of War 3, Chains of Olympus & Ghost of Sparta Remasters).
just goes to show you should always think of the developers when designing your hardware. you can make the most powerful hardware in the world but its useless if no one wants to develop for it.
Oh yea. The PS3 did not have a unified memory architecture unlike the 360. It was 256mb for the CPU and 256mb for the GPU. And usually, GPUs consume much more VRAM due to huge textures and 3d models. The benefit 360 had was that if the CPU was only using 100mb, then you had around 400mb of VRAM all to the GPU which mean higher res textures or more detailed character models.
@@PurushNahiMahaPurush But why in GTA 5 and L.A. Noire grass on the ps3 could be seen. But when I checked Xbox 360 the grass was bleeding with the ground and blurred. How? I was dissapointed
@@SalmaKhatun-ow6bf simple is xbox 360 don't had that extra power to run those thing... it was more simplify which most dev are train for while ps3 require addition coding and skill... it like the car with 12 cycle but you only know to made v8... it just not going to work...
This is really interesting. I thought previously that the PS3 was simply hard because it had more cores/distributed hardware and multicore parallel programming is hard. I had no idea the Cell was essentially a dual core with extremely low level coprocessing units.
Jetsetlemming I’m no computer science student, but as for PS3 co-processing unit - does it mean that they don’t have/build a simple call function for developers to utilise like in modern game engine’s library or whatever correct terms for it?
it was not really good in gaming... since og design is for running server.. but due to it powerful load compare to power to run.. it is very good but just the xbox used the modified one that are alot cheaper...
I wrote my master's thesis on the Cell BE processor, for extending an H264 decoder. It was quite the experience - the SPEs indeed needed very low-level code, and the Cell processor was only fast if you utilized all six SPEs, and also made sure to utilize the DMA memory streaming features. There's one thing you didn't mention either: The PS3 only had 256 MB RAM, and each SPU had 256K - code and data combined. Access to main memory needed one of these DMA accesses, so you constantly had to stream through data, which was a pain in the ass. Parallel code is hard, and the Cell BE required you to manually parallelize everything. That small amount of local memory also meant: No C++ on the SPUs, C only - and you had to be very efficient in your coding, otherwise you wouldn't have space left for any data to process.
@Rob Wyatt That, too - yes. To write any kind of efficient C code, you had to make heavy use of the intrinsics they defined, which were essentially Assembler commands wrapped in C. The compiler didn't help you there.
Maybe I'm crazy, but I always thought there was an element of future-proofing in the inanity of the PS2/3's architectures; it ensured that games would consistently improve in graphics and performance throughout the console's lifetime as developers learned to navigate the system.
Somewhat difficult. The CPUs were using paradigms that weren't very common. You literally need several years of experiment and/or trial and error to really know how to use them
For the PS3, it would have been hard for that era. Games were just starting to become multicore. Even on PC, CPUs were starting to hit the limit on single core systems. The whole video game industry was going through a transition. The Xbox 360 was even hard to use at 100%. PS2 era? Also hard. The problem with game consoles is that you couldn't slap in the most powerful PC CPUs because of the amount of watts they would use. Game consoles need to try to not be over around 250W or so. Game console makers especially in and before the N64 era were trying to figure out clever ways to get the CPU power with that power envelope This whole "percent of the console" is also ridiculous. It feels like a marketing ploy to keep the Sony fans happy since the console was marketed with "potential". It feels like there were Sony PR agents especially trolling gaming forums. It sounds like Sony chose to go more conservative lately by using an AMD-derived CPU The issue for consoles isn't just hardware, but software and education. What actually made the Xbox a viable product: the developer documentation was in English. CPU core counts also only scale so far. Once you hit a certain core count, with games especially, it starts becoming more of a GPU task over a CPU task.
I'm surprised you didn't mention that Portal 2 was cross platform online play on the PS3 with the PC. You even got a free PC copy with the PS3 version. My brother and I had a blast, I was on the PS3 and he was on his PC it ran absolutely fantastic, I could see my brothers POV in a small window in the corner of the screen with no hiccups at all. I always hoped Valve would've brought more cross online play games, i'm sure there was rumours about it but it never happened. It's obviously more common now, but back then it was mind blowing. 😁👍
Kaz did an interview on that, stating that, for example, the PS2's texture fill rate was much higher than the PS3's, thus preventing them from implementing the heat haze effect in GT5 that was formerly in GT4 and GT3.
Very interesting stuff. This explains why some later PS3 titles were better optimized than 360 titles, yet so many cross platform titles in the early days of that generation performed much better on the 360.
Ps3 vs 360 reminds me of snes vs genesis. The snes was thought of as more powerful yet games that were on both systems almost always played smoother on Genesis. But games that were optimized for snes specifically could technically be better.
@@Matanumi Genesis has the faster cpu, and the higher resolution, but in all the other categories snes ranks higher. It just depends on opinion for which one is better.
For me all the Japanese games that I cared about looked better and ran better most of the time on the PS3, it was a brilliant system and I had a far better time with it and its games than I did the PS4.
@@statesminds I swear, the guy who was in charge of selling the Xbox to Japan couldn't have done a better job. They found Sakaguchi and asked him to make what basically is the real Final Fantasy XI / XII / XIII with Lost Odyssey. They even triggered Blue Dragon with Akira Toriyama designs to emulate a "Dragon Quest"-like adventure. Furthermore, they were able to snatch Final Fantasy XIII from being a Sony exclusivity too ( the game is seen badly for good reason, but it still sold insanely well ! ), they were about to get the latest Tri Ace game with Resonnance of Fate or Star Ocean, the latest Tales of with Vesperia. But that's not all ! They took the arcade by storm with most rhythm games being ported for the 360, Cave was on it too. All the latest shmups were on the 360 ! Including the very otaku-oriented Otomedius by Konami. They even made a new very profitable license Idolm@aster which was a huge success only in Japan. Really, there is no parallel world where that guy could have done a better job of making the Xbox having japanese game. He has done EVERYTHING he could... And despite that Japan didn't wanted the 360... The PS3 sold better there...
I did a year studying software engineering (wasnt for me) around 10 years ago. I really enjoy the more in-depth programing aspects you give in your videos. Also with the consoles its crazy to look back on the older in terms how how the visuals improved with newer games. Its a bit of a shame there isnt any secret weapons anymore hardware wise. The current gen consoles werent a massive jump visually and due to hardware/architect we havent seen a jump during the lifespan
From a high level, the PPE looks a lot like an Intel Atom (the original ones), being in-order, dual issue architectures with SMT. The PPE has a deeper pipeline to push higher clocks however.
Python print("Hello, World!") looks like it's just one line of code but it's NOT EVEN CLOSE to 1 CPU instruction :-) That's the trade-off: fast and simple to understand vs fast executing code.
@@chrisakaschulbus4903 Depends on your system. An Amiga with Bridgeboard (Zorro expansion) and/or co-processor on the system bus had no problems whatsoever in specifying which core to use when. In fact that was the easy part of programming the Amiga, it was the rest which was fucking hard. Agnus, Denise and Gary mostly. Hard but satisfying as the result for that time was just incredible. Amiga was so far ahead that it took PC about 8 years to somewhat catch up. At the height of Amiga we had 4 channel stereo sound and millions of colors against the PC at the build in speaker noise and 4 colors max.
Another thing worth mentioning was the unified memory on the X360 being 512mb vs the split 256/256mb CPU and GPU.on PS3. This made open world game streaming much harder since your memory pools needed to be more aggressively managed. The technique of doing work on the CPU and having it available for the GPU was not effective and you would tropically just pre bake the operation on the disc since you had up to 50gb to stream from.
I'm so glad I dabbled in C++ a bit, it made it so much easier to understand this video. I kinda see this as parallel to CUDA cores on nvidia, however in that case, games didn't end up using it for more than "optional" features, such as physx.
Man, you just keep on stepping it up with every new video! The technical explanations are just perfect. I also liked the last segment where you talked freely, that felt really “up close and personal” as compared to some other videos of yours where you apparently read the text. Please keep it up!
HAH! YES! Amazing video and captures it perfectly! I remember writing my SIMD Vector/Matrix math library and ported it to CELL using IBM's Broadband Engine emulator. The test harness ended being more work than writing the actual math library!
I always knew it was harder to develop for PS3, but never exactly why. Everyone tossed the word "architecture" without actually explaining it. Thanks for the video!
To some extent, the PS2 was the same story. It was popular due to it's DVD player functionality though. Some early multiplarform games looked better on the Dreamcast as a result.
The PS3 had a Blu Ray drive, so it also had a media advantage over the 360. It wasn't quite as effective as with the PS2 though, since having a DVD drive was good enough for most consumers in 2006.
The Xenon CPU sounds so crazy for the time. Three cores with SMT when Intel desktop CPUs had two cores OR hyperthreading. But the Xenon only had 165 million transistors, while Intel's single-core Prescott 2M based Pentium 4s had 169 million transistors. So there were 3 cores but they were much smaller than contemporary CPU cores.
1:35 "here a lot of thread could be spawned" Well.. note really. The issue here is a lack of terminology. This is not really threads, but rather program branches. The PPE could branch of a task to a SPE to finish this task. Very much like a FPU does. In an effect, the SPE is sort of a standalone FPU with some added capability. The main diffrance from a FPU is that the SPE can run the code independent of the ALU that is in the PPE. So the PPE branch of a task, that is not really a thread, to a SPE. Then the PPE keep working with something else, and can branch of a new task to a other SPE. A normal CPU stop working when it branches of a task to the FPU and wait for the result... The important bit here is that the PPE and SPE run in the SAME thread. This is important because some calculations need to be done in a specific thread, making multi-threading of that task hard, if not impossible. This is for instance exporting data to the GPU. 6:15 "by simply breaking code out as a thread" While this can in theory be done, but in most cases its not as simple. Now there is a lot of stuff that can be done in the compiler. Breaking out a thread is more complicated then accessing a SPE, so this is just plain wrong. 6.30 "those SPE is needlessly complicated" That is not the case. They are really not that hard to make code for.. The issue is that you have to actively use them. And here is the major problem. Most cross platform game of the gen 7 era was made on either PC or Xbox to begin with. Then simply just recompiled. Recompiling a DX 9 game to Xbox was really not that hard. And Microsoft made sure that the dev tools used the processor as efficient as possible. Most programmers spawn threads, not really when its needed, but when its practical. So if a subroutine work independently, they spawn a thread on it. This generally did at this time leave anything from 60-90% of the workload in the original thread. The real issue was that most devs after recompiling the code for 360, then just recompiled it for PS3. PS3 have all the functions of the 360, and them some more. But then totally not using the call for the SPE, that IS NOT COMPLICATED. There is not to much of a diffrance making a AVX call to making a SPE call. The thing is, the code will work either way. If the game is originally made for the PS3, it can´t be recompiled for the 360. It need to be change to run The Hello world example is kind of stupid. You just order the SPU to return the value you send to it. It literally does nothing. The same thing, if you wanted the hello world to run on a different core than the one that started it, the complexity would be the same, or even worse, because if there is dependencies in the code to the thread, those have to be taken care of seperatly. The argument is pretty much the same as to say that a 286 is better than a 386 becasue if you write the code for a 386, it will not work on a 286. The whole idea that games used more threads was not really even correct. Most games when this generation launched really used one main thread. Look at the game ported to PC during this time. Reduce the thread count to 2, and the performance will hardly even differ. Was really until very late that era, like battlefield 3 where the main thread used less than 50% of the performance. With BF3 the performance increase almost linear until 3 threads, and the bump to 4 threads is quite considerate.... The look at Crysis. It just run one solid thread. That is it.
I love this channel when you go into actual C or assembly code to show off the architecture or instruction set. Most people can't even do the research on this let alone present it properly, but you actually seem to know it outright. Well done m8.
Sorry for my English...I worked on XBOX/PS3 Rainbow Six Vegas game. The development for PS3 was a real pain, especially when the main platform was Xbox. The Xbox was our main platform, with a small team for PS3. Basically, they took more than a year, just to make the run at 1-2 fps on PS3. Think about that, it took months to compile, months to start without crashing, months to display something else than a black screen. When the Xbox version was finished, the game was still barely running on PS3 (It took 9 more months to finish it) The PS3 had more power than Xbox on paper, but in practice it didn't: a lot of its computing power (SPU) was for calculations, which is not needed much for a game. Personally, I never saw a game on PS3 that runs better than its Xbox version. Problems I remember: - Low cpu power: 1 CPU 2 threads on PS3 compared to 3 CPU 6 threads for Xbox - Low system RAM: Video RAM (256 MB) and system RAM (256 MB) separated on PS3 instead of unified RAM (512 MB) for Xbox - Operating system (OS) using too much memory - low GPU performance: pipelines were weirdly inefficient compared to xbox - Hard to get power: SPUs only had 256k RAM each, running separate processes, required DMA requests access main RAM and PPU, specialized for calculations, tricky programming - Shitty API: not consistent, not thread safe, not reentrant, buggy, voice chat had to be redone, bad Sony support etc. - Inferior development platform: code warrior vs visual studio And the list could have been longer, there was a lot of problems. The biggest problem was the memory. The Xbox version used 510 MB (375 MB for game data and 135 MB for video). Now try to fit 375 MB in the 156MB available on PS3... oh yeah, the OS takes like 100 MB from the available 256MB (I cant remember the real amount, but it was high). The lack of CPU and GPU power was also bad (I am not familiar how it was fixed in the game). Months of work to split and simplify game levels in smaller parts, optimize memory, remove stuff, push some game data into the video RAM, simplify AI, decrease textures, decrease models complexity, doing weird hacks, etc. to be able to have an ugly, low fps, low resolution game. By hack, I mean something like that: before you open the virtual keyboard (which required 10 MB of free RAM), the game moves some game data from the RAM to the hard drive and when you close the VK, it moves the game data back from the HD to the RAM... It really have been unpleasant to work on PS3.
Incredible video. As always I love the technicality and architecture explanations. As well as that code sample for the SPUs, that was really great to see, especially with all those comments and explanations. Great work. It was really appreciated and very interesting
Sony wanted 3rd party exclusives, which meant getting devs used to developing for their system and no one elses, that's why 3rd party devs didnt like ps3 because they had to learn twice as much to develop for all 3 (PC) systems.
I remember being in 9th grade during Final Exams in June 2008 in my computer class. I'd use Wikipedia to learn about the clock speeds and compare them between all the consoles lol.
In a way I miss the days when game consoles used exotic hardware that you’d need a super expensive pc to match. These days we just have budget pcs in a custom case with its own OS
Well it would have costed a lot of money to create a custom gaming CPU based on high-end CPUs of desktops for PS4 In 2013, the XB1 at $500 could have opted for better specs it wasn´t sold with gimmicks like obligatory kinect
i think you look at it the wrong way, consoles are everyting a cheap pc would be for gaming, and the fact that next gen consoles starting from 7th gen are basically multimedia, streaming and also computer (using otherOS on PS3), its just a step for consoles to be mature and powerful enough to be a genuine pc
@@ThisBirdHasFlown Gta5 is actually pretty simple mechanically. Getting the physics to work in GTA4 was a miracle. Everything had active dynamics physics running at all times.
I've been doing programming since the early 1980s, and professional development for over 25 years now. I've had challenges where I needed to get every last bit of performance out of a system, such as a Mandelbrot set generator on an Amiga that was optimised down to the last CPU clock cycle. But you know what? I'm past that. I write code that runs exclusively on a virtual machine. Performance is a consideration, but more to the point of not doing anything really stupid. (Quite contrary to some of my predecessors, I might add.) I think that, as time moves on, the physical architecture will become less relevant, and we developers will be writing code on virtual machines that other people have optimised for us. There's only so much that the head of a developer, or a team of developers, can contain. Because systems are incredibly more complex than even 20 years ago.
The Cell vs Xenon comparison is over simplistic without going more in depth on each processor's various aspects and how developers were expected to use them. Few people realize that the Cell Broadband Engine itself was a developmental dead end not just because of developmental difficulty, but for it's utter disregard for non-vector/non-SIMD processing outside of the PPE core. Cell didn't have the total integer or branch prediction capability to really back up all that floating point performance, along with oft-mentioned in-order processing issues (though this saved on transistor cost). Despite less that half the floating point capability, Xenon created much fewer developmental woes as it had three PPE cores, each based on the same branch prediction, integer, and load-store capabilities as the PPE on Cell, except, well THREE PPEs instead of one. Xenon's PPE also had a more capable and flexible implementation of the VMX128 vector processing unit with two sets of registers and the ability to run both processing threads through the VMX unit consequently. The Cell PPE was not designed for this, as it was meant to rely on the SPEs for floating point/vector/SIMD performance. It's a whole 'nother can of worms to even go into why Cell was designed the way it was. Alot of bad predictions of the part of Sony (esp Ken Kutaragi), Toshiba, and IBM.
Sorry for a late reply, but I'd actually be interested in hearing about why those bad predictions were made, why Sony thought the things they did was the right way forward and so on. Are there any articles or so you can link to that talks about this?
@@goranisacson2502 Sony and Kutaragi thought they could vectorize/SIMD accelerate everything under the sun when branch prediction and integer performance are still important. Just look at the difference between Cell and the octo-core Jaguar set up. They swapped half the theoretical vector/SIMD capability for multitudes better actual non-SIMD performance that Cell and Xenon to a lesser degree both highly lacked. In turn they created a developmental nightmare for a gaming system. Required alot of memory management to take advantage of it's stream processing capabilities. The Cell BE made quite a bit of sense for IBM server computing since they could pair it with x86 processors to keep in under command and treat Cell as an accelerator. Cell was already quite big with the 8x SPEs, the PPE, all the internal interconnects and cache. Adding another PPE would've made the chip bigger and more expensive, but would've eased some of the woes.
seems like all that threads starting on the spu's could have been built into the compiler and made easier. its repetive but fairly simple. but simple and repetive are perfect things to automate with software. seems like all those lines of code could be built into a librairy or command and just put the command at the start of the function or whatever
I suspect a lot of games didn't have their code neatly threaded. Multithreading in general was pretty limited in those days. Therefore there were probably threads which bundled what probably should have been two or three threads together. Unbundling this at least would have to be a manual process.
@@rbauer961 it was a sad time when game developers tried to adopt enterprise development practices, such as OO, which really doesn't mesh all that well with threading, and especially not the SPUs
I just discovered your channel and I’m really enjoying your topics especially in light of the time frame. It gives you a current day take on things few people might have cared about say 10 or 15 years ago. Also, I love the shirt, I’ll have to find that one. I’m a Neo Geo enthusiast and collect both MVS and AES.
Thank you! I've always been curious as to why the PS3 was hard to develop on. I honestly feel bad for those who had to program on the system. Despite that and the performance drops in multiplatform games, the PS3 is my favourite console of that era. I did start with the Xbox 360 because of price. I do have fond memories with both systems!
The SPEs were also focused on doing vector maths and CPU programming back then was mostly based on scalar logic. You could get massive speedups by unfolding loops and running them on the SPEs, but devs weren't used to doing that. One of the interesting things about that is that since then not only we've seen a big push for vector maths execution on CPUs (through stuff like SSE and AVX/2/512), but a pretty strong adoption of GPGPU, that follows similar concepts. PS4 GPU has extra hardware that makes GPGPU more efficient on it, and you can be sure that first party devs, being pretty used to this kind of programming paradigm, made good use of that.
7:23 With all due respect, I think it's unfair to put "Hello world" into complex architecture and then say its unneededly complex. I think its more of an issue with development managment. Its not like coding for NES or GBA was all rainbow and sunshine. My guess would be that XBOX360 was the culprit. It offered easy solution, whilst PS3 required work and effort to utilize system to its max.
So your solution is to work harder than necessary to achieve the same results? Making something hard to work with does not make that thing better. The 360 ultimately was just as good as that console generation could be and was the easier machine for the devs to work with. That makes the ps3 the definition of needlessly complex
My solution is to use and utilize hardware for the things its made for, not rushing lazy ports (like Red Dead Redemption 2 for PC). Benchmarking two consoles on ports is not a fair assessment. Comparing quality of exclusive games that utilize consoles to the max should be a primary factor.
@@LemonGingerHoney There are a few problems with your assesement here. Firstly, Benchmarking ports on console is a fair assessment. You can't sell a system on just exclusives (see the Wii U, Saturn, PSVita etc) and expect it to succeed. People buy consoles with the expectation they can play most games that release. Secondly, comparing quality of exclusives is also arbitary as a means of judging a system. Suppose I make a system that can play Space Invader better than every other machine on the planet but can't play any other game. I doubt the machine would last longer than its novelty
I am learning about multiprocessing, multi-threading and code architecture for my current Computer Science project. Very interesting to hear some of these concepts in regards to the consoles. I always wondered why the xbox 360 had a better game ecosystem despite the less powerful CPU. This has been very revealing and makes a lot of sense.
4:30 Some of the architectural features (like out-of-order) can be handled by the compiler. In some cases the compiler knows what can be reordered better than the CPU. Pulling things like out-of-order and speculative execution not only save money, they can save power as well (which again I guess saves money). It would be interesting to cross reference the compiler technology at the time that coincided with the decisions.
The compiler can reorder static code, but as soon as you do anything dynamic (branching code), that all goes out the window. Games tend to be extremely branch heavy, so relying on the compiler to reorder is pretty pointless.
@@adamk203 For starters, it's not "dynamic". You're thinking of control flow code. Second, just because you have control flow code doesn't mean the compiler can't reorder it. You should probably go ahead and cite a source for your assertions. For a compiler, it's called Instruction Scheduling. en.wikipedia.org/wiki/Instruction_scheduling And yes, they can do control flow code. Instruction reordering can occur in both the compiler and the CPU. It's roughly the same thing, except again the compiler (actually I should say the entire toolchain because optimizations occur through the entire toolchain) is usually going to know more about the data and its dependencies than the CPU at runtime. Having the toolchain do it costs you build time. Having the CPU do it costs you power and die size, plus you'd better make sure to validate it else you get a grievous hardware exploit.
GoatZilla You have no idea what you’re talking about. Compilers can only perform instruction scheduling on code where the order of execution is known ahead of time. Also, control flow is dynamic (as it occurs at runtime vs compile time [static]). Any branch taken forces the CPU to load and reorder a new set of instructions. This is why branch prediction and OOO are so important. If compilers could run once and reorder everything in advance, there would be no need for OOO. Yet, we see that the performance advantages of OOO are considerable and any architecture leveraging performance is going to make use of it.
@@adamk203 The code is not dynamic, therefore just stop calling it dynamic. The compiler can reorder control code as long as the program's meaning (semantic) is followed. The compiler just gets to take into account a much larger program scope to make its decision. If a CPU is forced to flush its entire pipeline every time it gets to a branch, that's not exactly a ringing endorsement of CPU OOO capabilities. Flushing the pipeline isn't a feature, it's an incredibly expensive penalty. I don't know why you're talking about it like it's a feature. And yes, branch predictors are designed to help mitigate this. Along with speculative execution. Which is how we wound up with Meltdown and Spectre. Turns out that dreaming up some wizbang feature isn't enough -- you also have to figure out how to formally validate it. All the reordering that you did just to throw it all away, all the flushing, all the branch predictor logic, and all the speculative execution are all very, very expensive in silicon.
GoatZilla You’re just some scriptkiddie who thinks you know everything from reading a bunch of Wikipedia articles. I do this stuff for a living. “Dynamic” is a perfectly acceptable term when referring to program/control flow during execution time. We’re talking about object-oriented programming, not a block of BASIC with a few GOTO statements. Branching is completely unavoidable in complex code, and flushing the pipeline is thus also unavoidable. That’s why branch prediction is so important - for each correct prediction, the pipeline is already filled with the next instructions, ready to be executed. Any in-order architecture must also flush its pipeline upon branching - and because there is no reorder capability, a branch can lead to severe pipeline stalls. In-order architectures are terrible for anything other than repetitive calculations, and thus are limited in practical application.
I'm so glad I found your channel, the immense amount of knowledge and information you share with your viewers with is absolutely mind blowing! Thank you so much for each and every one of your videos, they are always appreciated. (:
Splendid material dude ! I understand that you are (or were) a very competent programmer. Sometimes it really takes someone who really knows what they're talking about just to understand the complexity of the issue. Thank you !
I’m glad you did this video, I’ve always been curious why ps3 ports were always worse than Xbox 360 despite Sony’s claims that the ps3 was powerful. I guess my question was why did Sony decide it was better to design the PS3 this way?
One of the least appreciated aspects of the C64 was: It was cheap, widely available, and the moment you switch it on, anyone with a BASIC understanding of programming could write code - or load a game. Imagine that: You turn on a computer, and can immediatelly type code in an easy-to-understand language. In a sense it was the ultimate "homebrew"-machine, and this low entry-barrier was the reason, why so many programs and games were released for it.
For those of you reading this comment in 20xx: Grab a ZX Spectrum emulator and try programming on one of those. It had a surprisingly nice line editor for its time, and still holds up as, well, pretty usable.
Regardless of all the flak the PS3 received, it’s still my favorite console from that generation. I own 3 launch day mint 60GB PS3’s complete in box, and I still love to game on the PS3 to this day.
My wife got me a PS3 for Christmas. I wasn’t expecting it either. The first game I played was Uncharted 2. After playing it for 10 minutes, after the train scene. I stopped playing because I wanted to play the Uncharted first. Luckily Blockbuster was open and I went there and they had a used Uncharted game for sale. I still have those games. Those games means a lot to me.
Hehe The Orange Box always get's thrown in as the example of a bad port, but it's not horrible :). Also, the servers for Team Fortress 2 is still online, which is just amazing, almost 12 years! Shame that the Naughty Dog server shut down earlier this year, but outstanding support from EA to outlast 2nd party Sony games. If anyone still plays TF2 on PS3, I hope I see you there! I play each week and usually upload my sessions as well.
Salesman: "Sir, can i interest you in our latest invention? This car does 300MPH and costs just ten grands, but you need 5 years training to drive it, because we didn't bother to optimize the controls." Customer: "Uh... no thanks." Salesman: "Damnit. Again! Maybe we should just stop innovating and sell the same boring cars as everyone else." Nope, they didn't learn jackshit.
@@bitelaserkhalif Again having same architecture doesn't mean easier emulation, they still have deal with kernel and firmware and also that is a custom chipset. Alexaltea(main developer of orbital, a PS4 emulator) already mentioned in it in Reddit.
hey Modern Vintage Gamer please make a video like this but about the Wii U comparing its CPU/GPU against the xbox 360 and ps3. This is so interesting to see and your explenations/examples are great!!!.
That’s not why OOOE was removed. Well, it was, as die size is cost at the end of the day. But it was removed because the SPEs in design were moved from 6 -> 8. And that blew the die size up and meant picking between SMT and OoO for the main core. As the main CPU core was built for the cell CPU only, initially.
@@MrAckers75 Well It's more the case of devs spending more time and money on making long boring cutscenes with expensive celebrity voice actors that they put in expensive motion capture suits so they can parade them around on E3 and other press events to impress dumb games journalists and share holders. Also, it's expensive and time consuming to build an entire game around collecting items like costumes, emotes and other useless crap that they can sell as microtransactions or hide inside loot boxes. They say they need microtransactions because video game development is expensive, then they go ahead and pay millions to celebrity voice actors and license holders. How about spending some of that money on bug fixes and optimization? Just an idea
@@MrAckers75 No. They don't actually. Games were actually far buggier before and devs today have far larger QA departments and resources to solve bugs. Given how much more complicated systems are now, It's surpising it's not more buggy, But seriously, watch any% speedruns of older games and you'll see how much buggier they were.
Gabe newel only said it was difficult because it has a 3
I knew it
*Boo!*
The PS4 is not hacked because of the 4
Git gud
Omg you confirmed it 🤯🤯🤯
I once dreamed about writing a Sega Saturn emulator for PS3 and optimize the use of the SPEs to run the Saturn's multiprocessor architecture. Then I woke up from this nightmare.
PFFT
There's was i believe a Spanish Guy that actually maneged to put a Saturn Emulator(In needed more development and optimization but still) in ps3 and Pitched to sega but that was to late in the PS3 life and i am sure Sega didn't wanted an Emulator like that there's demo videos here in youtube.
@@Cholimao that sounds like a lie lol
That definitely sounds possible. It may be very hard to do, but it seems possible.
@@LeseanDeVon Not verifying, if it’s a lie or the truth, but I heard the same rumor
I remember someone explaining once that the PS3's Cell was like hiring a bunch of guys to work for you, but rather then being able to tell quickly telling them what they need to do that day when they clocked in, you had to hold a meeting, complete with a power point presentation.
But then tools came around that essentially made the powerpoint for you.
Thanks. That really puts it easier terms for people like me. Sony should have done that earlier but they were a little bit slow moving this generation. Still a great system though.
brandon muse Sony abandon Cell because third party developers were finding it hard to program for only some used all if SPEs
@@brandonmuse5532 "Sony should have done that earlier" the 140 lines of code you need to write a Hello World program ACTUALLY IS a ton of PREDONE work for the programmer(s). It's not even that uncommon to do this style of coding in the games industry, just that such a task would NEVER run on any other than the main thread, so it's kind of a bad example.
The REAL problem is PORTING. PS3 exlusives like The Last Of Us or even the 2008 Metal Gear Solid 4 are stunning and I've never heard a serious programmer complain about being able to write SAFE, multithreaded code. WHAT YOU DO HEAR LOTS OF COMPLAINTS ABOUT is rewriting millions of lines of code "just" to gain 10 fps. Nobody wants to DO that and more importantly PAY for that.
@Nathan Peterson You gotta learn the alphabet before you can write anything.
@Nathan Peterson You didn't get the context.
So how much do you know about programming?
Even if you fully understand a programming language, there can be things we call "libraries". They can sometimes be entire game engines or even just a framework for coding for the multithreaded PS3 architecture.
These things have to be learned all the time by professional programmers, apart from also having to learn entirely new languages and frameworks for them aswell...
Those "meetings" are necessary (what I meant with my previous post) but nothing special at all in the course of a programmers career, even if you just look at a single year. SO... I don't know what you're trying to say - it seems you don't understand much of what you're criticizing
The best PS3 games were developed either by Sony themselves or by one of their subsidiary studios. They knew the architecture and capabilities of their system much better than any third party developer so they could optimize their games very well. Even today, most Sony titles are extremely hard to run on an emulator due to these optimizations.
Cell is indeed a pretty strange architecture. No wonder many third party developers hated it. Xbox 360's Xenon was based on Cell's PPE cores, but without the SPUs. It was a much simpler processor.
It's more like the Cell's CPU was somewhat GPU-like. It would be like three PCs. One PC had a balanced CPU and GPU combo, and the other had a weaker CPU but "stronger GPU", provided you knew how to use the SPEs. Now, if you didn't use the SPEs, you basically had a system with both a weaker CPU and a weaker GPU. Getting from PC #3 to PC #2 was the trick
@@JoeStuffz righto
you do know the 360 cam out over a year befor the ps3 though do you not, so cell was based on the 360's cpu if anything.
@@youtubeshadowbannedmylasta2629 You do know the development of the Cell began two years before that of the Xenon though do you not. So yes and that's a fact, the 360's Xenon was based on Cell's cores.
That SPE hello world example does a great job of demonstrating the complexity involved in coding for them. That's exactly the kind of content I love from this channel!
Well you have to make a library/framwork and that's it... also/// Hello World is just a printf you don't use directly the Hardware unlike his example (also some library and engine did exist for the PS3 by sony), it's something important to have the hand on low level... I don't see the problems... complaints are mostly from lazy programmers (understandable tho).... try to do that with a PC... with semaphores and threads... can be messy and yet you'll not have this proximity with the hardware.
using the printf function in a main as an example is dishonest
Remember it was 2006/2007 it was a beast... 8 cores in a time when it was mostly 1 core or sometimes 2 cores... surely Sony have some balls to do that.
@@technite5360”lazy”? Even studios like Naughty Dog, who were a Sony studio who tried more than any other developer to utilise the CELL could not utilise all of it until basically when the PS4 was being released.
You severely underestimate how much of a drag it was to bring performance to even the same level of the 360 for the PS3, no less having more performance
@@hayax I have never seen the point of making something more efficient at the severe cost of development speed. Labor is worth more that hardware so it's just not efficient or cost effective to have something more difficult to develop for. This is why I always use the "slowest programming language", Python at work. I've made a whole web app with Python as a backend yet everyone else in my company just wants to use Java, then they take months to make changes to the code and break all kinds of stuff while I take less then a week to do the same. And at the end of they day, the performance difference between my Python app and their Java app is not noticeable at all.
@@technite5360 If you had the power of LISP to generate code maybe it would have been easier to automatically handle putting code into the SPUs O_o.
I legit laughed out loud when in the next comparison the Wii u was running at 60fps vs the ps3 at 30. With the amount of deadlines console titles have, there’s absolutely no reason to make it harder to code for. You’re only gimping your own product from its full potential
I LOVE how you actually integrate architecture concepts like Out-of-order execution. As a Computer Science student I really appreciate you taking the time to explain these concepts and not dumb your videos down to make them more accessible. You made me personally interested in building emulators and homebrew.
Agreed, that was splendid to see an example of.
Now that you understand what o-o-o execution is, you can go and read up on Spectre/Meltdown :D
true, there are always different audiences, and one shouldn't try to please them all at once, since it's downright impossible. He captures the audience that understands (or wants to know about) the most hardcore details and technical specifications about the hardware and code, and shouldn't change it out, there must be plenty already that cater to the less knowledgeable on the subject, and their job is also not to be frown at.
As a recent CS graduate myself, I feel the same way. Seeing actual source code and how it would run was super beneficial from an explanation standpoint.
One even better advantage of OoOE is the "branch prediction", the CPU can start evaluating both branch, and just discard the side that is not taken once known. Will on the in order CPU, a branch is always a pipeline flush ( we had some manual branch hinting bit, but it is not the same and it was static )
as a software engineer, I love that you walk through code, makes the problem easier to conceptualize!
we get it, you can code
Agreed, seeing an example was awesome
to normal people... it mean it take time and money just to made one game for just one system.... while xbox 360 had similar in chip but more friendly to PC port.... Only few game used ps3 at it full power and to ps4 that still too weak....
exactly
Coding because we learnt to read and often went to university as well. 😀
It should be also mentioned that the memory layout was widely different between them. Both offered 512MBs of memory, but PS3 had a hard divide offering 256MBs for each system and video RAM. While on 360 you could use whole 512MBs for whatever you needed.
This was a big deal. It is why the 360 had better textures in most games.
thats true, the 360 also had EDRAM very fast bandwidth. 32gb/s
you could use graphics memory as a system memory and vice versa, BUT reading gddr memory from cell was extremely slow (like 16MB/s slow) so extra tricks had to be used for that.
The unified memory architecture of the XBox 360 was also one of the reasons PC ports often sucked, as 360 games weren't designed with swapping textures in and out of video memory in mind.
Another literally big issue on the cell was the big pipeline.
It pretty much did the same mistake as the pentium 4 CPUs of using a too large pipeline.
The "rule" so far was that the bigger the pipeline, more clock you can put but you sacrifice performance as the stalls last longer, and sony designed the Cell CPU to run at 5Ghz.
But as with the pentium 4, the transistors themselves were just unable to reach that speed, no matter how much pipeline stages you had, so they got the performance sacrifice without the clock advantage.
But at least they didn't designed it for 15Ghz like intel did with the P4.
when you've got amazing hardware vs. deadlines, the latter usually win.
Unless it's amazing
LBP3 on launch was destroyed by deadlines. Yeah, it could be because it was being pushed to a developer with nothing to do with the franchise, but the game on launch was a trainwreck.
Me: I couldn't care less about why PS3 was hard to develop for.
MVG: *Uploads video about Why PS3 was hard to develop for*
Me: Wow I was always curious about that!
sony mistake is try to invest a lot of money to get a powerful chip but they keep it going for 10 years that is very long time for this chip before they can get new chip for ps4... which only for 6 years...without 3 years upgrade chip...
Gabe Newell: The Playstation is a waste of everyone's time
Interviewer: Which one sir?
Gabe Newell: Playstation..... E...
The Playstation 2+1
HAHAHAHAHAHAHA YOU MADE THE JOKE AGAIN EVERYONE LAUGH
PlayStation 2 Episode 1
Playstation.... More than 2 but less than 4
ps1 was the shit way btr then any thing out there like snes and stuff ps2 was the shit btr then n64 or what ever was out ps3 same btr then wii but what a waste off time plus ps3 first consule able to boot lunix and link multi ps3 togeter to build super pc
Your explanation of what went on behind the scene in the gaming development world is simply brilliant. Some of the most interesting gaming content on TH-cam. I always look forward to your vids.
Really enjoying this series with the low level approach.
I never knew you were into this sort of stuff
@Ancient Warrior the joke
You
Karl What Are you doing here I Didn't knew you are in gaming?
Woa. What r u doing here karl!
@@lordzooq8987 tht was gud. I kept spamming it like a r*tard
This has to be the most convoluted " Hello World " ever.
144 lines of code?
Try writing it in assembly for x86
@@schrenk-d That would only be ~10 lines...
I believe he could have executed it directly on the PPU instead. 144 lines is because of parallelism achieved by using SPU's.
@@tommymalm This does sum up why ports were shite though
@@schrenk-d BIOS has functions for printing null terminated strings. The assembly is pretty small you just set some registers and trigger a software interrupt.
A few more things:
- Sony threatened with "consequences" if they released games on Xbox 360 first before Playstation 3 if they needed more development time. (Because it would give the end-user thoughts that may be Microsoft had a 'exclusivity deal' with the publisher)
This resulted in many games being delayed while the Xbox 360 version was well and done (and sometimes even leaked in Asia months before release because the "gold" disc was already with the factory)
- Sony spend A LOT of money to fly "cell developers" all over the world to third-party big shot developers like Infinity Ward to help development just so that the Playstation 3 version of the game would atleast look equal to the Xbox 360 version. This rarely gets mentioned as Sony kept this (mostly) quiet.
- The difference between Forza 2 and Forza 4 is also insane. Developers learned to code for multi-threaded processors during this generation after years and years of single-threaded performing hardware. It's not limited to Playstation 3 only.
True but to deny that the last of us was as close to next gen as we got last gen would be crazy. I've played that game in PS3 and PS4 the only difference is the extra PS4 power gets it to 1080p
@@josuem7398 and it runs in 60fps too
@@chrisalcala1007 mostly 45 fps on standard ps4 not sure about the pro
Font: dude Trust me
The Last of Us on PS4 doesn't look as good as other games of its generation though. It really does look like an upres of a last gen game , just like The Phantom Pain did. Compare it to the other big PS4 games (including the same developer's own Uncharted 4 which is stunning)...
144 lines of code to output hello world from the spu, good lord, my brain hurts just thinking about having to code using those, calling it a nightmare was not an exaggeration, wow.
"Yes, but your SPU Hello World code runs _one million times_ faster " -Sony marketing team
I know right!? Now I can say that creating GUI in Win32 API is a lot easier :D
To be fair, that's because most of the program is boilerplate needed to interface CPUs. It's not like all programs would always take 50 times the amount of code.
The biggest problem IMHO is that the game needs to be structured in such a way that different tasks can be run in different CPUs and synchronise everything. Similar to multithreading, although I imagine this would be harder.
I can see why studios weren't willing to use those when developing for multiple platforms. There are already other things to think about (different GPU, controls, etc).
i had to program for a TPM (trusted platform module) that's als quite the disaster!
and i thought that hello world in assembly took long to write, i have to take my word back
Developers can still definitely optimize quite heavily considering the graphics APIs like DX12, Vulkan and even Sony's own are designed to be async/multi-threaded and low level in nature. They allow graphics developers to heavily optimize the graphics/system memory allocation and rendering pipelines. The initial convertion from OpenGL3.2+ to Vulkan for my own game engine ended up being orders of magnitude more code than it's OpenGL 3.2+ codebase. Graphics drivers make no assumptions nowadays about rendering intent and the majority of the work is put on the graphics developer instead (good thing). There is so much pipeline, memory and thread management for savvy GPU developers to take advantage of and optimize. You're right that systems are more indistinguishable from one another, but it definitely doesn't mean that there isn't heavy optimization to be done. Devs will have to be just as cautions to properly take advantage of the GPUs these low level graphics APIs expose. This isn't even mentioning the use of the hardware threads that modern CPUs still have and need to be maintained/synced in a game engine.
At my University's library there's a book solely dedicated on programming on Cell.
Well, not only is hard to program for those SPUs but I've also read that if you want to share data between them you have to do it in a circular manner.
Basically if you want to send data from SPU 0 to SPU 4 you can't write
MOV SPU0 SPU4 (this is not real Power PC assembly, this is just an example, also check the comment below by Tom schleck),
but you have to transfer the data on each concurrent SPU until you reach the desired one:
MOV SPU 0 SPU1
MOV SPU 1 SPU2
MOV SPU2 SPU3
MOV SPU3 SPU4.
What a mess.
This aspect was mitigated by the fact that the CPU can send data to whatever SPU you want but still it's a complicated business.
This is why the Cell architecture was abandoned relatively quickly.
@@brpadington I won't say abandoned. I think neglected would better.
@@Rex-zm7xb They no longer use it in any of their products. Only legacy customers can get support for it. It's similar to the itanium stuff. You can get parts if you pay the crazy support fees but they no longer offer it to new customers.
@@brpadington yeah, in the book the Cell architecture is presented like it is some kind of breakthrough in the super computers market.
They even wrote how to install Linux onto the console to install the Homebrew SDK, a few years later Sony pulled the Other Os feature from its console.
@Gareth Fairclough i don't remember how many registers each PPU has, but if it only has one then you'd be right.
Great video! The PS3 processor is always such an interestingtopic
Yeah man! Tell me about it 😄 It's said that thing still had untapped potential when it ended so I am literally so curious about it's coding and architecture
@@AllaroundVideogames it's kind of ashame that today's console hardware is just scaled down PC hardware, but I understand it for simplicities sake.
@@AgentSmith911 Yeah I find it really depressing that today's consoles are just mini itx desktops. All of the magic is gone.
This sounds eerily like the criticisms of the Sega Saturn.
Both consoles had the same issue where the proposed hardware was drastically changed later than it should've (adding 3D acceleration hardware to the Saturn, and replacing the second Cell processor with a GPU for the PS3). The PS2 was also a nightmare machine compared to the competition but it was a well thought out nightmare that could play DVDs as well so everyone dealt with it.
Yet when sony does it its acceptable in the end........
The atari jaguar also
It's kinda like how the N64 is set up but with more co processors and more dedicated hardware,
@@halo3odst Yep, fanboys always defend their favourite consoles. In reality every one of the big three have made some very questionable decisions
As a computer geek i will always love the cell and if the industry had caught on and cells were made it would a very interesting i mean multi core and low latency thats basically were computing has been moving for the last 15 years anyway
The design philosophy of underpowered CPUs to cut costs, while having powerful GPUs, carried over to the current generation.
lmao current consoles use iGPUs from 2010. I fail to see how they're powerful at all...
@@ephemeralViolette Relative to their cost, and, more materially, relative to their CPUs, they are powerful: that was my point.
Their CPUs were vector/floating point monsters - a very important thing to have in a system designed for graphics, real time physics, animation, and sound. The problem with both CPUs is they lacked other performance metrics more needed in traditional non-gaming computing. Xenon actually still retained some semblance of this, while Cell went full retard on vector performance, because Ken Kutaragi of Sony thought everything could thrown onto floating point and vector engines, building off what the Emotion Engine was in the PS2.
A good example of the gaming processing landscape changing, is that a dual core PC CPU from 2005 would struggle to run GTAV as well as the Xenon on 360, which has the same transistor count as a *single core* Athlon 64 w/ 1 MB L2 cache from that same 2005 era. It highlights how vector/floating point dependent games got to run such large, interactive worlds, where as integer and branch prediction performance really wasn't as important
@Transistor Jump The Xbox One and PS4 both use AMD APUs (basically their series with iGPUs) from around the early 2010s.
edit: specifically, they use the Jaguar microarchitecture from around 2013... so I was a little off.
@Transistor Jump The PS4 Pro came out in 2016, and 2010 was just an estimate (2013 is still early 2010s).
Not to mention they still use iGPUs that are worse than any dGPU today you can get for the same price as the console itself.
It's even more impressive that a group of developers were able to reverse engineer the ps3 and build an emulator for it. even metal gear solid 4 is able to run on RPCS3 at 60 fps at 4k
I was suprised when they made mgs4 playable in just 2 to 3 weeks. Still they have a large amount of work to do with getting other Sony exclusive. God of war 3 and ascension do seem to be coming to playable state.
There should be a major asterisk here: so far it runs at 60 FPS only in some less demanding places only on very powerful CPUs and only on custom builds.
That's good but why not other games like RDR ?
Mir Hammal they already did that
They didn't make MGS4 playable, BSoD's video and the dsoGaming article are clickbait. All the developers and admins are annoyed because it's misleading people into thinking it runs better than it does. The DSOgaming article says it runs at mostly 60fps and yet, they didn't even mention the hardware used. You need to use a custom build which still has crashes from time to time and performance requires a top of the line CPU for even half-decent fps. An overclocked 8700k cannot get 60fps everywhere, its more like 40-50 and will dip below 25fps in some scenes like the REX chase sequence.
If you think about it, one of the reasons Naughty Dog was able to get so much out of the PS3, it was because they were a Sony exclusive studio. They didn't have the pressure on them to release cross platform games and only had to develop for one system. This made a huge difference in helping them push the PS3 resulting in games such as The Last of Us and Uncharted 3
They were also part of the ICE Team which was a team Sony created 2 to 3 years before the launch of the PS3 to help create libraries and learn how to best use the CELL with its SPU's.
Because of this, Naughty Dog and also Insomniac are probably by far the two developers that know the most when it comes to programming to get the most out of the CELL. Naughty Dog had 8 to 9 years at this point of CELL programming experience when Last Of US came out so they really had a massive advantage compared to others. Not having to worry about other platforms also helped them like you said.
*Gabe Newel:* This box will make no money.
.
*Also Gabe Newel:* Hold my Steam Machine.
Short answer: Many devs treated the PS3 as a single-core Xbox 360 and ignored the SPUs
Not really the devs fault though, especially when other devs have to work on those ports without the original devs supervision. Either they need a lot of money from the publisher or a lot of money and the help of other first-party devs.
Short answer: You get what you paid for.
Yep, most multi-plats looked dated on the PS3.
Dual-core*
@@claudiolluberes111 Single-core, but dual-thread
That sounds a lot like the Saturn
honestly I've always wanted to know how much did Persona 5 took advantage of the PS3s hardware, it was released in 2017 & it's easily one of the best looking games of this generation despite being on a last gen console..
I think almost every game with that kind of art style looks great. For example, look at those 2D art style games from many years ago how great they look. Ni no kuni on the PS3 and much more.
while persona 5 is my favorite game of all time, it's graphics were definitely pretty average. It's the stylish aesthetic that makes the game look really good. Many anime games look way better than persona 5 when it comes to graphics.
It's the art style that makes it look great
it's a cross gen port i wonder why when the ps4 was dominate at this point but it was nice to see just how powerful the ps3 really was.
Still wished to have seen a vita port :(
That hello world example was amazing :O
I don't know any other channel that talks about processor architecture this eloquently. Fantastic video!
The Cell processor was just a precursor to modern GPGPU programming - the CPU was basically meant to offload work onto little programs running on the SPUs much like modern games would offload physics and stuff onto a shader. It's just at the time developers were kind of clueless to this sort of programming so it seemed exotic and hard because their games weren't designed around that sort of pipeline.
Honestly yeah, it's not that Sony gave up to the idea, it's rather that all those SIMD instructions are now baked into the everyday processors we use. To this day it's still hard to write good code that utilizes your hardware fully, and seeing the date that all this debate took place, it occurs to me that devs needed to "git gud".
Proper tooling that abstracted away intrisincs might have helped, because even today I'd argue most devs have no idea over how to code with AVX512.
Nice waking up the MVG in the morning
Imagine how difficult this thing is to emulate. Kudos to RPCS3 to somehow pulling this off
I remember how piss poor early ports were. The 360 killed it on multiplats especially madden. The first madden on ps3 ran at half the speed of the 360 port. Really made that 599 i spent look extremely foolish at the time.
*Compares Wii U with other consoles*
Me: Yes! The Wii U actually does something!
Hahaha I bought 2 of em. Just for small form factor multimedia players, Virtua Fighter, and Linux.
SHUJINCELL ps3 is a awesome media player it plays everything
@@half-qilin Hack the Wii U and it does more..
Kenrick Eason I already did to mine.
Heh, I'm kind of flattered to part of the chart I made for PS3 backwards compatibility on PS4 at 8:20. That whole post really took off a lot better than I thought it would. 😅
Thank you please let me know how I can credit you in the description!
@@ModernVintageGamer imgur.com/gallery/zGJ1v
Idk if TH-cam will allow this link but this was the original post I made on Imgur. ^^
Honestly, just a link to that and my alias (SilverAura) will work. I'm too humbled to expect more.
When you said it had no out of order programming I almost fell in floor. The rise of quality toward the PS3's end-cycle makes so much more sense, now.
"PS3 has no games"
Here's a vintage meme for y'all
It was true in the beginning.
@@Crashandburn999 It's kinda true for most consoles at launch lol. PlayStation 4 was frequently criticised the same way too... and look how that turned out XD
@@Reydriel The ps3 was even worse for it though. The ps4 at least still got all the 3rd party titles releasing on it, the ps3 was a console that devs wanted nothing to do with early on, so it didn't get most 3rd party multi-platform titles until about 2008 or so. There were actually games being released on ps2, xbox, xbox 360, pc, even wii but not ps3.
"Ps tree gotz da best games."
@@josh18230
Memes aside, the PS3 does have some pretty amazing exclusives from Sucker Punch (inFAMOUS 1&2), INSOMNIAC (Resistance Trilogy, Ratchet & Clank Future Saga), Naughty Dog (Uncharted Trilogy, The Last of Us) and Santa Monica (God of War 3, Chains of Olympus & Ghost of Sparta Remasters).
just goes to show you should always think of the developers when designing your hardware. you can make the most powerful hardware in the world but its useless if no one wants to develop for it.
And then they will use shitty outdated and bloated APIs like directx on your sexy new hardware.
@@andljoy the ps3 used an nvidia geforce 7900 and directx 9
Just as the xbox 360
Oh Sony knew exactly what was gonna happen. Port after port after lazy port. It said no thanks. Best decision ever.
@@SeñorDossierOficial lol ikr XD Direct X is fine, nothing wrong with it. and it gets plenty of updates since its Microsoft's API
Epic vid as always, learning electronics and coding was never a thing without your channel, thanks man
I ran into a guy playing disc golf back in the late 00s and he was a dev for EA Sports, his #1 complaint about the PS3 was its smaller texture memory
Oh yea. The PS3 did not have a unified memory architecture unlike the 360. It was 256mb for the CPU and 256mb for the GPU. And usually, GPUs consume much more VRAM due to huge textures and 3d models. The benefit 360 had was that if the CPU was only using 100mb, then you had around 400mb of VRAM all to the GPU which mean higher res textures or more detailed character models.
@@PurushNahiMahaPurush But why in GTA 5 and L.A. Noire grass on the ps3 could be seen. But when I checked Xbox 360 the grass was bleeding with the ground and blurred. How? I was dissapointed
@@PurushNahiMahaPurush it just not what the dev train for since most of them used to something a little more simple...
@@SalmaKhatun-ow6bf simple is xbox 360 don't had that extra power to run those thing... it was more simplify which most dev are train for while ps3 require addition coding and skill... it like the car with 12 cycle but you only know to made v8... it just not going to work...
Reading this in 2021 and "back in the day" + "complaint about PS3" hits hard. ;_;
This is really interesting. I thought previously that the PS3 was simply hard because it had more cores/distributed hardware and multicore parallel programming is hard. I had no idea the Cell was essentially a dual core with extremely low level coprocessing units.
Jetsetlemming I’m no computer science student, but as for PS3 co-processing unit - does it mean that they don’t have/build a simple call function for developers to utilise like in modern game engine’s library or whatever correct terms for it?
I think they tried to make something similar to GPU. More cores with parallelism
it was not really good in gaming... since og design is for running server.. but due to it powerful load compare to power to run.. it is very good but just the xbox used the modified one that are alot cheaper...
Cell is a single core with 7 coprocessors
I wrote my master's thesis on the Cell BE processor, for extending an H264 decoder. It was quite the experience - the SPEs indeed needed very low-level code, and the Cell processor was only fast if you utilized all six SPEs, and also made sure to utilize the DMA memory streaming features.
There's one thing you didn't mention either: The PS3 only had 256 MB RAM, and each SPU had 256K - code and data combined. Access to main memory needed one of these DMA accesses, so you constantly had to stream through data, which was a pain in the ass. Parallel code is hard, and the Cell BE required you to manually parallelize everything.
That small amount of local memory also meant: No C++ on the SPUs, C only - and you had to be very efficient in your coding, otherwise you wouldn't have space left for any data to process.
@Rob Wyatt That, too - yes. To write any kind of efficient C code, you had to make heavy use of the intrinsics they defined, which were essentially Assembler commands wrapped in C. The compiler didn't help you there.
Maybe I'm crazy, but I always thought there was an element of future-proofing in the inanity of the PS2/3's architectures; it ensured that games would consistently improve in graphics and performance throughout the console's lifetime as developers learned to navigate the system.
I'm wondering if it was to make emulation harder. The PlayStation got emulated during its active lifecycle
Why not just get the full potential out of it from the start?
Somewhat difficult. The CPUs were using paradigms that weren't very common. You literally need several years of experiment and/or trial and error to really know how to use them
@@JoeStuffz Yeah, but it would have been better if they got 100% out of the console from the start. Bad move from Sony imo.
For the PS3, it would have been hard for that era. Games were just starting to become multicore. Even on PC, CPUs were starting to hit the limit on single core systems. The whole video game industry was going through a transition. The Xbox 360 was even hard to use at 100%.
PS2 era? Also hard. The problem with game consoles is that you couldn't slap in the most powerful PC CPUs because of the amount of watts they would use. Game consoles need to try to not be over around 250W or so. Game console makers especially in and before the N64 era were trying to figure out clever ways to get the CPU power with that power envelope
This whole "percent of the console" is also ridiculous. It feels like a marketing ploy to keep the Sony fans happy since the console was marketed with "potential". It feels like there were Sony PR agents especially trolling gaming forums. It sounds like Sony chose to go more conservative lately by using an AMD-derived CPU
The issue for consoles isn't just hardware, but software and education. What actually made the Xbox a viable product: the developer documentation was in English.
CPU core counts also only scale so far. Once you hit a certain core count, with games especially, it starts becoming more of a GPU task over a CPU task.
Teacher: "The test isn't that hard to understand."
The test:
Naruto Logic: 'Many of the test takers were there to aid in cheating'
@@AmyraCarter The cheating was the point of test... For some reason, I don't remember it clearly
@@miguelpereira9859 its a info gathering test
that joke wasn’t even funny
Man, you have no idea how much I appreciate you showing the actual code for initializing the SPEs.
I'm surprised you didn't mention that Portal 2 was cross platform online play on the PS3 with the PC. You even got a free PC copy with the PS3 version. My brother and I had a blast, I was on the PS3 and he was on his PC it ran absolutely fantastic, I could see my brothers POV in a small window in the corner of the screen with no hiccups at all.
I always hoped Valve would've brought more cross online play games, i'm sure there was rumours about it but it never happened. It's obviously more common now, but back then it was mind blowing. 😁👍
Kaz did an interview on that, stating that, for example, the PS2's texture fill rate was much higher than the PS3's, thus preventing them from implementing the heat haze effect in GT5 that was formerly in GT4 and GT3.
Very interesting stuff. This explains why some later PS3 titles were better optimized than 360 titles, yet so many cross platform titles in the early days of that generation performed much better on the 360.
Ps3 vs 360 reminds me of snes vs genesis.
The snes was thought of as more powerful yet games that were on both systems almost always played smoother on Genesis.
But games that were optimized for snes specifically could technically be better.
I thought the Genesis was seen as the slightly more.powerful hardware on paper?
But SNES had that incredible support
@@Matanumi Genesis has the faster cpu, and the higher resolution, but in all the other categories snes ranks higher. It just depends on opinion for which one is better.
For me all the Japanese games that I cared about looked better and ran better most of the time on the PS3, it was a brilliant system and I had a far better time with it and its games than I did the PS4.
Xbox 360 had a ton of great jrpg exclusives back in the day.
@@statesminds Blue dragon and lost odyssey will forever live on in my heart.
@@statesminds I swear, the guy who was in charge of selling the Xbox to Japan couldn't have done a better job. They found Sakaguchi and asked him to make what basically is the real Final Fantasy XI / XII / XIII with Lost Odyssey. They even triggered Blue Dragon with Akira Toriyama designs to emulate a "Dragon Quest"-like adventure. Furthermore, they were able to snatch Final Fantasy XIII from being a Sony exclusivity too ( the game is seen badly for good reason, but it still sold insanely well ! ), they were about to get the latest Tri Ace game with Resonnance of Fate or Star Ocean, the latest Tales of with Vesperia.
But that's not all ! They took the arcade by storm with most rhythm games being ported for the 360, Cave was on it too. All the latest shmups were on the 360 ! Including the very otaku-oriented Otomedius by Konami. They even made a new very profitable license Idolm@aster which was a huge success only in Japan. Really, there is no parallel world where that guy could have done a better job of making the Xbox having japanese game. He has done EVERYTHING he could...
And despite that Japan didn't wanted the 360... The PS3 sold better there...
I did a year studying software engineering (wasnt for me) around 10 years ago. I really enjoy the more in-depth programing aspects you give in your videos.
Also with the consoles its crazy to look back on the older in terms how how the visuals improved with newer games. Its a bit of a shame there isnt any secret weapons anymore hardware wise. The current gen consoles werent a massive jump visually and due to hardware/architect we havent seen a jump during the lifespan
From a high level, the PPE looks a lot like an Intel Atom (the original ones), being in-order, dual issue architectures with SMT. The PPE has a deeper pipeline to push higher clocks however.
The PPE has a vastly better vector SIMD engine, especially on Xenon.
@@BlitzvogelMobius no AVX on Atom? Or at least any other SIMD extensions?
Python/BASIC: print “Hello World”
PS3 Cell Architecture: 5000 lines for Hello World
python and basic can easily be run on hardware, but when you have to specify which core to use and stuff like that, it gets complicated...
Python print("Hello, World!") looks like it's just one line of code but it's NOT EVEN CLOSE to 1 CPU instruction :-)
That's the trade-off: fast and simple to understand vs fast executing code.
@@igorthelight I hand that job to the compilers.... **Notices that printing takes 5000 cpu cycles**
The Cycles Haven't Been Kind to You...
~Flynn
Sony PR Person: Yes, but now your 5000 line code rubs better
@@chrisakaschulbus4903 Depends on your system. An Amiga with Bridgeboard (Zorro expansion) and/or co-processor on the system bus had no problems whatsoever in specifying which core to use when. In fact that was the easy part of programming the Amiga, it was the rest which was fucking hard. Agnus, Denise and Gary mostly. Hard but satisfying as the result for that time was just incredible. Amiga was so far ahead that it took PC about 8 years to somewhat catch up. At the height of Amiga we had 4 channel stereo sound and millions of colors against the PC at the build in speaker noise and 4 colors max.
Another thing worth mentioning was the unified memory on the X360 being 512mb vs the split 256/256mb CPU and GPU.on PS3. This made open world game streaming much harder since your memory pools needed to be more aggressively managed. The technique of doing work on the CPU and having it available for the GPU was not effective and you would tropically just pre bake the operation on the disc since you had up to 50gb to stream from.
excellent points. thanks Alex
I'm so glad I dabbled in C++ a bit, it made it so much easier to understand this video. I kinda see this as parallel to CUDA cores on nvidia, however in that case, games didn't end up using it for more than "optional" features, such as physx.
Man, you just keep on stepping it up with every new video! The technical explanations are just perfect. I also liked the last segment where you talked freely, that felt really “up close and personal” as compared to some other videos of yours where you apparently read the text. Please keep it up!
HAH! YES! Amazing video and captures it perfectly!
I remember writing my SIMD Vector/Matrix math library and ported it to CELL using IBM's Broadband Engine emulator. The test harness ended being more work than writing the actual math library!
I always knew it was harder to develop for PS3, but never exactly why. Everyone tossed the word "architecture" without actually explaining it.
Thanks for the video!
As usual, you pick the most fascinating of topics and somehow, they always feel like they appeal precisely to my own interests. Great work!
To some extent, the PS2 was the same story. It was popular due to it's DVD player functionality though. Some early multiplarform games looked better on the Dreamcast as a result.
True but Sony had a problem that it didn't have with the PS2.
Releasing a year later than its competition.
The PS3 had a Blu Ray drive, so it also had a media advantage over the 360. It wasn't quite as effective as with the PS2 though, since having a DVD drive was good enough for most consumers in 2006.
The Xenon CPU sounds so crazy for the time. Three cores with SMT when Intel desktop CPUs had two cores OR hyperthreading. But the Xenon only had 165 million transistors, while Intel's single-core Prescott 2M based Pentium 4s had 169 million transistors. So there were 3 cores but they were much smaller than contemporary CPU cores.
1:35 "here a lot of thread could be spawned"
Well.. note really. The issue here is a lack of terminology. This is not really threads, but rather program branches. The PPE could branch of a task to a SPE to finish this task. Very much like a FPU does. In an effect, the SPE is sort of a standalone FPU with some added capability. The main diffrance from a FPU is that the SPE can run the code independent of the ALU that is in the PPE. So the PPE branch of a task, that is not really a thread, to a SPE. Then the PPE keep working with something else, and can branch of a new task to a other SPE.
A normal CPU stop working when it branches of a task to the FPU and wait for the result...
The important bit here is that the PPE and SPE run in the SAME thread. This is important because some calculations need to be done in a specific thread, making multi-threading of that task hard, if not impossible. This is for instance exporting data to the GPU.
6:15 "by simply breaking code out as a thread"
While this can in theory be done, but in most cases its not as simple. Now there is a lot of stuff that can be done in the compiler. Breaking out a thread is more complicated then accessing a SPE, so this is just plain wrong.
6.30 "those SPE is needlessly complicated"
That is not the case. They are really not that hard to make code for.. The issue is that you have to actively use them.
And here is the major problem. Most cross platform game of the gen 7 era was made on either PC or Xbox to begin with. Then simply just recompiled. Recompiling a DX 9 game to Xbox was really not that hard. And Microsoft made sure that the dev tools used the processor as efficient as possible.
Most programmers spawn threads, not really when its needed, but when its practical. So if a subroutine work independently, they spawn a thread on it. This generally did at this time leave anything from 60-90% of the workload in the original thread.
The real issue was that most devs after recompiling the code for 360, then just recompiled it for PS3. PS3 have all the functions of the 360, and them some more. But then totally not using the call for the SPE, that IS NOT COMPLICATED. There is not to much of a diffrance making a AVX call to making a SPE call. The thing is, the code will work either way.
If the game is originally made for the PS3, it can´t be recompiled for the 360. It need to be change to run
The Hello world example is kind of stupid. You just order the SPU to return the value you send to it. It literally does nothing. The same thing, if you wanted the hello world to run on a different core than the one that started it, the complexity would be the same, or even worse, because if there is dependencies in the code to the thread, those have to be taken care of seperatly.
The argument is pretty much the same as to say that a 286 is better than a 386 becasue if you write the code for a 386, it will not work on a 286.
The whole idea that games used more threads was not really even correct. Most games when this generation launched really used one main thread. Look at the game ported to PC during this time. Reduce the thread count to 2, and the performance will hardly even differ. Was really until very late that era, like battlefield 3 where the main thread used less than 50% of the performance. With BF3 the performance increase almost linear until 3 threads, and the bump to 4 threads is quite considerate.... The look at Crysis. It just run one solid thread. That is it.
I love this channel when you go into actual C or assembly code to show off the architecture or instruction set. Most people can't even do the research on this let alone present it properly, but you actually seem to know it outright. Well done m8.
Awesome video, I learned a lot of new things.
Sorry for my English...I worked on XBOX/PS3 Rainbow Six Vegas game. The development for PS3 was a real pain, especially when the main platform was Xbox.
The Xbox was our main platform, with a small team for PS3. Basically, they took more than a year, just to make the run at 1-2 fps on PS3. Think about that, it took months to compile, months to start without crashing, months to display something else than a black screen.
When the Xbox version was finished, the game was still barely running on PS3 (It took 9 more months to finish it)
The PS3 had more power than Xbox on paper, but in practice it didn't: a lot of its computing power (SPU) was for calculations, which is not needed much for a game.
Personally, I never saw a game on PS3 that runs better than its Xbox version.
Problems I remember:
- Low cpu power: 1 CPU 2 threads on PS3 compared to 3 CPU 6 threads for Xbox
- Low system RAM: Video RAM (256 MB) and system RAM (256 MB) separated on PS3 instead of unified RAM (512 MB) for Xbox
- Operating system (OS) using too much memory
- low GPU performance: pipelines were weirdly inefficient compared to xbox
- Hard to get power: SPUs only had 256k RAM each, running separate processes, required DMA requests access main RAM and PPU, specialized for calculations, tricky programming
- Shitty API: not consistent, not thread safe, not reentrant, buggy, voice chat had to be redone, bad Sony support etc.
- Inferior development platform: code warrior vs visual studio
And the list could have been longer, there was a lot of problems.
The biggest problem was the memory. The Xbox version used 510 MB (375 MB for game data and 135 MB for video).
Now try to fit 375 MB in the 156MB available on PS3... oh yeah, the OS takes like 100 MB from the available 256MB (I cant remember the real amount, but it was high).
The lack of CPU and GPU power was also bad (I am not familiar how it was fixed in the game).
Months of work to split and simplify game levels in smaller parts, optimize memory, remove stuff, push some game data into the video RAM, simplify AI, decrease textures, decrease models complexity, doing weird hacks, etc. to be able to have an ugly, low fps, low resolution game.
By hack, I mean something like that: before you open the virtual keyboard (which required 10 MB of free RAM), the game moves some game data from the RAM to the hard drive and when you close the VK, it moves the game data back from the HD to the RAM...
It really have been unpleasant to work on PS3.
Incredible video. As always I love the technicality and architecture explanations. As well as that code sample for the SPUs, that was really great to see, especially with all those comments and explanations. Great work. It was really appreciated and very interesting
I love how your content is so genuinely good even when i have no idea what you're talking about i still enjoy it😅
Gabe Newell in 2007: "I hate the PS3!"
Sony during Portal 2 development: "We'll let you run Steam on it..."
Gabe Newell in 2011: "I LOVE the PS3!"
I really wish Gabe Newell would actually release games on consoles again cuz I want to play Left 4 Dead and I'm not moving to the PC to play it
@@redseagaming7832 left 4 dead is so old that you could just buy a low-end gaming laptop and a mouse and run it easily
@@redseagaming7832 Its available on Xbox backwards compatibility if you have an xbox one
Sony wanted 3rd party exclusives, which meant getting devs used to developing for their system and no one elses, that's why 3rd party devs didnt like ps3 because they had to learn twice as much to develop for all 3 (PC) systems.
I remember being in 9th grade during Final Exams in June 2008 in my computer class. I'd use Wikipedia to learn about the clock speeds and compare them between all the consoles lol.
In a way I miss the days when game consoles used exotic hardware that you’d need a super expensive pc to match. These days we just have budget pcs in a custom case with its own OS
Well it would have costed a lot of money to create a custom gaming CPU based on high-end CPUs of desktops for PS4
In 2013, the XB1 at $500 could have opted for better specs it wasn´t sold with gimmicks like obligatory kinect
i think you look at it the wrong way, consoles are everyting a cheap pc would be for gaming, and the fact that next gen consoles starting from 7th gen are basically multimedia, streaming and also computer (using otherOS on PS3), its just a step for consoles to be mature and powerful enough to be a genuine pc
10:49 that gran turismo gameplay made me mad, the person who played in that moment really sucks at that game
He do be having brain latency though
@@d9zirable lmaooooo
This game not for all.))
PS3 was like the SEGA Saturn: complex but amazingly capable. I've never seen something like "The Last of Us" on the Xbox 360 or even the WiiU.
In terms of what?
Surely GTA V is a more impressive technical feat?
@@ThisBirdHasFlown Gta5 is actually pretty simple mechanically. Getting the physics to work in GTA4 was a miracle. Everything had active dynamics physics running at all times.
@@likeclockwork6473 Is that why it runs like ass on everyone's PC's.
@@likeclockwork6473 Actually if you remember a post from July 2014 or 2015 some guy reversed engineered the skybox and how that worked on consoles.
www.adriancourreges.com/blog/2015/11/02/gta-v-graphics-study/
I've been doing programming since the early 1980s, and professional development for over 25 years now. I've had challenges where I needed to get every last bit of performance out of a system, such as a Mandelbrot set generator on an Amiga that was optimised down to the last CPU clock cycle. But you know what? I'm past that. I write code that runs exclusively on a virtual machine. Performance is a consideration, but more to the point of not doing anything really stupid. (Quite contrary to some of my predecessors, I might add.) I think that, as time moves on, the physical architecture will become less relevant, and we developers will be writing code on virtual machines that other people have optimised for us. There's only so much that the head of a developer, or a team of developers, can contain. Because systems are incredibly more complex than even 20 years ago.
The Cell Processor is way ahead of its time.
Excellent video fams!
The Cell vs Xenon comparison is over simplistic without going more in depth on each processor's various aspects and how developers were expected to use them. Few people realize that the Cell Broadband Engine itself was a developmental dead end not just because of developmental difficulty, but for it's utter disregard for non-vector/non-SIMD processing outside of the PPE core. Cell didn't have the total integer or branch prediction capability to really back up all that floating point performance, along with oft-mentioned in-order processing issues (though this saved on transistor cost). Despite less that half the floating point capability, Xenon created much fewer developmental woes as it had three PPE cores, each based on the same branch prediction, integer, and load-store capabilities as the PPE on Cell, except, well THREE PPEs instead of one. Xenon's PPE also had a more capable and flexible implementation of the VMX128 vector processing unit with two sets of registers and the ability to run both processing threads through the VMX unit consequently. The Cell PPE was not designed for this, as it was meant to rely on the SPEs for floating point/vector/SIMD performance.
It's a whole 'nother can of worms to even go into why Cell was designed the way it was. Alot of bad predictions of the part of Sony (esp Ken Kutaragi), Toshiba, and IBM.
Sorry for a late reply, but I'd actually be interested in hearing about why those bad predictions were made, why Sony thought the things they did was the right way forward and so on. Are there any articles or so you can link to that talks about this?
@@goranisacson2502 Sony and Kutaragi thought they could vectorize/SIMD accelerate everything under the sun when branch prediction and integer performance are still important. Just look at the difference between Cell and the octo-core Jaguar set up. They swapped half the theoretical vector/SIMD capability for multitudes better actual non-SIMD performance that Cell and Xenon to a lesser degree both highly lacked. In turn they created a developmental nightmare for a gaming system. Required alot of memory management to take advantage of it's stream processing capabilities. The Cell BE made quite a bit of sense for IBM server computing since they could pair it with x86 processors to keep in under command and treat Cell as an accelerator.
Cell was already quite big with the 8x SPEs, the PPE, all the internal interconnects and cache. Adding another PPE would've made the chip bigger and more expensive, but would've eased some of the woes.
7:12 And that's why I respect so much RPCS3 developers... Those brave people :'/.
it is really so much extra work
seems like all that threads starting on the spu's could have been built into the compiler and made easier. its repetive but fairly simple. but simple and repetive are perfect things to automate with software. seems like all those lines of code could be built into a librairy or command and just put the command at the start of the function or whatever
I suspect a lot of games didn't have their code neatly threaded. Multithreading in general was pretty limited in those days. Therefore there were probably threads which bundled what probably should have been two or three threads together. Unbundling this at least would have to be a manual process.
@@rbauer961 it was a sad time when game developers tried to adopt enterprise development practices, such as OO, which really doesn't mesh all that well with threading, and especially not the SPUs
I just discovered your channel and I’m really enjoying your topics especially in light of the time frame. It gives you a current day take on things few people might have cared about say 10 or 15 years ago. Also, I love the shirt, I’ll have to find that one. I’m a Neo Geo enthusiast and collect both MVS and AES.
I remember at university how proud was an IBM delegate to show the architecture of the Cell CPU...
Thank you! I've always been curious as to why the PS3 was hard to develop on. I honestly feel bad for those who had to program on the system. Despite that and the performance drops in multiplatform games, the PS3 is my favourite console of that era. I did start with the Xbox 360 because of price. I do have fond memories with both systems!
The SPEs were also focused on doing vector maths and CPU programming back then was mostly based on scalar logic. You could get massive speedups by unfolding loops and running them on the SPEs, but devs weren't used to doing that.
One of the interesting things about that is that since then not only we've seen a big push for vector maths execution on CPUs (through stuff like SSE and AVX/2/512), but a pretty strong adoption of GPGPU, that follows similar concepts. PS4 GPU has extra hardware that makes GPGPU more efficient on it, and you can be sure that first party devs, being pretty used to this kind of programming paradigm, made good use of that.
7:23 With all due respect, I think it's unfair to put "Hello world" into complex architecture and then say its unneededly complex.
I think its more of an issue with development managment. Its not like coding for NES or GBA was all rainbow and sunshine. My guess would be that XBOX360 was the culprit. It offered easy solution, whilst PS3 required work and effort to utilize system to its max.
So your solution is to work harder than necessary to achieve the same results? Making something hard to work with does not make that thing better. The 360 ultimately was just as good as that console generation could be and was the easier machine for the devs to work with. That makes the ps3 the definition of needlessly complex
My solution is to use and utilize hardware for the things its made for, not rushing lazy ports (like Red Dead Redemption 2 for PC).
Benchmarking two consoles on ports is not a fair assessment.
Comparing quality of exclusive games that utilize consoles to the max should be a primary factor.
@@LemonGingerHoney There are a few problems with your assesement here.
Firstly, Benchmarking ports on console is a fair assessment. You can't sell a system on just exclusives (see the Wii U, Saturn, PSVita etc) and expect it to succeed. People buy consoles with the expectation they can play most games that release.
Secondly, comparing quality of exclusives is also arbitary as a means of judging a system. Suppose I make a system that can play Space Invader better than every other machine on the planet but can't play any other game. I doubt the machine would last longer than its novelty
Man I really enjoy your videos. Waiting a whole week for the next is hard.
I am learning about multiprocessing, multi-threading and code architecture for my current Computer Science project. Very interesting to hear some of these concepts in regards to the consoles. I always wondered why the xbox 360 had a better game ecosystem despite the less powerful CPU. This has been very revealing and makes a lot of sense.
"Mistakes were made" because "Sacrifices needed to be made somewhere" 👍
"I took one life to save millions"
4:30 Some of the architectural features (like out-of-order) can be handled by the compiler. In some cases the compiler knows what can be reordered better than the CPU. Pulling things like out-of-order and speculative execution not only save money, they can save power as well (which again I guess saves money). It would be interesting to cross reference the compiler technology at the time that coincided with the decisions.
The compiler can reorder static code, but as soon as you do anything dynamic (branching code), that all goes out the window. Games tend to be extremely branch heavy, so relying on the compiler to reorder is pretty pointless.
@@adamk203 For starters, it's not "dynamic". You're thinking of control flow code. Second, just because you have control flow code doesn't mean the compiler can't reorder it. You should probably go ahead and cite a source for your assertions.
For a compiler, it's called Instruction Scheduling. en.wikipedia.org/wiki/Instruction_scheduling And yes, they can do control flow code.
Instruction reordering can occur in both the compiler and the CPU. It's roughly the same thing, except again the compiler (actually I should say the entire toolchain because optimizations occur through the entire toolchain) is usually going to know more about the data and its dependencies than the CPU at runtime.
Having the toolchain do it costs you build time. Having the CPU do it costs you power and die size, plus you'd better make sure to validate it else you get a grievous hardware exploit.
GoatZilla You have no idea what you’re talking about. Compilers can only perform instruction scheduling on code where the order of execution is known ahead of time. Also, control flow is dynamic (as it occurs at runtime vs compile time [static]). Any branch taken forces the CPU to load and reorder a new set of instructions. This is why branch prediction and OOO are so important. If compilers could run once and reorder everything in advance, there would be no need for OOO. Yet, we see that the performance advantages of OOO are considerable and any architecture leveraging performance is going to make use of it.
@@adamk203 The code is not dynamic, therefore just stop calling it dynamic. The compiler can reorder control code as long as the program's meaning (semantic) is followed. The compiler just gets to take into account a much larger program scope to make its decision.
If a CPU is forced to flush its entire pipeline every time it gets to a branch, that's not exactly a ringing endorsement of CPU OOO capabilities. Flushing the pipeline isn't a feature, it's an incredibly expensive penalty. I don't know why you're talking about it like it's a feature.
And yes, branch predictors are designed to help mitigate this. Along with speculative execution. Which is how we wound up with Meltdown and Spectre. Turns out that dreaming up some wizbang feature isn't enough -- you also have to figure out how to formally validate it.
All the reordering that you did just to throw it all away, all the flushing, all the branch predictor logic, and all the speculative execution are all very, very expensive in silicon.
GoatZilla You’re just some scriptkiddie who thinks you know everything from reading a bunch of Wikipedia articles. I do this stuff for a living. “Dynamic” is a perfectly acceptable term when referring to program/control flow during execution time. We’re talking about object-oriented programming, not a block of BASIC with a few GOTO statements. Branching is completely unavoidable in complex code, and flushing the pipeline is thus also unavoidable. That’s why branch prediction is so important - for each correct prediction, the pipeline is already filled with the next instructions, ready to be executed. Any in-order architecture must also flush its pipeline upon branching - and because there is no reorder capability, a branch can lead to severe pipeline stalls. In-order architectures are terrible for anything other than repetitive calculations, and thus are limited in practical application.
I need a game system that does not need internet to play a damn game.
But pretty much everything can do that, what do you mean
I'm so glad I found your channel, the immense amount of knowledge and information you share with your viewers with is absolutely mind blowing! Thank you so much for each and every one of your videos, they are always appreciated. (:
Splendid material dude !
I understand that you are (or were) a very competent programmer.
Sometimes it really takes someone who really knows what they're talking about just to understand the complexity of the issue.
Thank you !
I’m glad you did this video, I’ve always been curious why ps3 ports were always worse than Xbox 360 despite Sony’s claims that the ps3 was powerful.
I guess my question was why did Sony decide it was better to design the PS3 this way?
Sony hates ports.
Cell processor rapes Xbox 360 Xeon CPU.
1980's:
10 PRINT "HELLO WORLD".
2006:
.......it's complicated.
One of the least appreciated aspects of the C64 was: It was cheap, widely available, and the moment you switch it on, anyone with a BASIC understanding of programming could write code - or load a game. Imagine that: You turn on a computer, and can immediatelly type code in an easy-to-understand language.
In a sense it was the ultimate "homebrew"-machine, and this low entry-barrier was the reason, why so many programs and games were released for it.
For those of you reading this comment in 20xx: Grab a ZX Spectrum emulator and try programming on one of those. It had a surprisingly nice line editor for its time, and still holds up as, well, pretty usable.
Running hello world on a GPU also require quite deal of boiler plate.
I heard there was 8 SPEs with 1 being disabled from the factory for quicker performance yields... can you confirm?
Regardless of all the flak the PS3 received, it’s still my favorite console from that generation.
I own 3 launch day mint 60GB PS3’s complete in box, and I still love to game on the PS3 to this day.
My wife got me a PS3 for Christmas. I wasn’t expecting it either. The first game I played was Uncharted 2. After playing it for 10 minutes, after the train scene. I stopped playing because I wanted to play the Uncharted first. Luckily Blockbuster was open and I went there and they had a used Uncharted game for sale. I still have those games. Those games means a lot to me.
fix gabens problem by simply renaming the console to "Playstation 2 Episode 1"
Hehe The Orange Box always get's thrown in as the example of a bad port, but it's not horrible :).
Also, the servers for Team Fortress 2 is still online, which is just amazing, almost 12 years! Shame that the Naughty Dog server shut down earlier this year, but outstanding support from EA to outlast 2nd party Sony games.
If anyone still plays TF2 on PS3, I hope I see you there! I play each week and usually upload my sessions as well.
Vanilla TF2. 💕
Yes!
I'm here
kudos
It Fazer mint
At least Sony learned its mistake with the PS4.
And that console generation will hopefully easier to emulate due to x86-64
And improving it with the ps5
Salesman: "Sir, can i interest you in our latest invention? This car does 300MPH and costs just ten grands, but you need 5 years training to drive it, because we didn't bother to optimize the controls."
Customer: "Uh... no thanks."
Salesman: "Damnit. Again! Maybe we should just stop innovating and sell the same boring cars as everyone else."
Nope, they didn't learn jackshit.
@@bitelaserkhalif Again having same architecture doesn't mean easier emulation, they still have deal with kernel and firmware and also that is a custom chipset. Alexaltea(main developer of orbital, a PS4 emulator) already mentioned in it in Reddit.
@@Rex-zm7xb yeah, but less job focised on architecture itself
hey Modern Vintage Gamer
please make a video like this but about the Wii U comparing its CPU/GPU against the xbox 360 and ps3. This is so interesting to see and your explenations/examples are great!!!.
That’s not why OOOE was removed.
Well, it was, as die size is cost at the end of the day.
But it was removed because the SPEs in design were moved from 6 -> 8.
And that blew the die size up and meant picking between SMT and OoO for the main core.
As the main CPU core was built for the cell CPU only, initially.
It's a big relieve that nowadays nearly all consoles uses x86 architecture
Yup. Now basically all games run on either x86 or ARM
Nah devs are getting lazy and we have games that have more bugs than ever!
@@MrAckers75 Well It's more the case of devs spending more time and money on making long boring cutscenes with expensive celebrity voice actors that they put in expensive motion capture suits so they can parade them around on E3 and other press events to impress dumb games journalists and share holders.
Also, it's expensive and time consuming to build an entire game around collecting items like costumes, emotes and other useless crap that they can sell as microtransactions or hide inside loot boxes.
They say they need microtransactions because video game development is expensive, then they go ahead and pay millions to celebrity voice actors and license holders.
How about spending some of that money on bug fixes and optimization? Just an idea
@@MrAckers75 No. They don't actually. Games were actually far buggier before and devs today have far larger QA departments and resources to solve bugs. Given how much more complicated systems are now, It's surpising it's not more buggy,
But seriously, watch any% speedruns of older games and you'll see how much buggier they were.
Fraser Souris lol that’s not even remotely true!