News:

The Forum Rules and Guidelines
Our forum has Rules and Guidelines. Please, be kind and read them ;).

Support for PNG Alphachannel for tree graphics

Started by NNW, March 07, 2016, 08:53:06 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

kierongreen

Indeed - best starting off now rendering with no background colour, with the blue added back in later to any completely transparent pixels.

Sarlock

As promised, here are some trees with alpha enabled.  I have included the same tree in pak64 format with and without shadows for comparison purposes.

Having shadows that taper to the edges should produce a better effect with the alpha channel.

I wasn't able to test them so I can't be sure that they are in the right format or don't have some other issue with the images that I didn't notice.

I'll produce more images as I have available time.  The shadows took a bit of work as I had to cast them in Blender on a white surface and then remove the surface after to just pick up the alpha values.  There might be an easier way, I'll have to investigate.





Combined in to one image:

Current projects: Pak128 Trees, blender graphics

prissi

Unfourtunately this is completely wrong. ONLY the shadow must be transparent, the tree must be solid (or it looks really wierd. Here is the correct shadow.

kierongreen

Trees can have some transparency, as you can see between the leaves and branches, but the fading to black doesn't look quite right.

Leartin

I made a mockup with Sarlocks trees by just placing them in a screenshot in photoshop. This is "normal blend", and as an artist this is what I would expect Simutrans to produce as well. This is somewhat important since testing via paking and starting new games takes way longer, you don't want to do that for every pixel.

What I see in the mockup is fine. The trees would not mix well with existing ones, but that's intentional. Their relation to old trees is pretty much the same as that of old trees to comic trees, and everyone has his own preferences.

So what does it look like when using the patch? Since 'mere mortals' can't test it on their own, wouldn't it be a good idea to at least show a screenshot of how it looks instead of just claiming it's wrong and looks weird? That way, everyone can see and state whether it looks weird to them, and compare it to the mockup to see how well Simutrans implements transparency...

jamespetts

Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Sarlock



Maybe I've misunderstood what this patch was intended to accomplish, or is capable of, but alpha on trees makes a massive difference in their appearance in game.  The vast majority of a tree is partially transparent.
Current projects: Pak128 Trees, blender graphics

prissi

It looks more or less like on your screenshot, which is not how trees look in real life to me (they are not that transparent, especially not the trunk ... ) This is most notable to me in forests, onsnow and close to a straight wall like the factory. But I admid that this is might be also a matter of taste.

Leartin

Obviously trees are not transparent, but they are not confined to pixels either.

I attached an image of a tree trunk with a grid. Assuming you tried to convert the tree to a very small image a tenth the size, each pixel would be as big as a square on the grid. If you look on the left tree, its trunk would be two solid pixels wide. The right, identical trunk is alignes slightly different, so it would be a column of solid pixels accompanied by a column of 50% transparent pixels to either side.
If the trunk was thinner, you may have no solid pixels anymore, just like the ones sarlock rendered. I'd try to avoid such situations, and have at least one trunk pixel completely solid, but I do pixelart where sarlock renders, so these are different philosophies from the start.


Nevertheless, I think a big part of the problem is that it indeed does not look that good in the game. I made another mockup by simply replacing the previous screenshot. In the mockup, the trees are better visible than in the game screen. Therefore, we have a discrepancy that needs to be explained. Maybe transparency is "rounded down" when it is a not supported transparency level? If something like this reduces visibility, it should be easy to fight simply by duplicating the trees in photoshop (or similar software) and put the copy on top of the original, thus reducing the degree of transparency.

kierongreen

Comparison between patches:



Prissi's patch



My patch. There are a few artifacts around the edges which I'm investigating the cause of, however in general I think this achieves the artists intent better than prissi's.

I would note that there appears to be a bug in prissi's patch which prevents the complete compilation of pak64 with it. I have to use the standard pak64 with only the tree paks overwritten, as pak64 textures don't compile correctly and cause Simutrans to crash on startup. This doesn't happen with pak128.Britain.

Sarlock

That second shot looks very nice!  The first one is odd: if you look at the trunk of the cedar tree, it completely disappears.  Parts of the trunk are at 240-255 alpha.  It almost looks as if the alpha is inverted (edges of the tree are darkest and the middle with the highest alpha is almost transparent).

The artists can always tweak the alpha to suit individual tastes.  The trees that I am using for these renders were built to have the alpha channel stripped out... I would slightly change the construction of the tree for an alpha-enabled image so that the middle part of the tree is closer to 0% transparency in many spots.
Current projects: Pak128 Trees, blender graphics

kierongreen

#81


Fixed issues with my patch (attached, now code changes pixels which are fully transparent alpha to be the simutrans transparent blue when writing the image) and new screenshot of the same trees scene above.

Regarding inverting, for some reason prissi included code to deliberately to this in his patch....

Edit - I tried removing the inverting code from prissi's patch but that didn't fix problem (made it much worse infact!)

Sarlock

Wow, that looks great!  I'll try to set aside some time and make some more tree renders for testing.  I'll make some in pak 128 format as well.

This is very exciting... it opens up so many possibilities!
Current projects: Pak128 Trees, blender graphics

kierongreen

pak128 ones, especially ones suitable for pak128.Britain would be welcome :) There going to be different seasons too? Having leaves gradually fall as autumn deepens should be quite pretty with alpha.

Will need to think whether shadows should be added to pak128.Britain with this - one reason I didn't include them from the start was that they didn't look great without alpha (though fixed shadows can still look odd in some situations, and it's a fair bit of work so will see).

prissi

#84
There seems then something very wrong with Irfanview and gimp, because both interpret alpha 255 as fully opaque. Anyway, I corrected my patch.

The textureslope you provided for pka64 is an 8 bit indexed image with alpha ... Hence the crash as parts of its will be now considerated transparent and thus can no longer rotate. Here a new makeobj that will strip the transparency from paletted images and invert the alpha as intended.

(I was confused an though the Halo pixel was my error and thus inverted the alpha. However, I still get the Halo with the trees; only when I really reduce the first transparency to be more than 32 or so this will vanish.)

kierongreen

#85
OK - can confirm that crash issue is fixed.

Same scene for comparison with latest version of prissi's patch:



There are a few artifacts visible around trees, and a zooming comparison reveals differences between patches::

(my patch on left, prissi's on right)

Currently as I see it between the patches we have:
my patch - better alpha and colour reproduction
prissi's - smaller pak file

Performance between the two is unknown yet, but as I said above it would be trivial to add an option to disable alpha with my patch which would allow users finding the slowdown a problem to solve this at the expense of graphics quality. From what I've seen of prissi's it would probably be more complicated to do this (but then if prissi's doesn't slow down plotting this is a moot point, can only say that from what I've seen neither slows plotting down drastically in tests so far).

Dwachs

Indeed, kierongreen's patch version looks much better. I would also not worry too much about performance. The usage of alpha transparency could be toggled off if performance is too bad, like this is done for the clipping drawing method.
Parsley, sage, rosemary, and maggikraut.

kierongreen

Incidentally I think for prissi's patch one possible reason for drop in quality (other than restricted palette) is zoom routines not dealing with alpha. With mine it gets dealt with like any other colour channel.

Isaac Eiland-Hall

Sorry to be offtopic, but I'll be very brief: I just wanted to thank you all for the hard work on this. I think whatever we end up with will just be a small but amazing little addition to Simutrans. I love watching the discussion and seeing this come together. .....oops, I was gonna be brief. OKBYE :)

prissi

In the current incarnation there should almost no visible difference between the patches in standard zoom (but for errors ... ) since for most transparency levels the additional information in kierongreens patch is lost when blending. But the zoom routines handle alpha like a special color, i.e. alpha pixel gets extended rather than be omissed (as could happen with kierongreens patch. Indeed, changing that would be trivial. I still have to convers more trees to alpha (since otherwise they will be removed upon loading) and some smoke and stations and then will try my standard profiling game.

Sarlock

Give these two a try:





I agree about the shadows: I didn't use shadows for my own personal pak128 trees as I didn't like how they looked with the alternating pixel setup.  Using shadows with the alpha transparency, however, looks quite nice.

I made these without shadows so that you could compare them against the current pak128.Britain trees.  The first tree is more sparse and has more transparency in between the branches while the second is more solid in the centre.  This gives a chance to compare the two styles.

It's important to keep in mind that artists will adapt their style to whatever end product this patch creates: through a process of trial and error we will find what does and doesn't "look nice" and develop a style that works.
Current projects: Pak128 Trees, blender graphics

Leartin

I'd like to know more about the interaction with special colors. For that matter, I created some "test images" - kierongreen, would you please test them?

first tests the interaction of transparent pixels with player color. If it works as intended, you should be able to choose the colors of the mona lisa portrait by changing the player color settings.
second tests the interaction of transparent pixels with light. I used the same mona lisa, but a bit darker. I'm interested in how that looks at night.
third tests the interaction of transparent light pixels with other light. If it works as intended, there should be some orange lights mixed in the flames.
fourth two test the interaction of transparent light pixels with normal stuff. I made a blue one after I realized that green might not be too visible.

I have no idea if any of these would work, since they are a bit beyond tree shadows - but it's all about finding the limits :D


obj=building
name=monalisaplayer
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.0
FrontImage[0][0][0][0][0][0]=./images/transtest.1.0
---
obj=building
name=monalisalight
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.1
FrontImage[0][0][0][0][0][0]=./images/transtest.1.1
---
obj=building
name=fire
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.2
BackImage[0][0][0][0][1][0]=./images/transtest.0.3
BackImage[0][0][0][0][2][0]=./images/transtest.0.4
FrontImage[0][0][0][0][0][0]=./images/transtest.1.2
FrontImage[0][0][0][0][1][0]=./images/transtest.1.3
FrontImage[0][0][0][0][2][0]=./images/transtest.1.4
---
obj=building
name=spotlight green
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.0.5
---
obj=building
name=spotlight blue
needs_ground=1
type=cur
BackImage[0][0][0][0][0][0]=./images/transtest.1.5
---

kierongreen

QuoteI'd like to know more about the interaction with special colors. For that matter, I created some "test images" - kierongreen, would you please test them?


My patch


prissi's patch

Incidentally you've managed to find some bugs with the recoding in my patch with those images - after player colour change it takes a while (and zooming in/out) for the image to change... Will investigate.

Leartin

 :o honestly, I did not even expect it to work that well. It's beautiful <3
By combining frontimage and backimage, you can mix playercolours with black and white to gain a substantial amount of shades. You can also mix lightcolors to create new lightcolors - not the full spectrum, even if you had RGBCMY the saturation would be somewhat limited, but still a huge step up from 10 colors.

I frankly love it! 10/10 would paint smurfa lisa again!

prissi

OK, there were some bugs with high transparency (those discolored stray pixels) and zooming of player colors in mine. Here is hopefully something without these issues anymore and some more test objects. (I think a transparent dialogue skin was also tried by dithering some time ago and might be another good test object.)

And unfourtunately smoke does not support front and back_images ...

Leartin

Quote from: prissi on April 05, 2016, 09:51:01 PM
unfourtunately smoke does not support front and back_images
The original intention of frontimages, seperating "in the back of vehicles" and "in the front of vehicles" only made sense for a few types of objects - ways, stations, depots.
In pak192.comic, we frequently use the frontimage differently - usually for animation, since if something is only changing position you can do that with offset, saving frames. Plus, moving parts are usually unaffected by seasons, so you can reuse the same animation frames over different static seasoned images, saving images in memory. Now they became even more useful with transparency blending.

So could we have an optional "Image2" that is always drawn right after and on top of the normal image (as opposed to back- and frontimage where something else can be inbetween) to gain access to all the benefits frontimage provide? I don't exactly see how it would be useful for smoke (yet), but I think it would be very beneficial. Especially that trick for all shades of player colors.

kierongreen

Adding a second image is technically possible for sure but will slow things down, doubly so since alpha plotting will be used. Given the limited circumstances it would be used in I feel it probably wouldn't be worth adding.

Incidentally it seems like a multithreading race condition in activating special colours during image recoding is causing errors with my patch. That might be quite difficult to solve without having separate colour maps for each player, which could be a good thing anyway. However if prissi is going to be committing his patch it's not worth me investing any more time in mine, so I'll leave this for now.

prissi

The profiling will be done with single threaded mostly, as multithreaded has been given unreliable results before. Although I am not sure how to make sure that then partial clipping (_pc) routines get their fair share then.

About the second image: Front image animation is the recommended way for most animations an certainly nothing specific to pak192.comic. However, an overlay for everything somewhat defies the meaning of overlay. Then a true 32 bit image would have the same memory consumption and drawing bandwidth without all the limitations and gains we have currently from using 16 bits.




Leartin

Quote from: prissi on April 06, 2016, 09:24:00 PM
an overlay for everything somewhat defies the meaning of overlay.
Then a true 32 bit image would have the same memory consumption and drawing bandwidth without all the limitations and gains we have currently from using 16 bits.

Buildings already can have frontimages. Is the frontimage potential in buildings affecting performance in a significant way? I don't think so, since if that was the case, it would have been restricted to depots and stations. There hardly are animations in most paksets, and where they are they could be done by animating the backimage, so you would not lose any functionality.
Would adding the same potential to vehicles do significant harm? I really don't think so, cause that would not even double the potential frontimages on the screen - except when your screen shows an armada of boats at sea. Conclusion: Potential does not do the harm.

Used Potential can do harm. If we were to use some transparent playercolor overlay on each vehicle, that's probably a significant performance hit old PCs can't take. Of course, the same is true if it was used on other structures that already have the potential - let's put animated disco lasers on every roof! ... Actually, I startet adding animated smoke to each snowy house with chimney. Would probably look better if it was transparent, too. So yeah, of course, if you give me new toys tools to play work with, I'll do my best to destroy that old win95 PC on grandpas attic. Good thing there are more reasonable paks like p64 you can still play on that machine.  ;)

The difference between "changing to 32bit images" and "adding frontimages to more objects" is therefore that:
one certainly hits performance and makes the game unplayable on old systems without any initial gain,
but a potential of nicer colors (possibly not even visible difference for common user),
one hardly hits performance and does not make the game unplayable on old systems while still having no initial gain,
but a potential of adding more player colors and more lightcolors for a performance hit each time it's used.

kierongreen

The difference is that front images are there for a specific reason: to be plotted over any vehicles on a tile. Having an additional image would only be there for the purposes of transparent overlays (and logically you would need second images for front images also, so up to 4 images per tile).

Leartin

Quote from: kierongreen on April 07, 2016, 10:01:24 AM
The difference is that front images are there for a specific reason: to be plotted over any vehicles on a tile. Having an additional image would only be there for the purposes of transparent overlays (and logically you would need second images for front images also, so up to 4 images per tile).

Hold on: Whoever implemented frontimages could have restricted them to stations and depots, like the ability to be placed on a way. This was not done. In any building but station/depot, frontimages are only there for the purpose of non-transparent overlays. Either even that's enough for them to be useful, or they simply don't do anything bad - including dropping performance.

Sure, the only purpose for an additional image in a vehicle would be that of a transparent overlay. Or a non-transparent overlay even. I once had an end wagon which was the same as the leading wagon, but turned and with red lights. Typical case where I would use frontimage if it was a building, not a complete copy. - not requiring transparency.
But yes, the main part would be to add additional lightcolors and additional player color shades to the mix. What's easier, implementing an "overlay" image for vehicles and possibly groundobjects, signals, ... or actually allowing many more lightcolors and playercolorshades?

And no - having "Image2" does not mean you need to have "Backimage2" and "Frontimage2". Just like having frontimage and backimage in some objects does not mean they need to be in all.

kierongreen

Stations and depots are buildings internally though. Hence adding for one you might as well add for all. I wasn't stating that every pakfile would have to have 4 images but that this would be expected to be supported by the program for consistency.

prissi

Animation would hit performance, if done on enough buildings. Same for transparency or anything else.

The profiling has yield some strange results. The biggest consumer in my patch (22%) was
display_img_stretch_blend
display_blend_wh_rgb
although I do not call this in my patch at all. I think there are some issues with my mingw.
display_img_xx (which had been at 5-10% in old profiling ages ago) was not in the list at all.
Maybe I need to install Linux again for a proper profiling.

prissi

#103
OK finally got some profiling:

prissi V7 twice as much time than baseline, same pak size.
kierongreen V4 triple time need for display, twice pak size

Without transparency neither mine nor kierongreen is slower.

Three or 31 level of transparency do not have an impact.

In detail

prissi V7

  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.51     27.47    27.47                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
24.04     41.09    13.62                             display_img_nc(short, short, short, unsigned short const*)
  3.98     43.34     2.25                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  2.03     44.49     1.15                             display_img_wc(short, short, short, unsigned short const*)
  1.80     45.51     1.02  8496986     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  1.21     46.20     0.69    12930     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  0.74     46.62     0.42     4310     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.65     46.98     0.37    90815     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.60     47.33     0.34  5508308     0.00     0.00  obj_t::display(int, int) const
  0.53     47.62     0.30  2271370     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.53     47.92     0.30                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.44     48.17     0.25  8901805     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.41     48.41     0.23    70777     0.00     0.00  haus_besch_t::get_animation_time() const
  0.41     48.63     0.23                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.39     48.85     0.22 12743014     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.39     49.08     0.22                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.35     49.27     0.20  8296751     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.34     49.47     0.19    40198     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.32     49.65     0.18        1     0.18     9.30  karte_t::interactive(unsigned int)
  0.32     49.83     0.18                             BZ2_bzDecompress
  0.30     49.99     0.17 14616543     0.00     0.00  planquadrat_t::get_kartenboden() const
  0.30     50.16     0.17  1874850     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.28     50.33     0.16  1961050     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.26     50.48     0.15    64748     0.00     0.00  gebaeude_t::sync_step(unsigned int)
  0.25     50.62     0.14    31838     0.00     0.00  interrupt_check(char const*)
  0.23     50.74     0.13 10549744     0.00     0.00  grund_t::get_hoehe() const
  0.23     50.88     0.13  1961050     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.21     50.99     0.12  2754090     0.00     0.00  objlist_t::display_obj_vh(short, short, unsigned char, unsigned char, bool) const
  0.19     51.10     0.11 20881723     0.00     0.00  karte_ptr_t::operator->()
  0.19     51.22     0.11 12001622     0.00     0.00  obj_t::get_flag(obj_t::flag_values) const
  0.19     51.33     0.11  8792400     0.00     0.00  baum_t::get_age() const
  0.19     51.44     0.11    62075     0.00     0.00  karte_t::is_fast_forward() const
  0.19     51.55     0.11                             longest_match
  0.18     51.65     0.10 20278534     0.00     0.00  grund_t::get_flag(grund_t::flag_values) const
  0.18     51.74     0.10 12150910     0.00     0.00  obj_t::is_moving() const
  0.18     51.84     0.10  4396200     0.00     0.00  baum_t::get_outline_image() const
  0.16     51.94     0.09 11538312     0.00     0.00  koord::koord(short, short)
  0.16     52.02     0.09  9012841     0.00     0.00  karte_t::access(int, int) const
  0.16     52.12     0.09  1961050     0.00     0.00  planquadrat_t::display_obj(short, short, short, bool, signed char, signed char) const
  0.16     52.20     0.09    11938     0.00     0.00  win_poll_event(event_t*)
  0.16     52.30     0.09     4310     0.00     0.00  karte_ansicht_t::display(bool)


Kireon V4

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
65.11     48.85    48.85                             pix_alpha_recode_16(unsigned short*, unsigned short const*, unsigned short const*, unsigned int, unsigned short, unsigned short)
11.58     57.55     8.69                             display_img_alpha_wc(short, short, short, unsigned short const*, unsigned short const*, unsigned char, int, void (*)(unsigned short*, unsigned short const*, unsigned short const*, unsigned int, unsigned short, unsigned short))
  4.69     61.06     3.52                             display_img_nc(short, short, short, unsigned short const*)
  1.87     62.47     1.40                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  0.95     63.17     0.71  4499521     0.00     0.00  display_rezoomed_img_alpha(unsigned int, unsigned int, unsigned int, short, short, signed char, unsigned short, int, int)
  0.90     63.85     0.68    12909     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  0.67     64.35     0.50  8492824     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  0.57     64.78     0.43  5509635     0.00     0.00  obj_t::display(int, int) const
  0.56     65.20     0.42                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  0.43     65.52     0.32  8991301     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.33     65.77     0.25                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.32     66.01     0.24     4303     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.31     66.24     0.23  8367499     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.31     66.47     0.23    90767     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.31     66.70     0.23    40163     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.31     66.93     0.23     4303     0.00     0.00  karte_ansicht_t::display(bool)
...


Baseline

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.32     17.68    17.68                             display_img_nc(short, short, short, unsigned short const*)
  7.86     20.55     2.88                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  3.18     21.72     1.17  8504237     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  3.03     22.83     1.11                             display_img_wc(short, short, short, unsigned short const*)
  2.61     23.79     0.95    12930     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  2.09     24.55     0.77                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.20     24.99     0.44  5510121     0.00     0.00  obj_t::display(int, int) const
  1.12     25.40     0.41                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  1.04     25.78     0.38  8898019     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  1.04     26.16     0.38  8290592     0.00     0.00  get_xrange_and_step_y(int&, int&)
  1.01     26.53     0.37    90827     0.00     0.00  haus_tile_besch_t::get_besch() const
  0.89     26.86     0.33    64748     0.00     0.00  gebaeude_t::sync_step(unsigned int)
  0.85     27.16     0.31     4310     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.82     27.46     0.30    70787     0.00     0.00  haus_besch_t::get_animation_time() const
  0.79     27.75     0.29  2271370     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.74     28.02     0.27                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.71     28.29     0.26 12755840     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.68     28.54     0.25                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.60     28.75     0.22        1     0.22    10.37  karte_t::interactive(unsigned int)
  0.57     28.96     0.21  1874850     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.55     29.16     0.20  1961050     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.55     29.36     0.20                             BZ2_bzDecompress
  0.52     29.55     0.19 20278534     0.00     0.00  grund_t::get_flag(grund_t::flag_values) const
  0.52     29.75     0.19                             non-virtual thunk to gebaeude_t::sync_step(unsigned int)
  0.46     29.91     0.17    37382     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.44     30.07     0.16  1961050     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.41     30.23     0.15     4310     0.00     0.00  karte_ansicht_t::display(bool)


prissi V7 with non-transparent images from baseline (kieron should have here nearly baseline)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
48.08     17.66    17.66                             display_img_nc(short, short, short, unsigned short const*)
  7.43     20.39     2.73                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  3.95     21.84     1.45                             display_img_wc(short, short, short, unsigned short const*)
  2.78     22.86     1.02  8506616     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  2.29     23.70     0.84    12939     0.00     0.00  karte_t::sync_list_t::sync_step(unsigned int)
  2.14     24.48     0.79                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.42     25.00     0.52  5516012     0.00     0.00  obj_t::display(int, int) const
  1.28     25.48     0.47  8945006     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  1.20     25.91     0.44    90874     0.00     0.00  haus_tile_besch_t::get_besch() const
  1.20     26.36     0.44     4313     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  1.06     26.75     0.39                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.79     27.04     0.29  1962415     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.79     27.32     0.29        1     0.29    10.71  karte_t::interactive(unsigned int)
  0.74     27.59     0.27  2272951     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.68     27.84     0.25                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.65     28.09     0.24  8332987     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.63     28.32     0.23    70830     0.00     0.00  haus_besch_t::get_animation_time() const
  0.60     28.54     0.22 12757252     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.60     28.75     0.22    40134     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.60     28.98     0.22                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.57     29.18     0.21 12173572     0.00     0.00  obj_t::is_moving() const
  0.56     29.39     0.20  1876155     0.00     0.00  grund_t::display_boden(short, short, short) const
  0.54     29.59     0.20     4313     0.00     0.00  karte_ansicht_t::display(bool)


And finally prissi7 only using the 25% 50% and 75% transparency (faster) with my patch (does not make much difference!)

Each sample counts as 0.01 seconds.
  %   cumulative   self              self     total           
time   seconds   seconds    calls   s/call   s/call  name   
47.75     24.48    24.48                             colorpixcopy(unsigned short*, unsigned short const*, unsigned short const*)
25.87     37.74    13.27                             display_img_nc(short, short, short, unsigned short const*)
  3.71     39.65     1.90                             pixcopy(unsigned short*, unsigned short const*, unsigned short const*)
  1.84     40.59     0.94                             display_img_wc(short, short, short, unsigned short const*)
  1.66     41.44     0.85  8488408     0.00     0.00  display_img_aux(unsigned int, short, short, signed char, int, int)
  0.78     41.84     0.40  5503238     0.00     0.00  obj_t::display(int, int) const
  0.70     42.20     0.36        1     0.36     7.87  karte_t::interactive(unsigned int)
  0.62     42.52     0.32                             void display_img_pc<(pixcopy_routines)0>(short, short, short, unsigned short const*)
  0.59     42.82     0.30  8293189     0.00     0.00  get_xrange_and_step_y(int&, int&)
  0.59     43.12     0.30  2268735     0.00     0.00  objlist_t::display_obj_bg(short, short, unsigned char) const
  0.55     43.40     0.28    33167     0.00     0.00  interrupt_check(char const*)
  0.52     43.66     0.27   113496     0.00     0.00  log_t::debug(char const*, char const*, ...)
  0.51     43.92     0.26  8899568     0.00     0.00  clip_line_t::inc_y(xrange&, int&, int&) const
  0.47     44.16     0.24                             create_alpha_tile(bild_besch_t const*, signed char, bild_besch_t const*)
  0.43     44.38     0.22     4305     0.00     0.00  karte_ansicht_t::display_region(koord, koord, short, short, bool)
  0.37     44.58     0.19 12137255     0.00     0.00  obj_t::is_moving() const
  0.37     44.77     0.19                             BZ2_bzDecompress
  0.36     44.95     0.18  1958775     0.00     0.00  grund_t::display_obj_all(short, short, short, bool) const
  0.35     45.13     0.18 14600202     0.00     0.00  planquadrat_t::get_kartenboden() const
  0.35     45.31     0.18    63369     0.00     0.00  karte_t::is_fast_forward() const
  0.33     45.48     0.17  9002641     0.00     0.00  karte_t::access(int, int) const
  0.31     45.64     0.16 12729435     0.00     0.00  karte_t::is_within_limits(short, short) const
  0.31     45.80     0.16  1958775     0.00     0.00  objlist_t::display_obj_fg(short, short, unsigned char, bool) const
  0.29     45.95     0.15                             display_fb_internal(short, short, short, short, unsigned short, bool, short, short, short, short)
  0.27     46.09     0.14    12576     0.00     0.00  dr_sleep(unsigned int)
  0.27     46.23     0.14                             longest_match
  0.21     46.34     0.11 20861272     0.00     0.00  karte_ptr_t::operator->()
  0.21     46.45     0.11 10537638     0.00     0.00  grund_t::get_hoehe() const
  0.21     46.56     0.11  4965882     0.00     0.00  local_display_obj_bg(obj_t const*, short, short)
  0.21     46.67     0.11    40171     0.00     0.00  display_text_proportional_len_clip_rgb(short, short, char const*, unsigned short, unsigned short, bool, int)
  0.21     46.78     0.11     4305     0.00     0.00  karte_ansicht_t::display(bool)

kierongreen

Nothing like good scientific evidence to make a decision on! :) In terms of practical usage by pak authors, how many objects were on the screen to get that kind of slowdown?

Attached is patch which simply swaps the red and blue labels around for alpha colour components (which are used for landscape tiles at present). Just checking here before committing that red is always the highest bits in the pixel and blue the lowest? (when I originally wrote the code I assumed it was the other way round but seemingly not...). Also is this order of colour bits true across all platforms (maybe I'm getting slightly paranoid about endianess...)?