Dev Blog 110: Assessing Alpha 27, Rendering Performance through Tile Merging & Feature Voting

June 13, 2018

Good evening airport CEO and welcome to this week’s briefing! The development train is pushing forward and there are a lot of exiting stuff happening on multiple fronts. From the testing of the new UI on the experimental branch and Alpha 27 to a community wide effort in determining the next features to be implemented through Feature Voting, we really have a lot to discuss tonight and so let’s stop this into and get into the good stuff.

Assessing Alpha 27

Alpha 27.4-5 is currently being tested on the experimental branch and we’re receiving bug reports and feedback like never before! It’s a major change compared to the current Alpha 26 on the default branch and so we’ve definitely expected a lot of functions not behaving as intended. Over all, the feedback we’ve received is that the new UI is a lot better compared to the old one. According to the community it’s less clunky to use, looks better and performs better in terms of UI related script execution but also graphics rendering. The new UI also features a lot of new functionality as compared to the old one such as a flight process panel, which has been a much appreciated addition, as well as the incident tracking panel which will see a lot of interactive improvements ahead.

We still have several important bug fixes to implement and improvements to deal with prior to a default transition as Alpha 27 is not yet stable enough. This is currently our to priority and we’re aiming for a stable version that is compliant with a default transition within the next week.

Rendering Performance through Tile Merging

In previous devlogs performance optimization has been heavily discussed both on what we would call scripting optimization, when we improve certain parts of the code to run faster, and rendering optimization, when we investigate how to render objects and UI in the world faster. Ever since the early access launch we have been working frequently on both and it is a continuous aspect of our development model. As we’ve seen in a many bug reports and when doing some investigation recently, we discovered the origin to that large saves with a large terminal and taxiway structure had a huge difference in FPS between being zoomed all the way in versus zoomed out, which could be changes of upwards of 50 FPS in the editor. When doing a deep profiling on these saves, we could see that the CPU was spending a lot of time preparing the frame for the GPU. There were a lot of rendering processes within Unity which took a lot of time and the only thing that really made a difference was to deactivate a bunch of rendering components. The biggest villain was the terminal foundation structure, which consists of a four by four tile with a total of 16 floor rendering components. If you drag out a terminal 30 by 30, in four by four tiles, you will therefore get a total of 14400 rendering components which the CPU need to process and batch together for the GPU. Quite a lot to say the least… and of course, we’ve known of this issue since a long time ago and created a simplified merger system to merge similar floor types on the same terminal foundation piece (the four by four tile) so in theory we might get anywhere from 1000 to 7000 renders or so depending on the complexity of the floor layout. However, as our profiling showed, this fix was not enough. The difficult part of creating a more complex merger system was that we still needed to allow floor placement on the one by one tile to enable the player to fully customize the terminal flooring. We got to work creating a new kind of system that analyzes the terminal design and the different floor placement to then spawn large tiled sprite rendering components in the world as replacement for the actual individual floor objects. The system worked very well and was implemented on taxiways, sidewalls and concrete and asphalt tiles to further enhance performance. We are due to its success also currently working on implementing this merge system on zones, which will actually make the zone objects more or less useless. This is good news as we will reduce the performance impact of enabling the zone toggle as we as be able to reduce the loading and saving times since we no longer need to store individual zone tile data. We are still working on this as and it is expected to be released this or the next week on the experimental branch.

In the below test case which we ran for assessing the impact of the system, the FPS went from 23 to 50 in a large world and in the editor while being completely zoomed out during game night time, which is the heaviest rendering time as all the lights drains performance quite substantially. If you look closely, the pre-batching rendered count went from 19000 to 5600 which also reduces the load on the CPU greatly from 43 to 19 milliseconds.

Feature Voting

As of right now, you can join us on the Forum and help us decide what new feature to implement next! Prior to the weekend we enabled the feature voting category and opened it up to have it populated by the great ideas and creativity of the ACEO community. We’ve spent a lot of time planning and setting up this system and to learn how it will work in detail you should check out this forum thread. Right now, over 1500 votes have been cast and it’s really a pleasure for us as developers so clearly see what the next features you want implemented are. The voting will remain open for quite some time so you still have the option to join in, simply create a Forum account and check out the Feature Voting category and cast away.

Once the voting closes we’ll write a more thorough post-mortem of how it went and, of course, immediately update you on the development side of the selected features.

In Other News…

… we’ve also managed to take care of several minor tickets these past two weeks including setting up a repo for, and really launching the development of, the official Airport CEO Mod Tool (more on this in the next development blog!), transitioned to a new git repo for the main game’s code base as well as corresponding a bit with Sinephony (the music studio we’re working with for the ACEO sound track) and the UI/UX consultant who will aid us in further polishing the new UI.

We’ve also launched a new service, a public Trello board for following the development of Airport CEO live as issue are being transitioned through the pipeline. You can read more about that in The Airport CEO Development Pipeline blog post!

That’s it for this round, the weather in Sweden has been insanely hot for the past few weeks and we’re really happy to stay inside and code instead of having to sweat away on a beach (honestly). Fly safe, and don’t forget to vote on your next favorite feature to be implemented!

Related blog posts

Dev Blog 151: Businesses and contracts

May 28, 2020

Good evening, airport CEO, or something else depending on where you are! Welcome to the one hundred and fifty first development blog in the series and another update on what we...

Read more

Dev Blog 150: Stabilizing Alpha 35, Alpha 36 and beyond!

May 8, 2020

Well hello there, airport CEO, and welcome to the one hundred and fiftieth development blog! It’s been a little over another two weeks since we last spoke and we are very, very...

Read more


Enter your email to get the latest updates and news.

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.