Started by jamespetts, February 05, 2018, 11:46:51 PM
0 Members and 1 Guest are viewing this topic.
/** Hajo: mapping table for special-colors (AI player colors)* to actual output format - day&night mode* 16 sets of 16 colors*/static PIXVAL specialcolormap_day_night;/** Hajo: mapping table for special-colors (AI player colors)* to actual output format - all day mode* 16 sets of 16 colors*/PIXVAL specialcolormap_all_day;
Quote from: jamespetts on February 05, 2018, 11:46:51 PMAlso - is there any reason that these have to be hard-coded rather than the players being able to set the R, G and B values manually?
Quote from: DrSuperGood on February 06, 2018, 03:33:55 AMFor example I added a method to return the public player rather than hard coding the value 1.
Quote from: Ters on February 06, 2018, 07:04:54 AMFirst of all, there are the special colors, which are not transferred directly (or with optional night darkening) from the source graphics to the screen. I guess 256 is a nice round number for that. Since some of these are for lights, that explains why not all 256 is available for player colors. Each player color consist of 8 shades. However, only 224+15=239 special colors are actually in use. I don't know why. Maybe there were another group of special colors earlier. Maybe the remaining 17 colors were regular colors back when Simutrans used 8-bit graphics. Maybe there is set off room for more light colors.
QuoteHardcoding it is easier than creating a GUI for it. Especially since one also needs the other 7 colors to complete the shade. In addition, it might have something to do with 8-bit graphics. At that time, player colors likely doubled as regular colors. (Only 256 colors in total for everything, remember.) If the player could change the RGB values of what was the green player color to purple, then the grass would turn purple. The player could only be allowed to select an existing color range in the pre-defined palette, as other graphics relied on the palette being a certain way. And nobody has bothered changing how it worked beyond what little was necessary to go to 15-bit graphics.So I think most of this is a legacy from Simutrans' once 8-bit graphics. If things were done from scratch today, things would probably have been done very differently. Perhaps with a mask for player colors and dedicated night time images or overlays.
QuoteIf players were to arbitrarily select player colors, one would still have to figure out how to create both darker and lighter shades in order to show of the intended 3D look the artist wanted. (What if the player chose black or white?) Currently, the artists only need to ensure that their vehicles look good for a relatively small selection of possible player colors. Not that it appear that they care much for player colors, but rather go for real life livery. I don't know if multiplayer is forcing them to reconsider.
Quote from: jamespetts on February 06, 2018, 11:59:44 AMYes, the special colours do make things more complex. Is it your understanding that the 256 defined as the array size in specialcolourmap_day_night and specialcolourmap_all_day is the greatest possible number of player colours? I.e., are the hard-coded player colour values stored in these arrays?
Quote from: jamespetts on February 06, 2018, 11:59:44 AMThe trouble that I had when I attempted to increase the number of player colours is that the methods for finding the appropriate player colours (e.g. for drawing those colours on bridges, button icons, etc.) would not return a valid colour, sometimes simply returning a null value (and resulting in invisible bridges, icons, etc.) and sometimes crashing with an access violation (a.k.a. segfault).
Quote from: jamespetts on February 06, 2018, 11:59:44 AMI cannot speak for other paksets, but one of the main reasons that Pak128.Britain does not use player colours for vehicles (at least, as an option alongside the historical liveries) is that there is no easy way of doing this in Blender. Such player colours as there are in Pak128.Britain have been created by rendering objects then painstakingly substituting each pixel of the object that is to be player coloured (e.g. the eves or doors of a signalbox) one by one with the correct player colour. This is entirely impractical for vehicles given their number.I did once ask in the Blender Artists' Community about whether it might be possible to do this automatically in Blender. The response, here, suggests that, whilst it might theoretically be possible, it is fantastically difficult.
Quote from: Ters on February 06, 2018, 04:46:47 PMThat casts some doubt on how well the current mechanism works at all, or whether pak files should come with graphics pre-rendered in all the available player colors. Of course, that means that it will be even less possible for the players to pick their own colors or for the game to change the number of possible players.
Quote from: ACarlotti on February 06, 2018, 05:08:04 PMI think if I were to implement such a system from scratch, I'd go with a third approach - have an vehicle image and a mask. The mask specifies the weighting of the vehicle colour and the player to be applied at each pixel. So, depending on the intent of the pakset designer, it would be possible to apply the player colours as a subtle tint, or as monochromatic colouring, or anything in between. For this to work well, it might be necessary to restrict player colours to be of a specifc single intensity.
Quote from: Ters on February 06, 2018, 05:23:53 PMI touched upon that already in my first post in this discussion, and it was kind of what I did in one of my hardware acceleration experiments, but I'm not sure how easy that is to set up in Blender or post-processing.
Quote from: prissi on February 07, 2018, 06:26:53 AMOn a more practical note: Did you ever manage to have 16 players on a server without contantly desyncing and rejoining? My expereience is quite dated, but more than five active player was no fun anymore.
QuoteThe number of player colors is indeed from 8 bit times. You could not set more than 256-16 colors on an 8 bit graphics adapter, that was hardcoded in windows. (So windows could use the 16 colors for its own you in all programs.) With another 16 special light colors, you end up with 224 colors. Since the end simgraph8, the 256 limit is in principle no needed any more, one could rahter introduce an entirely new array without double function. Anyway with current simgraph8.cc, the array player_offsets holds values larger than 256 with more than 16 players, namely n*8+24=280 for 32 players, so it must become uint16. In imgd the players_flags must become uint32 to hold more players. This two I just found by a quick loot at your patch, there might be more.The 4 bit player size is hardcoded in thing_t as a bitfield. You need to change this to 5 for 32 players (28 does not really make sense). But then you may want to fiddle around with all other sizes, considering you are making 64 bit builds. You may also change the sizes freelist is using, because its main "customers" may be now of a different sizes. Use the sizes flag to show some allocated sizes.
Quote from: wlindley on February 07, 2018, 04:52:07 PMIf the color code is ever rewritten, it would be quite nice to have the foreground/background "player colours" for factories be drawn from their .dat file.
Quote from: wlindley on February 07, 2018, 04:52:07 PMThe concept being that, for example, a single storefront awning drawn in the player blue and player yellow color-scales would automatically be drawn correctly for whatever goods it sold. Likewise, a single pile of ore in player-blue-or-yellow could be automatically repainted as clay, sand, iron, and coal. Factories drawn with component tiles could share buildings which would be visually distinct between industries. This would be greatly convenient in drawing paksets.
Quote from: prissi on February 08, 2018, 12:32:57 AMThere was way back a version, where accidently factories belonged to the player and got draw with player colors (mostly some stray gray pixcels). I was pondering this concept, since it is used very successfully with OpenTTD to make nice looking towns (well) with just 9 different city buildings with different accent colors.