... wow. The reason PGO is so nice is because it reorders your human-readable code into something faster.

Assume a switch with eight possible cases, and non-linear indices that do not allow for a simple jump table optimization. Two of them may be vastly more common than the other six, and PGO can take them out of the switch, or reorder them to the top. You can also do this by hand, but it will make your code messier and harder to maintain.

Or take the frequency of code execution. Two routines may execute a lot, so they are stuck together in memory to aid in caching. But it may make no sense to have these two functions anywhere near each other ... say they are from two entirely different classes.

PGO also frequently decides when to inline things or when not to, and even telling the compiler when to inline isn't guaranteed. You'd have to resort to compiler-specific attributes (always_inline/__forceinline.) And the list goes on and on.

Taking your argument to the extreme, hand-writing your code in pure assembler can get you even more speed, and now you don't even need -O3 for decent speed. But there's a reason people use high-level languages. PGO is just one more tool to make your code more stable and easier to maintain.

It has little to do with reading the contracts. The problem is that if you want a good white collar job, you need a cell phone. And if you want a cell phone, every last service provider has the same clauses. Reading the clause won't help, as unfortunately most people don't care about their privacy. The providers won't care even if they did lose 0.1% of their customer base if the spyware gained them +10% profits.

One of the worst trends in computing is trying to make real-world analogies to everything. Who cares what the real top of your desk looks like? Your desk is not a personal computer, and vice versa.

My Intel Atom @ 1.6GHz can get 80fps, so yes, it's most definitely a configuration issue. Or perhaps he is using the accuracy profile. I really need to be more clear on the downloads page about the performance of the three profiles.

Ex: http://img405.imageshack.us/img405/9608/zelda3v.png

Why would you quote my name? :/

My first PC was a 25MHz 486SX. You will have a PC fast enough for bsnes one day. In fact, you can get such a system for ~$100 used today. And then you can play every game you care about, and every game that people other than you care about as well. Whereas you probably won't be using ZSNES on your new Windows 10 box that lacks 32-bit run-time libraries.

Anyway, something else is wrong if 2.5GHz isn't enough for you. But it doesn't seem like you are interested in troubleshooting, so no worries. Sorry that my software gave you a hard time.

Without double-checking the list, I can tell you right now that Wild Guns has hacks in most emulators.

That game will trigger a DMA past the end of NMI, and immediately toggle NMI on the next instruction for unknown reasons. Because of a hardware edge case, the NMI status is cached one cycle sooner than the next opcode.

Only bsnes and Super Sleuth simulate that delay, the rest hack around it. Without either, the entire in-game screen would flash between the real image and garbage every other frame.

If you want to see a list of ~100 or so known bugs, you could try here: https://zsnes.bountysource.com/development/bug_report

The library is still in progress re: memory management. Right now the idea is that the UI elements won't eat all that much memory, so why waste time with allocation/deallocation? You can of course use pointers anyway, and delete them whenever, but at the moment it'll be your responsibility to ensure they were no longer in use or bad things will happen. I'll add destructors that remove widgets from containers and such in a future release.

I use my own string class because std::string is garbage. No token replace (eg replace all 'cat' with 'dog'), no tokenize string (split, explode on key), unsafe find/strpos return value on non-matches (boost::optional works much better and throws exceptions when abused), no char transform (PHP strtr), no case-insensitive find, no support for parsing quoted strings (think split on = in a config file, quoted parameter may have = that we want to ignore; or think any kind of scripting/assembly syntax's strings), no math parsing (tell me what "3+2*7+4" equals), has to create a new object to be compatible with the native char* type of the language (c_str()), formatting with ios is torture, and building streams is a pain (no return { "My name is ", name, ", and I am ", age, " years old.\n" }; or openFIle({ baseFileName, ".txt" });) - it prefers the nonsensical operator left-shift over using traits to allow the more natural +, on and on. I could write a book on this class alone.

I have my own function class because std::function sucks at binding to member function pointers. You have to mix memfn/bind1st in odd ways, and when you get above one parameter I can't even figure out how to use it anymore. With mine: onClose = &globalFuncOrMemberStaticFunc; onClose = { &Class::MemberFunc, &classObject }; onClose = [this]() { closure(); }; can also attach to boost::bind for argument shuffling.

My version of optional is so you don't need boost to use it, and is four lines long. And that's it. The only thing you are ever exposed to is my string class on some return values, which is castable to and convertible from const char*, so pretend it's that and use with std::string if you like.

Thank you kindly for testing that for me. The numbers are at least twice as good as Qt, and GTK+ is DLL city. And yeah, ten years will do that to a project. I have noticed the run-time sizes going up with each new release of Qt. Also agree with you on sizes in general. Super Mario World was a 512KB game, and applications used to come on floppy disks. We've really lost our way when it comes to size and speed optimizations in programs.

I know it's not a big deal for most people, especially with Google Code hosting. But for one example, I had a binary differencing patcher. In the game translation scene, most people like to include a patcher with their patch files. But when the patcher is bigger than the entire game itself ... they tend to scoff and stick with the older DOS-based 40KB IPS patchers. And then you get a site like smwcentral that hosts thousands of patches, and having a patcher with each archive becomes impossible. Make them download a second file, and the less intelligent get confused. So there really are use cases where binary size matters.

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.

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 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.