It has been only almost 3 weeks since I released BRIX 0.0.2 and I have already recycled it’s sprites. If you liked BRIX maglev, the new PURR tracks are basically the same, with colours and custom tunnels!

You can find it on the content download, BaNaNaS.

Why update now?

PURR 0.0.3 has been out there for quite a long time already, and eventually it just got absorbed by the monstrous NUTS Unrealistic Train Set, later justified by adding engines directly influenced by PURR (the MEOW class).

Since then the only utility of PURR is when you use it with train sets other than NUTS. Which is still nice but makes it kind of semi-useful for us as we use NUTS in most games.

Now PURR has a new reason to exist – NUTS does have it, but not in 32bpp. If you want 32bpp, you need to add standalone PURR. It won’t break any functionality, just add graphics.

What is new?

As hinted above, PURR is now 32bpp with extra zoom which makes it super compatible with BRIX. Apart from that it also has new railtype tunnels exclusive to PURR.

The tunnels almost require BRIX to be around, otherwise their terrain won’t fit. Luckily there is a parameter so you can turn the tunnels off. That does not cause tunnels to disappear, base set’s tunnels for rail will be used instead, just like they always have in earlier versions of PURR.

There should probably be another parameter which would only define the ground to select compatibility. Maybe some day.

I think there was also some mess in functional compatibility to the PURR in NUTS – some railtype IDs were different or whatnot. Now I just literally copied the PURR code from NUTS so it should all be fixed.

Conclusion

Per usual I expected this to be way simpler, easier and faster to do, and per usual I found myself to be majorly wrong. Level road crossings were so much wtf that I actually left them alone, maybe I can gather more mental fortitude and give them another try sometime in the future.

I was obviously thinking about updating NUTS with the new PURR, but there isn’t really that much point. NUTS is a mostly 8bpp NewGRF except slugs, and that’s how it should stay. Not to mention that it would be another 15MB extra filesize that you can download separately.

In the end I can say that PURR again has a purpose and is updated to work properly.

What is BRIX?

BRIX Realism Is XXXX is purely visual graphics replacement NewGRF aiming to add 32bpp and x4 zoom level graphics to the game, while maintaining compatibility with 8bpp graphics. BRIX does not and will not do any changes to functionality – that way you can load it as a static NewGRF. Static NewGRF means you are using it as a base set add-on, and you can use it locally even when joining multiplayer servers, without the server actually enforcing the NewGRF to be used by all users. Learn how to use a static NewGRF here. You can find BRIX repository at the openttdcoop devzone project page.

You can customize which parts of the game should BRIX replace by parameters, which is especially useful when you for example get used to the train signals, and want to use those on all servers. Then you would just use a static NewGRF with only signals enabled.

BRIX is available for download on OpenTTD’s download content server through the game.

You can download various reduced versions of BRIX – without extra zoom or 32bpp, in case you want a lightweight version. The official BaNaNaS release is full 32bpp / extra zoom though. Even there you can still force 8bpp blitter through OpenTTD config file.

Along with BRIX I release a standalone 32bpp->8bpp png conversion script I call RGBA EATER, I will mention more about that further down below but you can find more info about it here.

Why?

The main purpose of BRIX is to create a 32bpp/EZ NewGRF, which would be visually compatible with other 8bpp NewGRFs.

32bpp vs 8bpp conflict

Ever since 32bpp/EZ exists in OpenTTD, each of 32bpp/EZ projects arrives to the same problem. People start using it, they declare they would like to have everything in 32bpp/EZ, and then they switch back to 8bpp NewGRFs because they refuse to throw away all the years of 8bpp content that there is available.

The big problem is that even if a 32bpp/EZ set was done excellently well, people would always want to return to their favourite train/industry/… sets in 8bpp. Reworking all NewGRFs into 32bpp is outright insane as that would be both too much work, not every author would like to do it, and the results might not even be visually better.

That’s why I believe it is essential to develop a 32bpp/8bpp NewGRF not as a superior replacement, but as a complementary thing to other 8bpp NewGRFs.

There are two sides of 8bpp compatibility to look at, one of them being purely visual, and one of them being functional. Visual side is that it either looks reasonable together or it doesn’t, I will describe that later. The functional part would mean that the 32bpp/EZ NewGRF provides proper 8bpp sprites. As you might be aware, 8bpp sprites are a mandatory part of every NewGRF, and 32bpp/EZ sprites are just an extra, an alternative.

However, converting full RGB to 8bpp is not as easy as it might seem at first thought, and most sets get to ignore it completely or provide really broken graphics.

The best case is when the NewGRF has always been 8bpp (zBase, NUTS, …) so it already has all 8bpp hand-drawn sprites, but obviously that is only the case for older NewGRFs, new projects are very unlikely to draw both 8bpp/x1 pixel art, and render or paint 32bpp/x4 pictures.

This lead me to writing my own python script I call RGBA EATER, which does the 32bpp -> 8bpp conversion for me, and I am sharing it so that any other 32bpp project can make use of it.

The RGBA EATER alone is a gigantic step forward for me. Not only it is a tool which totally redefines the problem of 8bpp conversion for me, but I also spent almost a month writing it and learned many new things about Python.

You can find more info about RGBA EATER here.

Available base sets

I have always been a big fan of TTD’s original graphics from 1998 by Simon Foster. To this day I firmly believe that it’s an absolute masterpiece. When I started drawing NUTS several years ago, TTD original graphics were my main source inspiration for pixel art techniques. The deeper I looked, the more I liked it.

On the opposite side, I find OpenGFX and zBase both have major visual issues. With all respect i have for Zephyris putting so much work into making them, OpenGFX I don’t consider great, but it does it’s job – ability to redistribute fully functional OpenTTD as open source. With zBase I thought 32bpp/EZ is just a bad concept but I was always intrigued if that’s really the case so I was trying to identify the problems…

There are many issues, suddenly everything looks bland, dead and without personality, totally unlike the vibrant TTD pixel art.

On the first look you can say “well 32bpp is just more colours, how can more colours break anything, and ability to add pixels is obviously better?”.

It’s not an easy problem to grasp properly. In my eyes, first of all looking at x1 zoom makes you imagine the rest of the details you can’t see in the pixels, assuming they are there. However if you make the same picture with 16 times the amount of pixels, you really need to have a lot more detail there, otherwise our eyes can see that there is no details and they can’t be fooled into trying to imagine the detail because they know it isn’t there.

The second half of the coin, 32bpp, is actually much harder to draw consistently than in the indexed colours. The palette is a great ruleset for all NewGRF authors – as long as everyone “obeys” the colours of the palette, everything looks relatively compatible. With the freedom of 32bpp comes a lot of danger because of this.

Another issue I think comes more from the way how the graphics are made – if you want to make 32bpp/EZ graphics, it starts being very appealing to use 3D modelling software. That typically completely removes the human touch on every pixel that pixel art has in extreme levels. Especially since orthographic rendering can be very inconsistent in rotations and have other weird issues, it’s vital that the sprites at least go through Photoshop for careful postproduction.

Trying it myself

After some time of rejecting 32bpp/EZ, I made YETI Extended Towns and Industries which made me want to try to replace the terrain for the industries to match with. Eventually I started attempting to make a “base set style” NewGRF with RAWR Absolute World Replacement, but it did not have this mindset of 8bpp compatibility, and RAWR’s 8bpp mode was basically utterly broken (about as bad as BRIX 0.0.1). After a long time of working on it, I abandoned the project mainly because of these conflicts, apart from the workflow getting stupidly complicated by attempting to replace all 4 climates with unique graphics.

BRIX is the successor of RAWR, but this time focusing mainly on 8bpp and x1 zoom compatibility, quality over quantity, and clarity.

Finding BRIX style

Figuring out how to do things technically can be challenging but step by step you can relatively easily find solutions. When something doesn’t work for you, it’s quite clear. However finding the style of how should something look is a whole different story that doesn’t have clear answers and finding what BRIX 0.0.2 is today has consumed a lot of brain cells and time. Here I am going to attempt to describe at least some of the paths and how I arrived to the concept of BRIX as version 0.0.2 is today. I hope you can see some difference between the following two pictures:

Focus on large-scale gameplay

As many of you know, I have been a big part of a community known as openttdcoop, based around building giant train networks. All of my NewGRFs are obviously targeted mainly at this group of people as it’s basically a reflection of how I perceive the game and how I personally play(ed) it.

When looking at the large track mazes and tangled constructions, it is massively helpful to be able to distinguish every type of signal, state of the signal, have track graphics work properly, clearly see slopes/elevations, and so on. Most of the time we spend in x1 zoom because we can’t see enough things in x2 / x4, however for people with high pixel density displays x2/x4 becomes very useful.

All of this I am trying to reflect in BRIX by all of the designs being very clean and clear, having only the amout of info you really need. The rail signals are a typical example. Even though they are a bit too monolithic and massive to me, they clearly show their type and state even at x1 zoom and the big gray structure works as a margin so the lights are even more visible. And as we all know, train signals are one of the most important things in this game to see and understand.

Ultra-clean style vs. textures/noise

RAWR was relying on textures in an extreme way – most of the models were flat surfaces with textures defining a lot. This made it look attractive (doesn’t have to mean good) with relatively little effort, if you ignored tiling issues and generally ugly patterns. But these issues were really noticeable when building because rails are very susceptible to imprecisions. Obviously I wanted to fix it, but unfortunately this whole texture-based approach made it very hard to improve and generally caused the whole workflow to become very messy.

So the obvious outcome was that I tried to start a new project – BRIX – and set an opposite extreme aim for myself to not use any textures at all. This trend lasted until BRIX 0.0.1 but after playing with it for a little while I realized that the clean look is just boring and lazy from me. It’s not just that but I also find that my eyes would hurt more after looking at it for not too long period of time as they would unsuccessfully search for little details to observe.

How long did your eyes comfortably stay on the left and on the right? Apart from being boring, ultra clean style also makes many things much harder. If everything is noisy and organic, you can’t really tell if the tunnel, tree or anything else is geometrically precise and your eye can get tricked much easier. Since many things in OpenTTD are just visual hacks, like tunnels having fake height, adding noise helps a lot – not just by looking better overall, but with hiding problems.

I also find that the noise brings some more visual resemblance to original x1 TTD graphics which I really like.

Colours

One of the original BRIX concepts was an attempt to make a hierarchy of saturation. Less important things for the gameplay would be desaturated, while the more critical things would be very rich in colour.

Today this concept has matured to be less extreme than the initial tests, but this logic still stays. There has been a lot of experimentation and talking to other people about the colour of grass for example. The question is, what meaning does grass have? In this game it’s just an empty canvas for us to build things on. To convey the information of emptiness and hint to fill it with things, I am fairly confident about the decision to make grass in grayscale. Later on I also realized that it makes it extremely friendly with 8bpp conversion as the palette has a lot of grayscale shades.

One of the reasons why I abandoned white grass was that it started to be rather hard to define the colour of snow. In the end, the logic of snow/desert to me is that it already has some impact on the game, so giving the feeling of snow/desert is meaningful. That makes snow get a cold blue, and desert a hot orange as you would probably expect. Water is blue but not too bright as it is not very important, it mostly just means an obstacle aka “hole in the empty canvas”.

Terrain variety and trees

It is not easy to give variety to OpenTTD’s terrain. This is mostly caused by every slope of a tile only having one sprite without any random variations. The only random effects are rough tiles, rocky tiles, and trees. For various reasons BRIX mostly omits rough/rocky tiles for now so the only random variety is trees.

BRIX 0.0.1 had white trees which didn’t look that great, with 0.0.2 I did a lot of experimentation and arrived to generally desaturated trees from the ground, getting more colourful at their tops to give some sense of height, especially since BRIX trees are very small compared to original TTD/OpenGFX trees. Trees only give terrain variety when you can see them – and most large-scale builders hit X all the time to hide things they don’t want to see. Making them smaller motivates the player to hide them less I hope, and that way get a nicer view more often.

Absence of proper trees were also one of the main reasons why BRIX 0.0.1 was not very nice to use with other than temperate climates (it wasn’t really nice with temperate either, but well…), defining all trees in all climates is massively helpful for 0.0.2 to even resemble a complete product.

Gridlines

I used to like terrain without grid lines because it seemed more natural in some way, but from BRIX 0.0.1 it removed even the last piece of detail that the terrain could have..I find grid lines also help to see the elevation slopes of the terrain as brighter/darker tiles don’t have to be enough sometimes, especially if you have a lot of things on your screen. Overall it just makes it harder to navigate and guess proportions of areas so I am returning to a visible grid in all ground tiles since the purpose of BRIX is functionality.

Graphics production workflow

The basic formula for the pipeline of BRIX is a 3D model being rendered in a 3D application, and the pictures processed by After Effects.

Most people don’t understand why do I use After Effects for post production but this is the place where I make sure that all things are systematically correct in a re-renderable, automated manner with the interface of a graphics program.

BRIX 0.0.1 is a perfect example of how the outcome of this looks. A basic, but systematically working thing. Careful grouping, instancing, referencing and material management along with V-Ray’s rendering rendering possibilities in 3DS Max made for a robust and rather editable 3D environment. In tandem After Effects organizes the renders so that things which should look exactly the same, look exactly the same. For example straight rail and straight rail overlay for junctions are exactly the same because the overlay is just a cut out from the straight rail tile, and so on.

There are various issues with this workflow but the biggest issue is the aforementioned lack of human touch and detail. Tunnels don’t have enough contrast, terrain looks empty. Masking is done by vector masks which feel sterile and for complex masking tasks like tunnels insufficient. Apart from that, controlling scaling algorithm in After Effects is basically impossible.

Since I have been using a Wacom Intuos tablet for Factorio ever since I started working on it, I started to realize how important it is to edit sprites with Photoshop, and eventually I tried the same with BRIX. The effects were massive as I finally had precise control over how the sprite looks. I was so in love with it that I even bought a Wacom MobileStudio Pro in order to get the direct screen-pen-tablet experience and since then I am not even considering working without it.

Originally it all started with 3DS Max for the models but I have completely switched to Blender mainly due to us using it at Factorio and I don’t even want to install 3DS Max on my computers anymore.

The main benefits of Blender for me are for example the quick modelling, ability to make complex python scripts for custom rendering systems, reasonable material management and extremely easy GPU usage – in Max I always rendered on CPU which took forever, with Blender I just throw a 1080Ti at it and it just does the job fast, without any complications.

The fact that I don’t even have 3DS Max anymore made a big restriction to making BRIX 0.0.2 – I couldn’t re-render 3D files without it anymore, so all the improvements you see in 0.0.2 are coming from After Effects and mainly hand painting in Photoshop. And the trees are from Blender.

To make this even remotely possible to happen, I am very happy that when I was working on the 3D models, I learned from RAWR that it is critically important to do things properly right away. Everything has to tile perfectly from the beginning and so on. This majorly influences the design of tracks for example – each track type in BRIX uses a different technique which fits it’s look in order to make it tile in junctions correctly. What all this means is that I don’t even need to re-render the 3D files because they don’t need fixing, I just needed to make things look better. In case of RAWR I constantly had to revisit the 3D scene and just iterate on solving the same problems over and over again, which really slows down the progress.

This means that overall BRIX is not trying to replace too many things too fast, but the things it replaces, it does quite properly.

Eventually even my standard After Effects + Photoshop combination wasn’t enough mainly for tunnels so I just had to export everything to Photoshop and just do manual magic there. This makes the current results much better but future revisiting will be much harder because now it’s a multi-step process where After Effects needs to generate some files for itself and grab some other things from Photoshop to render the last step.

Future of BRIX

Because of the last part of the process, I will probably try to avoid re-visiting the existing sprites in future versions. If I find the energy and time to do anything with BRIX, I will rather move forward and replace something else like industries or train stations. When that is going to happen however, I don’t know. I will definitely take a break from BRIX for a while because in the last year I have been working quite intensely on it (mainly the last 4 months), and it’s been really long and exhausting.

Conclusion

It has been almost seven months since I released BRIX 0.0.1. I did so because I felt like I’m not making enough progress with it to be holding it just for myself while others wanted to try it. It made me so embarassed by the poor quality of it that it actually motivated me to do something about it.

A few months after the release I started to spend a lot of my free time with it and slowly, step by step, I eventually brought it to the current state.

Right now I am quite satisfied with how it looks, although many things could obviously look much better. There is a point where I feel like it’s stable enough to be released and more effort is just tedious self-torture, and that point is pretty much now. I could add rough and rocky tiles, add nicer bulldozed tiles, add depots, train stations, track electrification, finish vehicles, … , and the list just continues. For now I call this rather proudly BRIX 0.0.2 .

There have been many points where I am just asking myself “Why do I even do this?”. The force that is driving me is the vision that when I look back what I did in the last year in my free time, I see product of it, and even better a product which shows that I have learned many things when making it. And the learning part is the most important part for me which lets me justify why do I do this. Working on NewGRFs for OpenTTD made me learn a sea of things I would have normally never known about and eventually gave me enough to be able to give me a dream job to work on Factorio. Every single thing I learned here I utilize there, and Factorio makes me learn many things again, you see the pattern .

All of this isn’t just because of some games, it’s all because of the people. I didn’t just learn all of the things by myself, even if I went through all of the solutions personally. I have to thank everyone who I talked to for teaching me so many things…

From any forms of visual concepts and overall artistic enlightenment that Albert ‘glex’ Bertolin from Factorio teaches me, through discussing many not only visual and python-y problems with andythenorth, me asking dumb programming-related questions to all the wonderful programmers such as frosch or Alberth, and programmers in Factorio such as Martin ‘HanziQ’ Hanzík or Michal ‘Posila’ Pavel?ík. I have to thank planetmaker for all the wisdom he has told me about general workings in OpenTTD, all the things about licensing and over all guidance, even though it has been a while I come to appreciate it more and more as I discover and realize many of the problems by myself. Last but not least, I would like to thank everybody who has ever discussed anything related to my NewGRFs in the past, be it in IRC or tt-forums, or anywhere else, especially Mark, Jam35 and Sylf for being great members of openttdcoop. Lukasz1985’s words about “you will want to use python” are in the back of my mind constantly ever since I started making extensive use of Python, or SyberSycho and R2T9 who have faithfully followed the tt-forums thread over the long period of time and showed interest in the project, which in turn made me motivated to continue working on it. I thank you all, for without you I would not even be interested in working on a project like this.

In the past I have been working on multiple sets at the same time, considering all of them a work in progress. Many years ago I could afford to do that with the amount of free time I had, but we all get older and pretend to get wiser, so it’s time to realize that I can only really keep one project at most so the slow progress doesn’t dissipate entirely.

Even though one of the biggest benefits of BRIX is the lack of any functionality since it’s just a graphics replacement, it’s also one of the things I miss. The kind of functionality that I was able to create in NUTS Unrealistic Train Set, making OpenTTD a game with even more possibilities.

Some of you might remember I was experimenting with a few new train sets, but none of them was ever released or even seriously started past a stage of concept and experiments.

In the last few years I have been thinking and dreaming about a train set which would learn from some of NUTS’s flaws, yet give even more interesting experience. I am happy to announce that with BRIX being stable for now, I will be focusing on making a new train set.

it has been a while since I wrote anything in here, and what better time could there be than on April fool’s? As many of you might remember, it’s not just the 1st April, it is NUTS birthday. It has been five years since I released NUTS 0.0.1 and many things have progressed since. One of them are my other NewGRFs that took place after NUTS. The latest one – BRIX – will now share birthday with NUTS as I am releasing BRIX 0.0.1 right now. I will also talk about some more things later in the article…

NUTS Unrealistic Train Set 0.7.9

The last update happened when I was adding 32bpp/ExtraZoom graphics to it. That was probably sometime in 2014 if I remember correctly, which is insanely long time ago to me. Over time, I have realized that converting it all into 32bpp would be absolutely insane amount of work. On top of that, the already present 32bpp is of very poor quality and would require serious further attention. This brought me to the first major change of removing 32bpp except slugs (you can always turn your blitter to 8bpp if you really want them in 8bpp anyway). I might create a separate newgrf which will be NUTS-with-32bpp, with the same grf ID, just only obtainable from devzone, not from BaNaNaS.

Other than that, I added a few parameters for disabling signals as NUTS defines them by railtype, which BRIX can’t overwrite, so now you can choose which signals you want,  or even disable them if you use NUTS alone.

I also fixed a couple of old bugs some looooong time ago, but I don’t even remember which.

If you reported something to me in the past for the latest version, please re-check if you can remember what it was, so I could fix it.

Future of NUTS

Mainly with the 32bpp-out decision I started to realize what NUTS should truly be and what should it’s final form look like.

I consider it feature-complete now, and the only things I would like to add/change in the future are related to cargo sprite definitions. Vast majority of NUTS sprites are wagons. Simply because there are about 70 cargoes in OpenTTD, and NUTS defines graphics for basically all of them (in any game you won’t ever have 2 same graphics for 2 different cargoes – this isn’t true anymore since some from FIRS 2.0 are missing, but it’s the aim), combine this with about 10 wagon classes, 3-10 loading stages, 8 rotations and you get insane amount of sprites.

I would like to simplify that by using sprite layering, and 8bpp mask recolouring by code. That way, I can just define recolour patterns, define empty sprite, define sprite of the cargo alone, and done. Of course this is still a really big amount of work, but if anything, I will put my energy towards this in NUTS, mainly because it is the only thing that will need upkeep as others add new cargoes, and such rewrite could both make it better manageable, and reduce the filesize of NUTS as a nice bonus.

Overall, NUTS has made huge progress over the years, and in the last 3 years of no updates, I have been quite happy with it. You probably know that I number my releases like 0.7.9 is 79th release, so I won’t declare it 1.0, but . Thank you everyone for your support of this train set, be it discussions I had with you about it, any form of feedback, using it on servers, …

BRIX 0.0.1

A long time ago I have made RAWR – a NewGRF aiming to replace all base set sprites. When releasing 0.0.1, I wasn’t too happy with it and my general mindset was “I can always fix it later”. I continued working on it, and I was almost done with version 0.0.2, but even after basically completely reworking everything ground-up apart from some template 3D models and the code, there were still so many issues that it just became unbearable pain and I just decided to stop. At the same time I didn’t really like how it looks, even if it didn’t try to look realistic, it used real-life-style textures and it just looked off with OpenTTD’s scale.

I just started doing some random models and I modelled a tile of straight rail, monorail, a road piece and a hole in the ground. All of them pretty much exactly the same as you can see them in v0.0.1. From there I was just like “ok, it’s cubes, let’s make a project called BRIX and go with it”.

So I re-used some of the RAWR sources and code, and continued.

Some parts like the landscape were completely redone for the better, some parts like all rails were just re-used for the system. When making these base-set-style NewGRFs, the first task I always did was investigate the base set which sprite ID is which, and sort my 3D models in the same way for consistency (because it is often an insane mess to go through). This alone takes a lot of time to do, so at least I didn’t have to do that again for BRIX.

In general my mindset was totally different. This time I didn’t want to “just make something and fix it later”. The idea was to make things right on the first try, and what is in BRIX, is there to stay. I will skip to present and now I can tell you that about every single sprite will change in terms of receiving some Photoshop postproduction, but the 3D models won’t change, I won’t even re-render them for the most part. Some things like the bulldozed land are horrible and need complete rework however.

This mindset is what lead to me postponing the release “until it’s ready”. My last big effort put into BRIX has been in July/August last summer and around Christmas a tiny little bit. Since then I have “just” written a 8bpp converter (more about that later) in the beginning of February. As you might know, I work full-time as technical artist on another game Factorio. This is taking all of my interest and time lately, and it’s only getting more and more intense. I find this day a good opportunity to face the reality, this is what BRIX is today.

I am definitely hoping to continue working on it, I am not in a state of unhappiness with it like I was with RAWR – mainly because the 3D models are made very precisely and for example the tracks are made with a LOT of thought going into them. I just don’t want to do it right now. I even have a lot of Photoshop painted masks for making it look a lot nicer, but they need applying very carefully, and some of them need finishing, so it’s still a non-trivial task for which I don’t want to delay 0.0.1 right now.

Using BRIX

It is a very specific NewGRF in usage. You can load it into your game just like any other, but you can also use it as static NewGRF. I have already written a guide on how to do this with RAWR here. BRIX takes this even further as you can customize which sprites do you actually want to use. You can disable any part of BRIX individually so for example if you only want to use the signals all the time, even when playing on servers which don’t have BRIX, you easily can.

32bpp -> 8bpp conversion

One of the last things as I mentioned is a python script which converts 32bpp to 8bpp. With all of my NewGRFs I have observed that 32bpp isn’t necessarily better, especially when some people have obscure problems with the game running slowly with 32bpp. Even some people with high-end workstations can get into those problems which is just downright weird. Apart from that, the magic of 8bpp is strong, and often people actually just want the additional pixels that extra zoom gives.

Every 32bpp NewGRF I have looked at either ignores the 8bpp completely, or does something ugly. RAWR and YETI is basically broken with 8bpp because of ugly blue artifacts everywhere, and NUTS is saved in this regard because it existed as 8bpp only NewGRF before 32bpp was added, so there is no need to somehow generate new 8bpp because it already exists. I believe 8bpp is very important, and this always made be feel quite sad. The way I always did it was palette conversion in Photoshop, but that’s very limited and any sprites which have semi-transparent pixels look very ugly.

When making Factorio, I have learned to use some basic python for making scripts. Once I needed a special script which would filter images for specific colours, and to practice the techniques for making it work, I decided to write a 32bpp->8bpp converter for my OpenTTD things.

The idea is very simple, it just reads a 16×16 RGB image with the palette colours, and then goes through every pixel in the given spritesheet, and tries to compare it’s colour to the palette colours. Using various formulas (experimenting with that), the closest colour is declared winner and placed into the output spritesheet. Currently I am not saving it as 8bpp image just because I didn’t code it yet, but eventually…

The biggest problem of Photoshop is how it handles alpha (transparency). It just mixes everything with a colour that you specify. The best results I got with 50% dark gray were ok-ish in majority, but still very broken in so many cases. I needed something that would allow me to say how exactly should the alpha channel be handled. My script reads the alpha of the pixel, and if it is less than 50% visible, then it just throws it away. If it is more than 50%, it takes the colour of the pixel. Now, depending on the alpha value, it shifts the colour closer towads the shading spectrum in it’s palette by 1 or 2 shades.

For example, if I take a pixel with colour (ignoring alpha) closest to index 1 – pure black. Imagine the pixel is at the edge of an image where it is 40% transparent. When drawing it, it probably doesn’t look like a pure black pixel. Instead, it is most likely something around dark gray. This is why the script will add 2 to the index, and use colour of index 3. The same applies for white, but vice versa – it will make it darker.

This logic of course isn’t perfect as it assumes a 50% dark gray behind it, but it is much better than what Photoshop does.

The result is very slow since BRIX spritesheets have about 350megapixels, going through each pixel one by one by getpixel() and putpixel() function is very slow. There are probably many ways how to optimize this, and/or try using numpy or a python on CUDA, and run it on a graphics card. But I didn’t have the time to do that so for now I am happy with letting the computer crunch it for some time while I do other things. I am hoping to do a lot more experimenting with the algorithm which finds the closest colour. There is a lot of magic to be done here. For example I want parameters by which I can explicitly enable-disable target colours. So if I don’t like a specific colours, I can skip it. Also, the shade shifting is pretty bad in the middle of the shade ranges because it starts “overlapping/switching sides”. Apart from that, there is a whole bunch of ways how to determine close colours so I want to look into that eventually. For now the 8bpp is kind of broken but it isn’t exactly easy to fix it quickly.

You can find the current version (v8) of this script in my BRIX repository /scripts folder and use it for your NewGRFs as you like.

Conclusion

BRIX is what it is, it might get better (hopefully will), for now you can play with it to some degree. I had many more plans and ambitions for 0.0.1, like finishing trains, applying the Photoshop postproduction, making more trees, giving trees colours, and so on. But here is the time where I decide to just publish it, and push the rest of the things to 0.0.2.

I believe NUTS is heading in the right direction in the long term, even if now you might feel like “well now I finally have BRIX in 32bpp, and I can’t have 32bpp NUTS?”. Which I understand and for that reason I will probably try to release NUTS32bpp soon on devzone. If you like, please test if it is properly compatible with the main Bananas version.

Once again, thank you for reading and for your continued support through the years, it’s always been a lot of fun.

As you may have noticed our services have received some outtage. This happend during a maintenance that was required for needed security updates related to CVE-2015-0235 (the glibc story / http://www.openwall.com/lists/oss-security/2015/01/27/9). When we rebooted the server the most scary thing happend for us. Our server did not return online. After some help from our hosting provider we managed to log back in.

To make the most out of this situation we immediatly also starting converting some of our local containers to a diskimage format (PLOOP / https://openvz.org/Ploop/Why). However because one of our main containers which has all the HG repositories has so many small files this conversion is taking longer then expected.

We want to apoligize for this situation and are waiting for this container conversion to finish. After this the most critical containers should all have been converted and most of the other ones are related to non-development stuff that should have no extended downtime like this.

Regards,

^Spike^

just now I am realizing I forgot to officially mention that I have been working on another project for the past months. RAWR Absolute World Replacement is currently 32bpp/ExtraZoom LANDSCAPE with ROADS and TRACKS. Eventually I am hoping to replace all the sprites the game needs, and the final output then could be a full base set.

Visually, the set is obviously 32bpp/ExtraZoom which looks relatively nice. Functionally, it lets you choose from the 4 climates and force any of them visually. That way you can apply any of them you want – especially if you load the newGRF as a static one. I hope you like it, there is still a lot of things to be done, but the core is there.

The project home is at the devzone per usual – you can also find a guide on how to apply static NewGRFs. I also have a thread at tt-forums, you are welcome to contribute/place your impressions/screenshots there

You can download RAWR from the online content – BaNaNaS – through the game, or from the website manually.
Enjoy and let me know what you think!

V

Being around for a long while, most of you probably know him, but if you don’t, Hazzard is a great builder and person. His logic mechanisms and other construction put your brains in greater hazard when you see them. He has been generally very helpful, teaching people, being a nice person, and everything else.

Everybody, please welcome Hazzard to the openttdcoop members club!

Today one of the changes that you will see is a change to our paste service. The paste service as it currently is has changed. We have switched to a new backend which was needed. The old pastes are NOT deleted. They can still be reached at http://old-paste.openttdcoop.org. However do keep in mind that this will go offline at some point and we strongly advice against creating new pastes there.

Our new backend is currently live at https://paste.openttdcoop.org. In this case we are using sticky-notes as a backend. This gives you more privacy and options compared to the old paste. We do hope the new features help everyone out even us as admins in maintaining it all.

Another change that already is active (and you might not always notice) is a replacement we did for our bundles server. This had to happen at some point. And today it is done. This change won’t have much of an impact. But we hope to improve response times with this new server.

These are just a few of the changes you’re going to see. More will follow at some point but this is just a start

Should you have any questions join in on IRC (#openttdcoop @ OFTC or through http://irc.openttdcoop.org)

After 3 months I have managed to model 14 industries and code all of them in the last two weeks.
Creating some industries took more than the others, especially huge amount of effort was put into 3-X Machinery Factory, with all the robots being animated and the car being assembled.
While some look less simple, they often had some problem I had to overcome, but in the end it all works at least somehow.
Only the Worker Yard gets the 404 graphic for now.

Functionally:
– The Worker Yard outputs amount of YETI dudes based on current year (so it will grow no matter what), but the production can be increased by Food and Building Materials. Both of Food and Building Materials should have the same effect.
– Other industries all work simply based on Consume->Produce method, even “primaries”. This is done over time so you do not get all of the production immediately. 10% of cargo currently waiting is consumed and produced.
– I do not know in what way do industries die, find out!

– There are only 15 industries, Plantation / Orchard is missing due to missing sprites And coincidentally I am somehow unable to add 16th industry… to be added later.

NUTS Unrealistic Train Set 0.7.2 Universal wagons are able to load YETIs (Workers), and will show specific sprites. Older NUTS versions also work but will show just flatbed crate graphics.

Currently the file has 30MB, and I have not yet added a single animation. Right now I just want to release this as 0.0.1, and add fancy things later (animations will probably go asap).

Sooo, enjoy it

V

Just like about 3 years ago when I announced first concepts of NUTS, this time I am glad to announce that I started to sketch schemes and industries for YETI.
This article is for one like my notepad so I remember the core idea, and to let you know and/or give feedback what you think about the concepts.
To demonstrate my ideas I have created some scheme images below.

Introduction

Years ago, NUTS started being developed because other train newGRFs had so many limitations, the only hope I saw was in creating a new train set which would attempt to fix those gameplay hurting parts, and extending it all with my own experience.
YETI situation is similar, yet different. Similar because currently the industry newGRFs each have a lot of downsides.

With original industries most people generally get bored after some time and start searching for something new. And so they find ECS, Pikka Basic Industries, OpenGFX+ Industries and FIRS.

But since ECS is completely unusable due to its limiting features and strange production mechanics, that is one down.
Another one out of the game is Pikka Basic Industries as they not only have strange limitations like steel mill requiring precise amount of coal and iron ore to work, but most importantly industries just die when they empty out.
From remaining options, OpenGFX+ is great, but it is “just” the original mechanism – transport and it grows, nothing more, nothing less. While this should not be underestimated – it is still a ton of fun as the concept has been confirmed to work by numerous players of OpenTTD for years, for industry newGRF people generally search also for some new mechanism how it works.
Last but not least, FIRS has minimum of limiting inconvenient features while adding a whole new mechanism of supplying industries, and adds a TON of new cargoes/industries – you can even choose them to some extent by economies. In general FIRS is great (at least in the beginning), but…
The problem of FIRS is that cargoes which are able to produce supplies become a “better tier” automatically as you do not have any reason to use the other cargoes, not to mention the insane amount of effort you have to put into connecting e.g. the clustered farms – for which you do not get any reward.
In the end you return to OpenGFX+ or Original industries as they simply work, which is unfortunate.
YETI is trying to create a simple yet interesting system which would be fun to play, without overwhelming complexity but allowing for different approaches and ways to play it.

Main YETI system

Now of course you are probably asking how do I want to achieve this. Learning from the downsides and upsides of other sets, I would say that some kind of mechanism like supplies is very nice as it suggests the network to connect everything together so supplies can be distributed. So I added supplies (Toys/Machinery) which improve the primary industries in some way.

To avoid confusion FIRS creates, every primary has to be useful and contribute to the supplying mechanism somehow. And not to self-reproduce, there are two different kinds of supplies – Workers which improve industry production, and Toys/Machinery which make the production fluctuate (decrease) less.

Workers also create a new link to towns and their size so they also play a role. With that come into play two chains which boost town size, and amount of workers per citizen.

What all that means: You can service one industry chain and survive, but the system motivates to connect all chains together – not necessarily in a perfect balance as they all contribute to the whole system somehow. You do not get punished for lacking something, you only get rewarded for caring for your industries better.

Other YETI details

In order to motivate to connect more towns, I intend to make the worker amounts grow in a linear fashion up to e.g. 500 food and 500 building materials delivered per month. But if you deliver more than that amount, your delivery starts being less effective. This means growing a gigantic town is an option, but it would probably make more sense to give care to multiple towns instead.
At the same time though, when redistributing things you probably “lose” some amount of cargo by not 100% precise distribution, so the multiple town strategy would be viable but not too overpowered.

The biggest problem of original industry mechanism generally is that their production stays sane until later years, but then it explodes to astronomic values like 2295 cargo units per month. I think this value is way too high under no other conditions.
Such condition being for example that you have to dump enormous amount of workers/machinery into the industry in order to produce that amount – which generally means you focus on that industry and you do not have many other industries, so the 2295 does not hurt as much.
Obviously similar mechanism like with towns would have to apply – after some amount of workers/machinery, the supplying would be less efficient so it would make good sense to give your industries enough to produce e.g. 500 cargo units monthly.

Another important detail FIRS does is clustering, which generally means the company has to use whole map in order to get all kinds of cargoes. I am definitely not going follow that path and make industries just spawn randomly over the whole map instead, so multiplayer games, where each company gets its own piece of land, are unharmed.

What will it look like?

Pixel graphics are great, nice, amazing, and keep the TTD look – the downside is that they are also extremely time consuming – especially as industries are a ton of pixels, and I need to learn more 3D things for my job.
So, ultimate solution arose – I am going to model and render all of YETI so you can look forward to extra zoom sprites.
General graphical style is going to be similarly wtf to NUTS – weird things and hidden jokes, but the colour scheme being sane (not like toyland).
What all can come, only the Yetis know.
Obviously NUTS is going to be fully compatible – NUTS will get new cargo sprites for that, in case some are missing.

WHEN?!11!1!!!1!

14.7.2014

Conclusion

I just wanted to let you know that I am working on something new, and if you have some constructive ideas, I am interested to hear them. In case you wanted to help, I will certainly need somebody to code the thing as I want to 100% focus on graphics this time.
Thank you for reading and your upcoming ideas.
I am not going to be active on the IRC as I used to be, so please if you have something to say do so here in the comments below.

P.S. YETI is not just a name!
V453000 the Yeti

It is happening again, 1st April is here!

Just like last year and the year before that, we can celebrate the existence of NUTS with a new version again.

In the past year NUTS made a lot of progress even though it seemed quite “complete” even last year. Most notably were added some trains (who knew) which improves the choice a player can make – and also the awesome factor of the set. Namely, PURR tracks got eaten by NUTS as they are now integrated in one newGRF – which happened because MEOW trains are completely dependent on them. Also WetRail vehicles (the wet tracks which were the main surprise in last year birthday) got completely redone and have now 10 vehicles! Plus many other details, but RAINBOW SLUGS are a thing to never forget!

At the same time, NUTS got so huge that became very confusing to new(er) players. Especially lately, I have been trying to make this barrier easier to breach – first of all by adding the wiki which is trying to explain how each vehicle works. Not just that though, another one of steps in that direction making vehicles expire – so only the useful ones remain. And with this version I made all vehicles 1 tile long so you can autoreplace any to any without losing wagons or getting into problems. My intention also was to introduce an Ultimate wagon which could attach to any train and adapt sprites/parameters accordingly, but the obstacles in coding such a thing were way too large. So, I at least added a parameter to NUTS (gets its first parameter after 2 years =D) which makes only universal wagons purchaseable for more simplicity. For full choice you can simply switch it back at any point.

It might be noteworthy that NUTS reached above 100 000 total downloads not long ago, currently counting 100992 times for versions 0-67.

Enjoy! (: