Planet ScummVM

I was shocked to notice that, as of yesterday, it has been a year since I posted anything on here. That's not really that surprising, given that I've been well and truly absent from the ScummVM community, but I plan for that to change. I've set aside some time each week for personal programming, either ScummVM or Android (for which I've set up a separate blog) (or possibly a combination of the two, now ScummVM has an Android port).

I also suddenly realized how out of date the title and description of this blog was (referring to "motions towards", etc), so I've made it a little more relevant. I didn't want to put a pun in, but when the engine name is Groovie it's hard not to. Forgive me?

This is just a quick post is to announce a set of SVN builds of ScummVM mainline code for the GP2X Wiz and new Caanoo,.

This release is mainly to support SCI testing and give users a chance to preview updates to some of my ScummVM backends.

These releases are build straight from the mainline trunk ScummVM code for the given SVN revision number.

An OpenPandora and original GP2X ScummVM SVN release should follow next week(ish). Been a little busy to track down some bugs in them.

Note: Please don’t mirror or hotlink these preview/test/alpha etc. releases or put them on download services but rather, direct people to this page.

This helps me ensure that users always have the most recent versions.

Also note that these test releases are not officially (or unofficially) supported .

Please give these releases a go and provide feedback.

New features since 1.1.1 releases:

Below are the main features and fixes added with this new release.

GP2X Wiz: Further cleanup to the downscaling support. Most of the glitching that has been seen in previous releases should now be gone.

A few small performance tweaks.

Caanoo: The Caanoo is GamePark Holdings new console and it is based on a slightly upgraded version of the platform used for the GP2X Wiz.

Performance of this new backend should be similar/better to the GP2X Wiz. It’s also VERY new so expect a few snags and issues.

I hope to make Caanoo support official with the upcoming 1.2.0 ScummVM release.

Supported engines:

These releases feature support for all the game engines supported in ScummVM 1.1.1 and additionally include support for testing the SCI engine (early SCI games) and for testing Fascination support in the Gob engine (remember, it’s really not a children’s game). It is the testing of these engines that is the main motivation behind the release.

Specific restrictions:

Each of the releases has a small number of restrictions that have an affect on the games/engines you are able to use with each platform.

Caanoo: The biggest restriction of this backend is simple. I have not tested it as I do not yet own a Caanoo (it’s in the mail). Several testers have tried it and told me it works well but it has been coded blind. Feedback appreciated.

GP2X Wiz:  I have spotted a minor issue where the screen is not totally cleaned when some types of screen movement occur, that combined with the Wiz’s LCD tearing can lead to the odd graphics glitch.

Providing feedback:

If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

• Bug Reports (ScummVM’s Sourceforge bug tracker)
• Feature Requests (ScummVM’s Sourceforge feature tracker)
  • Source Code Patches (ScummVM’s Sourceforge patch tracker)
  • General Forum Feedback (ScummVM’s GP2X/GP2X Wiz/Caanoo forum, I also check any official news posts I make to the GP32x forums)

Downloads:

Please ensure you download the correct version for your device.

• GP2X Wiz: download

Extract the contents of the zip to the game folder on your SD card, ensuring that you have a “scummvm.ini” in your game folder and the rest of ScummVM in a “scummvm” subfolder.

Launch “ScummVM” from the main SD launcher menu to run.

Review the README-GP2XWIZ for more information.

• Caanoo: download

Extract the contents of the zip to the game folder on your SD card, ensuring that you have a “scummvm.ini” in your game folder and the rest of ScummVM in a “scummvm” subfolder.

Launch “ScummVM” from the main launcher menu to run.

Review the README-CAANOO for more information.

Regards,

John

You're Doralice, the cutest airline captain of the Paris-Miami flight. During your last trip, a dying passenger asked you to deliver top secret vials. Will you succeed in your mission, avoiding deadly traps and solving every mystery?

Currently, the PC versions of Fascination are missing an AdLib player, but everything else is there. Please note that the CD version requires some manipulations and the ScummVM tools to extract the required files.

Get the latest daily build of ScummVM and your version of the game and give Fascination a try! Please post any bugs and unrecognized versions you can find to our bug tracker, following the bug submission guidelines.

And if you find interesting sights, be sure to submit your screenshots.

While this is a little late to say the least (better late than never and all that, I mean it’s only 3 months late ) I have finally managed to get my hands on a working GP2X Wiz, some all important free time and motivation, and built up and tested the GP2X Wiz backend for the 1.1.1 release following on from the official announcement.

This post is also an announcement of the GP2X backend release as I forgot to post about it at the time despite the fact it got uploaded and released only a few days late .

I have not had a great deal of time recently to work on these releases so the backends are largely the same as the previous releases with just the needed changes to support all the fancy new things in the ScummVM core. No reworking of the control system or the like has been done yet (it’s still on my TODO).

Some of the highlights of the changes 1.1.1 bring, that benefit the GP2X and GP2X Wiz, include 2 completely new engines and games, Dragon History (available free from here) and TeenAgent (available free from GOG.com). Also new is 16bit graphics support, which allowed us to add support for a whole bunch of newer Humongous Entertainment games for kids and improved support for the Amiga versions of Monkey Island, Legend of Kyrandia and Future Wars.

Please provide feedback in the usual places on these releases and enjoy using them.

Platform specific restrictions:

Each of the releases has a small number of restrictions that have an affect on the games/engines you are able to use with each platform.

GP2X: The biggest restriction with this platform is the overhead (and crudeness) of the downscaling when using 640*480 high resolution games on the 320*240 screen making such games perform poorly and look, well, bad.

GP2X Wiz:  The downscaling support is a relatively recently added feature to the Wiz backend and while it looks a lot better than the GP2X, some issues still remain with high resolution games exhibiting ‘tearing’ when updating the screen under some circumstances.

Unfortunately this seems to be an exhibit of the Wiz screen tearing bug and while efforts have been taken to minimise it in this release it the problem has not totally gone away.

Providing feedback:

If you would like me to consider a feature or fix a bug help me to help you by ensuring the reports end up recorded in official places.

• Bug Reports (ScummVM’s Sourceforge bug tracker)
• Feature Requests (ScummVM’s Sourceforge feature tracker)
  • Source Code Patches (ScummVM’s Sourceforge patch tracker)
• General Forum Feedback (ScummVM’s GP2X/GP2X Wiz forum)

Downloads:

• ScummVM download page

What’s Next:

Now I have the outstanding official 1.1.1 releases out of the way my plan is to get test releases from the main ScummVM trunk codebase featuring the ‘new’ SCI engine out as soon as I get time for the GP2X and Wiz, hopefully I will also be including support for the new GPH Caanoo at the same time.

I also plan to update the OpenPandora release at the same time.

Regards,

John Willis

Well, I'm sure anyone that has played Riven has at least heard of the massive easter egg system that is in there. (Yes, this will work in ScummVM :P). I was checking some scripts in Riven because there are some other hotspots that will make the cursor disappear in the original game but weren't really attached to the easter egg. Richard Watson ("RAWA") even said that they weren't related to the easter egg. Well, it seems that they were originally going to be part of the game, but were cut out - and the scripts prove it.



The first of the hotspots, is the one above the cage. When clicking on the hotspot, this code runs:

switch (tdl) {
case 2:
    tdl = 3;
    break;
default:
    tdl = 0;
    break;
}

Unfortunately, all the other hotspots set tdl to 0, so the variable can never truly be set here. Not to mention tdl is also not set to 2 anywhere.

Now for the Cho hotspots. It seems it was intended to have you click the hotspots in a specific order after tdl is set to 3 (from the above code segment). I have labeled them in the correct order here:



The hotspots labeled 1-6 will increase tdl by one if pressed in the right order. When you press the last hotspot, this segment of code is run:

switch (tdl) {
case 9:
    araw = 4;
    break;
}
tdl = 0;

araw is the variable used for the main Riven easter egg variable! aova is the other one. araw is normally set to 4 when you click the hotspot above the elevator on Garden Island:



So, it seems that this content was cut and replaced by the elevator hotspot. Or it could be that they changed the whole easter egg structure after having this initial "Cho code" in there.

(NOTE: The green/red rectangles are part of the hotspot debugging mode I added to the engine in ScummVM. Green = enabled, red = disabled)

In the previous post, I wrote that I’ll try to give some news about Fascination progress before the summer. I tried

More seriously, the good news came very recently: in less than two weeks, with the impressive help of SylvainTV, all the versions of Fascination became playable and completable, or at least all the ones I possess.

The main thing missing currently, only used by PC versions of the game, is the AdLib player (and IMHO, the SoundBlaster sounds a lot better). There’s a wrong delay (too short) between rooms in several places of most versions. This seems to be caused by the delay required at the time to load from the floppies, and it’s easily patchable.

Last detail, the (rare) CD version still requires a tool for the STK extraction. joostp is cleaning it up, and will commit it when it’ll be in a good state.

Maybe it’s a good time now to grab your originals and send us some feedback on the game, specially if you find some of those too short delays!

A short blog post today. I normally can't come up with something that's worthy of a full blog post anyway, so here's an attempt to post a bit more often. Take a look at this page which goes into detail of a lot of the combinations of puzzles in Riven. Gotta love that marble puzzle...

In the programming realm, I added support for drawing the dome combination and telescope combination in the lab journal and Catherine's journal, respectively. Screenshots of course!





Now you might say "But, clone, I can see where the numbers in Catherine's journal end and the page begins." Yes, you can. You also can in the original game. Nothing I can do to make it look better than what it does currently :P

And for those who are really interested and have forgotten the D'ni number system, the dome combo here is 2-6-16-18-22 and the telescope combination is 1-5-5-2-3.

EDIT: I forgot to mention that because Catherine's journal now displays the telescope combination, two more endings are now accessible from the beginning without using the debug console. \o/

First of all, some comments regarding what I have been coding since my last blog post. Mostly I have been hunting bugs, and testing games to if all was working well.

There were some compilation/linking problems with some ports and with some help I have hopefully fixed them all, still there are some ports that have not been tested yet. Some problems arised also when switching between SDL and OpenGL graphics modes, but those bugs are fixed now. Also, there was some discussion regarding the aspect ratio modes in devel list. I was taking as base for the aspect ratio correction system the one that the SDL graphics manager had, but that wasn’t really necessery for the OpenGL rendering, as it does allow scaling to any size. After some talk, I removed some unnecessay options, and now there are 3 aspect ratio modes: “None”, “Conserve” and “Original” (this last one added after its suggestion in the discussion).

And, the big news are that Google Summer of Code (Winter of Code for me here, hehe) has ended, at least the coding part has ended last monday. Now it is time for the final evaluations, and I hope that finish well :) It was a really nice time, and a great experience :D

I finished well the SDL backend refactoring (including most of its ports), into a modularized design, and the OpenGL graphics manager for the SDL backend is working good. However, I could not finish all what I planned to do, I could not finish the WinCE port refactoring in time. It is a really complicated port to modularize, there is a lot of common code between the events and graphics parts, and without being able to test it nor even compile it, it is a really hard task. I will have to discuss a bit about this with my mentors later.

And for the future, I plan to continue working on ScummVM. There are some pending feature for implementing in the OpenGL graphics manager, like shaders, that because the short available GSoC time I couldn’t do. And I thought before starting GSoC that I would be able to implement them in time, but reality showed to be more complicated. Still, before I hope that my branch be merged with trunk, and in case there is some problem for that, I plan to continue my work and fix those issues.

At the time of writing, there are less than 2 hours left of GSoC coding time - so it's time for my last GSoC blog post.

It's been a fun couple of months, and it's really nice to see that the end product actually works.

Of course, it's not perfect, and there are things I'd do differently if I were to do it again - but then, it would be pretty unrealistic to expect that everything could be perfect after only a few months. A decompiler is a complicated project, and making a generic kind doesn't make it any easier.

There are still plenty of stuff on the to-do list, and I've already talked to my mentors about how we can deal with several of the outstanding issues - but there's no way all of that can be done within the time frame allocated for GSoC.

Right now, though, I'm going to take a short break from coding - and later, I can hopefully find the time to work more on the decompiler and implement some of the remaining things.

Hi All,

First of all my apologies for showing up late this week, as something urgent came up this weekend.
Next, some updates on my work till today :
Last week I started with implementing the exit Dialog using ListWidget, which is shown to the user before exiting. The advantage of using a ListWidget is making the exit dialog scrollable.

Next I moved on to implement AudioCD tests.
Backend provides an API to play audio tracks from a CD Drive or a hard drive if no tracks are found in the cd drive.
To play tracks from hard drive, the search is made in predefined directories using SaerchMan.
To test if the implementation is fine or not, I have created 4 mp3 files and play them in order i.e
track1-track2-track3->track-4.
Then I verify the ordering from the user and decide if the implementation is fine or not.

The audioCD data tracks are MP3 files, converted from text using text-to-MP3 converter.

Next I moved on with producing audio outputs with variable sample rates.

Finally, to test MIDI, i brought changes from trunk to my branch, through a SVN merge.

Next, I figured out a bug in the Message Dialogs. The problem was, the hotkeys were not working as they should be.
I explored this and found out that the Initializer list for the button instances was incomplete. Finally  committed the patch to the trunk.

Next I did worked upon improving tests/UI as pointed out by Eugene.

I now plan to finally get done with MIDI tests, and send my code to review.

__

Neeraj

Well, I did manage to get the code generation running in just one day after all! That's means I have the entire weekend to rewrite the documentation, and there's still the final week after that for polishing everything off.

Here's a function as seen in one of the scripts (INHOME.EMC):

00000F88: global_sub0xF88() {
00000F8A:   if ((-1 < var4)) {
00000F94:     if (!(var17)) {
00000F9C:       var17 = 1;
00000FA0:       retval = auto_sub0x33C(30, 0, 28);
00000FAC:       retval = o1_queryGameFlag(2);
00000FB2:       localvar1 = retval;
00000FB6:       retval = o1_queryGameFlag(1);
00000FBC:       localvar2 = retval;
00000FC0:       var3 = 1;
00000FC4:       if ((localvar2 && localvar1)) {
00000FCE:         retval = o2_zanthiaChat("At least I found my cauldron and my spellbook.", 29);
00000FD6:         return;
00000FDA:       }
00000FDA:       if (localvar1) {
00000FE0:         retval = o2_zanthiaChat("At least I found my cauldron.", 30);
00000FE8:         return;
00000FEC:       }
00000FEC:       if (localvar2) {
00000FF2:         retval = o2_zanthiaChat("At least I found my spellbook.", 31);
00000FFA:         return;
00000FFE:       }
00000FFE:       retval = auto_sub0x33C(34, 0, 32);
0000100A:       retval = auto_sub0x33C(35, 0, 33);
00001016:       return;
0000101C:     } else {
0000101C:       var17 = 0;
00001020:       retval = o2_randomSceneChat();
00001020:     }
00001022:     var3 = 1;
00001026:     return;
0000102A:   }
0000102A:   retval = o2_useItemOnMainChar();
0000102C:   return;
0000102C: }

Currently, the decompiler only works with scripts from the talkie version of Kyra2, as one of the functions differ in the number of arguments - but I'll get that fixed before GSoC is over.

Right now, though, I'll focus on the documentation - there's a lot of stuff that needs to be written and rewritten with the changes I've made for Kyra.

After some work, I've gotten a good, automatic function detection algorithm implemented in the CFG analysis, which engines can choose to opt-in to. This is perfect for Kyra, as some of these scripts really do require you to look at the control flow to determine where they stop.

The algorithm is really pretty simple: we find any unreachable code that is not already inside a function, and follow the code flow to see where that piece of code ends - and that is then registered as a function. However, it still requierd quite a bit of rewriting to accomplish this properly, so it took a bit longer than I'd planned - but it should be worth it.

Here's a relatively small sample script from the HoF CD demo:


and just for the heck of it, here's a really big script (Warning: full image is 19873x16660 pixels large!):


Now, it's finally time for the code generation part of Kyra. I'd originally planned to finish it Friday, but this took a day longer than planned, so I have a feeling the code generation won't be ready before Saturday - but we'll see. At the very least, I should be able to get it done during the weekend, so I have all of next week to polish the documentation, clean up some of the code, add some small features that would be nice to have - stuff like that.

This last week, I have been working mainly on fixing bugs, and testing the SDL refactoring changes and the new OpenGL graphics manager. So far, it is going well. Here is a list of the changes:

• Merged from trunk (Not upto actual HEAD, but was a big update)
• Fixed a crash when a texture was only partialy updated, crashing Broken Sword 2.
• Fixed a hack for reseting the wndow scale to x1 when starting a game. I added a resetGraphicsScale() function to OSystem.
• Added options in Graphics Mode list for switching between SDL graphics modes and OpenGL graphics modes.
• Added OpenGL libs to configure script for MingW, it was not compiling before.
• Added support for BGR pixel formats.
• After some discussions and changes, improved the way that the default fullscreen mode was selected. Now it will prioritize the desktop resolution, and in case that it is not available select one that has the same aspect ratio the desktop has, and as last resource use the one with the best metric.
• Implement coordinates adjustments for warpMouse, the cannon sequence of COMI was failing when using aspect ratio correction and resizing the window.
• Disabled 16/9 and 16/10 aspect ratio corrections, they are not really needed.
• Implement some basic OpenGL auto detection for the configure script.
• Other minor fixes, and some commenting.

Also, it is needed some help testing the modified Ports, and testing the new OpenGL graphics manager, you can follow the discussion on the mailing list.

At this point I am behind my shedule, I should have finished the OpenGL graphics manager quite ago, and start working on refactoring some ports. So, the next plans are to continue debugging the changes I made, try to finsih the WinCE port refactoring and the next week work on merging with trunk and doing the last tweaks.

This blog post is a special one. Most of you know that SCI testing is going on already for all those boat loads of SCI games you have. That's for SCI0-SCI1.1, of course. I'm here to announce something different, though. No, not another LordHoto joke. No joke at all, actually!

I'm here to announce that GABRIEL KNIGHT: SINS OF THE FATHERS is completable in ScummVM. Not without bugs of course. And note that it will still NOT be tested in our current SCI testing nor be supported with the rest when they make it into a full release eventually.

EDIT: DrMcCoy has a quick trigger finger and found out that the hi-res (Windows) version is not completable. The DOS CD version is (and almost definitely the floppy version). This should be fixed now.

There are two major bugs with it still, but both are fixable if you use the fan made patches. In other words, both of these bugs were in the original game so they're not "our fault". You can download said patches from here. You'll want the NRS patches for either floppy or CD. There will be some other problems too. The save/restore menu is not working 100%, the text wrapping isn't correct, and transparency does not work yet. You'll see what I mean about the transparency if you get to use the flashlight or arrive at Schloss Ritter.

We do NOT want bugs submitted about Gabriel Knight, we know there's plenty of them still.

Also, please don't play Gabriel Knight if you still have other SCI0-SCI1.1 games to test. We really need you loyal ScummVM users concentrating on those. We love you guys! :D And thanks for all those SCI games you've already played through... and a seemingly neverending amount of bugs :P

Last August, SCI32 games weren't even startable and look how far we've come in just under a year!

Ah, and the obligatory screenshot. This was taken two days ago when I beat it for the first time. Yes, I missed 7 points. No idea where though...


PS - My apologies to pgr on #scummvm (IRC). We had decided not to reveal this, but changed our minds after discovering that the Day 5 lockup was indeed in the original too. It's also skippable using the spacebar. I'll be comparing both the good and bad scripts to add a workaround to the code for it soon. Hopefully I'll be able to figure out something clean ;) I hope you can forgive me! :)

Hey all!

It's been a while since I last blogged (whoops!).

But in the time since my last post, quite a bit has happened.

First off, I got the DS port working with loadable modules after reintegrating the thumb-interworking code into the DS port. It was quite simple, really, as the thumb relocations used were PC-relative (and thus needed little to no manual work). I tested a good number of the engines after getting this work done, including the SCUMM, SKY, LURE, QUEEN, and AGI engines. They all seemed to work fine (though I only played through about 10 minutes of each game and I've heard some, like Sam and Max, use more memory later on). The one exception in terms of successful testing is the CRUISE engine. That plugin had a single relocation type (R_ARM_TARGET1) that none of the other engines have. This type is supposed to be treated either the same as R_ARM_ABS32 or R_ARM_REL32 (how it should be treated can differ, even in the same file). Since I saw no easy way to determine how it should be treated during runtime, I added "--target1-abs" linker flags to the ds makefile (the flags specify that R_ARM_TARGET1 should be treated as R_ARM_ABS32 in all cases) and coded for the R_ARM_TARGET1 relocation accordingly, but to no avail ("Cruise for a Corpse" still crashes on bootup, showing only the Cruise cursor). As of now I can't see the console (on the top screen of the ds) at the point of the crash, so debugging is difficult, but I'll continue to work on this.

Another problem with the DS build is that (as mentioned before) I had to remove the "--gc-sections" linker flags since things were being garbage-collected in the plugins and main executable that referred to each other. This unfortunately resulted in a lot of bloat in the main executable. For some engines, this bloat is around 300kb, which is too much to be ignored. There's been some discussion among the mentors concerning different ways to decrease this bloat, including building static builds with garbage collection and dumping the symbols then telling the linker to included only those symbols in the dynamic builds. In any case, this is something that will need to be worked on before the DS dynamic plugins work is reintegrated into the trunk.

Apart from the DS work, I did some work abstracting a more generic ELF-loader last week. It's a little rough at the moment, but works for both the PS2 and DS ports, so at least I didn't break anything :-). I put the methods dealing with relocations into their own files based on processor type (like arm-relocs.cpp and mips-relocs.cpp) and also split the shorts-segment-manager (made to effectively use the gp-relative section of MIPS processors) into its own file. There's still a bit of work to be done for abstraction, including making subclasses of DLObject (like PS2DLObject, which could be a subclass of MIPSDLObject, etc.) and having the different plugin-providers use these different subclasses (right now, I just used "ifdefs" with different ports).

I've also worked on a bit of the plugin design change work. It took me a while of looking through the base code to understand how to best begin implementing the plugin design changes, but I added some new functions to the PluginManager class (a "loadFirstPlugin" and "loadNextPlugin") as well as changing main.cpp and some functions in plugins.cpp to use these functions in a loop when "NEW_PLUGIN_DESIGN_FIRST_REFINEMENT" is enabled. I tested on a Windows build with dynamic plugins enabled and was able to successfully launch games with only one plugin ever loaded at a time!

So the plan for this week is to continue plugin design change, abstraction, Cruise for a Corpse, and DS memory problem work,

Tony

Hi everyone,
Here are some updates on my work last week.
I started up with fixing the boundary palette problem in the palette rotation test. The problem was I was taking two colors for background and foreground, these were now included in the palette to be rotated. This also involved implementing colored progress bar so that they look nicer.
Next I moved on with Sound Subsystem tests. The intent was to test if the backend was able to identify sounds or not using beeps. For generating the sound data I used the PC speaker emulator, the stream could also have been a file but that would couple it with FS tests.

Next I found out that the progress bar displays the testsuite counts to the sizes even if none of them are enabled. The next commit intended at displaying correct information, like if X out of Y tests are enabled, the bar should be like XX of X tests instead of XX of Y tests.
Similarly,, as required, a finish test zone was added to mouse event tests. This would be useful for keyboardless backends.

Next was GUI, of sound subsystem tests. As earlier uses of GUI in the engine code were using some stuff, so this work involved a bit refactoring of GUI code in the engine with introduction of Generic class and a few generic methods.
This was used in generating Multichannel sound to test if Mixer works fine. The user can pause and play a particular channel at his choice using the GUI.

Next, I tried an entire run under valgrind, this identified new-delete mismatches at two places, these were fixed as well.
Next I moved to fix a bug in configFile handling, with testsuite rerunning, the size of the config file key-value pairs was increasing, for each rerun. The fix to this was simply an one-liner .

Finally, we have a GUI in the end, which displays a summary of the current execution of testbed. One can rerun the testsuite from that dialog.

For next week, I have:
Monday/Tuesday : AudioCD/ Sample rates
Wednesday onwards : Midi Tests, testing and documentation later on once Midi tests are done.

Thanks

It's a day later than I'd estimated, but last night, I finished the Kyra disassembler, including function detection.

For now, I'm only handling one game - Hand of Fate - but it would be pretty simple to add the other Kyra games as well, as the only things different between them are the "magic" functions, and they're all referred to by a parameter to a specific opcode. However, there's not much point in doing that right now; it won't help me to decompile the bytecode.

Here's an excerpt from the disassembly of a small script:

00000016: jumpTo 0x0 (0)
00000018: push 6 (1)
0000001a: push 3 (1)
0000001c: setCharacterPos (0)
0000001e: addSP 2 (-2)
00000020: push 6 (1)
00000022: push 2 (1)
00000024: setCharacterPos (0)
00000026: addSP 2 (-2)

The next step is to get the code flow analysis working with KYRA, and then it's on to the code generation.

Still, I need to complete some more things before finishing with the OpenGL Graphics Manager:

• Add options for switching between OpenGL manager and SDL manager
• Porting to OpenGL ES and testing, most OpenGL code should work for GLES, still I need some testing
• Code cleanup and documentation

Here I was bracing myself for the imagined complexities of movement logic, and it turned out to be a whole lot simpler than I imagined. Probably blame it on the other two engines I've had experience with path-finding for: Lure, and Tinsel, both of which have their share of complicated logic. For Rex Nebular, though, the implementation was a lot more elegant than I'd expected.

What the MADS engine does for walkable areas is to have two parts. The first is a priority/depth surface, which had already been previously implemented. This is a surface which both specifies the walkable areas, and is also used to determine which parts of an object, at a given 'depth', should be drawn on-screen. In the first room, for example, the area comprising the chair has some varying levels so that the player gets drawn behind it.

The other part to the movement functionality is a series of 'scene nodes'. These are a series of points distributed across the scene to represent appropriate intermediate points in movement. If a straight line between the start and end point isn't possible, because of a marked obstruction, then the engine calculates the distance between each node in the scene, including both the start and end points as two extra nodes. It then calculates which series of nodes will take the shortest amount of time to traverse, and uses that as the basis for movement - the actual walking then moves the player from node to node until the destination is reached.

This works well for the game since, unlike in Tinsel or Lure, there aren't ever any moving actors that could interrupt the walking path. The only NPC character movement that ever happens is in cut-scenes, where the player is either not moving, or is being controlled by the computer (such as when Rex is taken to the cells).

Now that I've got Rex moving around on the screen, the next immediate step is to get the hotspot and selection code working. Somewhat ironically, this is turning out to be more complicated than the walking code itself. I'm currently working my way through disassembling the various routines and implementing comparable code. Hopefully, I'll soon have enough implemented that I can properly implement some actual actions in the first room.

Hi everyone!,

Here is a brief summary of my work last week.

I started with implementing progress bars, now the progress within a testsuite and the overall progress are reflected by two text lines of form (X of XX tests), In addition the progress within a testsuite is also shown graphically as progress bar, which gives a cool look .

Next I moved on to some more improvements in GUI as suggested by Eugene. There existed a button to select all tests at once but no such button to do the reverse. This was balanced by making the same button do both the jobs, i.e if number of selected tests is more than deselected ones, it shows “Deselect All”, “Select All” otherwise. Other improvements included, modifying the GUI texts, and some formatting.

Next, their were tests which when ran in interactive mode showed no activity, code was added to make them display the information about what they are working with.

Finally, I started on enabling the testsuite and test selection using a config file. Initially, I rolled out my custom implementation to read and parse config files, later i figured out that this could also be done using the ConfigFile class. So I switched my implementation to make use of that class.
Now we have a layout-like this:

[Global]
# Global-parameter-name value pairs here
isSessionInteractive=true
[Testsuite]
# Decides if testsuite itself is enabled or not
this=true
# Tests within the testsuite go here
dummyTest=true

This does two useful things:

• It saves your configuration each time you customize and remembers it, so that you don’t have to customize every time if you needed a particular customization.
• One can also manually edit t his file to affect exactly which tests of a particular testsuite be executed.

Next, I also worked on writing a testcase for cursor-trails in GUI bug.
The problem was if the shake offset is set, and then GUI is shown, cursor leaves trail in GUI and its very difficult to click any button. I first reproduced this problem which quite ended up as a test for it.
I have an offset of 25 pixels set and I then prompt GUI dialog to verify if the user sees a trail or not, If there are no trails, user will probably click the “No” button on right, if there be trails, clicking any button would be difficult and user may end up pressing “return”, which is interpreted as “Yes” i.e trails were there.

Finally towards the end, I enabled the logging feature.
Now testbed outputs are logged with more details, and are also produced on stdout with lest explicit details.
One can provide his own logDir/logFile, by default log files are “testbed.log” produced in game-data directory.

Next week I plan to take on sound subsystems. This is probably the last subsystem to be tested.
I want to do all this quick so that I could get some time to modify things as mentors want them to .

–
Neeraj