Month: May 2009

Minor progress update.

If the prior post is to be taken as a checklist, the first item can now be crossed off.

ScummVM displaying a background from freddicove in glorious 16-bit color.

Many thanks to Kirben for the help he provided in locating this resource.

Road map

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):

  1. 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).
  2. Integrate this functionality into the standard running of the Scumm HE engines.
  3. Add 16-bit support in place for other resource types.
  4. 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)
  5. Perform unit tests to ensure that all 16-bit Scumm HE games are rendering properly
  6. Discuss with mentor at length to determine ideal API behavior for bit-depth/pixel format negotiation between game engines and backends.
  7. Add this API for game engines to negotiate bit-depth/pixel format with backend, with a default assumption of paletted 8-bit.
  8. 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.)
  9. Document this API exhaustively.
  10. 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.

Initial progress

So, I’ve got the SDL backend set up with a 16 bit game screen, and copyRectToScreen set up to use it instead of the 8bpp one. Currently, for testing purposes, it just assumes that all pixel data passed from the game is 16bit RGB.

So games aren’t exactly playable with this compiled in, at the moment, as I haven’t yet begun modification of the core engine to display in 16bpp, as you can see in this screenshot of the freddicove demo

Freddicove in 16bpp

As you might see there, I still have it rendering the mouse pointer as 8bpp. This is so that I can still have a reasonable idea of what it’s pointing at and use it to find the exit button.

At _sev’s suggestion, I have changed the vCUPhe subengine to display a 16bpp gradient instead of playing humongous entertainment preview movies, in order to test the backend.

Well, it turns out the backend portion is working, fine, as you can see in this

full color 16-bit gradient

So, this is the current state of things. I’ll be making another post a little later on with my current roadmap for the rest of the project.