Category: Uncategorized

Hello again, we are into the 3rd week and I spent the last week working to finish the inventory and we are almost there. So, the inventory has four states depending upon how long the inventory item has been clicked for and where on the screen the click is recorded. In simpler terms-

• If the user click outside the inventory, the inventory is to be closed and objects wiped out until we click the inventory again.
• If we click on the item, check for how long we clicked and if it crosses a threshold, set it for drag(which we’ll later use to check for dragging). But there was a challenge while I implemented this. _mouseB is a variable that stores the mouse state and we use it to check if there was a mouse input or not. But the problem was, _mouseB is being reset in the mouseEngine() function that caused the timer to increment on each click rather than incrementing on hold. So, to fix this, I decided to query the mouse state from the EventManager directly.
• When we make a quick click on the item, it runs an examine script and throw a text description of that particular item on the middle of the screen.
• The final part is dragging the object to use it. For eg, to open the fire exit, we drag the bar to the door. I am currently working on it’s implementation.

And, if you remember from the first blog, we had converted the engine to 32-bit and we talked about the main game screen that was an 8-bit buffer and we merged them together before the screen output. The control panel has a separate screen and naturally, it was also an 8-bit screen. When the menu was built in an 8 bit buffer but passed directly to a 32 bit renderer, we got this-So naturally, just like with the main game screen, we let the menu to build its 8 bit layout but merge it before rendering.

Currently, I am working on the dragging part of the inventory items which I will brief about in the next blog.

Thanks for reading 🙂

We are into the second week and the last week went primarily working on the LINC inventory and spawning regular inventory items. As opposed to BASS, the inventory shows up at the left bottom of the game window, like this-

Currently, as you can see, there’s a transparency issue in the icon that I am trying to solve at this moment. Coming back to the inventory, the first item inside the inventory is joey’s circuit board just as it is in BASS. Same goes for the bar which is used to open the ‘FIRE EXIT’.You can see the inventory items in the images above.

Since the regular inventory’s behaviour is not yet implemented, we can’t currently go past this scene to hack into the LINC terminal. This week, I will be working on it and in the next blog, I’ll be briefing about it in a lot more detail.

Also, you might have noticed a very minute detail in the last blog where I posted the screenshot of the icons spawning. In that image, the icons were inverted. It didn’t catch my eyes until i drew the inventory and it was also rendered in an inverted position. Same goes with joey’s circuit board. I worked on it for almost a day just to find that in the original sources of ibass, it was reading the bitmap in the reverse. I did some research and found out that most bitmap files store pixel data upside down i.e. bottom-to-top, starting with the left bottom corner of the image, as opposed to how graphics APIs expect texture memory to be, i.e. top-to-bottom, starting from the top-left corner. I fixed the behaviour and now the icons are rendered like this-

Thanks for reading 🙂

We are into the first week and I have a lot of work to brief about which also includes the work done before the official start of gsoc.

For ibass, I started off by adding it to the detection table. Unlike og bass, ibass doesn’t have a separate file for the dinner table entries. Hence, adding it to the skyVersions[] array seemed a bit incorrect. So, I created a separate PlainGameDescriptor for ibass.

After the detection, the next milestone was to make the game start. But the problem was, the UI icons used in ibass are 32-bit images but our sky engine was 8-bit. So, what I did to solve this mismatch was turning the engine into a 32-bit one, keeping the game screen separately at 8-bit and clapped them together before the output.

I have skipped the intro for now because it has a separate video for the intro(and for the outro too). I have saved it for later.

The next natural step was to overlay the icons. To load the bitmaps, I ported the loadAnim() function from the ibass sources and wrote an icon renderer that we then call from our screen compositor. And finally, we have the icons rendered on our screen-

Next step was to trigger the respective actions for those icons. Upon a click, it incorporates something called “_actionFlash”. When we click, the “_actionFlashTime” starts decrementing if _actionFlash is set. So, it gives a flickering effect to the icon until _actionFlashTime becomes zero. It happens like this. As you can see, when _actionFlashTime is even, the icon is cleared and vice versa. In the game, it looks like this-

Thanks for reading 🙂

Hello everyone, I am Priyanshu Kumar and I will be porting the iBASS engine to ScummVM this summer as part of the Google Summer of Code. In this post, I will be covering a little background of this task and what exactly needs to be done.

By “porting”, we usually get an idea that it must be about an engine that needs to be ported and integrated to ScummVM in order to get the games based on that particular engine running through ScummVM. iBASS is not any different but still a lot different.

Sky engine is one of the oldest engines to be supported by ScummVM and the most popular game it powers is Beneath a Steel Sky. This engine was created by Revolution Software in 1994 and ported to ScummVM in 2003. Later, Revolution Software created a remastered version of the game in 2009 with enhanced UI controls for iOS which they built on top of ScummVM’s sky engine.

So, the goal of this project is to port(you may call it “backport”) the changes done for the remastered version and integrate them with ScummVM’s Sky engine to make the remastered version(iBASS) playable on ScummVM. The efforts have already been started and in the next post, I will be briefing about the progress.

Thanks for reading.