Solitaire Till Dawn BETA 2 is now available for download.
This release should fix the serious compatibility problems with OS X 10.6.8 (Snow Leopard) and 10.7 (Lion) that were seen in the b1 release. These were bugs ID 1 and 2 in our Bug List.
We also know more now about bug ID 3, where some users never see a game window, and instead only get a menu bar with nearly all of its menu items disabled. This is a conflict between Apple's "Gatekeeper" feature and software downloaded from the Internet instead of from the App Store. Update: The workaround that we originally suggested for this problem is not helping. Currently we have no solution, but it's our highest priority and we're working on it.
To get the b2 release, visit our Beta Page.
Solitaire Till Dawn - card games for Macintosh
Friday, January 3, 2014
Thursday, January 2, 2014
Happy New Year—and Beta!
We still can't tell you when you'll be able to buy Solitaire Till Dawn, but we are kicking off the new year by launching our beta program!
Beta means that Solitaire Till Dawn is nearly done (all the features are in, and everything works nearly all the time) but there may still be some bugs left to find and fix. By participating in the beta program, you can help us shake out the last bugs and get Solitaire Till Dawn ready for release as soon as possible.
If you've been itching to get hold of the new Solitaire Till Dawn, and you're willing to try a pre-release version, then we invite you to visit our Beta page by clicking that link or the one in the sidebar to the right.
Be aware that the beta version is time-limited and will expire in a few weeks. If significant bugs are found, we may issue further beta versions with later expiration dates.
When will it really be done and available for purchase? As always, we don't know. It depends on how well the beta goes, for one thing. For another, we are still awaiting some important artwork; and we cannot predict how long Apple will take to approve Solitaire Till Dawn for the App Store even when we think it's 100% ready. So please continue to be patient; and in the meantime, enjoy the beta. (We can't promise that you'll always have a non-expired beta until you can buy the finished version, but we are trying to get the finished version out as soon as possible, and we want to keep you happy in the meantime.)
Update: There's a bug in some builds of OS X 10.7.5 that can cause Solitaire Till Dawn to crash, and may cause other issues. Apple has issued a fix, in the form of a minor update to 10.7.5. If you have 10.7.5, please use Software Update to see if there's an update to 10.7.5 that you can install.
Update: We've added a Bug List page where you can see all of the bugs that have been reported to us, and monitor our progress in fixing them.
Beta means that Solitaire Till Dawn is nearly done (all the features are in, and everything works nearly all the time) but there may still be some bugs left to find and fix. By participating in the beta program, you can help us shake out the last bugs and get Solitaire Till Dawn ready for release as soon as possible.
If you've been itching to get hold of the new Solitaire Till Dawn, and you're willing to try a pre-release version, then we invite you to visit our Beta page by clicking that link or the one in the sidebar to the right.
Be aware that the beta version is time-limited and will expire in a few weeks. If significant bugs are found, we may issue further beta versions with later expiration dates.
When will it really be done and available for purchase? As always, we don't know. It depends on how well the beta goes, for one thing. For another, we are still awaiting some important artwork; and we cannot predict how long Apple will take to approve Solitaire Till Dawn for the App Store even when we think it's 100% ready. So please continue to be patient; and in the meantime, enjoy the beta. (We can't promise that you'll always have a non-expired beta until you can buy the finished version, but we are trying to get the finished version out as soon as possible, and we want to keep you happy in the meantime.)
Update: There's a bug in some builds of OS X 10.7.5 that can cause Solitaire Till Dawn to crash, and may cause other issues. Apple has issued a fix, in the form of a minor update to 10.7.5. If you have 10.7.5, please use Software Update to see if there's an update to 10.7.5 that you can install.
Update: We've added a Bug List page where you can see all of the bugs that have been reported to us, and monitor our progress in fixing them.
Thursday, October 24, 2013
You've Gotta Have Art...
I sent off a couple of requests for artwork quotes today. I can't release Solitaire Till Dawn without at least a new icon, simply because the old one is too small for the App Store: they insist on big, high-resolution icons. I am hoping that it won't take more than two or three weeks for that to be done, as it's a pretty simple job.
We've also requested a quote for some new card art. That will take longer I'm sure, and I have no idea how much it might cost: maybe more than I can afford at this point. But even if we commission new card art, we won't let it delay the release significantly. We can always add it as an update later, if it's not ready for the initial release.
Other progress: the Help pages are essentially done now, although I still need to add a couple of the "special" pages, like "What's New" and "Frequently Asked Questions".
Also I have completed the reveal-overlapped-cards feature. Veterans of Solitaire Till Dawn know that, in some games, a fan of cards can get way too long to fit normally in the window. When that happens, the fan will automatically compress, that is, squeeze the cards more closely together until they fit. But if they squeeze too much, then you can't read what the squeezed cards are any more, and that's not fair.
The old Solitaire Till Dawn had a feature that let you ⌘-click on cards to let you peek at them when they're tightly-squeezed like that. I've now added this feature into the new version, too. It looks a little different than it used to. Here's a small screen shot:
We've also requested a quote for some new card art. That will take longer I'm sure, and I have no idea how much it might cost: maybe more than I can afford at this point. But even if we commission new card art, we won't let it delay the release significantly. We can always add it as an update later, if it's not ready for the initial release.
Other progress: the Help pages are essentially done now, although I still need to add a couple of the "special" pages, like "What's New" and "Frequently Asked Questions".
Also I have completed the reveal-overlapped-cards feature. Veterans of Solitaire Till Dawn know that, in some games, a fan of cards can get way too long to fit normally in the window. When that happens, the fan will automatically compress, that is, squeeze the cards more closely together until they fit. But if they squeeze too much, then you can't read what the squeezed cards are any more, and that's not fair.
The old Solitaire Till Dawn had a feature that let you ⌘-click on cards to let you peek at them when they're tightly-squeezed like that. I've now added this feature into the new version, too. It looks a little different than it used to. Here's a small screen shot:
⌘-clicking this black 2 reveals that it is a 2♣.
Friday, October 11, 2013
Snow Leopard It Is
A quick update: In my last post, I asked whether anyone would be upset if the new release required Lion (Max OS X 10.7) or later. I received several responses from users on Snow Leopard (10.6) who were hoping to be able to use the new Solitaire Till Dawn. I hear you, and I am keeping as much backward compatibility as I can reasonably manage. The new release will be compatible with Snow Leopard (10.6.8) or later; and of course "later" includes Lion, Mountain Lion, and the soon-to-be-released Mavericks.
Saturday, September 28, 2013
A Little Atmosphere
Just a quick progress report: Since my last post, I've finished up the animation bug fixes I was working on, and I'm now doing a little decorating: think of it as turning Solitaire Till Dawn into a place with "a little atmosphere."
Much of this work has actually been done for a long time: selecting cardbacks, royalty images, and window backgrounds is all already working. But the user interface for the Decor window, where you can select these things, was clunky and hard to use. I spent some time on it, and I think it's better now.
By the way, there's one feature from old Solitaire Till Dawn that won't be in the next release: you won't be able to create cardbacks using your own photos. I'm sure people will want that, and it will appear in a later release. But right now I'm focussed on getting a usable release out the door and into your hands, and custom cardbacks would take too much time to implement. (You will be able to use your own photos for the window background; that's already working. Cardbacks are harder because they're small, so you'll want a nice user interface to scale and crop your image so that it fits nicely: that's the hard part.)
I am now adding the old sound effects to the new release. This is another feature I might have skipped if it would have taken very long to do, but Cocoa makes it dead simple. I've spent just part of today on it, and I'm nearly done already.
Update October 11 2013: I am retaining compatibility with Snow Leopard (Mac OS X 10.6.8). Everybody who wants the new version but doesn't want to upgrade to Lion or Mountain Lion, y'all can relax. And thanks for the feedback!
Here's a chance for you to make yourself heard: I am now inclined to make this new version require at least Lion (Mac OS X 10.7) or later. I was going to make it compatible with the older Snow Leopard (10.6) as well, but there are some niceties in Lion that I'd like to take advantage of. The old Solitaire Till Dawn will run in Snow Leopard if you hand-install Rosetta (which is free from Apple), and Lion is now nearly three years old, so I think requiring at-least-Lion is not unreasonable. If you are still running Snow Leopard and you desperately want the new release to work on your current system, please leave a comment here. No promises, but I'll be listening. (If you are not using Snow Leopard, please do not respond. I assume that nearly everyone following this blog is using at-least-Lion, and I only need to hear from the exceptions. Thanks!)
Much of this work has actually been done for a long time: selecting cardbacks, royalty images, and window backgrounds is all already working. But the user interface for the Decor window, where you can select these things, was clunky and hard to use. I spent some time on it, and I think it's better now.
By the way, there's one feature from old Solitaire Till Dawn that won't be in the next release: you won't be able to create cardbacks using your own photos. I'm sure people will want that, and it will appear in a later release. But right now I'm focussed on getting a usable release out the door and into your hands, and custom cardbacks would take too much time to implement. (You will be able to use your own photos for the window background; that's already working. Cardbacks are harder because they're small, so you'll want a nice user interface to scale and crop your image so that it fits nicely: that's the hard part.)
I am now adding the old sound effects to the new release. This is another feature I might have skipped if it would have taken very long to do, but Cocoa makes it dead simple. I've spent just part of today on it, and I'm nearly done already.
Update October 11 2013: I am retaining compatibility with Snow Leopard (Mac OS X 10.6.8). Everybody who wants the new version but doesn't want to upgrade to Lion or Mountain Lion, y'all can relax. And thanks for the feedback!
Tuesday, September 17, 2013
Bloodied but Unbowed
Last post, I mentioned that after a difficult-but-necessary architecture change, I tested all 100 games and discovered some previously-unnoticed bugs. This little status update is to reassure you all, once again, that I'm still working on Solitaire Till Dawn, and to report that I have once again descended into the pit of monsters that is concurrent animation programming, and once again emerged victorious.
I really hate working on the animation stuff. It has to look good (and it has to just plain work), and I'm not an expert on this kind of coding. This latest bug fix took me several days of studying old code and trying to remember how it works, watching the animations fail in veeeerrrryyyy sssssslllooooowwww mmmmooootttiiiooonnn so that I could see exactly what was happening, and experimenting with fixes.
By the way: if it surprises you that I can't remember how my own code works, then you've simply never coded anything very complex yourself. Every experienced programmer knows that within three months, any code written today will become as unfamiliar as if it had been written by a Martian. That's why good programmers comment their code liberally, and write it for clarity even if they don't expect anyone else to ever see it. And I do that; but There Are Times when even that is not enough, and you wind up spending significant amounts of time trying to figure out just exactly what the hell you thought you were doing when you wrote some bit of code or other.
Anyway, I won this round. But there are still more bugs to fix, so I'm going to cut this short and get on with fixing them. Happy Autumn, everybody!
I really hate working on the animation stuff. It has to look good (and it has to just plain work), and I'm not an expert on this kind of coding. This latest bug fix took me several days of studying old code and trying to remember how it works, watching the animations fail in veeeerrrryyyy sssssslllooooowwww mmmmooootttiiiooonnn so that I could see exactly what was happening, and experimenting with fixes.
By the way: if it surprises you that I can't remember how my own code works, then you've simply never coded anything very complex yourself. Every experienced programmer knows that within three months, any code written today will become as unfamiliar as if it had been written by a Martian. That's why good programmers comment their code liberally, and write it for clarity even if they don't expect anyone else to ever see it. And I do that; but There Are Times when even that is not enough, and you wind up spending significant amounts of time trying to figure out just exactly what the hell you thought you were doing when you wrote some bit of code or other.
Anyway, I won this round. But there are still more bugs to fix, so I'm going to cut this short and get on with fixing them. Happy Autumn, everybody!
Tuesday, August 6, 2013
ARC, pronounced "Argh"
When I built the previous (and still current) incarnation of Solitaire Till Dawn, I made the mistake of clinging to an older technology: I used Apple's Carbon API instead of their newer Cocoa framework. I had what I thought were good reasons to do so at the time, but in the long run it was a mistake (chronicled here, if you want the gory details). So this time, I am determined to do everything in the most modern way possible, doing my best to ensure the longevity of this version. In the past couple of weeks, this has caused me to take a bit of a detour to modernize an important part of Solitaire Till Dawn.
I'll explain what this is, but you'll need to be patient while I give you the background info you'll need to follow along.
One issue that every programmer has to face is memory management. Programs have to store and manipulate data, which takes up space in your computer's memory. Chunks of space get used, and as the program continues to run, may outlive their usefulness. Now, think of what your office would look like if you never threw out any piece of paper, ever, not even your scratched notes: it would soon become cluttered to the point where there was no room for more paper, nor for any work to get done. It's the same way in a computer program: you have to "throw out" the chunks of memory that are no longer useful. In the computer, this is more like erasing the paper so that it can be re-used; but it's still basically the same job of cleaning out the old stuff to make room for the new.
There are a number of ways to go about this. The original way that Apple recommended for their Cocoa framework would semi-automatically clean up some of the disused memory chunks, but required the programmer to keep track of which chunks were still in use, and to explicitly clean up some of the disused ones. The programmer had to say "okay, I'm done with this" for every chunk (except for some very temporary scratch chunks), or else the chunk might be kept forever.
A few years ago, Apple introduced a mechanism called "garbage collection" in which the Cocoa framework tried to do all the work of keeping track of which chunks were still in use, and which could be thrown out. This is a great system for a programmer, because you don't have to keep track yourself. You don't have to mark each chunk as disposable when you're done with it; you just forget about it and it gets cleaned up automagically. It's what I was using for Solitaire Till Dawn up until a couple of weeks ago.
But recently, Apple deprecated garbage collection: this means that, although it still works, Apple is warning us that it will stop working in some not-too-distant future release of Xcode and Cocoa. Apple is abandoning garbage collection because it is slow. Instead, they have come up with yet another way to manage memory, a faster and more efficient way, and this new way is now the recommended method for memory management in Cocoa. They now want all developers to convert their programs to the new way.
The new way is called ARC (which stands for "automatic reference counting", although you don't need to know that). Switching from older methods to ARC is not entirely straightforward: we developers have to make changes to our code in order to use ARC successfully. Apple thoughtfully provided a tool to aid us in converting our code to ARC, and my hat's off to them: the tool was incredibly useful. Unfortunately, it couldn't fix everything for me; in a number of places, it could only flag problems, and leave them to me to work out the fix.
There's a piece of functionality in Solitaire Till Dawn that has, for most of its history, used what is normally considered to be a bad programming practice. By "bad" I mean that the developer (me, in this case) needs to really know what he's doing in order to avoid certain pitfalls; and also that the code written this way may not be portable to new operating systems or CPUs. Well, I will claim that I know what I'm doing, and that code has been working fine in Solitaire Till Dawn for 15 years and more; but the day has come when indeed, it cannot be ported to a new architecture. It is not compatible with ARC.
The piece of functionality in question is the PCode engine, a hidden portion of Solitaire Till Dawn that is used in many of the more complex solitaires. It gives Solitaire Till Dawn a great deal of flexibility and it's the reason that Solitaire Till Dawn can contain such wildly different games as Klondike, TriPeaks, Thirteens, and Grandma's Game. I had to rewrite a big chunk of the PCode engine to make it compatible with ARC, and then I had to debug it.
To ensure that I'd done the job right, I had to play at least a couple of games of each of Solitaire Till Dawn's 100 solitaires. Some of the ones that are difficult to win required playing many more than just a couple of games, to be sure that they were working. And of course, some of them weren't working, and then I had bugs to fix. It was A Big Job, and it has taken me two or three weeks to get through it.
The good news is that it's done, and successful: I now have a fully up-to-date, ARC-compliant Solitaire Till Dawn, and it has no new bugs that I could find in over a week of searching. Yay!
The bad news is that it does have bugs. They weren't introduced by the ARC conversion (I know, because I kept a pre-ARC version for comparison), but of course they still must be fixed. In the end, the ARC conversion didn't cost me as much time as it might seem, because I knew I would have to test all 100 games again anyway. So now I've done that, and I have a list of the bugs I've got to fix. That's a good thing.
A side note: unrelated to (and prior to) the ARC conversion, some bugs cropped up in the behavior of the drawer that displays lists of games and players. I think they appeared when I upgraded to Mac OS X 10.8. I had to rewrite all that code, and that took several days. But that's done too, and was very successful.
My last post was about writing the built-in Help pages. That's still in progress; I put it on hiatus when Xcode started complaining that I was using a deprecated form of memory management. I plan to try to fix some or all of the bugs I've found next, after which I'll return to the Help pages.
As I've said before, it's a big, long job. I am spending as many hours on it as I can, every day, weekends included. We'll get there!
I'll explain what this is, but you'll need to be patient while I give you the background info you'll need to follow along.
One issue that every programmer has to face is memory management. Programs have to store and manipulate data, which takes up space in your computer's memory. Chunks of space get used, and as the program continues to run, may outlive their usefulness. Now, think of what your office would look like if you never threw out any piece of paper, ever, not even your scratched notes: it would soon become cluttered to the point where there was no room for more paper, nor for any work to get done. It's the same way in a computer program: you have to "throw out" the chunks of memory that are no longer useful. In the computer, this is more like erasing the paper so that it can be re-used; but it's still basically the same job of cleaning out the old stuff to make room for the new.
There are a number of ways to go about this. The original way that Apple recommended for their Cocoa framework would semi-automatically clean up some of the disused memory chunks, but required the programmer to keep track of which chunks were still in use, and to explicitly clean up some of the disused ones. The programmer had to say "okay, I'm done with this" for every chunk (except for some very temporary scratch chunks), or else the chunk might be kept forever.
A few years ago, Apple introduced a mechanism called "garbage collection" in which the Cocoa framework tried to do all the work of keeping track of which chunks were still in use, and which could be thrown out. This is a great system for a programmer, because you don't have to keep track yourself. You don't have to mark each chunk as disposable when you're done with it; you just forget about it and it gets cleaned up automagically. It's what I was using for Solitaire Till Dawn up until a couple of weeks ago.
But recently, Apple deprecated garbage collection: this means that, although it still works, Apple is warning us that it will stop working in some not-too-distant future release of Xcode and Cocoa. Apple is abandoning garbage collection because it is slow. Instead, they have come up with yet another way to manage memory, a faster and more efficient way, and this new way is now the recommended method for memory management in Cocoa. They now want all developers to convert their programs to the new way.
The new way is called ARC (which stands for "automatic reference counting", although you don't need to know that). Switching from older methods to ARC is not entirely straightforward: we developers have to make changes to our code in order to use ARC successfully. Apple thoughtfully provided a tool to aid us in converting our code to ARC, and my hat's off to them: the tool was incredibly useful. Unfortunately, it couldn't fix everything for me; in a number of places, it could only flag problems, and leave them to me to work out the fix.
There's a piece of functionality in Solitaire Till Dawn that has, for most of its history, used what is normally considered to be a bad programming practice. By "bad" I mean that the developer (me, in this case) needs to really know what he's doing in order to avoid certain pitfalls; and also that the code written this way may not be portable to new operating systems or CPUs. Well, I will claim that I know what I'm doing, and that code has been working fine in Solitaire Till Dawn for 15 years and more; but the day has come when indeed, it cannot be ported to a new architecture. It is not compatible with ARC.
The piece of functionality in question is the PCode engine, a hidden portion of Solitaire Till Dawn that is used in many of the more complex solitaires. It gives Solitaire Till Dawn a great deal of flexibility and it's the reason that Solitaire Till Dawn can contain such wildly different games as Klondike, TriPeaks, Thirteens, and Grandma's Game. I had to rewrite a big chunk of the PCode engine to make it compatible with ARC, and then I had to debug it.
To ensure that I'd done the job right, I had to play at least a couple of games of each of Solitaire Till Dawn's 100 solitaires. Some of the ones that are difficult to win required playing many more than just a couple of games, to be sure that they were working. And of course, some of them weren't working, and then I had bugs to fix. It was A Big Job, and it has taken me two or three weeks to get through it.
The good news is that it's done, and successful: I now have a fully up-to-date, ARC-compliant Solitaire Till Dawn, and it has no new bugs that I could find in over a week of searching. Yay!
The bad news is that it does have bugs. They weren't introduced by the ARC conversion (I know, because I kept a pre-ARC version for comparison), but of course they still must be fixed. In the end, the ARC conversion didn't cost me as much time as it might seem, because I knew I would have to test all 100 games again anyway. So now I've done that, and I have a list of the bugs I've got to fix. That's a good thing.
A side note: unrelated to (and prior to) the ARC conversion, some bugs cropped up in the behavior of the drawer that displays lists of games and players. I think they appeared when I upgraded to Mac OS X 10.8. I had to rewrite all that code, and that took several days. But that's done too, and was very successful.
My last post was about writing the built-in Help pages. That's still in progress; I put it on hiatus when Xcode started complaining that I was using a deprecated form of memory management. I plan to try to fix some or all of the bugs I've found next, after which I'll return to the Help pages.
As I've said before, it's a big, long job. I am spending as many hours on it as I can, every day, weekends included. We'll get there!
Subscribe to:
Posts (Atom)