MyCoolStory.cpp

>write awesome but buggy as hell C program to kick ass at minesweeper
>1 second top score on expert mode.  .47 seconds if I use a clone that keeps track of decimals.
>nagging feeling that I'm being a noob by writing in C and not C++
>learn C++ and rewrite program using classes and maps and vectors and lists and that kind of shit instead of just arrays.
>program works perfectly now, code is much cleaner, but it can't solve an expert board in under 10 seconds
>switch on every speed optimization I can find in Visual Studio
>times down to 6-7 seconds
>decide to rewrite the whole thing in C again from scratch so maybe it can be fast AND reliable at the same time
>change mind and decide to bitch to /prog/ instead and then take a nap

Nice hax, anus.

UPDATE:

>keep c++ framework
>replace the code that actually does stuff and needs to be fast with the old c code
>tweak code to work in new environment, make a couple improvements to algorithm
>average solving time ~.3 seconds, new record is .25 seconds
>program locks up half the time in vista for some unknown reason, though >:I

>>42
>program locks up half the time in vista for some unknown reason, though >:I
>mfw i read that

>>43
it's because the program tries to read a square before it's redrawn on the screen, but somewhere in the middle of 5 GetPixel calls it finally updates, and tricks the program into thinking it's a different type of square than it is.  apparently XP has always been updating the screen faster than my program could read it, so it wasn't an issue.

trying to figure out a workaround that won't slow things down.

>>44
You're a fucking moron.

>>45
NO U

(fixed it btw)

OMGZ LULZ ARCHIVE LEGENDARY THREAD NAO FAGET ROASTING IN EPIC BREAD

>>46
What was the problem?

>>47
Oh wow. This poster posts as though he is straight out of /b/! We have a standard for posting just so you know.

>>48
When the program calculates that a square is safe to click, it sends the click and immediately starts trying to read its new state from the screen.  Sometimes the game doesn't update fast enough, and the program will loop until it gets a valid read,  but sometimes it'd get a mix of the old state (an unclicked square) and the new state (a "3", for instance), and the program would get confused since the mix of data actually corresponded to a completely different state.

I fixed it by just choosing a different (and actually smaller) set of pixels to poll, where that kind of thing won't happen.

Record's down to .23 seconds already thanks to the speed improvement from not needing to poll as many pixels.

>>50
You're awesome. Keep up the good work.

I'm just gonna bump this one more time before going to sleep. I'm not OP, by the way, because
I know how to quote,
,,faggot''

>>52
That's not how you quote
«faggot».

>>42
Sounds like you figured out how to use C++ correctly. I use classes for higher-level components, but underneath, I'm using C style arrays for constant-time lookups where possible. Just because the standard library has associative key-value data structures doesn't mean they're going to be faster than straight memory offset calculations. You'd have to be retarded to think that.

Associative data structures are more useful for when your key data type has a non-trivial representation that can't be easily mapped to a unique array offset. Like strings for example.

>>53
,,proper quotes''
«gay quotes»
``faggot quotes''
"neurotypical quotes"
`èxpert quoté´
⁶⁶ awesome quotes ⁹⁹
「weeaboo quotes」
Know the difference.

And finally,
₉₉proper awesome quotes 99

>>55
You missed ^_\\proper quotes^_//

>>57
U MENA ^\\FURIOUS MASTURBATION QUOTES^//

>>58
[code] tags?

>>59
Why not?

So what's causing this, cache misses?

>>61
OP's incompetence, probably.

>>61
No, not cache misses per se. OP was using the wrong data structures. Instead of using 2-dimensional arrays with O(1) lookup complexity like he was in C, he thought it was a good idea to use std::map, which is usually a red-black tree or avl tree with O(log n) lookup complexity, simply because he wanted to ``make it look more like C++,'' whatever that means. He has since corrected his mistake. Yes, using std::map does stress the cache more by nature of nodes not being local to one another using the default allocator, as well as link and allocation overhead. However, using a std::map for something that can easily be implementing as a memory offset calculation for indexing into an array is the real meat of the problem.

In other words, >>62 is correct.

>>62
>>63
just for that, i'm not going to post the source :p

enjoy your pathetic >.15s minesweeper times.