Doombringer's adventures

Another week pass, with a lot of breaking and fixing. The good part is, I am really getting used to this.

The first one was a obvious mistake, I forgot to increase the iterator I use. When you try to exit, the removeAllScripts function is called, and it tries to free the first element a second time.

Second one was a save load problem. I was using iterators, and checking if the iterator equals to end(), but loading creates and adds a new node in every loop, so it never ends. Since the number of elements is written in the save file, and read before the loop, I just changed the check in the for body.

I have worked on ctp.h/cpp this week. Player walk logic is in it. There were too many global variables used, so I decided to form them into classes. I have created two classes, one for walkbox and one for routes. I manage to move most of the globals, and move to Scripts.h/cpp unaware of the lurking problems.

This was a smooth week for me. I had no big glitches, no unpretictable segmantation faults etc. I worked on different parts, but the most important class I created is the Stack class.

There was a implementation of stack in stack.h/cpp, but fingolfin leave a TODO comment that suggest replacing with Common::Stack, so I did that. I had seen code parts using Common but this was the first time I did. The stack was used for both int16 and void*. There is a union of those two, and a enum for type, capsulated as stackElementStruck, so it uses spesific pop and push functions. first I made it a class, and added constructors for both possible data type, then created a new Stack class, inherited Common:Stack, and added pop & push methods to it. It is pretty straight forward, but it feels better integrated.

I am thinking about using Common::List for some of the parts I already worked on, but it has to wait after midterms, which is this week.

This week was a little sad for me. I have started working to make use of Cell lists head, but in the end, I have to backup, and postpone it until GSoC midterms.

I started with modifying the add and remove. But of course it did not work out as expected. I had a lot of faulty assumptions. First of all, add does not always adds to end of the list, and it was obvious actually. I knew Remove does not have to remove from last, what I did not realise was, removing head is not an option. After every modification another problem emerged, and of course a lot of segmantation faults. After days of working, I manage to fix nearly all of the problems, except unable to save or load, and an odd rendering issue. Some of the objects were rendering in wrong order. I tried everything I can think of on sorting, but I could not found the origin of the problem, or anything wrong in the code. On that point I feel I do not have a choice, but surrender.

This week I worked on some list strucks. First one was backgroundIncrustStruct, that holds previous and next pointers, and the variables that composes backgroundincrust. I thought having the list and the class together complicates code too much, so I decided to split it in two. I had some concerns but everything worked out, and I decided to go on, trust the original engine developers.

This was my last week of finals, so I expected to speed up, but things does not always work out as you expect, are they?

The problem started when I need to merge the upstream(main ScummVM repository) changes. Updating the master branch was pretty easy since I did not do any changes, only a fast-forward was enough but when it come to rebasing my working branch, things get complicated.

I have pushed my first commit to github this week.Althought it seems quite big (~300 lines), it is variable rename mostly, no real coding was done. Even this commit made working easier, experimenting is fun, and it makes me feel that I am making progress.

I am going to modify some smaller files this week to speed up, and hoping this way I can clear my way of thinking about objectification a little more. Getting small parts done also can make further modifications smaller, and easier to understand when anybody wants to study them.

I am also thinking about writing down a new schedule. Since I changed my approach to project, my old timeline is useless for first 7-8 weeks at least. Having a schedule, and milestones, deadlines for that milestones helps keeping motivation high.

I have been doing some reading this week. I start reading Cruise Engine source, and looked around for older objectifications on side, starting with AGI engine. After seeing how the old objectifications were made, I began to question my approach to the project.

I was thinking to read all the engine code, before determining the classes etc. But as far as I saw, AGI was objectified step by step, objectifying one file in the step, and modifying only the ones that needs to. This method makes more sense to me considering several reasons.

I haven’t written anything in this blog for a very long time, and since I have been selected to participate in Google Summer of Code, it seems to be a good time to get back.

It is a great opportunity to be a part of GSoC, but joining ScummVM is something that even my little sister got excited ( I told her, I will be working with people whom made monkey island work on her computer). I am at the beginning of everything right now. I haven’t even read through the engine code, yet the scummVM code base. I don’t know how to proceed, I don’t have the game I am supposed to work on. On the other hand, this is how anybody starts working, isn’t it?

My project is to objectify Cruise engine. the cruise engine is a modified version of the cine engine, and used in the game cruise for a corpse. It is already a part of the scummVM, but written in plain C. I am going to be working on this all summer, and posting new entries frequently so anybody interested can keep an eye easily.