32bit Graphics Extra Zoom Patch

[gugusilva]

Whenever I get an error when I open the game.

• *** OpenTTD Crash Report ***
  
  Crash at: Fri Sep 25 01:36:42 2009
  
  Crash reason:
  Exception: C0000005
  Location: 00516167
  Message: <none>
  
  OpenTTD version:
  Version: r17608M (2)
  NewGRF ver: 080044c8
  Bits: 32
  Endian: little
  Dedicated: no
  Build date: Sep 22 2009 14:49:03
  
  Registers:
  EAX: 013C6E4C EBX: 00000005 ECX: 00000000 EDX: 00000058
  ESI: 0012F9DC EDI: 013C70BF EBP: 0012F9BC ESP: 0012F9A0
  EIP: 00516167 EFLAGS: 00010246
  
  Bytes at instruction pointer:
  8A 14 0A 88 10 40 4B 75 F4 89 45 10 E9 55 FF FF FF 8B 4E 04 89 4D F0 0F
  
  Stack trace:
  00700550 00000000 00000000 01AE5E7D 00000000 020B25A4 00000024 0012FA2C
  0041AB95 00000000 00000002 013C6E4C 800004E0 00FFFFFF 00000000 020AFCE8
  00000000 00000000 00000000 00000036 00000014 00000036 00000014 00000057
  00000008 013C59E8 00000280 00000000 00000000 00000014 00000036 00000000
  00000000 00000000 00000000 0012FA4C 0041A9CF 0000023F 000000F7 00000002
  FFFFFFFF 00000000 0041A9CF 0012FA7C 0044353D 0000023F 000000F7 00700550
  00700594 05A2B8C8 05A261D8 0000023F 000000F7 00000B8C 05A260A4 0012FAC0
  00443A2B 007005A0 000001E8 00000002 00D4DFE8 00000002 000000F0 000001E8
  0012FBAC 013C59E8 FFFFFA02 00000B8C 00000280 000001E0 00000280 00000002
  0012FAE4 00443B44 000001E8 000000F0 000001E0 0012FBAC 00000000 00000098
  FFFFFEF2 0012FB14 00443BDC 000000F0 00000280 000001E0 00000000 00D7F648
  00D4D5A0 0000001A 00000000 000001E0 000001E8 0012FB6C 00448C8F 00D4D5A0
  00D7F648 00447F30 00D4D5A0 00D4D5A0 004470DD 00D4D5A0 00D4D5A0 00D4D5A0
  000001E0 00000032 00D4D5A0 0012FB6C 00000086 0012FBAC 0044AC47 00D4D5A0
  000001E8 000001E0 00000097 0012FB90 0045FF28 00D4D5A0 0012FBAC 0044AC47
  0012FCF4 00D4D5A0 00000000 000001E8 0012FBC8 0044ACAC 00000000 00000280
  00000097 000001E0 00000280 013A01E8 000001E8 00000000 00000098 000001E0
  00000280 00000002 0012FC18 0041B185 00000000 00000000 00000280 000001E0
  00000280 0000000A 0041B2F4 00000000 00006000 00000000 0000FFFF 7E37A78F
  000001E0 00000280 000001E0 00D4A7C0 00000000 00000000 0012FC34 0044CD86
  7E37A78F 390A08E9 00000000 0012FC30 77E5597F 00000000 0054539D 006DB328
  00000002 0012FD14 00000000 0012FC38 390A08E9 390A0907 00000000 00000000
  00160896 0000C0BF 00000708 00000028 390A08D9 00000098 000000EB 0042B6D5
  0012FD2C 0012FE30 00000001 0000FDE8 010208D4 00000000 00000934 00000000
  
  Operating system:
  Name: Windows
  Release: 5.1.2600 (Service Pack 3)
  MSVC: Yes
  
  Configuration:
  Blitter: 8bpp-optimized
  Graphics set: original_windows
  Language: brazilian_portuguese.lng
  Music driver: dmusic
  Sound driver: win32
  Sound set: original_windows
  Video driver: win32
  
  AI Configuration:
  0: Human
  
  Libraries:
  FreeType: 2.3.9
  ICU: 4.2.1
  
  Module information:
  C:\Arquivos de programas\OpenTTD\openttd.exe handle: 00400000 size: 2928128 crc: 76228173 date: 2009-09-22 17:50:28
  C:\WINDOWS\system32\ntdll.dll handle: 7C900000 size: 721920 crc: 0F778B0D date: 2008-04-13 21:20:08
  C:\WINDOWS\system32\kernel32.dll handle: 7C800000 size: 1028608 crc: FD4C55BF date: 2008-04-13 21:20:30
  C:\WINDOWS\system32\WINMM.dll handle: 76B20000 size: 179200 crc: D899F0F5 date: 2008-04-13 21:20:44
  C:\WINDOWS\system32\ADVAPI32.dll handle: 77F50000 size: 683520 crc: B8C7199D date: 2008-04-13 21:20:24
  C:\WINDOWS\system32\RPCRT4.dll handle: 77DB0000 size: 584704 crc: B0B9F671 date: 2008-04-13 21:20:40
  C:\WINDOWS\system32\Secur32.dll handle: 77F20000 size: 56320 crc: F1D033E2 date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\GDI32.dll handle: 77E50000 size: 285184 crc: E17AD0B5 date: 2008-04-13 21:20:28
  C:\WINDOWS\system32\USER32.dll handle: 7E360000 size: 579072 crc: 48E4727E date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\WS2_32.dll handle: 71A70000 size: 82432 crc: 6BD7EDDD date: 2008-04-13 21:20:46
  C:\WINDOWS\system32\msvcrt.dll handle: 77BF0000 size: 343040 crc: E2A93694 date: 2008-04-13 21:20:36
  C:\WINDOWS\system32\WS2HELP.dll handle: 71A60000 size: 19968 crc: DC53E155 date: 2008-04-13 21:20:46
  C:\WINDOWS\system32\SHELL32.dll handle: 7C9C0000 size: 8491008 crc: 1A42E0BE date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\SHLWAPI.dll handle: 77EA0000 size: 474112 crc: 88F2F6BB date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\IMM32.DLL handle: 76360000 size: 110080 crc: BCF4D8FF date: 2008-04-13 21:20:30
  C:\WINDOWS\WinSxS\x86_Microsoft.Windows.Common-Controls_6595b64144ccf1df_6.0.2600.5512_x-ww_35d4ce83\comctl32.dll handle: 773B0000 size: 1054208 crc: 44537A5F date: 2008-04-13 21:17:58
  C:\WINDOWS\system32\comctl32.dll handle: 5D510000 size: 617472 crc: C733BF22 date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\SHFolder.dll handle: 76760000 size: 25088 crc: 5F870556 date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\wdmaud.drv handle: 72CD0000 size: 23552 crc: DB21424A date: 2008-04-13 22:21:28
  C:\WINDOWS\system32\WINTRUST.dll handle: 76C10000 size: 176640 crc: 00D461C9 date: 2008-04-13 21:20:44
  C:\WINDOWS\system32\CRYPT32.dll handle: 77A60000 size: 605184 crc: 756C1B6D date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\MSASN1.dll handle: 77B00000 size: 57344 crc: 24DF9AC1 date: 2008-04-13 21:20:34
  C:\WINDOWS\system32\IMAGEHLP.dll handle: 76C70000 size: 144384 crc: 3BB360E2 date: 2008-04-13 21:20:30
  C:\WINDOWS\system32\msacm32.drv handle: 72CC0000 size: 20992 crc: 39FBED6A date: 2001-10-28 17:07:02
  C:\WINDOWS\system32\MSACM32.dll handle: 77BC0000 size: 71680 crc: 6ECA0834 date: 2008-04-13 21:20:34
  C:\WINDOWS\system32\midimap.dll handle: 77BB0000 size: 18944 crc: FC5ABE09 date: 2008-04-13 21:20:32
  C:\WINDOWS\system32\ole32.dll handle: 774C0000 size: 1287168 crc: 1EF8812C date: 2008-04-13 21:20:38
  C:\WINDOWS\system32\MSCTF.dll handle: 746E0000 size: 297984 crc: B4BC3FC7 date: 2008-04-13 21:20:34
  C:\WINDOWS\system32\MPK\MPK.dll handle: 10000000 size: 73728 crc: 01020328 date: 2008-03-24 14:59:38
  C:\WINDOWS\system32\CLBCATQ.DLL handle: 76FB0000 size: 498688 crc: 55F263EB date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\COMRes.dll handle: 77030000 size: 821760 crc: 083844EA date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\OLEAUT32.dll handle: 77100000 size: 551936 crc: 8500C952 date: 2008-04-13 21:20:38
  C:\WINDOWS\system32\VERSION.dll handle: 77BE0000 size: 18944 crc: 71A2631D date: 2008-04-13 21:20:42
  C:\WINDOWS\system32\dmime.dll handle: 59A70000 size: 181248 crc: F5E3F4F9 date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\DSOUND.dll handle: 73EC0000 size: 367616 crc: 02DEA484 date: 2008-04-13 21:20:28
  C:\WINDOWS\system32\dmusic.dll handle: 6CEE0000 size: 104448 crc: 5D9D362C date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\KsUser.dll handle: 73E90000 size: 4096 crc: 7B8F3899 date: 2008-04-13 22:20:32
  C:\WINDOWS\system32\dmsynth.dll handle: 6CF00000 size: 103424 crc: 43C8A885 date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\dmloader.dll handle: 6CF70000 size: 35840 crc: 4B88447E date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\msctfime.ime handle: 75290000 size: 177152 crc: 81E58825 date: 2008-04-13 21:18:54
  C:\WINDOWS\system32\mswsock.dll handle: 71A10000 size: 247808 crc: 16DEA431 date: 2008-04-13 21:20:36
  C:\WINDOWS\system32\hnetcfg.dll handle: 60B30000 size: 346624 crc: A910246B date: 2008-04-13 21:20:30
  C:\WINDOWS\System32\wshtcpip.dll handle: 71A50000 size: 19456 crc: 819BA77D date: 2008-04-13 21:20:46
  C:\WINDOWS\system32\dmstyle.dll handle: 6CF20000 size: 105984 crc: 86C21EE0 date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\dmband.dll handle: 6D120000 size: 28672 crc: F21D5FF6 date: 2008-04-13 21:20:26
  C:\WINDOWS\system32\psapi.dll handle: 76BD0000 size: 23040 crc: BE23874E date: 2008-04-13 21:20:38
  
  ---- gamelog start ----
  Tick 62675: game loaded
  Conversion from OTTD savegame without gamelog: version 4, 1
  Revision text changed to r17608M, savegame version 127, modified, _openttd_newgrf_version = 0x080044c8
  New game mode: 0 landscape: 1
  ---- gamelog end ----
  
  *** End of OpenTTD Crash Report ***

[maquinista]

I have seen this

Code: Select all

8bpp-optimized

Did You modified the file openttd.cfg?
http://wiki.openttd.org/32bpp_Extra_Zoo ... imitations

You need change it in order to run the game.

[Rubidium]

If it crashes early enough the configuration file has not been read and the crash log will show the defaults. Nevertheless, it shouldn't crash even if the wrong blitter is selected.

Anyhow, with the crash.dmp, the pdb and executable it's up to the person who compiled OpenTTD to give you a (semi-)proper stacktrace.

[gugusilva]

Tem alguem ai que fala Português?
Is someone here who speaks Portuguese?
Sou brasileiro e não sei muito de Inglês.
I am Brazilian and I do not know much English.

[BeeJAy]

Hi there, I see that it does crash if the blitter is not corrected first run, generally it is understood that you must set the setting before your first run but I will dig around the code and see if I can edit the default openttd.cfg values, for now download this:

openttd.cfg

(57 Bytes) Downloaded 155 times

Put it in your "My Documents" folder and run the game, it should load fine after that.

[gugusilva]

Hi there, I see that it does crash if the blitter is not corrected first run, generally it is understood that you must set the setting before your first run but I will dig around the code and see if I can edit the default openttd.cfg values, for now download this:

openttd.cfg

Put it in your "My Documents" folder and run the game, it should load fine after that.

Thanks

[BeeJAy]

It is done.

The game will start up with the default blitter set to 32bpp-optimized and the default sprite_cache_size set to 64.

I chose to set those values by default in the configuration file when first loaded because they can both be set in the same area of the same source file (making the diff smaller) and when you open the config file you can visibly see the settings have been set to those values.

The latest diff is here: (Keep in mind it's a newer revision than the latest nightly file as of right now but it seems ok)

32bpp_17633_v9_fixes.diff

(103.3 KiB) Downloaded 177 times

Windows Binaries:

OpenTTD 32bpp Extra Zoom r17633 32-Bit
OpenTTD 32bpp Extra Zoom r17633 64-Bit

Remember to copy all files over, if any of them have changed since the last diff the game won't run.

[Lord Aro]

so whats been changed?

[BeeJAy]

Nothing has really changed for people who have already used the patch before, it just includes a failsafe, if you don't set the blitter and sprite cache size in the cfg file it does it itself on first run.

There may have been some fixes for a few crashes that occured in earlier trunk revisions as well but If you didn't get any then you probably won't notice anything different.

[GeekToo]

cool! someone needs to update thitle of the thread
next fix required:get all the company colours to work

I did start some work on that a while ago:
http://www.tt-forums.net/viewtopic.php?p=790396#p790396

but nobody seemed interested too much, so I stopped it again.
But before changing anything, it's best to get some requirements settled:
So what exactly does not work in your opinion, and how should it be changed?

There are some things that complicate the matter:
-colours of the sprite pngs are not standardized, so the original truck or train or station can be red or orange or green or..
-In the set of in-game company colors some of them are variations of the same colour (hue, that is) with different brightness, like white and grey. Since this patch uses the brightness of the original sprite to set the brighness of the blended sprite (so the hue changes for CC, but not the brightness), how do you propose to make the difference between gray and white. I do not want to go to the original game's blending, where the original sprite pixel is replaced by the mask file's one, effectively making it 8bpp in the blended areas again (==ugly).
-the 3D renderers that are used to generate the png, also use small variations in hue to add some (desired) noise in certain areas. So a plain colorization algorithm(make it all the same hue) would also lose some of the detail of the original, not to mention the fact that plain white highlights (like reflections) are also coloured, which doesn't look very good (but of course better than 8bpp).

So, given this information, provide some ideas how you would like it to be solved.
Example:
original rgb : ff, 00, 00 (red) CC colour: blue 00,00,ff ---> blend 00, 00, ff (not too hard)
CC colour: white:ff,ff,ff ----->blend (??hmm, now what?)
ff, 00, 80 CC colour: blue 00,00,ff ------>blend (?? more hmm)


Also remember any algorithm you come up with needs to be executed in the blitter, so it must be fast, i.e. no fancy math stuff etc. that would make things very slow. Another option, premultiply every sprite that contains CC with all possible CCs when it is loaded, will result in needing a lot more memory runtime. Yet another option, provide a separate sprite png for every CC, will mean that the sprite needs to be loaded for every other CC, more memory, and creating a lot more png's by the graphics creators.
I hope I've given some insight in why this is not a very easy problem to solve, a good discussion about this would be nice.


@BeeJAy, thanks for the updates, actually I haven't checked the diffs, I do my own svn-ing, but some guys seem to be happy you did some syncs

[tsjook]

Well GeekToo, I, for one, am definitely interested! Keep up the good work.

I have one question left which is semi-related: In game there are two colour versions of many buildings. For instance, the temperate "shops and offices" are normally red, but will also appear in white in 8bpp OpenTTD. My question is: is this also done through an 8bbp mask in 32bpp OpenTTD? Or, is it done through a completely different sprite, allowing us to replace one building with two completely different buildings in 32bpp?

[GeekToo]

The former, the color variations are created by doing some palette shuffling in 8bpp.

[maquinista]

GeekToo: I'm very interested in this patch, but I am unable to compile the source. I always download the binaries.

Well GeekToo, I, for one, am definitely interested! Keep up the good work.

I have one question left which is semi-related: In game there are two colour versions of many buildings. For instance, the temperate "shops and offices" are normally red, but will also appear in white in 8bpp OpenTTD. My question is: is this also done through an 8bbp mask in 32bpp OpenTTD? Or, is it done through a completely different sprite, allowing us to replace one building with two completely different buildings in 32bpp?

If the color mask doesn't work well in this building, It can be coded without them.

[Migran]

I downloaded
OpenTTD 32bpp Extra Zoom r17633 32-Bit and then apply the patch 32bpp_17633_v9_fixes.diff

Added graphics file (32bpp. Tar), in file openttd.cfg written
[misc]
sprite_cache_size = 64
blitter = 32bpp-optimized

But the game still runs on 8bpp - what to do and how to fix? I want to play with 32bpp = \


ps.
if you can - upload your already finished, the version 32bpp and give me a link for downloading

[Gremnon]

Are you using OpenGFX? If so, change to the original Windows/DOS graphics instead.

[maquinista]

cool! someone needs to update thitle of the thread
next fix required:get all the company colours to work

I did start some work on that a while ago:
http://www.tt-forums.net/viewtopic.php?p=790396#p790396

but nobody seemed interested too much, so I stopped it again.
But before changing anything, it's best to get some requirements settled:
So what exactly does not work in your opinion, and how should it be changed?

There are some things that complicate the matter:
-colours of the sprite pngs are not standardized, so the original truck or train or station can be red or orange or green or..
-In the set of in-game company colors some of them are variations of the same colour (hue, that is) with different brightness, like white and grey. Since this patch uses the brightness of the original sprite to set the brighness of the blended sprite (so the hue changes for CC, but not the brightness), how do you propose to make the difference between gray and white. I do not want to go to the original game's blending, where the original sprite pixel is replaced by the mask file's one, effectively making it 8bpp in the blended areas again (==ugly).
-the 3D renderers that are used to generate the png, also use small variations in hue to add some (desired) noise in certain areas. So a plain colorization algorithm(make it all the same hue) would also lose some of the detail of the original, not to mention the fact that plain white highlights (like reflections) are also coloured, which doesn't look very good (but of course better than 8bpp).

So, given this information, provide some ideas how you would like it to be solved.
Example:
original rgb : ff, 00, 00 (red) CC colour: blue 00,00,ff ---> blend 00, 00, ff (not too hard)
CC colour: white:ff,ff,ff ----->blend (??hmm, now what?)
ff, 00, 80 CC colour: blue 00,00,ff ------>blend (?? more hmm)


Also remember any algorithm you come up with needs to be executed in the blitter, so it must be fast, i.e. no fancy math stuff etc. that would make things very slow. Another option, premultiply every sprite that contains CC with all possible CCs when it is loaded, will result in needing a lot more memory runtime. Yet another option, provide a separate sprite png for every CC, will mean that the sprite needs to be loaded for every other CC, more memory, and creating a lot more png's by the graphics creators.
I hope I've given some insight in why this is not a very easy problem to solve, a good discussion about this would be nice.


@BeeJAy, thanks for the updates, actually I haven't checked the diffs, I do my own svn-ing, but some guys seem to be happy you did some syncs

I don't know how It is implemented now, but I suggest this:
Get the RGB values of a pixel, and short it from higher value to lower value.
If the CC is orange, use the higher value in the red, use the middle value in the green and use the lower value in the blue.
If the CC is red, use the higher value in red. The green and blue values should be the average of middle and lowers values.
WITH!!!!! green, the same, but with the higher value in green. The red and blue WITH!!!!! the average...
With green, the average of the three colours, in red, green and blue.
Also, I think that pink could be made with the average between red and grey algorithms.

I don't know if this idea is enough fast.

[Zephyris]

-colours of the sprite pngs are not standardized, so the original truck or train or station can be red or orange or green or..

So this is a bit of a mess... In short, without significant calculation, it is not possible to use the data in the image for a starting value for hue or saturation. Therefore the only accessible data is the luminance. This is easy to grab quickly from the image as the max of r,g,b or the average of r,g,b.

-the 3D renderers that are used to generate the png, also use small variations in hue to add some (desired) noise in certain areas.

Unfortunately without being able to recover the hue information from the starting image this is not possible.

-In the set of in-game company colours some of them are variations of the same colour (hue, that is) with different brightness, like white and grey.

So the recolouring algorithm has to be able to colourise with hue and saturation.

not to mention the fact that plain white highlights (like reflections) are also coloured

If the correct recolouring algorithm is used then this isn't a problem.

Therefore try this:
This is a basic recolouring algorithm to give r,g,b from h,s,l; it is based on http://en.wikipedia.org/wiki/HSL_and_HS ... ifications
It would probably be too slow to be used to recalculate every pixel of the sprites, so would be best used to generate a lookup table for the 256 grey values. This would make the recolouring algorithm a simple max of r,g,b followed by an array lookup.

The values put into this algorithm would be:
[*]h: a user/code specified hue for that company colour (0-1).
[*]s: a user/code specified saturation for that company colour (0-1).
[*]l: the luminance of the pixel, increased or decreased by a user/code specified luminance adjustment value (0-1).

This is written in the ImageJ (a scientific image editing program) macro language - it is a heavily stripped down Java-like language which should be easily readable as pseudocode.

Code: Select all

function HSLtoRGB (h,s,l) {

	if (s==0) {
		red=round(255*l);
		green=round(255*l);
		blue=round(255*l);
	} else {
		if (l<0.5) {
			a=l*(1+s);
		} else if (l>=0.5) {
			a=l+s-l*s;
		}
		b=2*l-a;

		u=h+1/3;
		if (u<0) {
			u=u+1;
		} else if (u>1) {
			u=u-1;
		}
		v=h;
		if (v<0) {
			v=v+1;
		} else if (v>1) {
			v=v-1;
		}
		w=h-1/3;
		if (w<0) {
			w=w+1;
		} else if (w>1) {
			w=w-1;
		}

		if (6*u<1) {
			red=round(255*(b+(a-b)*6*u));
		} else if (2*u<1) {
			red=round(255*a);
		} else if (3*u<2) {
			red=round(255*(b+(a-b)*((2/3)-u)*6));
		} else {
			red=round(255*b);
		}
		if (6*v<1) {
			green=round(255*(b+(a-b)*6*v));
		} else if (2*v<1) {
			green=round(255*a);
		} else if (3*v<2) {
			green=round(255*(b+(a-b)*((2/3)-v)*6));
		} else {
			green=round(255*b);
		}
		if (6*w<1) {
			blue=round(255*(b+(a-b)*6*w));
		} else if (2*w<1) {
			blue=round(255*a);
		} else if (3*w<2) {
			blue=round(255*(b+(a-b)*((2/3)-w)*6));
		} else {
			blue=round(255*b);
		}
	}

	value=red<<16+green<<8+blue<<0;

	return(value);

}

I tested the recolouring on one of the trains, I pushed it to a bright red (h=0.0; s=0.8; dl=0.0) and a dark brown (h=0.2; s=0.3; dl=-0.2); notice how you can change the image brightness and not colourise the highlights at high saturations.

[tsjook]

The examples look very impressive! Could this also be used to make an alternate color mask for buildings?

[GeekToo]

Zephyris and Maquinista, thanks for your input.
I'm updating my code now to the latest trunk, and then I'll start working on the alternate CC algorithms. I think that esp. Zephyris' proposal is very promising, Maquinista's version does look a bit what is present now. On Zephyris proposal, I think there is room for optimisation, like using 256 iso of 255 as factors, which results in an 8 bits shift, that is much faster than multiplication by 255, and by using ints for the hsl values iso floats. And/or maybe indeed use a lookup table.
But let's work on that later, first I want to see how it looks, when that is OK, we can always optimize when the algorithm is stable.

Tsjook, depends on what you mean with alternate: if you mean user settable, then no, if you mean that the colour variations in the houses will be using this new blending mechanism, then yes.

[Zephyris]

On Zephyris proposal, I think there is room for optimisation, like using 256 iso of 255 as factors...

I should have said - the macro language I am used to makes no distinction between variable types (I think internally everything is a float ) and I have made no attempts at optimising the algorithm! But I am glad you find it interesting, there are probably faster h,s,l to r,g,b algorithms around, I'll have a look...