Project description

During GSoC 2019, I was working on adding support for original versions of Red Comrades 1: Save The Galaxy (1998) and Red Comrades 2 : For the Great Justice (1999) games developed by S.K.I.F.

 

Goals achieved

Red Comrades Engine:

Pull Request

Engine branch

Red Comrades Demo is fully supported.

Red Comrades 1: Save The Galaxy (1998) and Red Comrades 2 : For the Great Justice (1999) are runnable, but are bugged due to no implementation of walking system.

During reversing I have encountered problem with walking system, because it is very large and complex. It uses more than 30 functions. For comparison, the dialog bytecode interpreter uses only 17 functions.

Advantages over original engine:

• Low CPU usage. The original engine doesn’t have delay after each frame despite the fact that dirty rectangles are implemented in it.
• All advantages which ScummVm offers(scaling, cross-platform, etc)

ScummVM’s library:

During GSOC I have improved INI reader class in ScummVM.

• COMMON: added support for reading ini files with different 8bit encodings

• COMMON: fixed reading ini files which have not value for key 

• COMMON: fixed reading ini files with section containing more than one word

Future work

• Make games fully playable
• Maintain Red Comrades engine during its testing period
• Add another engine to ScummVM

Code

The code for Red Comrades Engine is in the repo:

Engine branch

The commits that I made:

Commits

This week I have been preparing engine to merge with ScummVm’s main tree and reversing walking system.

 

Some ini files in games are invalid like this:

Also ini files have CP-1251 encoding, which makes them unreadeable by ScummVm’s ini class. So I have created pull requests(1, 2) to fix those issues.

Also, I have implemented saving/loading system.

Saves in those games have such structure:

Considering the walking system, I continue to reverse it. I have encountered some problems with it, because it is highly connected with other parts of the engine, so I  review other parts and add things that I have missed earlier.

But this is only the one thing that has left. After implementing it the engine should be playable.

I will create the engine pull request when the pull requests concerning ini reader will be accepted.

This week, I have been implementing:

 

1. Map interface
2. Events handling
3. A lot of opcodes

For now, there is only left to implement about 10 opcodes. Most of them are related to the walking system.

After implementing walking system, along with saving system the games should be playable with some bugs.

I have recorded some gifs to show the current state of the engine.

 

 

This week I have been ending reveresing of the engine.

 

For now only walking system is left to reverse. Considering its complexity I will leave it until I implement things that have much more priority.

What’s left to implement:

• Map interface
• Some opcodes
• Sequence interface
• Saving/Loading

Given that I know how these things work, I will implement them very fast to the end of GSOC.

Currently engine can play demo without any problem, execute intro of the first game, probably the second game intro can also be excecuted, but I haven’t checked it.

This week I have been reversing action and inventory systems.

 

Action system

There are 7 action types:

• LOOK
• WALK
• USE
• TAKE
• TALK
• OBJUSE(HERO 1)
• OBJUSE(HERO 2)

All of them are processed using opcodes.

Inventory in this engine is array of item IDs.

There are 3 opcodes for inventory:

• ADDINV – adds new item
• DELINV – deletes item
• SETINV – replaces the current item with another

The item id is then used to show the item sprite and used in OBJUSE handler.

This screenshot shows the fixed font rendering along with star object, which is used for choosing action type.

There is only left to reverse InterfaceSequence(don’t know for what it is used) and walking system.

Considering code I need to clean it, end what hasn’t been transfered from disassembly and prepare engine for merging.

This week I have been reversing text classes in Red Comrades engine.

 

Although, the text doesn’t render properly for now. There is a problem with font. It seems that ScummVm’s fonts don’t support cyrillic letters.

The engine consists of 4 text classes:

• QText
• QTextDescription
• QTextChoice
• QTextPhrase

QText is a base class for other classes.

QTextDescription is used to render text about item.

QTextChoice is used to make choice.

QTextPhrase is used for dialogs. It monitors the sound and notifies dialog manager when sound ends.

The text in game is stored in Windows 1251 codepage. I have used the converting funtion which I had written last year for Pink Panther engine.

I have also polished dialog manager, so the intro can be continued.  However, intro is bugged because heroes are not implemented. So they are not rendered and walk is skipped.

The plan for next week is to fix the problem with font if possible, start to implement heroes, and reverse the inventory.

This week I have spent all time reversing dialogs bytecode format.

I have almost reversed and implemented it.

Let’s look at opcode format.

The opcodes in dialog format have size of 4 bytes. 

There are at least 10 opcodes:

• BREAK
• MENU
• GOTO
• MENURET
• 0x05
• RETURN
• PLAY
• CIRCLE
• 0x09
• 0xA

For example, PLAY opcode contains index of struct which contains speaker id, sound  name and subtitle. The engine executes this opcode and when the sound ends the next opcode is executed.

For now the only thing that I doesn’t understand why the file with dialogs contains data which is not used. But I assume this was used to display some useful info for developers.

Small video showing the current state of first game scene.

The next week I plan to implement drawing subtitles and polish dialogs, so that intro dialog in first game scene can be continued.

This week I have fully implemented demo and started reversing dialogs.

 

Earlier the demo had problem with rendering 1-bit monochrome bitmaps because ScummVm doesn’t support them, I have made a little hack. All 1-bitmaps in those games are black, so instead of implemeting support for them the engine creates black surface.

The second problem was that some scripts hadn’t worked properly. This was due to handlers which had more than one PLAY opcode. When the PLAY opcode executes, the opcodes after it should wait. After animation ends END opcode is sended to object and it continues executing opcodes after PLAY.  The same algo is used when walk opcodes are used.

Also, this week I have added support for 5 new opcodes:

1. PASSIVE
2. ACTIVE
3. SHOW
4. HIDE
5. SETPOS

Now, the first game scene can execute startup scripts without dialogs.

Dialogs in game are the most complicated part. They are using bytecode.

I have fully reversed file format where dialogs text with sounds are stored.

The format is pretty simple and standard. The only trick is that strings are stored at the end of file rather than as pascal string. The same trick is used in the game archives.

This is structure of the file where the bytecode is stored. Each object in the game can have dialogues handlers which are selected by message opcode which was sended to them. These can be obj use, taking item, etc.

The bytecode part isn’t known to me. I only know that each code has 4 bytes and first byte seems to indicate kind of operation.

The first month of work is ended and I have implemented the game demo.

 

The game demo is just advertisement intro, which consists of several game scenes.

To get this demo working I have implemented these opcodes:

• GOTO – changes game scene
• ZBUFFER – sets z coordinate
• STOP – shows or hides cursor depending on first argument
• BGSFX – sets fx id to background
• ON – shows object
• OFF – hides object
• SET, PLAY – starts sprite playing.

Unfortunately, some opcodes aren’t implemented which leads to some problems in demo. These include END opcode and IMAGE opcode. IMAGE opcode actually isn’t needed. It is used because game script file always starts with heroes objects, which aren’t used.

Also, there is a problem with 8 bit BMP, because game uses a bit modified format, which leads to problem when scene changes to BMP, which isn’t actually loaded.

Next week I will polish the demo and start to implement dialogs, which are essentially needed for game. Most of scripts can’t be executed without it.

This week I have ended implemeting settings menu, which wasn’t so hard to do, and started implemeting the game itself. For now it can start new game through startup menu and then play intro video which starts because of AVI opcode.

The next week, I plan to implement some opcodes, so the game can be continued after the intro video.