Question for you Mac C++ wizards



Welcome, Guest \| Home \| Search \| Login \| Register


Author	Question for you Mac C++ wizards (Read 48524 times)
ShinobiKenobi 256 MB Posts: 362 System 7 fan	on: March 28, 2024, 07:18 It's been over 20 years since I last messed with C++, and I want to get back into it, but at this point I remember next to nothing about it, so I'm pretty much a beginner again. I'm fluent in C, but I know that in C and from what I've seen on reviews of C++ books tonight, I've seen that the following is also true for C++: just because something is standard doesn't mean it should be used. For example, scanf() in C should not be used, and also gets(). For example, I downloaded a pdf of "C++ Programming with CodeWarrior" by Jan L. Harrington from 1995. Then I saw in a review by Richard John Botting that, not only does it teach unsafe C, but that it also teaches C++ the way it was in 1984. He also criticizes the author for only mentioning the "bubble sort", and no other sorts, quoting from the book, "a bubble sort is as efficient as just about any other sort method...", then he rebuts it, saying that because of books like this, he has seen his students using bubble sorting to sort hundreds of records on a disk, stating that it takes multiple passes to bubble the new element into place, and suggesting instead to use an insertion sort, stating that it only takes one pass. He also says that the author teaches programming practices that were over 10 years outdated at the time of publication. These are things that a student or reader would not know, and would learn bad C++ programming. These are the kinds of things I want to avoid, because I want to learn the most efficient and proper C++ practices possible in general, and specifically for System 7. Here is the review (modern browser needed). What books or resources would an expert old Mac C++ programmer recommend, so that I can learn the proper way? I would be very grateful for your recommendations.
Last Edit: March 28, 2024, 07:30 by ShinobiKenobi
Bolkonskij Administrator 1024 MB Posts: 2023	Reply #1 on: March 28, 2024, 08:40 I have no C++ experience. I think lauland has, he might be able to help you by answering your question. You may want to take a look at https://vintageapple.org/macprogramming/ (modern browser needed - sadly!) which is a huge PDF collection of Mac programming related books and pick one. If I were you, I'd first start learning the Mac Toolbox routines and what they do, as this gives you some idea on how things 'work' on a Mac. After that, you may still address the issues you mentioned.

ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #2 on: March 28, 2024, 10:11 That was actually where I downloaded it, number 14 Thanks, I'll research the Mac Toolbox.
Last Edit: March 28, 2024, 10:12 by ShinobiKenobi
ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #3 on: March 28, 2024, 22:42 Pardon my ignorance. I see Mastering The Macintosh Tool Box 1986.pdf, which is number 77 on the list. Should I look for a more recent book, or is the toolbox the same throughout classic Mac OS? Another dumb question, do I have to or should I use System 7 when developing for System 7, or is it OK to develop System 7 software on a newer Mac OS? The reason I ask is because working on my Quicksilver would obviously be faster, and I know that for example, CodeWarrior can make software for 68K Macs. Sorry for these noobish questions lol
Last Edit: March 28, 2024, 23:16 by ShinobiKenobi
Bolkonskij Administrator 1024 MB Posts: 2023	Reply #4 on: March 29, 2024, 06:41 These are no "noobish" questions. Don't worry, just fire your questions away. (actually that's the idea of a forum :-) ) The Macintosh Toolbox is actually the "built-in" routines in the Macintosh ROM that come with every Mac and that you, as a programmer, can access to draw windows, text and all other fancy stuff. Basically every programming book on the Macintosh will adress this topic, with more or less depth, so you don't need to pick a 1986 book for that. Naturally, Toolbox routines evolved over time though not as game breaking as one might think (software that stuck to it usually runs fine across nearly all versions of classic Mac OS). As for your question regarding the development environment - that has a bit of a religious touch. There's modern cross-compilers but I've heard mixed results. I think the name was Retro68, but somebody correct me please if i'm wrong. Others develop software within emulators on modern gear, but as @Nightingale will tell you from his recent Angry Robots experience, they tend to be not accurate. So you may end up writing something that runs fine in an emulator but not a real hardware. The speed is a plus though. Another option is to program on a machine like your Quicksilver in Mac OS 9 to use the faster hardware for better compile times. Definitely a possibility, just make sure that the CodeWarrior version supports your target (e.g. 68k). CodeWarrior versions are not neccessarily compatible with eachother, so if you're using 6 and suddenly decide you'd like to go back to 4, it'll definitely give you some errors to fix. Some also like to code on their G4 / G5 Macs but do so in classic mode on OSX because they state that a programming error that freezes your machine will only require a restart of classic mode but not the whole Mac. Programming directly on System 7 has its own merits - while arguably no memory protection is in place, you get to run your software directly on the machine you intend to target. Some people also like the way it requires you to focus on the one (programming) task at hand. Joshua Stein (aka jcs) programmes all his software (Wallops, Wikipedia Reader etc.) exclusively in Think C on a 9" screen Mac Plus. If you go to his website at jcs.org you can watch videos of him doing it, he has a great video series on that. (unfortunately it's all .mp4 and no Quicktime. I may have to write him and ask about bringing it onto Cornica). Speaking of it, there's also a video of him where he sets up a Mac OS boilerplate application (that is initializing the Toolbox, setting up a window, drawing something in it etc.). You may want to watch it to get an idea on how the Mac Toolbox works. Hope this helps you getting started with your project. Good luck!
Last Edit: March 30, 2024, 11:31 by Bolkonskij
ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #5 on: March 29, 2024, 07:13 Awesome, that's a lot of really helpful info. Thank you so much!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #6 on: April 08, 2024, 01:30 To re-iterate what Bolkonskij said, no such thing as a "noobish" question! The MacOS version supported by the software you write is entirely dependent on the compiler, so, if it runs on the host, you can build for older and newer...as long as you're careful not to call functions not supported at runtime. About a year ago, I took a challenge to port an open source game to support older black and white machines. I primarily used a G4 powerbook while working on it, but was targeting the Mac Classic II and SE/30. I wrote completely new graphics routines, first using just classic B&W quickdraw, but when it still wasn't fast enough, used direct screen buffer writes. You can follow my stumbling progress here: https://macintoshgarden.org/forum/calling-all-programmers-arashi-in-black-and-white Being very careful to only use older toolbox calls (Inside Mac vol 1), I was able to support System 6. I even got it to run on plain 68000, even though my target was '020 min, but it runs too slow. It'd need more work to be playable there. My Mac Classic II died just before completion, but I have an Amiga with AMax, and both '020 and '030 boards for it...so was able to test with both the accelerators and without (plain 68000). I used Think C 5.0 for older version but primarily used Symantec C++ 6, since it was newer and nicer when I could. I'm currently working on an m68k port of Goliath and JabberNaut: https://system7today.com/forums/index.php?topic=3532.30 I'm using CW6 since it was the last version of CodeWarrior that supported m68k targets (but not hosts!). One thing you may or may not be interested in, I started a port of the game "Attack of the PETSCii Robots" to Mac, eventually targeting plain 68000 macs like the MacPlus. I hoped to find others to join and to help teach them Classic Mac game programming using it, but didn't get any serious bites. I abandoned it because it wouldn't have been a real challenge for me alone (I've done game dev in the past) and didn't have any interest in finishing it solo. https://system7today.com/forums/index.php?topic=3254.0 https://tinkerdifferent.com/threads/interest-in-a-system-6-7-version-of-attack-of-the-petscii-robots.320/ The new mac code I wrote is all #ifdef'd _MAC https://github.com/laulandn/PETSCIIRobotsMac I used CW7 and XCode 2, but once I had it basically running, was planning on using Symantec C++ for older machines, although I ran into issues of language feature support. I used Color Quickdraw for the graphics, but would just use B&W calls...and possibly need to use framebuffer access once I got down to the MacPlus. Anyway, it may or may not be useful for you to look at the code...but it's a decent example of porting something with no Mac support. The skeleton of what is needed is easy to see. Moral of the story: You can absolutely mix and match your host and targets! And, if you're careful enough, you can support all the way from System 6 to Carbon with the same source. And I'd be happy to answer any specific questions, if my experience would help.
Last Edit: April 08, 2024, 01:56 by lauland
ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #7 on: April 08, 2024, 07:30 @lauland Thank you very much! When I get time I'll definitely study those.
Last Edit: April 08, 2024, 10:25 by ShinobiKenobi
Bolkonskij Administrator 1024 MB Posts: 2023	Reply #8 on: April 08, 2024, 09:07 Great post @lauland and thanks for sharing your insights / experience! ShinobiKenobi, really, feel free to post here. Others who are interested in programming might learn from it as well?

ShinobiKenobi 256 MB Posts: 362 System 7 fan	Reply #9 on: April 08, 2024, 10:25 Good point, Bolkonskij Thanks

Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #10 on: April 08, 2024, 10:45 @lauland Inspiring post! I have made plans to work on a Mac game of my own as soon as I'm done with another unrelated Mac project, and one question I seriously have is how I should handle graphics manipulation, in every aspect. You mentioned using the QuickDraw API, but also that you switched to "direct screen buffer writes". I would love to hear more about that, code examples would be most welcome. I plan to stick to pure ANSI C89, but C++ is also fine, or any other language really, even PPC/68k assembly if need be. I get that I need to decide on the resolution (i.e. 160 x 144 pixels), blank out that area, then start adding non-blank pixels wherever I want to "draw" on that "canvas". After I got my sprites, then the "logic" can be applied, and then concerns such as collision detection and whatnot apply. I assume I will have to divide my "sprites" into "bigger units of multiple pixels", like 4 x 4 pixels, perhaps I could add a sense of "realism" and less blockiness if the sprites can partially overlap, for example the collision could make sure that, for two 4x4 sprites, only the bottom 2x4 (last two "rows" of pixels) can't collide/overlap, but otherwise can "walk over each other". Does this all sound right? The question for me, then, in terms of C code (or any other language), becomes how to actually draw the pixels where I want to draw them in the canvas, as in, what QuickDraw calls I should be making or keeping in mind, as well as how I can bypass QuickDraw and just "rudely" draw in the pixels directly myself, perhaps even with sheer disregard for the OS, and "hacking it up", if I wanted to. Any insight, code or comments on that would be greatly appreciated, and be used as a reference. EDIT: Found a gold mine from you in the Garden! I'm not sure what to make out of QuickDrawGX and Game Sprockets. I think Diablo used the latter, incidentally? Then, there's also SDL to consider, on top of all the other options/APIs discussed there.
Last Edit: April 08, 2024, 12:13 by Jatoba
lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #11 on: April 08, 2024, 17:17 Regarding Arashi, the guy that posted the challenge (who also helped with ideas, etc) and I wrote up notes: https://macintoshgarden.org/sites/macintoshgarden.org/files/manuals/Arashi_in_Black_and_White_0.pdf What you'd be interested in: The original code manipulated the screen buffer and colormap in an extremely clever way (in assembly) to do double buffering...but the approach only worked for 8 bit screens. My first try was to #ifdef the original code and as I slowly painfully figured out what it was doing add Color QuickDraw equivalents (but only drawing black and white). This ran ok on '040's, but the challenge was for Classic2/SE30 where it was horrible. So I added new alternate code that writes to the frame buffer. I did 256 color (because 8 bit pixels are EASY) and 1 bit (trickier, ironically!). So it ended up with multiple options at compile time...the original engine, QuickDraw, or the new drawing routines with 1 bit or 8 bit. Parts of the original double buffer code is still there, so doesn't erase between even and odd frames, but is fast enough you rarely notice. (Almost all) the actual drawing takes place in the nick*.h files here: https://github.com/laulandn/Arashi/tree/master/Arashi/For%20your%20think%20c%20folder/VA%20Kit%20%C6%92 I found the hack of using include files sped things up a LOT by having all the drawing inline (no function call overhead). The C is about as fast as it can get, probably not worth writing new assembly. NOTE: Classic in MacOS 10.4 and higher buffer the windows, and only update them when GetNextEvent (and friends) is called. This means no display when running the non-QuickDraw versions...so keeping QuickDraw as an option allowed me to debug on G4 class machines. ---- What I did for PetSCII Robots was take the SDL source version, since I know SDL and could tell what it was doing, and added new #ifdef _MAC, strictly using the toolbox, mostly to a single file. It has all the basic drawing and event handling a game needs (other than sound): https://github.com/laulandn/PETSCIIRobotsMac/blob/main/PlatformSDL.cpp I didn't rename the functions, so they still have "SDL" in the names, a little confusingly, but that also shows the Mac classic toolbox (and Carbon) equivalents of the SDL calls right next to them, as examples. (It'll still build the original SDL version if you DON'T define _MAC) It's nowhere near done, I wanted to get it just to the point where the game starts, but leave the rest to other people to figure out as they learned. There's lots of error checking and debug statements, which you wouldn't normally have in a game. ---- Arashi is all vectors, so there's no bitmaps at all, but PetSCII is just bitmaps. I created raw 256 color dumps of the art assets and load those into offscreen GWorlds (See IMG_Load()) and just do CopyBits between them (See SDL_BlitSurface()). This should be fine for faster machines, and might even be ok on really slow ones, since the game itself is more turn based than "arcade" like Arashi. (Although note that REALLY old machines don't have GWorlds, so they'd just be BitMaps). Here's one of the tilesets (original): https://github.com/laulandn/PETSCIIRobotsMac/blob/main/petsciixcode2/build/sprites.png I'd highly suggest using QuickDraw first, just to get your feet wet, and only learn raw pixel manipulation if it ends up too slow for your game. There's lots of books you can use to learn the toolbox and CopyBits does a LOT for you. You should ignore DrawSprocket, it doesn't get you much, and is PPC only (as far as I remember). SDL runs on ANYTHING, so is very good to learn, but only version 1 was ever ported to the PPC. Countless commercial games use it on every platform. I started writing an "SDL-shim" that implements just barely enough of SDL2, but that is a whole other kettle of fish...and since I wanted PetSCII to be an example for people to learn on, made it way too complicated, so just used the toolbox. I also didn't use anything like SpriteWorld or the other various toolkits...because I'd have to learn them (in 2024!), and be tied to whatever System version they supported. ---- If you're just reading to learn, don't look too closely at Arashi, it is a bit of a mess, spread out over many many files, and (relatively) heavily optimized. The PlatformSDL.cpp file from PetSCII I mentioned above is a one stop shop for basic toolbox use. Just look for the #ifdef _MAC's!
Last Edit: April 08, 2024, 17:55 by lauland
Jatoba 256 MB Posts: 270 System 9 Newcomer!	Reply #12 on: April 10, 2024, 09:53 @lauland Thank you for the directions!

lauland 512 MB Posts: 674 Symtes 7 Mewconer!	Reply #13 on: April 11, 2024, 02:33 A little more you might find interesting about Arashi: The source was avail for 1.1.0, and the final 1.1.1...they had different difficulty and levels...and of course bug fixes...but 1.1.0 ran fine. The source for 1.1.0 was for Think C 5, and 1.1.1 used Symantec C++ 6, but most of my coding was done in the vector graphics library, which actually had no changes between the versions. Think C 5 doesn't work in OS 9, so when I used my G4 (as much as I could), it was with 1.1.1 and Symantec C++ 6. I kept the 1.1.0 version in sync because Think C 5 was small enough to actually run on the Classic II and my Amiga (erstwhile MacPlus). To do this I used BBEdit's "Find differences" on the two source folders and could copy the relevant changes between them. My Amiga's faster accelerator was only a 25mhz '030, and it uses MacPlus roms, so no Color QuickDraw. When my Classic II gave up the ghost (probably powersupply, it'd already been recapped) I used a powerbook 170, since it was strictly B&W (tho Color QuickDraw in rom), although probably not MUCH faster than the Amiga, it had more ram, and it's motherboard is fully 32 bit (The Amiga 2000 is still mostly 16 bit). But the Amiga was useful in that I could test it with an '020 board I also have, and without an accelerator at all for plain old 68000...and it easily runs System 6. ---- I shuttled the source and test binaries between the various machines on floppy (usb drive for the G4)...but had to use this on the Amiga since I didn't have a working external Mac drive (and the Amiga's drive can't read 800k or 1.4m disks): https://www.bigmessowires.com/floppy-emu/ Because my G4 ran 10.4, whose Classic buffers the windows, it shows a blank display for the original graphics code, and the new B&W code I wrote, both of which hit the frame buffer directly. Thus even though the graphics code I had written using QuickDraw was too slow on '030's, it came in very useful on the G4. (In hindsight, trying downgrading to 10.2 or 10.3 probably would've been a good idea, I believe their version of Classic WOULD display) ---- Since I had the code down to a science, I tried CodeWarrior and XCode (Carbon) ports, but never finished them...although it was very useful just trying to build on them as their compilers gave different warnings and I found a decent amount of bugs that way.
Last Edit: April 11, 2024, 02:42 by lauland
ClassicHasClass 32 MB Posts: 39	Reply #14 on: April 11, 2024, 04:01 10.3 introduced double-buffered windows in Classic. 10.2 is probably the most compatible implementation of Classic and 10.2 also still supports classic EtherTalk Phase 2. IMHO it's the best version of OS X if you're primarily running non-Carbon apps. Myself I use CW7.1 Pro on my MDD G4 and CW Pro 2 on my Q800, which are my main PPC and 68K development machines.

	Pages: [1] 2

© 2021 System7Today.com.
The Apple Logo, Macintosh™, Mac OS™, and others property of Apple Computer, Inc.
This site is in no way affiliated with Apple Computer, Inc.