To answer some questions, I’ve gotten, and to note that I am deviating slightly from my mentor’s suggestion while he is on vacation, I am making this post about my current and future plans.
Before I start, though, I should mention that, for the duration of Summer of Code, it has been required of me that all the 16-bit code be compile-time optional, and impact 8-bit performance minimally if at all.
Now, the steps I see before me (in broad strokes):
- Modify the Scumm HE engine to display a 16-bit background resource when the freddicove demo is loaded (to test my understanding of the resource format and standard rendering process).
- Integrate this functionality into the standard running of the Scumm HE engines.
- Add 16-bit support in place for other resource types.
- Modify rendering, for 16-bit HE games, such that the 8-bit resources are rendered using the palette->rgb mapping system that the game engine provides. (possibly involves implementing this functionality)
- Perform unit tests to ensure that all 16-bit Scumm HE games are rendering properly
- Discuss with mentor at length to determine ideal API behavior for bit-depth/pixel format negotiation between game engines and backends.
- Add this API for game engines to negotiate bit-depth/pixel format with backend, with a default assumption of paletted 8-bit.
- Implement support for this API in SDL backend and Scumm HE engine. (This is the point at which the mouse cursor will be upgraded, because between the in-game mouse cursor and the in-game menu, at least one must be assured to display properly if any meaningful testing is to be done.)
- Document this API exhaustively.
- See what can be done about engines other than Scumm.
That’s all for now, but I’m sure there are several more points that will make themselves aware to me before my time is
done.