Best openttd newgrf4/9/2024 ![]() You can find more info about RGBA EATER here. 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. The RGBA EATER alone is a gigantic step forward for me. 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 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. 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. As you might be aware, 8bpp sprites are a mandatory part of every NewGRF, and 32bpp/EZ sprites are just an extra, an alternative. The functional part would mean that the 32bpp/EZ NewGRF provides proper 8bpp sprites. Visual side is that it either looks reasonable together or it doesn’t, I will describe that later. There are two sides of 8bpp compatibility to look at, one of them being purely visual, and one of them being functional. 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. 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. 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. 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 main purpose of BRIX is to create a 32bpp/EZ NewGRF, which would be visually compatible with other 8bpp NewGRFs.Įver since 32bpp/EZ exists in OpenTTD, each of 32bpp/EZ projects arrives to the same problem. Even there you can still force 8bpp blitter through OpenTTD config file.Īlong 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. The official BaNaNaS release is full 32bpp / extra zoom though. You can download various reduced versions of BRIX – without extra zoom or 32bpp, in case you want a lightweight version. Then you would just use a static NewGRF with only signals enabled.īRIX is available for download on OpenTTD’s download content server through the game. ![]() 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. You can find BRIX repository at the openttdcoop devzone project page. 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. BRIX does not and will not do any changes to functionality – that way you can load it as a static NewGRF. As BRIX 0.0.1 article was quite short due to being released in a rush, this one is going to go into a lot more depth.īRIX 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. Hello dear humans and inhabitants of slug planet, today I have great news to share with you as I have finished work on my graphics replacement NewGRF – BRIX version 0.0.2. ![]()
0 Comments
Leave a Reply.AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |