MGTK video drivers

[eric-ja]

Isolate/abstract the parts of MGTK that deal directly with video hardware, in order to provide support for other modes/platforms.

Possible targets:

• Apple II 560x192 B&W DHGR (original MGTK code)
• Apple II 280x192 HGR (the code for this is present in MousePaint and could be ported over)
• Apple /// 560x192 B&W SHGR (Madeleine)
• Apple IIgs/VOC SHR (?)
• Others ?

[eric-ja]

There are 4 main code areas that deal directly with screen memory:

1. Pattern fill/blitting

• Blitting from screen (dhgr_get_srcbits)
• Fill/blit to screen (dhgr_shift_line, dhgr_fill_line, SetPattern)

2. Text drawing

• (DrawText)

3. Cursor drawing and animation

• Drawing (draw_cursor)
• Erasing to saved pixels (restore_cursor_background)

4. Pull-down menu save-behind buffer

• Saving pixels to buffer (draw_menu)
• Restoring pixels from buffer (restore_menu_savebehind)

[JohnMBrooks]

Another good option is to make a smaller/faster 80-column mousetext-based lib, like Apple's original MTx lib for Apple Pascal, or as used in the text-based Finder util MouseFiler.

Mousetext UI would load faster and be more snappy than DHR.

[eschaton]

Just as Apple shipped (and documented!) the MouseGraphics ToolKit, they also shipped the MouseText ToolKit, with many of the same APIs so it was straightforward to port from MouseText to MouseGraphics.

(I’ve actually been puzzled by the amount of work being put into reversing MGTK when the information is available…)

[eric-ja]

@eschaton The goal is not just the API but a complete understanding of the code and a basis for further dev work.

We do have some official docs and headers for MGTK (they are not 100% accurate.)

[inexorabletash]

Heh, I stopped most of my work on MGTK when I began to suspect it was a separate library. Then some other pesky contributors started with the awesome PRs... :)