Today I tried to make a complete playthrough of Kyrandia 1 Amiga. It turned out I had to fix a few things, like the opcode used to display Kallak's Note and some potion animation related code. For the latter it turned out, that some offsets in kyra.dat were wrong, after fixing them up it worked like charm. After that I was finally able to complete the game. Yeah! I did not find any time to fix the credits yet though, so those are still a bit glitchy. I can not await merging of the MaxTrax playback code from the GSoC 2009 mod player branch. That might require some adjustments in the outro though, since unlike all other Kyrandia versions, the Amiga version seems to use a special sound file for that.
Anyway I made some screenshots of my playthrough. I just uploaded the nicest ones (IMHO) though. I hope you will like them :-).
After all the graphics are still nice, despite them using only 32 colors for the game screen.
For those of you who wonder: just because game is completable that does not imply that there is no more work to be done on it. For example I still need to check some bits I noticed in my playthrough, most important the colors of Brandon, when he is poisoned by the snake. The DOS version makes Brandon greenish when that happens, while the Amiga version does not change his colors at all (at least not in ScummVM). I will need to investigate that. Also I need to create an offset table for my German Kyrandia 1 Amiga version, which was kindly donated by sanguine (thanks to him again), so it can be used with ScummVM. And of course the aforementioned credits glitch needs to be fixed. And probably other bits I did not notice yet... :-).
11 August, 2009
More progress on Kyrandia 1 Amiga
Today I started to implement more differences in the Kyrandia 1 Amiga code. I finally got the GUI colors to work. Here is an screenshot of the text input field of the GUI.
Fixing up the colors of the GUI was quite easy. It was just a matter of changing some color values if the game platform is set to Amiga. The Amiga GUI uses color 17 for the background, and the colors 18 and 31 for the outlines. Color 18 is also used for the text field input background.
What was more work was to get the GUI strings to work. It turned out that the extraction routines, which extracted the strings from the original executable, were bugged. The Amiga version does use padding bytes now and then, so all strings start at even addresses. After I fixed proper handling of that, it worked just fine.
I was also able to implement palette differences for all opcodes I tested so far. This resulted in the grotto to be working now. Before I implemented the differences ScummVM always crashed, because the code tried to access non existent data. Funny here is that while the DOS version contained the special palettes in the executable, the Amiga version goes a much nicer way: All the special palettes are placed inside "PALETTE.DAT". This saved me some time finding the correct executable offsets for extraction. Now the fireberry glow palette for example works, which handles darkening of the grotto scenes, depending on the brightest fireberry in the scene and/or the players inventory. Here are some screenshots for that feature:
As you can see the brighter the fireberries are, the brighter the scene's color is.
The Will-O-Wisp also uses a special palette in the grotto. At first I thought it would work out of the box with the aforementioned changes, but sadly the Will-O-Wisp code has hardcoded palette handling, so I had to adjust that too. A little side note: I noticed that, when I wanted to make an screenshot of it for this blog entry ;-). Here comes a screenshot for the Will-O-Wisp in the grotto:
If I caught all palette differences, the game might be completable now. I probably missed some bits though. Of course there might be some other differences in the Amiga version, which might render the game not completable, but seeing how nice it worked so far, I doubt that is the case.
For the people interested why the palette differences might render the game not completable: I have an object / class handling palettes in the code. To catch all palette differences this code does assert out when the client code tries to access colors outside of the palette scope. This makes ScummVM quit when the code tries for example to use color 250 in a 32 color palette, which only offers colors 0 to 31. Of course that assertion also helps to catch out of bounds access in general cases too. So if now there is still a place I missed, which has hardcoded palette access based on the 256 color version, ScummVM will quit and that might render the game not completable. Of course that only applies if it is a critical point, which has to be passed, like for example the fireberry glow palette of the grotto was.
I also started to look a little bit into the outro / credits code. After implementing the differences, the outro works fine. The fewer colors of the Amiga version are noticeable here though. For example the Amiga version does not offer any Kyragem fading effects, as far as I can tell. I do not have any screenshot for that yet though, I will post some, when I really played the game till that point, instead of just using the ScummVM debugger for cheating ;-). The credits show up, but there are graphical glitches, like text not being aligned properly. I will need to take a look into that soon.
Fixing up the colors of the GUI was quite easy. It was just a matter of changing some color values if the game platform is set to Amiga. The Amiga GUI uses color 17 for the background, and the colors 18 and 31 for the outlines. Color 18 is also used for the text field input background.
What was more work was to get the GUI strings to work. It turned out that the extraction routines, which extracted the strings from the original executable, were bugged. The Amiga version does use padding bytes now and then, so all strings start at even addresses. After I fixed proper handling of that, it worked just fine.
I was also able to implement palette differences for all opcodes I tested so far. This resulted in the grotto to be working now. Before I implemented the differences ScummVM always crashed, because the code tried to access non existent data. Funny here is that while the DOS version contained the special palettes in the executable, the Amiga version goes a much nicer way: All the special palettes are placed inside "PALETTE.DAT". This saved me some time finding the correct executable offsets for extraction. Now the fireberry glow palette for example works, which handles darkening of the grotto scenes, depending on the brightest fireberry in the scene and/or the players inventory. Here are some screenshots for that feature:
As you can see the brighter the fireberries are, the brighter the scene's color is.
The Will-O-Wisp also uses a special palette in the grotto. At first I thought it would work out of the box with the aforementioned changes, but sadly the Will-O-Wisp code has hardcoded palette handling, so I had to adjust that too. A little side note: I noticed that, when I wanted to make an screenshot of it for this blog entry ;-). Here comes a screenshot for the Will-O-Wisp in the grotto:
If I caught all palette differences, the game might be completable now. I probably missed some bits though. Of course there might be some other differences in the Amiga version, which might render the game not completable, but seeing how nice it worked so far, I doubt that is the case.
For the people interested why the palette differences might render the game not completable: I have an object / class handling palettes in the code. To catch all palette differences this code does assert out when the client code tries to access colors outside of the palette scope. This makes ScummVM quit when the code tries for example to use color 250 in a 32 color palette, which only offers colors 0 to 31. Of course that assertion also helps to catch out of bounds access in general cases too. So if now there is still a place I missed, which has hardcoded palette access based on the 256 color version, ScummVM will quit and that might render the game not completable. Of course that only applies if it is a critical point, which has to be passed, like for example the fireberry glow palette of the grotto was.
I also started to look a little bit into the outro / credits code. After implementing the differences, the outro works fine. The fewer colors of the Amiga version are noticeable here though. For example the Amiga version does not offer any Kyragem fading effects, as far as I can tell. I do not have any screenshot for that yet though, I will post some, when I really played the game till that point, instead of just using the ScummVM debugger for cheating ;-). The credits show up, but there are graphical glitches, like text not being aligned properly. I will need to take a look into that soon.
10 August, 2009
Kyrandia 1 Amiga
This time a really long time passed since the last post. I decided to make a new entry now, since there has been finally some progress on Kyrandia 1 Amiga. Some of you might know that we have an GSoC student working on support for various AMIGA sound formats (to be precise: TFMX for Monkey Island 1 Amiga and MaxTrax for Kyrandia 1 Amiga). You can find his blog over here. He already finished MaxTrax support. This gave me enough motivation to look into Kyrandia 1 Amiga again.
First of all I finally managed to implement a font renderer. That was a major PITA at first, but with help from nolange (the GSoC student) I was able to get a bit into how the library code on Amiga works. This helped to RE the font format, since it used blitting of the "graphics.library". With this information I was able to decode all the important information and write an implementation for rendering the fonts in ScummVM.
Here is some screen of a font use in the intro:
As you can see it works fine, even the colors seem correct. I do not have any Amiga to check that though.
Next I implemented some differences in the Amiga palette code. Kyrandia 1 Amiga uses two 32 color palettes. It splits the screen into two areas: the main game screen and the inventory. The first one uses a palette supplied by the scene files, the latter uses a fixed palette, which also includes all colors used by the items. Now the in-game parts looks nice too.
There was a major other palette difference I implemented too: Since the Amiga has not too many free colors, the game overwrites color index 16 with the correct font color every time a text is displayed. The original used some kind of switch statement to determine from the color index passed from the scripts, which color to set up in the palette. I did implement that too, I chose to cleanup the way it is done though. Here comes a funny side note: the Amiga version still uses the 256 color indexes from the DOS version for text processing. It uses fixed colors for the font: 16 and 19. Color 16 is the font color, while color 19 is the outline color, which is usually black. Now the Amiga text palette color setup code takes the DOS color index compares it to certain values and then sets up color 16 accordingly. The font drawing code on the other hand ignores the passed color indices and just uses the aforementioned colors.
Here are two in-game screens of Kyrandia 1 Amiga:
and here is how it looked before:
As you can see the interface changed the colors back then, since the whole screen used the scene palette.
Of course there is still plenty of work to do. For example the in-game GUI is still horribly broken color wise (and text wise). Just take a look at this screenshot:
I will also try to make some more blog updates now in the future. So long. See you in the next blog entry.
First of all I finally managed to implement a font renderer. That was a major PITA at first, but with help from nolange (the GSoC student) I was able to get a bit into how the library code on Amiga works. This helped to RE the font format, since it used blitting of the "graphics.library". With this information I was able to decode all the important information and write an implementation for rendering the fonts in ScummVM.
Here is some screen of a font use in the intro:
As you can see it works fine, even the colors seem correct. I do not have any Amiga to check that though.
Next I implemented some differences in the Amiga palette code. Kyrandia 1 Amiga uses two 32 color palettes. It splits the screen into two areas: the main game screen and the inventory. The first one uses a palette supplied by the scene files, the latter uses a fixed palette, which also includes all colors used by the items. Now the in-game parts looks nice too.
There was a major other palette difference I implemented too: Since the Amiga has not too many free colors, the game overwrites color index 16 with the correct font color every time a text is displayed. The original used some kind of switch statement to determine from the color index passed from the scripts, which color to set up in the palette. I did implement that too, I chose to cleanup the way it is done though. Here comes a funny side note: the Amiga version still uses the 256 color indexes from the DOS version for text processing. It uses fixed colors for the font: 16 and 19. Color 16 is the font color, while color 19 is the outline color, which is usually black. Now the Amiga text palette color setup code takes the DOS color index compares it to certain values and then sets up color 16 accordingly. The font drawing code on the other hand ignores the passed color indices and just uses the aforementioned colors.
Here are two in-game screens of Kyrandia 1 Amiga:
and here is how it looked before:
As you can see the interface changed the colors back then, since the whole screen used the scene palette.
Of course there is still plenty of work to do. For example the in-game GUI is still horribly broken color wise (and text wise). Just take a look at this screenshot:
I will also try to make some more blog updates now in the future. So long. See you in the next blog entry.
Subscribe to:
Posts (Atom)