I'm fine with that, as long as the OSS shills also stop writing "VS isn't in my Linux repo LOLOL" posts. Seriously, it wasn't funny the first time, can we get back on topic, everyone?
If I had mod points, I'd mod you up. Not just because of the content of your post, but after scrolling through 50 pages of HURR DURR M$ IS t3h suxx0rs you're the first person to comment on the actual plugin itself.
A guy who bought an entry-level camera from Costco doesn't care how many bits his channels have. GIMP's support (or lack thereof) for 16-bit channels are irrelevant to him. Any halfway-decent editor will support 16/24/32 bits-per-pixel images, so when someone is discussing 16-bit color support in regards to photo editors the default assumption is that it refers to bits per channel. Context is everything.
Yes, you're right - native code called from a python script does not have GIL limitations. And Python code cannot directly interact with the hardware, so at some point all I/O code is native x86/x64/ARM/whatever binary code. I'm not denying I/O bound Python code can benefit from multithreading. The point I am trying to make, that was first brought up by citizenr way up there, is that for CPU-bound tasks both Stackless Python and CPython are effectively bound to a single core.
I/O is irrelevant; I have never used Stackless Python so I can't say how it handles I/O bound operations, but if your code is bottlenecked by the CPU improving I/O performance won't make much of a difference. Native code is irrelevant, I am only talking about pure Python code here.
Thanks, glad I could help. I'm 24, so I can't really say I've experienced what you have yet; that said, I have gone back to games I played as a teenager and noticed I'm not quite as sharp as I was back then. Someday I'm going to be playing these games with my kids and get my ass handed to me in a neat little package. At which point I'll launch into rant about how much better games were in my day, before we had these holo-projectors and full-body control suits that are just used these days to cover up the uninspired cookie-cutter designs of games like Call of Duty: Blood from a Turnip and they were fun because the graphics sucked and it was about gameplay, dammit!
Anyways, I can give you some advice on that PSP as well. Sadly, there's no perfect all-in-one resource for PSP homebrew like there is the Wii; the closest I've found so far is PSP Hacks, especially the forums. If you want to explore your homebrew options, you'll want to install a custom firmware (CFW) on it; which one to use depends on your PSP model and preferences. I personally have a PSP-Go and run 6.39 PRO-B8 on it. Some CFWs install permanently and other require a program to be run every time you start the PSP, which if you use sleep mode instead of turning it off isn't nearly as annoying as it sounds. The homebrew available for it is impressive, though not as good as the Wii; you can get emulators for almost every system up through the N64 - though SNES emulation is a little slow, and N64 is far more so, assuming you can get your game to run at all. Surprisingly, even though SNES emulation isn't perfect GBA emulation is much further along, if you like that platform. And if you have any interest at all in the PSX, the PSP has a near-perfect emulator built in; you can use PSX2PSP to convert disc images into PSP format. It doesn't support dual-shock though, and images with audio tracks are a bit tricky - they don't work at all in 6.xx firmwares.
As for the memory stick, don't bother with them - get a MicroSD-to-Memory-stick adapter instead, like this one. Or if you have a PSP-Go, you have 16GB of flash memory built in. For your media, use PSPVC to convert videos to something that will play on the PSP. If you want to listen to music, it should handle standard MP3s just fine.
Nevertheless, due to the GIL only one thread can run at once. Yes, I/O bound tasks can benefit from threads, but this is more for architecture reasons than anything else; a thread not running due to the GIL is functionally the same as a thread not running because it's waiting for I/O. You can throw all the cores in the world at it, but they won't speed anything up and can actually slow it down. If you try to take full advantage of said cores for a CPU-bound task, which is what the GP was complaining about and where multi-core processors shine, neither CPython nor Stackless python will help with that (assuming all threads are in the same process). IronPython has this problem as well, but Jython lacks the GIL - it may be worth investigating if one was trying to do heavy-duty CPU-bound processing in Python.
Homebrew central for Wii is at http://www.wiibrew.org/. The first thing you'll need is the Homebrew channel, which is what lets you do everything. It's extremely unlikely to brick anything; it's been installed by hundreds of thousands of people without issue. The most risky thing you can do is installing BootMii, but only if you happen to lose power for the few seconds it writes to boot memory - Nintendo's official updater is far more likely to brick your Wii, and in fact is so bad the authors of BootMii wrote their own, much safer, update code. I recommend you install BootMii anyways, because you can use it to make an image of the flash memory in the Wii, which you can use to restore it to the state it was when you imaged it; emulators aren't going to do anything, but if you or your kids start tinkering with the internals (whether hacking for the sake of hacking or, uh, less legitimate reasons) it would be handy to be able to unbrick it if anything goes wrong. If you're worried about losing power, borrow a UPS while it's updating and you'll be fine.
You'll also need to keep an eye on the system updates. Every now and then Nintendo releases a new version of the system software that doesn't add any new features, but does try to disable homebrew. They tend to get cracked quickly (Team Twiizers say they have plenty of cracks they haven't told anyone about yet, so whenever one gets blocked they just pull out another), but until that happens you might not have access to your homebrew channel. I recommend you update to the latest version, then disable automatic update checking. This will prevent any potential game discs from trying to update your Wii and wiping things out, at least until games with future updates start appearing.
After you install the Homebrew Channel, the first thing you'll want to install is the Homebrew Browser. This tool automatically handles downloading and installing software to your Wii, so you don't have to constantly move the SD card between it and your computer every time you want to install or update something. You can also take a look at WiiBrew's list of homebrew to see what's available. Besides the emulators, some other things to check out are Super Mario War, Piero's Wiicross, ScummVM, source ports of many game engines (Doom, Quake, Descent, Ur-Quan Masters, etc.), WiiMC (a media player), and be sure to take a look at the featured homebrew. There's other quality homebrew there too, I recommend you just try out anything that looks good - it only takes a few minutes to download and install something to try it out.
I mentioned PSX and N64 emulators in my last post, but be warned they're not quite complete yet. They're functional, but not especially fast or compatible. Still, the Virtual Console proves N64 emulation is possible on the Wii, and the developers behind Wii64/WiiSX are very dedicated to their work, so I have no doubt they'll eventually be complete. Even now, many games such as Super Mario 64, Banjo-Kazooie, and Final Fantasy 8 are at least playable on the emulators.
BTW, I don't know how much into the Wii your boys got, but in case they lost interest because most of the games on it are shovelware, there are some gems mixed in with the crud. I can personally recommend Zelda: Twilight Princess, Metroid Prime Trilogy, Super Mario Galaxy 1 & 2, Donkey Kong Country Returns, New Super Mario Bros. Wii, Mario Kart, Super Smash Bros. Brawl, and Resident Evil: The Umbrella Chronicles (maybe not so much for the kids, that last one). Though being mostly a PC gamer myself, I can understand if they already tried all that stuff and just prefer the PC; still, I don't like to ignore a good game just because it's not on my favorite hardware.
bsnes does do this, sort of. It's actually implemented as a.dll/.so/whatever named libsnes, and any program that wants to can load and use it, without needing to implement any SNES emulation on its own. If you want a command-line version of bsnes, a program named SSNES uses libsnes to provide this.
Which actually magically made your computer slow down, for running programs the rely on slow processors (badly programmed games, mostly). Same principle, but it slowed the clock rate rather than increasing it.
I don't know how it compares to the Xbox, but I do know the Wii beats the pants off the Dreamcast when it comes to emulation. Besides being easy to mod and not needing any discs, the faster processor allows for better emulation - there's even PSX and N64 emulators for it now.
Slashdot Mirror
WIN.COM!
For our gold. Obviously.
Obligitory George Carlin bit
640GB ought to be enough for everybody.
http://www.youtube.com/watch?v=I07xDdFMdgw
I'm fine with that, as long as the OSS shills also stop writing "VS isn't in my Linux repo LOLOL" posts. Seriously, it wasn't funny the first time, can we get back on topic, everyone?
If I had mod points, I'd mod you up. Not just because of the content of your post, but after scrolling through 50 pages of HURR DURR M$ IS t3h suxx0rs you're the first person to comment on the actual plugin itself.
Don't forget the link.
"Nooooooooooooo!"
Exactly, we come here to find out what the 25-year-old basement-dwelling nerds have to say about things.
A guy who bought an entry-level camera from Costco doesn't care how many bits his channels have. GIMP's support (or lack thereof) for 16-bit channels are irrelevant to him. Any halfway-decent editor will support 16/24/32 bits-per-pixel images, so when someone is discussing 16-bit color support in regards to photo editors the default assumption is that it refers to bits per channel. Context is everything.
Oh, a sarcasm detector, that's a real useful invention!
Shit, we lost another one. I keep telling them to be more careful where they drop those ropes.
Yes, you're right - native code called from a python script does not have GIL limitations. And Python code cannot directly interact with the hardware, so at some point all I/O code is native x86/x64/ARM/whatever binary code. I'm not denying I/O bound Python code can benefit from multithreading. The point I am trying to make, that was first brought up by citizenr way up there, is that for CPU-bound tasks both Stackless Python and CPython are effectively bound to a single core.
I/O is irrelevant; I have never used Stackless Python so I can't say how it handles I/O bound operations, but if your code is bottlenecked by the CPU improving I/O performance won't make much of a difference. Native code is irrelevant, I am only talking about pure Python code here.
Thanks, glad I could help. I'm 24, so I can't really say I've experienced what you have yet; that said, I have gone back to games I played as a teenager and noticed I'm not quite as sharp as I was back then. Someday I'm going to be playing these games with my kids and get my ass handed to me in a neat little package. At which point I'll launch into rant about how much better games were in my day, before we had these holo-projectors and full-body control suits that are just used these days to cover up the uninspired cookie-cutter designs of games like Call of Duty: Blood from a Turnip and they were fun because the graphics sucked and it was about gameplay, dammit!
Anyways, I can give you some advice on that PSP as well. Sadly, there's no perfect all-in-one resource for PSP homebrew like there is the Wii; the closest I've found so far is PSP Hacks, especially the forums. If you want to explore your homebrew options, you'll want to install a custom firmware (CFW) on it; which one to use depends on your PSP model and preferences. I personally have a PSP-Go and run 6.39 PRO-B8 on it. Some CFWs install permanently and other require a program to be run every time you start the PSP, which if you use sleep mode instead of turning it off isn't nearly as annoying as it sounds. The homebrew available for it is impressive, though not as good as the Wii; you can get emulators for almost every system up through the N64 - though SNES emulation is a little slow, and N64 is far more so, assuming you can get your game to run at all. Surprisingly, even though SNES emulation isn't perfect GBA emulation is much further along, if you like that platform. And if you have any interest at all in the PSX, the PSP has a near-perfect emulator built in; you can use PSX2PSP to convert disc images into PSP format. It doesn't support dual-shock though, and images with audio tracks are a bit tricky - they don't work at all in 6.xx firmwares.
As for the memory stick, don't bother with them - get a MicroSD-to-Memory-stick adapter instead, like this one. Or if you have a PSP-Go, you have 16GB of flash memory built in. For your media, use PSPVC to convert videos to something that will play on the PSP. If you want to listen to music, it should handle standard MP3s just fine.
Nevertheless, due to the GIL only one thread can run at once. Yes, I/O bound tasks can benefit from threads, but this is more for architecture reasons than anything else; a thread not running due to the GIL is functionally the same as a thread not running because it's waiting for I/O. You can throw all the cores in the world at it, but they won't speed anything up and can actually slow it down. If you try to take full advantage of said cores for a CPU-bound task, which is what the GP was complaining about and where multi-core processors shine, neither CPython nor Stackless python will help with that (assuming all threads are in the same process). IronPython has this problem as well, but Jython lacks the GIL - it may be worth investigating if one was trying to do heavy-duty CPU-bound processing in Python.
Seconded. I haven't tried some of the more obscure varieties, but fuji is the best of all the above.
Homebrew central for Wii is at http://www.wiibrew.org/. The first thing you'll need is the Homebrew channel, which is what lets you do everything. It's extremely unlikely to brick anything; it's been installed by hundreds of thousands of people without issue. The most risky thing you can do is installing BootMii, but only if you happen to lose power for the few seconds it writes to boot memory - Nintendo's official updater is far more likely to brick your Wii, and in fact is so bad the authors of BootMii wrote their own, much safer, update code. I recommend you install BootMii anyways, because you can use it to make an image of the flash memory in the Wii, which you can use to restore it to the state it was when you imaged it; emulators aren't going to do anything, but if you or your kids start tinkering with the internals (whether hacking for the sake of hacking or, uh, less legitimate reasons) it would be handy to be able to unbrick it if anything goes wrong. If you're worried about losing power, borrow a UPS while it's updating and you'll be fine.
You'll also need to keep an eye on the system updates. Every now and then Nintendo releases a new version of the system software that doesn't add any new features, but does try to disable homebrew. They tend to get cracked quickly (Team Twiizers say they have plenty of cracks they haven't told anyone about yet, so whenever one gets blocked they just pull out another), but until that happens you might not have access to your homebrew channel. I recommend you update to the latest version, then disable automatic update checking. This will prevent any potential game discs from trying to update your Wii and wiping things out, at least until games with future updates start appearing.
After you install the Homebrew Channel, the first thing you'll want to install is the Homebrew Browser. This tool automatically handles downloading and installing software to your Wii, so you don't have to constantly move the SD card between it and your computer every time you want to install or update something. You can also take a look at WiiBrew's list of homebrew to see what's available. Besides the emulators, some other things to check out are Super Mario War, Piero's Wiicross, ScummVM, source ports of many game engines (Doom, Quake, Descent, Ur-Quan Masters, etc.), WiiMC (a media player), and be sure to take a look at the featured homebrew. There's other quality homebrew there too, I recommend you just try out anything that looks good - it only takes a few minutes to download and install something to try it out.
I mentioned PSX and N64 emulators in my last post, but be warned they're not quite complete yet. They're functional, but not especially fast or compatible. Still, the Virtual Console proves N64 emulation is possible on the Wii, and the developers behind Wii64/WiiSX are very dedicated to their work, so I have no doubt they'll eventually be complete. Even now, many games such as Super Mario 64, Banjo-Kazooie, and Final Fantasy 8 are at least playable on the emulators.
BTW, I don't know how much into the Wii your boys got, but in case they lost interest because most of the games on it are shovelware, there are some gems mixed in with the crud. I can personally recommend Zelda: Twilight Princess, Metroid Prime Trilogy, Super Mario Galaxy 1 & 2, Donkey Kong Country Returns, New Super Mario Bros. Wii, Mario Kart, Super Smash Bros. Brawl, and Resident Evil: The Umbrella Chronicles (maybe not so much for the kids, that last one). Though being mostly a PC gamer myself, I can understand if they already tried all that stuff and just prefer the PC; still, I don't like to ignore a good game just because it's not on my favorite hardware.
...As opposed to standard CPython? Yay GIL!
bsnes does do this, sort of. It's actually implemented as a .dll/.so/whatever named libsnes, and any program that wants to can load and use it, without needing to implement any SNES emulation on its own. If you want a command-line version of bsnes, a program named SSNES uses libsnes to provide this.
Which actually magically made your computer slow down, for running programs the rely on slow processors (badly programmed games, mostly). Same principle, but it slowed the clock rate rather than increasing it.
I don't know how it compares to the Xbox, but I do know the Wii beats the pants off the Dreamcast when it comes to emulation. Besides being easy to mod and not needing any discs, the faster processor allows for better emulation - there's even PSX and N64 emulators for it now.
Gold farmers?
Another goatse warning, here.
In case you missed his first post, this is a goatse troll.
Already been done.