vgvgf's GSoC blog

After some feedback from Max/Fingolfin in the devel mail list, my old inheritance based design of subsystems resulted to be not that good. Instead, Max Horn suggested that I should work with the actual structure of Managers.

Until now, I’ve moved the sdl graphics and mutex code to their new Managers class, and I’ve ScummVM working with these changes. However, the code still needs lots of revision, and I still have to do the same with events, timer and audio.

There are some problems I still need to fix, like where to place shared code between the subsystems or how is the better way for the managers to interact with each other.

So, this new week work plans are:

• Finish the sdl managers (audio, timer, events)
• Clean the actual code, and fix some actual code issues
• And start with the real sdl backend refactoring, as until now I’ve just started working on it and haven’t made much except from diving the actual code

This last weekend I fought to some linker errors in MSVC 2010. It almost gave me a headache, as I was trying to solve the errors for hours without many results. The solution today was simply changing to MSVC 2008 where all works well until now. I still don’t understand what is the problem with 2010 version, I’ll try compiling last changes in other ides than that MSVC later.

Regarding the sdl backend code to subsystems separation I’ve started to do, I’ve Timer, Mutex, Audio and File ready and also Events, but if I commit it now it will break the system as I’ve modified the already existent events.cpp. Now I’m finishing with Graphics sdl subsystem.

Now, the main problem is solving how the subsystems will comunicate with each other. For example, the graphics subsystem needs to know where the cursor is, for showing it on screen. But the cursor coords are stored and modified in the events subsystem. So I need to create a way for both of them to share data.

My current ideas for solving this issue are:

• Creating a new function in OSystem_SDL class that will send to each subsystem a msg. Then, each subsystem would interpret the msg if they need.
• Adding the shared data/functions as public in the virtual subsystems, and then calling/reading them from the different subsystems.
• Having the shared data/functions in OSystem_SDL.

I’m still thinking what the best option is, and if there are other better solutions to this.

I’ll make some changes on my coding plans. I was planning 2 weeks for designing the new Backend system based on Subsystems, but there isn’t much to do for that time, so I’ll start with the SDL refactoring along with continuing improving the new backend structure.

This way I find it much easier to work, as I’ve already the SDL backend to work with. So the next plans will be, first to separate all the SDL backend to subsystem classes and get it working. That will be more like a copy pasting work. After that is complete, I’ll start the refactoring of the SDL codes.

The idea and goal

My first task is refactoring the backend structure. It has to be designed in a way to improve portability and make it easier to modify.  Also, it has to allow an easy and fast way to use different libraries in platforms. This is mainly for making the next task, implementing OpenGL, easy to port.

OpenGL is only a specification for rendering, and does not include Audio playing, timers, devices detection, and else functions that a library like SDL does have. So, the goal is to be able to use OpenGL for rendering and SDL for the other tasks, or other libraries/sdks if needed.

Now, the idea is to create a backend structure based on independent subsystems. Then, we can use the audio, timer, events, and else subsystems from SDL, and use the rendering subsystem from OpenGL.

Planed design

Each backend, like for example the SDL one, will inhereit from its subsystems that already inhereit from their virtual subsystem classes. And each subsystem will inhereit from the OSystem class.

Example class diagram

In the example diagram, SubSystem_Audio, SubSystem_Timer and SubSystem_Video are the virtual structure for the SubSystem_SDL* classes. The virtual subsystems will inhereit virtualy the class OSystem, then OSystem_SDL will only include one copy of OSystem. In actual ScummVM code, OSystem_SDL overrides all OSystem functions; in the planed desing, the OSystem functions will be mostly overriden by each subsystem, and only initialization or other special codes will be included in the OSystem_SDL backend.

An idea I have in mind is also to separate the platform specify codes in OSystem_SDL, and create for each platform a new OSystem_*Platform* class that would inhereit the subsystems it needs. Then, we will have OSystem_Win, OSystem_Unix, OSystem_Mac, and else insteand of OSystem_SDL. This will help when implementing the OpenGL subsystem, as it will only be needed to change the inhereited video subsystem in the platform, and as the SDL name in the class doesn’t reflect OpenGL is being used.

I’m really happy for being selected as a student for Google Summer of Code 2010 in the ScummVM project. I have never participated in GSoC or a big open source project before like ScummVM, so this will be a really interesting experience.

This blog will act as my GSoC journal, here I will publish the advances I make through the project.