ScummVM RGB color progress blog

June 5, 2009

Good news, everyone.

Filed under: Planning,Progress — Upthorn @ 11:02 am

My success in getting the initial 16-bit support into the backend, and getting it to work with resources from freddicove, triggered Kirben into a frenzy of updates to the Scumm engine code. 16-bit HE games seem to be working almost perfectly, now.

During this period, I have been doing some bug hunting in regard to this.

For example, when Kirben first mentioned strange graphical glitchesCoveIntroBroken

occuring in the intro to freddicove, I started msvc debugger and traced the issue to an error in the SDL copyRectToScreen method, that I had failed to correct when changing to 16-bit — when testing for the special case of a rectangle being the full width of the screen, it checked the rectangle’s pitch (or number of bytes from the start of one line to the start of the next), instead of width (or number of pixels from the start of one line to the start of the next) for equality with the screen width, resulting in the case being used when the rectangle being copied was half the screen width, but not when it was full.


I then corrected this error, and began looking at similar glitches that had been reported in baseball2001, and spyfox3.

During this time, the full versions of Spy Fox 3, Backyard Soccer MLS, Freddi Fish 5: The Case of Coral Cove, and Moonbase Commander arrived from ebay, and I began using those for testing. So far, I have concentrated primarily on Spy Fox 3, as it seemed to have the highest instance of graphical errors.

Long story short: Kirben seems to have fixed all of the known display errors that were internal to the Scumm engine, and I now have cursors displaying in 16-bit, because the work he did fixing hePalettes to work properly in 16-bit was incompatible with the cursors rendering properly in 8-bit mode. (I have screenshots of this, but this post is cluttered as it is, and little, if any, difference is visible from those cursors rendering properly in 8-bit.)

Additionally because of all these rapid developments on the scumm engine, I will begin discussion and work on the API as soon as Sev gets back from his vacation.


May 29, 2009

Minor progress update.

Filed under: Progress — Upthorn @ 7:54 am

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.

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

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

May 28, 2009

Road map

Filed under: Planning — Upthorn @ 12:06 am

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

May 24, 2009

Initial progress

Filed under: Progress — Upthorn @ 2:18 am

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

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

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.

April 30, 2009


Filed under: Uncategorized — Upthorn @ 2:46 am

At the request of the fine folks on the ScummVM team, I have created a blog to post progress updates on my Summer of Code 2009 task.

I probably will not begin regular updates until the coding period proper begins on May 23rd.

« Previous Page

Blog at