Category Archives: Toolbox

Old-style FONTs (and Harrier Strike Mission II)

Today we tried running Harrier Strike Mission II for the first time. The game appears stable, but runs way too fast, and the 3D drawing has some minor glitches causing some polygons to go to wrong place.

However, the most interesting part of this game was how it’s drawing its user interface. On the first run, this is the weirdness that we got:

Main menu, before old-style FONT support

In-game UI, before old-style FONT support

As you can see, there was a lot of text all over the place, as we didn’t have yet old-style FONT loading in place (up to this point only FOND & FONT/NFNT combination, which most of previously tested apps/games used). So, after implementing some “TODO” parts in our Font Manager implementation, we ended up with this:

Main menu after implementing old-style “FONT” loading support

In-game view after implementing old-style “FONT” loading support

It’s rather interesting to see fonts used in such way. As a nice bonus of this, we also got the tool palette icons to appear in MacPaint, which are also implemented as a custom old-style FONT:

The tool palette of MacPaint is now visible too!

Civilization – first run

Today we finally got for the first time Civilization to launch successfully. The major issues that were fixed were the preservation of unaffected 68k registers during native toolbox calls (especially D0 which memory manager uses for returning the result code), and fixing a invalid character in ADF filename.

There were some improvements (implementing some missing traps) and bug fixes to Dialog and Control managers needed to pass through the new game setup dialogs. Also, TextEdit is not yet completely implemented (and has some issues such as losing first character as seen in certain names in next screenshots), but works enough to allow passing through dialogs requiring text input.

The game appears to be playable and stable, although there’s some minor issues, such as main window appearing initially too large, status window missing, no scrollbars yet, and various other minor quirks.

Map view/movement, units, construction, technology and combat all seem to work ok. We were able to play this particular game all the way until first autosave, which would have required Standard File Package which we haven’t yet implemented.

Some progress on Test Drive II: The Duel

After some work on adding missing SANE (Pack4/Pack5) routines, loading of Test Drive II: The Duel is working. Also, there were some (due) improvements needed to OpenWD, which now handles also adding partial/full pathnames to the calls.

The intro and menus appear to work with music

Sadly, the in-game has still issues that may be CPU emulation-related. The in-car interiour and basic scenery is drawn ok, but the road is missing and all “3D” sprites are literally all over the place.

In-game screenshot with missing road and wacky sprites

Another weird-looking screenshot, just before crashing the game

Also after for driving some time, the game crashes – still some work to do here.

In the other news, various parts of toolbox and 68k emulation have been improved. Window highlighting bug was finally fixed, growing/zooming of windows works now (with the widgets on window title bars also visible), and literally half of Continuum’s graphics issues were fixed in 68k cpu emulation, so it’s also almost working now.

MacDraw & basic shapes

After some effort, we now have basic shape drawing working in MacDraw. One fun part of this was implementing FixDiv, which uses the binary long division algorithm like the original one on Mac. MacDraw uses this routine excessively to handle document grid sizing and coordination of all shapes drawn on the canvas.

“Hello” from the MACE team (with MacDraw’s custom MDEFs usable). No scrollbars visible yet though, have to get on finishing the CDEF 1 soon…

There was also a minor bug in MenuSelect causing zero item selections in MacDraw’s custom menus, but after a quick fix we can now also use them.

Contrary to many other applications, MacDraw uses a different approach to implementing custom menus – instead of providing a MDEF and assigning it to the menu using the menu definition proc ID in resource, it has its MDEF code as part of the program, and creates a fake handle which it assigns to the menu manually. Because of this, we had to tweak the memory manager handle operations to silently fail on such handles, and instead return the proper memAZErr (-113) in D0/MemErr.

Still no text drawing though, and there’s minor tweaking required for line drawing, but it’s looking promising at the moment.

MenuSelect

As a lot of the test games were already showing menu bars, we decided to finally implement the menu selection support at this point. In Toolbox, this is done by the “MenuSelect” call, which handles everything needed for selecting the menu item, including:

Using MBDF to save/restore menu background, highlighting titles, and drawing menu frame
Using MDEF to draw menu items and choose items
Returning the selected menu/item to calling application

After a some coding, we got this:

At this point, we have only the basic menu selection support (no support for hierarchical menus yet, scrolling long menus vertically, or popup menus), but it’s enough to handle most of the basic cases.

List Manager basics

With track and station building working, we could now also attempt adding trains to run on those tracks. Although we already had one List Manager dummy routine for the Train Roster window, the train creation screen needed a lot of more routines to make it work. This included implementing the following:

LAddRow (and LAddColumn for future use on the side)
LAddToCell
LCellSize
LClick
LDispose
LDoDraw
LDraw
LGetSelect
LNew
LRect
LScroll
LSetCell
LSetSelect
LUpdate

It took some time, but we were now able to successfully select and add cars from the car list to the train. Please mind the missing scrollbar, CDEF 1 is still unfinished 🙂

These List Manager routines will also be useful in the future, not only for the Train Roster window in Railroad Tycoon, but also for the Standard File Dialogs which will also make use of them in the file list.

Arcs and Masks

Time for some QuickDraw updates! Perhaps surprisingly, we already had at this point two cases which required Arc drawing: Dark Castle help screen (the “jump” arcs), and Railroad Tycoon signal circles. As the arc drawing is closely related to circle drawing, we had to just handle the arc begin/end angles and using them to control circle scanline rasterization, we had those cases working:

Another set of features in QuickDraw which we needed to implement at this point were the CalcMask and CopyMask routines. It appears that Glider 2 uses those to draw sprites:

The paper airplane in glider is now visible

…and Railroad Tycoon also uses those to calculate masks and draw everything dynamic on the map (tracks, stations, bridges, and lighthouses). A nice side feature of CalcMask is that it shares basic algorithm with SeedFill call, so with just adjusting a few values we could add support for that trap too. Hopefully we can soon run MacPaint or SuperPaint to test it…

Interestingly, the documentation on CopyMask has conflicting information between Inside Macintosh editions: The later books (IM: Imaging With QuickDraw) indicate that CopyMask scales image to destination rectangle, similar to CopyBits, but older IM:IV describes the correct “Classic” QuickDraw behaviour that it does *not* scale the image.

Tracks, stations, bridges and lighthouses are now visible on the map

SANE, and Railroad Tycoon map generation

After we got the Railroad Tycoon main menu to work, we were able to proceed all the way until map generation. This part of the code uses Pack4 (FP68K) dispatcher to run some certain floating-point operations, so we had to implement the following SANE operations:

FINTX
FMULS
FDIVS
FS2X
FX2S
FI2X
FX2I
FL2X

The tricky part was, that SANE operates on 80-bit extended floating-point numbers, but modern CPUs use only 32- and 64-bit floating point numbers. Following the conventions Apple used in the SANE implementation for PowerPC, we convert the 80-bit extended numbers into 64-bit “double” values for calculation, and convert them to required destination format (depending on operation, usually the 80-bit extended) again.

Map of europe in Railroad Tycoon, after passing through map generation

I’m however not sure if the 80-bit conversion is correctly implemented at the moment, but it seems to work for now, as after adding these couple operations, we immediately got the map generator to pass through successfully:

Railroad Tycoon runs now successfully through map generation, until crashing at unimplemented List Manager dispatcher

Dragging things around

As work on Window Manager was advancing quickly, and things are getting more and more complete for the phase 1, next up was one key feature: Dragging the windows. The Toolbox uses a generic “DragTheRgn” routine, which is shared by a few key parts:

Window dragging
Scroll bar thumb dragging
DragGrayRgn trap

So when we implemented this routine, we got got core support for all of them (except scroll bar thumb, as the scroll bar CDEF 1 was not yet implemented).

DragWindow works, in this case 3-D Maze main window

Thanks to DragGrayRgn, the “1000 Miles” game is now playable as it uses it to drag cards around the deck. It’s however still missing some secondary features: Menu selection, multi-line text drawing and Standard File Package are not yet implemented at this point.

The “1000 Miles” is now playable

PICT version 2 support (monochrome)

As we got Railroad Tycoon intro to load further, we encountered one PICT resource which was a bit different from the others: It was a version 2 picture, while all previous pictures in the same game were simple version 1 PICTs. It appears that when apple added support for the new version 2, they also added rudimentary system software patches to the old-style QuickDraw on “Classic” type macs to handle the new opcodes. Without support for these opcodes, the classic QD would just ignore picture data and display nothing.

The interesting part of these version 2 format patches is the fact, that it allows non-color QuickDraw to take PixMap data, and map it using a simple 50% threshold to either black or white in a regular monochrome bitmap. Also, any unsupported picture opcodes get ignored using the simple dummy StdOpcodeProc implementation for non-color QuickDraw. So, to make this type of pictures show, we had to implement all of this color mapping functionality, resulting in this:

Almost got it right on the first attempt…

Well, almost got it…just accidentally incremented a pointer twice during the color mapping loop. After quick fix, this is what we had:

M.A.C.E.

M*c Application Compatibility Environment