Yes, it does both. All GUI strings are in UTF-8 on all platforms (*not* UTF-16/UCS-2 on Windows), and it also has block-buffered file (FILE*) / filemap (mmap/MapViewOfFile) / directory (opendir/FindFirstFile) / dynamic-link library access (dlsym/GetProcAddress) wrappers that take UTF-8 as well. There's also a handy callback to grab a UTF-8 argv[] list on Windows (I do not hijack main.) And lastly, I provide some RAII UTF-8 UTF-16 transformations for when you absolutely need that on Windows.
Windows 64-bit was the other major reason I wanted to move off of Qt. You can pull it off in Qt, but it takes some source hackery and is unofficial, last I checked anyway (4.6.x)
If you're interesting in audio-visual stuff, I have a library called ruby (I'm great with this naming thing, huh?) that wraps DirectDraw+Direct3D+OpenGL(wgl+glx)+GDI+SDL+X-Video, XAudio2+DirectSound+PulseAudio+PulseSimple+ALSA+OSS+OpenAL+libao, DirectInput+RawInput+XInput+SDL+Xlib cross-platform as well. Like SDL but with pixel shaders, hardware scaling, multi-mouse, etc.
Qt is a very different case because it handles all widgets itself - it uses the OS APIs to get theming information so that it can make them look native, but actual rendering and behavior is fully implemented by the framework.
Yeah, I tell people this and they keep insisting Qt is 100% native. I'm kind of an OCD perfectionist, and find it falls into the 'uncanny valley' of UI design. Alignments and positioning of QGtkStyle and the Windows versions are just... off. Very easy to tell when you compile the same app with phoenix/GTK and phoenix/Qt and compare side by side.
I haven't tracked its development for several years now - now that you've piqued my curiosity, I might actually take another look, and check the size of binaries while I'm at it.
I don't mean to impose, but if you do this, could let me know your results? I'm at setsunakun0 from hotmail. No worries if you're busy, I should really do it myself. I'd like my pros vs cons page to be unbiased and could use the info.
But you don't have to dynamically link to wxWidgets - use static linking and full-program link-time optimization, so that any unused code gets discarded. I bet you could get at the same 300Kb figure in the end, so long as you use a similarly restricted feature set.
It can get that small? My attempts at statically linking Qt with a six-line-long --no-bla configure line, -Os build flag and upx --ultra-best could only get my executables down to an added 4MB or so. I will admit, that's very respectable indeed.
To be honest, I kind of fell in love with the Qt API. Mine is basically Qt sans a few inconsistencies, with references instead of pointers, with less std:: reimplementations (but still a few), and with C++0x enhancements. I haven't used wx because it seemed rather MFC-ish, but if sizes get that small it sounds like a great choice for more complex apps.
but how often is this, realistically, a requirement for most typical projects?
Kind of depends. Eventually someone would port over anything, even to new targets like OS XI. Qt is on Haiku, GTK+ is on OS X, etc. Go too far in the future and the entire UI paradigm we use could be thrown out.
You could end up with an embedded project based on QNX or something where the Qt run-time size becomes a bigger issue. Or maybe you just want to be 100% in control and able to modify the toolkit directly yourself. The library is ISC licensed.
Who knows, I'm definitely not saying phoenix is for everyone. But I do feel it's as small, as easy to learn, and as portable as you can possibly get while still being useful.
More of a wxWidgets Lite, but yes, same idea, just a different scale. wxMSW is 93MB of code, phoenix/Windows is 58KB of code.
You lose a lot of the great features (like HTML rendering) in return for the ability of one person to port the entire toolkit in two days. According to this page, wxmsw28.dll is 10MB in size. phoenix compiles to 20KB. Again, not important if your app spans two DVDs. Kind of important if you have a 5GB/mo hosting bandwidth limit and your app is otherwise only 300KB or so in size.
That said, I also feel the article is fear-mongering. Even if Nokia folds, and even if KDE doesn't utilize its agreement, the code is now LGPL'ed anyway. Such an important project will undoubtedly at least be maintained, if not extended upon, by others.
I hate to come across as advertising, but for those worried about the possibility of any specific API going away...
I've found that most small to mid-sized GUI applications only really need the basics: windows, menus, buttons, check/radio boxes, list/tree views, sliders, scollbars, combo boxes, and something to render graphics (Direct3D/OpenGL/raw pixels) onto. It won't get you Photoshop or Quark Xpress, but that's enough for most CLI frontends, emulators, text/hex editors, office tools, etc.
I put all my eggs in the Qt basket and got burned by a lot of platform-specific bugs. So I took all the core features and wrote a unified wrapper around all of the major toolkit APIs: pure Win32, GTK+ and Qt. In this way, there are no 4-10MB run-time library dependencies, the code is much simpler, and I feel my applications are more portable: the wrapper is so small one could port it to eg Haiku, Cocoa, etc in roughly one weekend. I can also target any platform (Win32, Win64, Linux, OS X), and any toolkit available on each, with the exact same codebase. Eg both Gnome and KDE users gets 100% native apps.
Doesn't have a snazzy public name, but internally I call it phoenix, and it's available here, if anyone is interested. There are, of course, obvious downsides: if you want a complex GUI, you would have to add the higher-order, platform-specific (floating docks, grid views, tab bars, sheets) controls yourself. And it also targets C++0x, which is great for lambda callbacks, but bad for portability at the moment.
Which has a strict non-commercial license. The developers do not want their work being sold for profit.
So in that instance this has nothing to do with the GPL. Not sure about the other two.
Personally, I'm happy to see this one pulled.
I've yet to see anyone who tries the 3ds and ISN'T immediately impressed with it.
I can't move my head or the 3DS more than a centimeter without the effect breaking like one of those cheesy 80s two-state holograms. It's more comfortable to play with the 3D turned off. The 3D itself is just like any of the glasses variety stuff: tons of bill-boarding that requires your eyes to refocus constantly, adds very little to the gameplay experience. I would honestly rather have the glasses if it meant I could move around a bit.
It's not a bad system by any means. It's just a shame to pay twice the cost of the DS for a device that has a quarter of the processing power of my year-old cell phone, especially when I turn the 3D effect off anyway.
That said, still waiting for Zelda, never beat the original OoT. They really should have just delayed the launch until June if they wanted to see bigger numbers.
It's one thing to give a tax break so you can pay for your kids education, it's a totally different thing to give a tax break so you can sustain a grown man who should be working for himself.
In that case... why should I have to pay for all of your children's education(s) with my tax dollars in the first place? At worst, I should only have to pay for one education, my own. Oh, as you just said:
Until greed comes along.
There are couples, both gay and straight, that want marriage primarily for monetary purposes. But I'm certain they are a super minority. Most people get married because they love each other. This has absolutely nothing to do with sexual orientation. Hi, this is my husband, Tom. Or hi, this is my (business? What's domestic mean?) partner, Tom. Hospital visitation was a major problem until just recently, and it may still prove to be when we get our next Republican president. Then there's inheritance rights. Then there's the power to make important medical decisions. And the ability to avoid anti-gay family members from interfering in the most devastating point of your life.
Why do you want tax breaks specifically for having kids, anyway? If you can't afford them, don't have them.
I wouldn't if I were you. If they are charging him with creation of child pornography for *post-editing lyrics into a video*, then they can charge you with possession / distribution (under the interstate commerce clause) of child pornography for having this song. And since the punishment for possession is equal to the punishment for creation, you could be looking at up to twenty years in prison if you were caught.
Perhaps the FBI can set up some honeypot links to this video and nail you for simply *trying* to watch it.
$750,000 to develop computer models to analyze the on-field contributions of soccer players... Do you really want your tax dollars going toward research for Soccer (Football everywhere else in the world) and video game sounds?
Wow, $750,000 for computer AI research, how obscenely wasteful! We definitely need to put a stop to that so that we can continue to fund our $5,000,000,000,000 war in Iraq.
Is there a way for port to simply install a pre-built binary, like apt does? It's not fun waiting three and a half hours on a GCC 4.5 install, only to have it error out near the end, having to port upgrade, and then do it all over again.
In this new interview, engine boss Mark Rein says the developer envisions a future where all game devices are handhelds, with high-end processors inside
The 3DS is a 2011-2012 handheld with a 266MHz processor that's slower than my desktop computer was in the mid-90s. You can argue battery life, but the PSP from 2004 has a faster processor inside of it.
Nintendo may not be the entire handheld market, but they're a huge share of it. He must be talking really, really, really long-term. At this rate, Nintendo will need at least five generations more to match current PC hardware specs in portable form. So if PCs don't get faster by 2040, then he may be right.
POS systems are basically computers with 5" LCD screens these days. A click here to read the agreement would suffice. I don't think it's likely, just pointing out that it can be done at most places, and that consumers wouldn't think twice about hitting 'I agree' there.
The only good news is that it is much harder to enforce a license when buying an actual good, because people aren't used to having to sign a document when buying a stove or a TV.
How long do you think it will be until the Point of Sale terminals have an "I agree to the EULA" checkbox next to "is this total correct?"
You should demand a full refund of all of your subscription fees for the online section.
And for all the games you buy that end up requiring a firmware >= the Other OS disabling version to play, since the game packaging doesn't mention minimum firmware required.
I prefer C++ still. With two tiny template classes:
readonly<int> numCars;
readwrite<int> numBoats;
From inside the class itself, both can be read and written directly: if(numCars == 0) numCars = 2;
From outside of the class, both can be read as functions: if(class.numCars())...;
But only numBoats can be assigned externally.
The article in question points out that Starfox is reproduced well on ZSNES. This despite the fact that ZSNES runs Starfox more than twice as fast as it runs on the real hardware.
The primary slowdown in bsnes comes from the video rendering. Rather than generate entire scanlines at one time, I actually calculate and draw each individual pixel one at a time. This requires 1,364 times the synchronization overhead of a scanline renderer, but is required for a single known effect: if you play Air Strike Patrol, your plane's shadow is drawn on the ground via raster effects. That is, it adjusts the screen brightness register to start drawing the shadow, and adjusts it back to stop drawing it. A scanline renderer like every other SNES emulator uses completely misses this. You may find such minute details unimportant. Unless you spent hundreds of hours playing the game as a kid, you may not even notice. In fact, nobody did for a few years. But when you play the game with this shadow in bsnes, you find the game is now substantially easier. It turns out the shadow is a great visual indicator of where your bombs will drop.
Another good example is Speedy Gonzales. Due to a bug in the game, it completely locks up when you hit a switch in level 6-1 in any other emulator. The reason it works on the real system is due to an extreme edge case, a mid-frame HDMA transfer huring Hblank updates the CPU's memory data register with the required value to break out of a loop that is reading from open bus.
There are hundreds of examples of bugs like this, and dozens of game-specific hacks. Yet for some reason, when Joe Sixpack loads up Zelda and Metroid and sees that they run, he loudly declares that ZSNES et al provide perfect emulation.
And it's not just the video rendering that is so precise. I also emulate all 32 cycles executed between each audio sample generated, rather than generating an entire sample at one point. I break down opcodes into their individual operation cycles, and I then break those down to support the bus hold delays requires for reads and writes to propagate to their inter-connected chips.
So I provide anywhere from 32x to 1,364x the synchronization between each processor; and people are shocked to discover that the system requirements are 10x higher than ZSNES, and 3x higher than Snes9X.
I know, I sound like an asshole here. In fairness, ZSNES and Snes9X are amazing software programs that fill a vital role in enabling those without fast computers to relive the classics. To get compatibility as high as they have, with all the shortcuts they took for speed, is quite an achievement. But they do not belong in an article discussing accuracy and preservation; just as mine would not belong in one discussing emulation speed.
The PDF article purports to be analyzing emulators for their ability to preserve the original hardware; yet on page 20 their choices for SNES emulation are ZSNES, Snes9X and MESS.
The article fails to do proper research on the one system they chose to specifically single out.
ZSNES and Snes9X are emulators created from the 90s, and were meant to perform the bare minimum necessary to play the games at fullspeed on then-current hardware (think 166MHz Pentium systems.)
For popular games with problems, these emulators apply game-specific hacks: adjusting CPU timing, disabling certain parts of the hardware, etc. For less popular games, like Sink or Swim, most people just don't notice that they don't fully work.
The original developers for both of these projects have long since vanished. They move at a snails' pace now because nobody fully understands their code to perform the substantial rewrites that are necessary to match the knowledge we now have about how the hardware really works.
MESS, like MAME, gets much ado about accuracy. And it is clear to me that their teams really do care about it. But quite frankly it is a jack of all trades, master of none situation. The SNES module in MESS has been worked on by a dozen people who take interest in it for a few weeks, and then all progress stops for a few more. Where MESS excels is only where there are no alternatives: such as for the Super A'Can. MESS has yet to even get close to ZSNES or Snes9X on the SNES.
So this article looking into digital preservation of games completely ignores bsnes. I've been working on it for six years now, and at this point I have a known compatibility of 100% with zero known bugs and zero game-specific hacks. I've emulated so many hardware quirks, many that are never used by any games even though they cause massive slowdowns to reproduce, that I've lost count at this point. I've analyzed just about every possible edge case, and I emulate everything at the raw clock/oscillator levels.
There are only three games that do not run, and that is because all three games contained special DSPs on the cartridge PCBs that contained embedded programs that can only be dumped by melting off the IC's cap and reading out the data with an electron microscope. A task that we can't find anyone willing to do. So you could argue that compatibility is at 99.89%.
I'll admit bsnes is not ultra-popular like ZSNES. I don't know why that is. Probably a case of not being around when SNES emulation was in its heyday, and people sticking with what they know despite there being new alternatives. Think of the inertia at first in getting people to move from IE6 to Firefox. The system requirements are also high. I find that most people's reaction to realizing their machine is not fast enough is to belittle the software as being shit; rather than taking the time to understand why the software is so much more demanding, and that it's extremely well optimized for all that it does. But even with that, I can assume at least half of the SNES emulation users out there are capable of running it at full speed. So yeah, I don't know.
It's certainly popular enough that if this "journalist" spent more than five minutes looking, he would have found it.
There's something funny about some random journalist commenting on the perceived accuracy of emulators by just observing the games running. It'd be like asking a young child about how the sun produces light, instead of asking an astronomer as you should.
Of course, perfect emulation is impossible. In fact, the game companies themselves can't even make two runs of the hardware without there being differences. I am very confident that the differences between the original SNES and the SNES Jr are greater than the differences between the original SNES and bsnes.
Further consider that these days no two consoles even act exactly the same. The SNES contained two oscillators in the 21MHz range, and as any EE knows, there is a tolerance to these chips. By having more than one tim
Under your scenario, a percentage of the apps that would otherwise be available to him through Apple's App Store would be distributed from other stores, and thus be out of bounds.
I suppose there is a possibility that some apps would not be distributed this way; but as a developer, it would make no sense to ignore the biggest potential market for moving my applications.
Perhaps we could look to the Android market to see if there are any major applications that are not available at all in the official store...
Most of the people clamouring for multiple stores are committed free-software types from slashdot who wouldn't buy an iP* anyway.
I can't speak for others, but I bought a Mac Mini recently, I've even ported some software to it. I was planning to buy the iPad until I learned of this restriction.
as an end-user, I LIKE the App Store and appreciate Apple's filtering process
And if Apple were to allow you to install apps from other sources, what harm would that cause you? Just continue only going to the Apple Store.
And to the grandparent, end users would care about the approval process because it directly affects what applications they can receive. For instance, if I wanted Flash, or tethering, or an emulator, I would be gravely concerned with said policy.
Slashdot Mirror
Yes, it does both. All GUI strings are in UTF-8 on all platforms (*not* UTF-16/UCS-2 on Windows), and it also has block-buffered file (FILE*) / filemap (mmap/MapViewOfFile) / directory (opendir/FindFirstFile) / dynamic-link library access (dlsym/GetProcAddress) wrappers that take UTF-8 as well. There's also a handy callback to grab a UTF-8 argv[] list on Windows (I do not hijack main.) And lastly, I provide some RAII UTF-8 UTF-16 transformations for when you absolutely need that on Windows.
Windows 64-bit was the other major reason I wanted to move off of Qt. You can pull it off in Qt, but it takes some source hackery and is unofficial, last I checked anyway (4.6.x)
If you're interesting in audio-visual stuff, I have a library called ruby (I'm great with this naming thing, huh?) that wraps DirectDraw+Direct3D+OpenGL(wgl+glx)+GDI+SDL+X-Video, XAudio2+DirectSound+PulseAudio+PulseSimple+ALSA+OSS+OpenAL+libao, DirectInput+RawInput+XInput+SDL+Xlib cross-platform as well. Like SDL but with pixel shaders, hardware scaling, multi-mouse, etc.
Qt is a very different case because it handles all widgets itself - it uses the OS APIs to get theming information so that it can make them look native, but actual rendering and behavior is fully implemented by the framework.
Yeah, I tell people this and they keep insisting Qt is 100% native. I'm kind of an OCD perfectionist, and find it falls into the 'uncanny valley' of UI design. Alignments and positioning of QGtkStyle and the Windows versions are just ... off. Very easy to tell when you compile the same app with phoenix/GTK and phoenix/Qt and compare side by side.
I haven't tracked its development for several years now - now that you've piqued my curiosity, I might actually take another look, and check the size of binaries while I'm at it.
I don't mean to impose, but if you do this, could let me know your results? I'm at setsunakun0 from hotmail. No worries if you're busy, I should really do it myself. I'd like my pros vs cons page to be unbiased and could use the info.
But you don't have to dynamically link to wxWidgets - use static linking and full-program link-time optimization, so that any unused code gets discarded. I bet you could get at the same 300Kb figure in the end, so long as you use a similarly restricted feature set.
It can get that small? My attempts at statically linking Qt with a six-line-long --no-bla configure line, -Os build flag and upx --ultra-best could only get my executables down to an added 4MB or so. I will admit, that's very respectable indeed.
To be honest, I kind of fell in love with the Qt API. Mine is basically Qt sans a few inconsistencies, with references instead of pointers, with less std:: reimplementations (but still a few), and with C++0x enhancements. I haven't used wx because it seemed rather MFC-ish, but if sizes get that small it sounds like a great choice for more complex apps.
but how often is this, realistically, a requirement for most typical projects?
Kind of depends. Eventually someone would port over anything, even to new targets like OS XI. Qt is on Haiku, GTK+ is on OS X, etc. Go too far in the future and the entire UI paradigm we use could be thrown out.
You could end up with an embedded project based on QNX or something where the Qt run-time size becomes a bigger issue. Or maybe you just want to be 100% in control and able to modify the toolkit directly yourself. The library is ISC licensed.
Who knows, I'm definitely not saying phoenix is for everyone. But I do feel it's as small, as easy to learn, and as portable as you can possibly get while still being useful.
More of a wxWidgets Lite, but yes, same idea, just a different scale. wxMSW is 93MB of code, phoenix/Windows is 58KB of code.
You lose a lot of the great features (like HTML rendering) in return for the ability of one person to port the entire toolkit in two days. According to this page, wxmsw28.dll is 10MB in size. phoenix compiles to 20KB. Again, not important if your app spans two DVDs. Kind of important if you have a 5GB/mo hosting bandwidth limit and your app is otherwise only 300KB or so in size.
That said, I also feel the article is fear-mongering. Even if Nokia folds, and even if KDE doesn't utilize its agreement, the code is now LGPL'ed anyway. Such an important project will undoubtedly at least be maintained, if not extended upon, by others.
I hate to come across as advertising, but for those worried about the possibility of any specific API going away ...
I've found that most small to mid-sized GUI applications only really need the basics: windows, menus, buttons, check/radio boxes, list/tree views, sliders, scollbars, combo boxes, and something to render graphics (Direct3D/OpenGL/raw pixels) onto. It won't get you Photoshop or Quark Xpress, but that's enough for most CLI frontends, emulators, text/hex editors, office tools, etc.
I put all my eggs in the Qt basket and got burned by a lot of platform-specific bugs. So I took all the core features and wrote a unified wrapper around all of the major toolkit APIs: pure Win32, GTK+ and Qt. In this way, there are no 4-10MB run-time library dependencies, the code is much simpler, and I feel my applications are more portable: the wrapper is so small one could port it to eg Haiku, Cocoa, etc in roughly one weekend. I can also target any platform (Win32, Win64, Linux, OS X), and any toolkit available on each, with the exact same codebase. Eg both Gnome and KDE users gets 100% native apps.
Doesn't have a snazzy public name, but internally I call it phoenix, and it's available here, if anyone is interested. There are, of course, obvious downsides: if you want a complex GUI, you would have to add the higher-order, platform-specific (floating docks, grid views, tab bars, sheets) controls yourself. And it also targets C++0x, which is great for lambda callbacks, but bad for portability at the moment.
Which has a strict non-commercial license. The developers do not want their work being sold for profit.
So in that instance this has nothing to do with the GPL. Not sure about the other two.
Personally, I'm happy to see this one pulled.
I can't move my head or the 3DS more than a centimeter without the effect breaking like one of those cheesy 80s two-state holograms. It's more comfortable to play with the 3D turned off. The 3D itself is just like any of the glasses variety stuff: tons of bill-boarding that requires your eyes to refocus constantly, adds very little to the gameplay experience. I would honestly rather have the glasses if it meant I could move around a bit.
It's not a bad system by any means. It's just a shame to pay twice the cost of the DS for a device that has a quarter of the processing power of my year-old cell phone, especially when I turn the 3D effect off anyway.
That said, still waiting for Zelda, never beat the original OoT. They really should have just delayed the launch until June if they wanted to see bigger numbers.
It's one thing to give a tax break so you can pay for your kids education, it's a totally different thing to give a tax break so you can sustain a grown man who should be working for himself.
In that case ... why should I have to pay for all of your children's education(s) with my tax dollars in the first place? At worst, I should only have to pay for one education, my own. Oh, as you just said:
Until greed comes along.
There are couples, both gay and straight, that want marriage primarily for monetary purposes. But I'm certain they are a super minority. Most people get married because they love each other. This has absolutely nothing to do with sexual orientation. Hi, this is my husband, Tom. Or hi, this is my (business? What's domestic mean?) partner, Tom. Hospital visitation was a major problem until just recently, and it may still prove to be when we get our next Republican president. Then there's inheritance rights. Then there's the power to make important medical decisions. And the ability to avoid anti-gay family members from interfering in the most devastating point of your life.
Why do you want tax breaks specifically for having kids, anyway? If you can't afford them, don't have them.
That's the very next thing I want to watch!
I wouldn't if I were you. If they are charging him with creation of child pornography for *post-editing lyrics into a video*, then they can charge you with possession / distribution (under the interstate commerce clause) of child pornography for having this song. And since the punishment for possession is equal to the punishment for creation, you could be looking at up to twenty years in prison if you were caught.
Perhaps the FBI can set up some honeypot links to this video and nail you for simply *trying* to watch it.
Honestly, if people can't start up "xSucks.com" they'll go and register something like "truthX" and spew their hate there.
The owner of sucks.com should start selling subdomain redirects for $~3/yr.
$750,000 to develop computer models to analyze the on-field contributions of soccer players ... Do you really want your tax dollars going toward research for Soccer (Football everywhere else in the world) and video game sounds?
Wow, $750,000 for computer AI research, how obscenely wasteful! We definitely need to put a stop to that so that we can continue to fund our $5,000,000,000,000 war in Iraq.
Is there a way for port to simply install a pre-built binary, like apt does? It's not fun waiting three and a half hours on a GCC 4.5 install, only to have it error out near the end, having to port upgrade, and then do it all over again.
How long have PCs been stuck at 2000 to 3000 MHz, just adding core after core?
The clock speed is stagnant, but a 3GHz Netburst Pentium IV is about 40% of the speed of my 3GHz Core 2.
In this new interview, engine boss Mark Rein says the developer envisions a future where all game devices are handhelds, with high-end processors inside
The 3DS is a 2011-2012 handheld with a 266MHz processor that's slower than my desktop computer was in the mid-90s. You can argue battery life, but the PSP from 2004 has a faster processor inside of it.
Nintendo may not be the entire handheld market, but they're a huge share of it. He must be talking really, really, really long-term. At this rate, Nintendo will need at least five generations more to match current PC hardware specs in portable form. So if PCs don't get faster by 2040, then he may be right.
It worked great with Bleem!, of course they were going to try again.
POS systems are basically computers with 5" LCD screens these days. A click here to read the agreement would suffice. I don't think it's likely, just pointing out that it can be done at most places, and that consumers wouldn't think twice about hitting 'I agree' there.
The only good news is that it is much harder to enforce a license when buying an actual good, because people aren't used to having to sign a document when buying a stove or a TV.
How long do you think it will be until the Point of Sale terminals have an "I agree to the EULA" checkbox next to "is this total correct?"
You should demand a full refund of all of your subscription fees for the online section.
And for all the games you buy that end up requiring a firmware >= the Other OS disabling version to play, since the game packaging doesn't mention minimum firmware required.
I prefer C++ still. With two tiny template classes:
...;
readonly<int> numCars;
readwrite<int> numBoats;
From inside the class itself, both can be read and written directly: if(numCars == 0) numCars = 2;
From outside of the class, both can be read as functions: if(class.numCars())
But only numBoats can be assigned externally.
No, there is no code that acts differently when Uniracers is loaded.
And to provide a bit more context:
The article in question points out that Starfox is reproduced well on ZSNES. This despite the fact that ZSNES runs Starfox more than twice as fast as it runs on the real hardware.
The primary slowdown in bsnes comes from the video rendering. Rather than generate entire scanlines at one time, I actually calculate and draw each individual pixel one at a time. This requires 1,364 times the synchronization overhead of a scanline renderer, but is required for a single known effect: if you play Air Strike Patrol, your plane's shadow is drawn on the ground via raster effects. That is, it adjusts the screen brightness register to start drawing the shadow, and adjusts it back to stop drawing it. A scanline renderer like every other SNES emulator uses completely misses this. You may find such minute details unimportant. Unless you spent hundreds of hours playing the game as a kid, you may not even notice. In fact, nobody did for a few years. But when you play the game with this shadow in bsnes, you find the game is now substantially easier. It turns out the shadow is a great visual indicator of where your bombs will drop.
Another good example is Speedy Gonzales. Due to a bug in the game, it completely locks up when you hit a switch in level 6-1 in any other emulator. The reason it works on the real system is due to an extreme edge case, a mid-frame HDMA transfer huring Hblank updates the CPU's memory data register with the required value to break out of a loop that is reading from open bus.
There are hundreds of examples of bugs like this, and dozens of game-specific hacks. Yet for some reason, when Joe Sixpack loads up Zelda and Metroid and sees that they run, he loudly declares that ZSNES et al provide perfect emulation.
And it's not just the video rendering that is so precise. I also emulate all 32 cycles executed between each audio sample generated, rather than generating an entire sample at one point. I break down opcodes into their individual operation cycles, and I then break those down to support the bus hold delays requires for reads and writes to propagate to their inter-connected chips.
So I provide anywhere from 32x to 1,364x the synchronization between each processor; and people are shocked to discover that the system requirements are 10x higher than ZSNES, and 3x higher than Snes9X.
I know, I sound like an asshole here. In fairness, ZSNES and Snes9X are amazing software programs that fill a vital role in enabling those without fast computers to relive the classics. To get compatibility as high as they have, with all the shortcuts they took for speed, is quite an achievement. But they do not belong in an article discussing accuracy and preservation; just as mine would not belong in one discussing emulation speed.
The PDF article purports to be analyzing emulators for their ability to preserve the original hardware; yet on page 20 their choices for SNES emulation are ZSNES, Snes9X and MESS.
The article fails to do proper research on the one system they chose to specifically single out.
ZSNES and Snes9X are emulators created from the 90s, and were meant to perform the bare minimum necessary to play the games at fullspeed on then-current hardware (think 166MHz Pentium systems.)
For popular games with problems, these emulators apply game-specific hacks: adjusting CPU timing, disabling certain parts of the hardware, etc. For less popular games, like Sink or Swim, most people just don't notice that they don't fully work.
The original developers for both of these projects have long since vanished. They move at a snails' pace now because nobody fully understands their code to perform the substantial rewrites that are necessary to match the knowledge we now have about how the hardware really works.
MESS, like MAME, gets much ado about accuracy. And it is clear to me that their teams really do care about it. But quite frankly it is a jack of all trades, master of none situation. The SNES module in MESS has been worked on by a dozen people who take interest in it for a few weeks, and then all progress stops for a few more. Where MESS excels is only where there are no alternatives: such as for the Super A'Can. MESS has yet to even get close to ZSNES or Snes9X on the SNES.
So this article looking into digital preservation of games completely ignores bsnes. I've been working on it for six years now, and at this point I have a known compatibility of 100% with zero known bugs and zero game-specific hacks. I've emulated so many hardware quirks, many that are never used by any games even though they cause massive slowdowns to reproduce, that I've lost count at this point. I've analyzed just about every possible edge case, and I emulate everything at the raw clock/oscillator levels.
There are only three games that do not run, and that is because all three games contained special DSPs on the cartridge PCBs that contained embedded programs that can only be dumped by melting off the IC's cap and reading out the data with an electron microscope. A task that we can't find anyone willing to do. So you could argue that compatibility is at 99.89%.
I'll admit bsnes is not ultra-popular like ZSNES. I don't know why that is. Probably a case of not being around when SNES emulation was in its heyday, and people sticking with what they know despite there being new alternatives. Think of the inertia at first in getting people to move from IE6 to Firefox. The system requirements are also high. I find that most people's reaction to realizing their machine is not fast enough is to belittle the software as being shit; rather than taking the time to understand why the software is so much more demanding, and that it's extremely well optimized for all that it does. But even with that, I can assume at least half of the SNES emulation users out there are capable of running it at full speed. So yeah, I don't know.
It's certainly popular enough that if this "journalist" spent more than five minutes looking, he would have found it.
There's something funny about some random journalist commenting on the perceived accuracy of emulators by just observing the games running. It'd be like asking a young child about how the sun produces light, instead of asking an astronomer as you should.
Of course, perfect emulation is impossible. In fact, the game companies themselves can't even make two runs of the hardware without there being differences. I am very confident that the differences between the original SNES and the SNES Jr are greater than the differences between the original SNES and bsnes.
Further consider that these days no two consoles even act exactly the same. The SNES contained two oscillators in the 21MHz range, and as any EE knows, there is a tolerance to these chips. By having more than one tim
Under your scenario, a percentage of the apps that would otherwise be available to him through Apple's App Store would be distributed from other stores, and thus be out of bounds.
I suppose there is a possibility that some apps would not be distributed this way; but as a developer, it would make no sense to ignore the biggest potential market for moving my applications.
...
Perhaps we could look to the Android market to see if there are any major applications that are not available at all in the official store
Most of the people clamouring for multiple stores are committed free-software types from slashdot who wouldn't buy an iP* anyway.
I can't speak for others, but I bought a Mac Mini recently, I've even ported some software to it. I was planning to buy the iPad until I learned of this restriction.
as an end-user, I LIKE the App Store and appreciate Apple's filtering process
And if Apple were to allow you to install apps from other sources, what harm would that cause you? Just continue only going to the Apple Store.
And to the grandparent, end users would care about the approval process because it directly affects what applications they can receive. For instance, if I wanted Flash, or tethering, or an emulator, I would be gravely concerned with said policy.