• Hello, Guest! Welcome back, and be sure to check out this post for more info about the recent service interruption and migration.

Help getting started with retro software development

Mu0n

Well-known member
I suggest just going with Symantec THINK C 6 (or even THINK C 5). Just use 'Mac Traps' and your app will run very well on a Plus, I do it all the time and if you hit a snag, I can help you.
 

Crutch

Well-known member
I think he’s looking for a class library recommendation though. Here are some options:
  1. MacApp - runs pre-system 6 for sure if you get an earlier version, but requires (I think) MPW
  2. Think Class Library (TCL), definitely supported in THINK C++ 7 and THINK C 6 and probably 5, any of which will compile code that runs under System 6 just fine.
  3. Use a UI toolkit like Prototyper, which I have not personally used but is intended to support all the common UI bits of a Mac application and dates back to 1986-ish so will definitely run under older system software.
  4. Bite the bullet and learn the Toolbox … liberally stealing code from a classic source code demo for a Mac application like MiniWriter.
I would go with option 2 or perhaps 4 personally, since I find learning a class library like TCL is itself a bit of work.

Good luck!
 

BacioiuC

Well-known member
Code Warrior 4 builds and runs apps on System 6. As far as the toolbox, you technically need to setup a wrapper for it once for a few things. In my own game I only touched the toolbox once in the beginning and did the following:
  • An init class that initialises everything I need.
  • A gui library that handles three thing:
    • Creating a window
    • Creating a button
    • Displaying a pict from the res file
  • The update function. It's basically a big case switch statement that handles on mouse down, updateEvt, activateEvt. inThumbPressed (for scroll bars) and controlPressed. That's all.
I straight up, without any remorse, copied the start template from Macintosh C Primer book from 1989 (I think) and then just wrapped the things in my own functions, allowing me to make a button like: CreateButton(x,y, width, height, label) and CreateImage(pictID, x, y, width, height) and UpdateImage(imageID, pictID) to allow me to do quick animation for standard picts.

Now, I saw your gifs and they look lovely. However, I have a feeling the gifs have been recorded from an emulator and the speed of drawing the picts you have there will be really slow on actual hardware. I'm saying this because drawing 20 picts directly using standard toolbox calls is pretty slow. Your next step is to learn about GrafPtr and offscreen rendering and probably the most useful routine for making games - CopyBits. I might be mistaken and you are already doing that but it was worth mentioning. You have no idea how surprised I was testing my first level editor on actual hardware and crying at my scroll routine.

In the end, even if you go for a class library for handling the toolbox, you will need to dive deep into how to use offscreen worlds and copybits if you want any chance to get the game to run okay on a plus.

If I had the time to start all over again, I would honestly just drop support for the toolbox outside of Initialising a window and handling the finder menus and just do my own gui controls.
 

nightingale

Well-known member
Thanks for the tips everyone! @Crutch and @Mu0n, I will definitely look into the tools you suggested tonight.


Now, I saw your gifs and they look lovely. However, I have a feeling the gifs have been recorded from an emulator and the speed of drawing the picts you have there will be really slow on actual hardware. I'm saying this because drawing 20 picts directly using standard toolbox calls is pretty slow. Your next step is to learn about GrafPtr and offscreen rendering and probably the most useful routine for making games - CopyBits. I might be mistaken and you are already doing that but it was worth mentioning. You have no idea how surprised I was testing my first level editor on actual hardware and crying at my scroll routine.

Don’t worry, I already had my crying moment the first time I ran it on actual hardware, then I learned how to draw to an offscreen buffer first and performance is quite good on my SE/30 right now. I draw all of my tiles to the buffer when the level loads then copy it to the visible window and scroll it. It takes a few seconds to load the level, but then it scrolls very smoothly. Right now for my bad guys, I am redrawing them in their new location and drawing a blank tile over their old location, so it’s quite slow with more than just a few bad guys on the map, so my next big task will be figuring out how to use sprites to relocate them instead of redrawing them every 200ms.
 

bdurbrow

Well-known member
If you mean sprites in the sense that Amigas have them... there's no hardware for that on the Mac Plus. The best you can do is CopyBits; or if you know that the pixels always align on byte boundaries, an assembler fragment that copies them as whole bytes as fast as possible.
 

Mu0n

Well-known member
iirc, copybits is fastest if you use a width that's an integer multiple of 32 bits (4 bytes) in srcCopy mode to prevent it from doing any per pixel checkup.

check out an earlier relevant discussion on the topic:
 
Top