I’ve just been informed by LordHoto that the 1900UTC August 17th line is not, in fact, a deadline for students, but the end of their obligation to perform, and I can continue up until the 24th, to submit code which may be evaluated.
So, I’ll be continuing to work on the API in the hopes of doing just that.
As I am writing this, the GSoC Coding period ends in just under 19 hours. Shortly after my last blog post, I began to make some headway on the task, and I’ve kept up a reasonable pace since then, and I’ve now got modifiers working in a way that I’m satisfied with, so I’m finally starting on the real meat of the task — the engine<->keymapper interface. Unfortunately, I haven’t managed to take a whole lot of time yet to sit and think about the details of how this is going to work, so I’m going to be flying by the seat of my pants a bit.
I hope to have a more fully-fleshed proposal for an API, and some work on an initial implementation done, before the 19:00 UTC deadline.
Wish me good luck, I will need it.
EDIT:
With 6 and a half hours remaining in the GSoC coding period, and badly in need of sleep, it looks like I won’t be able to get the API proposal finished before the pencils down deadline.
In fact, what I’ve managed to get done towards it is embarassingly small, but I will post it here for posterity, anyway:
How this is going to work:
As anyone who’s been following the commit logs can tell, I’m having a lot of difficulty keeping up a good pace of work on the keymapper. The reason for this is that, unlike with my prior project, nearly all the progress I make on this task comes at the expense of code that someone else wrote before, and because I did not get a lot of time to look over it before I started working (which is mostly my own fault), I don’t really understand how it all works together well enough to be certain that the code I’m replacing it with will be better.
As a result, I’m being very hesitant about any changes I make because I always want to be certain I understand what the existing code is doing (and how) before I destroy it to make room for my own.
However, I am still working on the keymapper improvements, and I have no intent of giving up before I’ve finished them, no matter how long I have to keep working on this past the end of this year’s GSoC.
Note: I’m staying up late to get this proposal written before the deadline my mentor has given, so my words in this post might not make a lot of sense.
It seems to me that the problem with the currently implemented approach is that the Action structure is too complicated to require engine authors to create and initialize a full structure for every single action that they wish to be mapped to a key. Additionally, it requires engine authors to give each individual action a universally unique 4 character ID, so that actions and their keymappings can be saved to the config without any other game that ScummVM can run ever overwriting it with a different key. However, some of the more complicated features of the Action structure may be necessary for some games to fully function in a reduced-key environment.
Because of these factors, it seems to me that there are two steps which should be taken to make the keymapper work better for engine authors:
I fear that this API proposal is grossly insufficient, because the task of properly implementing modifiers in the keymapper has been much more interesting and less straightforward than I expected, and has left me with very little time before to properly examine the other aspects of the keymapper component before now.
After a long break from coding (longer than what I’d wanted by half), I’ve started working on properly implementing modifiers for the keymapper, instead of feeding every key in an additional time for each possible combination of modifiers that exists.
I’ve got it halfway working in a temporary way — it only feeds the keys in once, but the remap dialog can recognize modified keys and tell that they are different from unmodified keys (and that ctrl-a is different from shift-a), but events mapped to modified keys aren’t triggering at all for some reason.
The more important thing, though, is that I’m back in the swing of coding and getting work done again. Hopefully I should be back up to full speed in another day or two.
Alright, I’m finally back from vacation, and well rested, and shaking off my cold, so it’s time to get back to work on this.
From this point, I’m actually going to be working on the keymapper, so I’m making this blog post to organize my thoughts into a plan of action.
This is only the most general of outlines at the moment, I expect to add subtasks, and rearrange the task list as I become more familiar with the keymapper as it currently exists.
Note: I wrote this post on July 30, but somehow wordpress never published it, thankfully it was saved to drafts, at least.
I’m still alive. Also still on vacation. I haven’t yet had an opportunity to discuss keymappers with Sev, but have not forgotten about my obligations. However, my schedule of having fun with people I haven’t seen in years is very demanding, and takes priority because of the limited window of opportunity. I hope to be back to working full swing on the project next Wednesday.
Ahead of even my wildest dreams, I have already completed the initial project goal of a color format API. (see prior blog entry for more information).
I must thank Eugene (sev), Max (fingolfin), Johannes (LordHoto), and Travis (Kirben), for the great amount of support and help they have provided me on this. I would also like to thank Sven (DrMcCoy), Willem (wjp), and Jordi (jvprat) for the interest they have shown and the insight they have provided.
Just in timed for the vacation I have already scheduled, which begins in the morning after I post this, and continues for two weeks. I will still be somewhat active on the next project goal, when I can get a moment away from having fun times with friends, but I do not expect to make regular SVN commits during this time, and it may be slightly longer than one week before my next blog update gets posted.
When I return, I expect to be tackling the issue of keymappers with full force.
Note: the following is copied from the source of the wiki reference article I just wrote for it.
This page is meant as a reference for developers implementing the Truecolor API in their engine and backend modules. This page will provide a complete spec of API requirements and suggestions, as well as a protocol for engines and backends to follow during setup.
NOTE: This API was designed with backwards-compatibility for 8-bit Graphics only engines in mind. If your engine only uses 256 color graphics, you should not have to change anything, so long as the engine’s ENABLE_RGB_COLOR setting matches the backend’s during compilation, so that functions link properly.
NOTE: This API was designed with backwards-compatibility for 8-bit Graphics only engines in mind. If your engine does not make use of per-pixel RGB color graphics, you should not have to change anything, so long as ENABLE_RGB_COLOR is set in configuration during compilation, so that functions link properly.
Here is an example of a simple engine that uses the best color depth available to display and color-cycle this gradient:
Common::Error QuuxEngine::run() {
Graphics::PixelFormat ourFormat;
// Request the backend to initialize a 640 x 480 surface with the best available format.
initGraphics(640, 480, true, NULL);
// If our engine could only handle one format, we would specify it here instead of asking the backend:
// // RGB555
// ourFormat(2, 3, 3, 3, 8, 10, 5, 0, 0);
// initGraphics(640, 480, true, &ourFormat);
// If our engine could handle only a few formats, this would look quite different:
// Common::List ourFormatList;
//
// // RGB555
// ourFormat(2, 3, 3, 3, 8, 10, 5, 0, 0);
// ourFormatList.push_back(ourFormat);
//
// // XRGB1555
// ourFormat(2, 3, 3, 3, 7, 10, 5, 0, 15);
// ourFormatList.push_back(ourFormat);
//
// // Use the best format which is compatible between our engine and the backend
// initGraphics(640, 480, true, ourFormatList);
// Get the format the system was able to provide
// in case it cannot support that format at our requested resolution
ourFormat = _system->getScreenFormat();
byte *offscreenBuffer = (byte *)malloc(640 * 480 * ourFormat.bytesPerPixel);
if (ourFormat.bytesPerPixel == 1) {
// Initialize palette to simulate RGB332
// If our engine had no 256 color mode support, we would error out here:
// return Common::kUnsupportedColorMode;
byte palette[1024];
memset(&palette,0,1024);
byte *dst = palette;
for (byte r = 0; r < 8; r++) {
for (byte g = 0; g < 8; g++) {
for (byte b = 0; b < 4; b++) {
dst[0] = r << 5;
dst[1] = g << 5;
dst[2] = b << 6; dst[3] = 0; dst += 4; } } } _system->setPalette(palette,0,256);
}
uint32 t = 0;
// Create a mask to limit the color from exceeding the bitdepth
// The result is equivalent to:
// uint32 mask = 0;
// for (int i = ourFormat.bytesPerPixel; i > 0; i--) {
// mask <<= 8;
// mask |= 0xFF;
// }
uint32 mask = (1 << (ourFormat.bytesPerPixel << 3)) - 1;
// Repeat this until the event manager tells us to stop
while (!shouldQuit()) {
// Keep t from exceeding the number of bits in each pixel.
// I think this is faster than "t %= (ourFormat.bytesPerPixel * 8);" would be.
t &= (ourFormat.bytesPerPixel << 3) - 1;
// Draw the actual gradient
for (int16 y = 0; y < 480; y++) {
uint8 *dst = offscreenBuffer + (y * 640 * ourFormat.bytesPerPixel);
for (int16 x = 0; x < 640; x++) {
uint32 color = (x * y) & mask;
color = (color << t) | (color >> ((ourFormat.bytesPerPixel << 3) - t));
// Currently we have to jump through hoops to write variable-length data in an endian-safe manner.
// In a real-life implementation, it would probably be better to have an if/else-if tree or
// a switch to determine the correct WRITE_UINT* function to use in the current bitdepth.
// Though, something like this might end up being necessary for 24-bit pixels, anyway.
#ifdef SCUMM_BIG_ENDIAN
for (int i = 0; i < ourFormat.bytesPerPixel; i++) { dst[ourFormat.bytesPerPixel - i] = color & 0xFF; color >>= 8;
}
dst += ourFormat.bytesPerPixel;
#else
for (int i = ourFormat.bytesPerPixel; i > 0; i--) {
*dst++ = color & 0xFF;
color >>= 8;
}
#endif
}
}
// Copy our gradient to the screen. The pitch of our image is the width * the number of bytes per pixel.
_system->copyRectToScreen(offscreenBuffer, 640 * ourFormat.bytesPerPixel, 0, 0, 640, 480);
// Tell the system to update the screen.
_system->updateScreen();
// Get new events from the event manager so the window doesn't appear non-responsive.
parseEvents();
// Wait a semi-arbitrary length in order to animate fluidly, but not insanely fast
_system->delayMillis(66);
// Increment our time variable, which doubles as our bit-shift counter.
t++;
}
return Common::kNoError;
}
Of my initial project (16-bit support), all that remains to be done is to document the API on the wiki. My mentor, Sev has requested of me that I move on to improving the keymapper, which he sees as a much higher priority than scaler and backend support for 24 or 32 bit color formats.
I agree with that assessment, and I can’t really say I was looking forward to upgrading the scalers.
In light of this, I am providing a new planned timeline:
Optimistic:
Pessimistic: