So, I have a few old C programs I wrote for MS-DOS. The problem is that both of my current computers are Macs, so I’d like to translate them over. For the most part, this is not a problem, since I mostly stuck to ANSI-standard C. The graphics, however, present a difficulty, since graphics will necessarily be different on all platforms. These being old DOS programs, the graphics consist mostly of things like “set the color of the pixel at these screen coordinates”, and “draw a line from this set of screen coordinates to this other set”, and “fill in the bounded region containing this point with this color”. In fact, that’s about all the graphics consist of. But I’m having a hard time finding any graphics package for OSX which can do these things. All of the graphics libraries I can dig up seem to assume that you already have image files, which I do not.
Since these are all just recreational programs, I’m not eager to spend a lot of money on such a package. Cheap would be good, and free would be better. And the package should be compatible with gcc, Project Builder, or some other cheap or free compiler. Can anyone point me in the right direction?
The current version of Qt/Mac Open Source Edition is 4.0.1. I believe I have OS X 10.4.2 on one of my systems with Qt 3.4.5 installed. If you have problems building the latest Qt system, you can download older versions of Qt and try them.
The download comes complete with examples documentation. You will need to convert your C code to C++, but that should be relatively easy if you follow the examples. Qt may be overkill for what you need, but it’s free and works rather well once you get it built and link to it.
It isn’t interactive, but the GD library will let you send drawing commands to an in-memory image, then save that to a file. GD is installable via either Fink or DarwinPorts.
Dominic mentions OpenGL, which also might do what you want. OpenGL isn’t as geared to 2D drawing as it is to rendering polygons in 3D space — but it can do some 2D, and it sounds like the features you need are pretty basic.
Another possibility is to render your output as PostScript code, which should also be straightforward in your case. You can then use Ghostscript (available, again, from Fink or DarwinPorts) to convert that to a raster image format, if desired.
The “fill the bounded region containing this point” will be the hard one to find. It’s called “Flood Fill,” and it’s nontrivial to write efficiently. (The first few algorithms you think of are likely to be prohibitively computationally expensive unless you look it up.)
The Classic Macintosh graphics library, “QuickDraw” has all these functions, in the form of “MoveTo(x,y)” “LineTo(x,y)” and the combination of “SeedCFill()” and “CopyBits().”
QuickDraw is deprecated in favor of Quartz (the newer graphics library with OS X), but it will still work for at least several years. Quartz has a much less pixel-oriented bent, and no equivilent to SeedCFill, so you probably don’t want to go that way.
SeedCFill() and CopyBits() can be a bit challenging to get right the first time, so if you need me to generate a little sample code, contact me offline.
OK, it looks like Qt will do what I need. It seems to assume familiarity with object-oriented programming, which is a bit intimidating to me (OOP = New trick. Me = old dog), but from what I understand of C++, I should be able to use all of the non-graphical parts of my code as-is. Fortuneately, the graphics in my programs are pretty well compartmentalized into a single “display” function which would need to be re-written.
TimeWinder, I’m aware of the subtleties of floodfilling, having actually asked about it once before here (in connection with a completely different programming project, that one actually being for work). If need be, I suppose I could probably cobble one together, but it looks like Qt probably includes it already pre-made (or other features which I could use instead). It’s like the old saying: Good programmers write good code. Great programmers steal good code.
But before I commit to Qt, what do you mean by QuickDraw being “Classic”, and that it’ll work for “at least several years”? If that means that applications compiled using QuickDraw would only work under the Classic environment, then I’d rather not go that route. My newer computer doesn’t even have Classic installed, and even on the older one that does, it’s a bit of a hassle to wait for it to start up.
Allegro is a free C/C++ cross-platform game programming library that is very simple to use, and provides all the graphics primitives that you’ll need, plus a lot more.
What he means (if I may speak for TimeWinder, for a moment) is that QuickDraw is deprecated, and at some point will likely vanish. It is however still supported in all versions of MacOS X up to the present one (10.4).
Nearly all QuickDraw functions — particularly the ones that, you know, draw things and all — are in Carbon, the bridge API between MacOS X and pre-X. Therefore, you can avoid the Classic environment entirely as you wish, and indeed probably should.
Oh, my, that does look easier to implement. It looks like I might not need to do anything more than re-name a few functions. I hadn’t really expected that there would be something available for vanilla C, on a system as new (relatively) as OSX. Thank you!
Bytegeist is correct. Yes, I meant “classic” in the sense of “old,” not the specific Macintosh run-time environment of that name.
I’m not sure how much to read into the deprecation of QuickDraw – it’s making for a lot of warnings in my curent projects as I switch to Quartz, but there are necessary functions in QuickDraw (such as anything to do with cursors) that simply don’t have replacements yet – so I don’t think that QuickDraw is on it’s last legs quite yet.
Unless you got really unlucky in your variable names, C++ should compile C just fine. Even if you did get unlucky, it will be a matter of a few minutes to fix it.
“class” is actually pretty common as a variable name for educational software or as a generic word for “kind.” “bool” might not be all that unusual as a typedef, either. You really want to get obscure? I’m guessing that not too many people have variables named mutable or typename.
And yes, I meant cursors from Carbon. I write a cross-platform Mac/Windows C++ library: the Mac part is Carbon since it’s closer to the Win32 model (and doesn’t require Objective C, which effectively doesn’t exist in the Windows world).