Anonymous user
Talk:Minesweeper game: Difference between revisions
→Too long?: recursion problem with Python 3 version
(→Too long?: recursion problem with Python 3 version) |
|||
| (5 intermediate revisions by 5 users not shown) | |||
Line 3:
I freely admit that the task was chosen with an eye to attracting those new to programming :-)<br> --[[User:Paddy3118|Paddy3118]] 10:58, 10 July 2010 (UTC)
:Sometimes the Python version exceeds the standard [http://effbot.org/pyref/sys.getrecursionlimit.htm recursion limit] (1,000) on my machine when clearing the first grid point:
<pre>
There are 4 true mines of fixed position in the grid
......
......
......
......
m x y/c x y/p/r: c 2 4
Traceback (most recent call last):
File "/Users/martin/mine.py", line 125, in <module>
clear(x,y, showgrid, grid, mines, markedmines)
File "/Users/martin/mine.py", line 97, in clear
clear(xx, yy, showgrid, grid, mines, markedmines)
File "/Users/martin/mine.py", line 97, in clear
clear(xx, yy, showgrid, grid, mines, markedmines)
File "/Users/martin/mine.py", line 97, in clear
clear(xx, yy, showgrid, grid, mines, markedmines)
(repeats a zillion times...)
File "/Users/martin/mine.py", line 86, in clear
for xx in (x-1, x, x+1)
RuntimeError: maximum recursion depth exceeded while getting the str of an object
</pre>
:I suppose that's a bug? Otherwise, I'm pretty impressed with the brevity and readability of the Python solution! --[[User:Morn|Morn]] 11:15, 25 December 2010 (UTC)
== Differences in behavior from classic game ==
Line 25 ⟶ 52:
FWIW, the ''real'' difference between this task and the classic game is that in the classic implementation, the first square you clear is ''never'' a mine; if there is a mine there, the game moves it away. In fact, there was (is?) a cheat which lets you find out where the mines are, and you can use that to confirm it yourself. (Alas, I don't remember the details of the cheat; it was a long time ago.) The moving of a mine only ever worked for the first square you cleared though. I don't suggest that anyone implements it, but it's one of the marks of the real original; it had a lot more thought applied to it than it appeared to have at the time. –[[User:Dkf|Donal Fellows]] 23:31, 11 July 2010 (UTC)
: Interesting feature. I believe the cheat was taken away before XP. --[[User:Dgamey|Dgamey]] 03:01, 12 July 2010 (UTC)
:: Could well be. It relied on being able to toggle a pixel in the corner of the screen directly, which I can imagine didn't fit well with the display management model updates that happened in the NT line of kernels. –[[User:Dkf|Donal Fellows]] 08:42, 12 July 2010 (UTC)
::: With Windows, that's abstracted away with Win32 (the API set, which oddly was available on Windows 3.1 and earlier). All graphic access in Windows prior to DirectX is done was a device-neutral fashion; a program could conceivably operate the same way on a printer framebuffer as it did on a monitor. The call sequence is the same (Get a handle to the device context, get a handle to the bitmap for the device context, lock the bitmap to get a buffer pointer, unlock bitmap, unlock the device context.), and any Win32 app can grab the NULL DC, which is assumed by the system to mean the full desktop. (Pretty easy way to test your coord-calculating logic in your code, actually.)
::: The easter egg apparently disappeared in XP SP2, which had a lot of security improvements. If I had to guess, I'd say that corner pixel violated some security policy that didn't have a basis in technical limitations, like covering part of the screen that didn't belong to the app and didn't serve a core app role. --[[User:Short Circuit|Michael Mol]] 12:34, 12 July 2010 (UTC)
60% seems too high. --[[User:Rdm|Rdm]] 17:35, 21 July 2010 (UTC)
: Agreed. Based on Dgamey's values above perhaps the task spec of 20-60% mines should be changed to 10-20%.--[[User:Tikkanz|Tikkanz]] 21:36, 21 July 2010 (UTC)
:: I suggest making the revision optional so as not to invalidate original entries. --[[User:Dgamey|Dgamey]] 01:22, 22 July 2010 (UTC)
| |||