Category: Uncategorized

Welcome back, the CgBI decoder is up and loading the assets wonderfully, see-

I am currently rendering text on it which is too close to be completed too. The text is rendered like this

I have already ported the required infrastructure for the hint system that includes methods like setSeenScreen and hasSeenScreen which, as their names suggest, sets the screen to true and tells if the screen is set respectively. It tracks that using a boolean array _seenScreen. Similar methods and array are there for the hint answers too. The hint lookup table is almost completed too. You’ll see that in the next blog.

Once the hint system gets implemented, I will most likely be moving to the implementation of the intro and outro videos. After that, I’ll implement the audio.

There’s hotspost too which is yet to be implemented. So, I’ll have to do that too. See you next week.

Thanks for reading 🙂

As I mentioned in the last week’s blog, the game assets have CgBI PNGs in it which we need to decode.

Initially, I thought about converting it to a standard PNG to have the PNGDecoder decode it but since we have the raw pixels extracted, we can just draw the surface.

How different is the CgBI format than standard PNG

Apple had created this format to optimize for the native pixel format of the iPhone’s early PowerVR GPUs. It contains significant differences like-

• An extra critical chunk(CgBI) – Right after the 8 byte standard PNG header and 4 bytes for length, CgBI format has also a CgBI type field from bytes 12-15.
• Swapped pixel format – Instead of a standard PNG file’s pixel format, i.e., RGBA, CgBI format has the pixel format swapped to BGRA. The red and the blue channel are swapped, presumably for high speed direct blitting to the framebuffer.
• It contains raw deflate data. It has the zlib header, footer removed from the IDAT chunk.
• It has every channel pre-multiplied with the alpha channel.
• Pre-multiplied with the alpha channel during encoding: color’ = color * alpha / 255

I have extracted the raw pixels by removing the CgBI header, un-premultiplying the alpha channel and swapping the red and blue channel all while working on raw deflate data. Next, I will be drawing the surface and we’ll have the help window displayed on our screen. The immediate next step after that would be to render the help contents on it. Hopefully, I will be briefing about that in the next blog 😉

Thanks for reading 🙂

We are past the mid-term now which means half of the GSoC season has come to an end and we have started on the second half. I overlayed the “Options” icon and the “Help” icon.

The wrench is for the “Options” that’s essentially the control panel and the help icon is for the hint system. It has a bunch of questions depending upon the part of the game we are in and a few hints for that question.

For an example –

Q – The Firedoor is locked – how do I open it?

A – Get the rung from the top of the stairs on the left of the gantry.

Open your inventory and use the rung on the fire door to lever it open.

The original source code uses a huge switch block to map the questions to the answers. I will be taking the same approach when I implement the text in ScummVM.

So, we load the help window and render the text on it.

But another challenge comes just at that point. The game assets are not standard PNG files but rather, a non standard variation of the PNG format optimized by Apple for iOS devices. It is called the CgBI format.

Since we depend upon libpng to decode our PNG files, CgBI files cannot be decoded since libpng doesn’t support them. To tackle this issue, we have decided to write a CgBI to standard PNG converter. We already have a program to do that which was shared by my mentor, @DJWillis.

I am currently studying it to understand how it’s doing it since I have a very limited experience in decoding.

Once I understand it, I will port it to ScummVM in the image/ directory where all the other image format decoders live, so that it can also be used in the future for any other games if needed.

After we have the decoder and we load the empty help window, we will proceed with adding the text.

Thanks for reading 🙂

Welcome back, happy to be writing back after so long. I’ve got myself on the work again and there’s 2-3 days of progress I want to brief about. But before that, I must inform that the initial PR for iBASS support has been merged(it was merged while I was away), which means that now you can play iBASS on the debug builds. All you need to arrange are the game files. Continuing the efforts of porting, I implemented the text chooser(the PR is currently opened). But first let’s understand what exactly is the text chooser.

Text Chooser

See the questions at the top. When we talk to the NPCs, a list of questions in this form appears. We have to select a dialogue from this list.

This is how it works.

The PR is currently opened. Once it gets merged, you’ll be able to use this feature.

The silent killer

Day before yesterday, while I was implementing the text chooser, the game crashed on starting. I was lucky that I had run that time with gdb so I recorded the backtrace-

Thread 1 “scummvm” received signal SIGSEGV, Segmentation fault.
0x000055555924128a in READ_UINT16 (ptr=0x55555ed36000) at ./common/endian.h:209
209 return ((const Unaligned16 *)ptr)->val;
(gdb) bt
#0 0x000055555924128a in READ_UINT16 (ptr=0x55555ed36000)
at ./common/endian.h:209
#1 Sky::Disk::getFileInfo (this=0x55555e4a7640, fileNr=60600)
at engines/sky/disk.cpp:310
#2 0x0000555559240c60 in Sky::Disk::fileExists
(this=0x55555e4a7640, fileNr=60600) at engines/sky/disk.cpp:169
#3 0x000055555922e5c6 in Sky::SkyEngine::init (this=0x55555e48dec0)
at engines/sky/sky.cpp:462
#4 0x000055555922f0f1 in Sky::SkyEngine::run (this=0x55555e48dec0)
at ./engines/sky/sky.h:130
#5 0x00005555560e808c in runGame
(enginePlugin=0x55555d3d2f60, system=…, game=…, meDescriptor=0x0)
at base/main.cpp:328
#6 0x00005555560ea70d in scummvm_main (argc=1, argv=0x7fffffffde28)
at base/main.cpp:840
#7 0x00005555560e4d84 in main (argc=1, argv=0x7fffffffde28)
at backends/platform/sdl/posix/posix-main.cpp:56

the getFileInfo function reads from a variable named _dinnerTableArea that is never written to in iBASS since iBASS doesn’t have a separate sky.dnr file.

So, the game starts successfully most of the time because it contains garbage. If it doesn’t, the game crashes. To fix this, I used the getEntry() method.

That’s all for this blog. See in the next post.

Thanks for reading 🙂

Hey there, welcome back to the blog. The inventory is fully implemented and hence, we’re now able to drag the rung and open the fire exit, hurray.

Other than this, there’s no way to get out of this scene(except if you use the debugger console 😉 ).

Also if you notice, I have revived the original cursor of Beneath a Steel Sky here too.

Ever since I started the development on iBASS, I had turned the engine to 32 bits for both BASS and iBASS. Since the original beneath a steel sky featured an 8 bit colour depth, sev suggested to revert it back to make BASS run in 8 bpp mode which I successfully did. Now, BASS is running in 8 bpp and iBASS in 32 bpp.

There was one more crash I encountered at this phase of the game-See the cursor at the right edge of the window? That is the exit. But when I clicked on it, it hit this assert. To fix this, I guarded this call to never draw out of the boundary of _screen32.

I also performed some refining in the LINC terminal.

Major tasks that are still left to be done include implementing the text chooser. Here’s a snippet from the original Beneath a Steel Sky regarding the text chooser-

Currently, we cannot do this in iBASS. Some other tasks yet to be done include fixing the transparency issue in the inventory icon, render the cog icon for the control panel on the top left, etc. All this while we have no audio yet along with the intro and the outro.

Also, I had an important announcement to make. I’ll be away for the next few weeks due to some personal reasons. As agreed with my mentor, I will be unavailable from 13 June to 3 July. I’ll be catching once I return. Thanks, and talk to you all in a few weeks.

Thanks for reading 🙂

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.