News:

Simutrans Forum Archive
A complete record of the old Simutrans Forum.

Updated application icons

Started by Max-Max, September 12, 2013, 11:30:58 PM

Previous topic - Next topic

0 Members and 1 Guest are viewing this topic.

An_dz

Quote from: Max-Max on September 27, 2013, 01:17:37 AM
@An_dz

I did reduce your Windows Icons a bit. For example, a 256x256 in 256 colours isn't supported in any of the Windows versions. So I removed the sizes and colour versions not specified by Microsoft for an application icon. I have not rescaled or changed any pixels, only removed the some formats.
Sorry to say but you're wrong. "Icon files require 8-bit and 4-bit palette versions as well, to support the default setting in a remote desktop."

There's also a note that 40x40 format is recommended for crisper look on Alt+Tab.

Quote from: Max-Max on September 27, 2013, 01:17:37 AM
Do you have more application icons for Release candidate and debug? :P
We can use the "Experimental Icon", I made the icon but later figured it doesn't fit Simutrans Experimental.

Max-Max

Under the nice colour picker image we can read:
-"Only a 32-bit copy of the 256x256 pixel image should be included, and only the 256x256 pixel image should be compressed to keep the file size down."

Sure we can add all sizes that Windows automatically does by itself, scaling between 32 and 256 with pretty good result. As long it doesn't add anything to the quality of the image I don't see why we should add them. The icon files can be quite big if all sizes and colour versions are added.

Anyway, you are the artist and it is your icon, you decide ;)

QuoteWe can use the "Experimental Icon", I made the icon but later figured it doesn't fit Simutrans Experimental.
Since a release candidate is between a nightly and a release, I was thinking of the Simutrans icon with a sunrise :) What do you think?

...and one overlay image for debug compiled maybe?
I'm writing the resource script so it will use different application icons depending on the compile settings such as Debug, and Simutrans versions (nightly, release candidate and release).
- My code doesn't have bugs. It develops random features...

kierongreen

8 and 4 bit versions really won't add much to filesize. Not that I'd like to try and use Simutrans over remote desktop!

An_dz

Quote from: Max-Max on September 28, 2013, 02:19:56 AM
Under the nice colour picker image we can read:
-"Only a 32-bit copy of the 256x256 pixel image should be included, and only the 256x256 pixel image should be compressed to keep the file size down."
Thanks, should have read fully.

Quote from: Max-Max on September 28, 2013, 02:19:56 AM
Since a release candidate is between a nightly and a release, I was thinking of the Simutrans icon with a sunrise :) What do you think?
Nice idea. Night -> Dawn -> Day

Quote from: Max-Max on September 28, 2013, 02:19:56 AM
...and one overlay image for debug compiled maybe?
Don't get it. Can't we use the experimental icon?

Ters

Quote from: kierongreen on September 28, 2013, 02:38:52 AM
8 and 4 bit versions really won't add much to filesize. Not that I'd like to try and use Simutrans over remote desktop!

One might still see the icon if one logs remotely onto a machine that is used to play Simutrans locally.

Max-Max

#40
Quote from: Ters on September 28, 2013, 07:44:25 AM
One might still see the icon if one logs remotely onto a machine that is used to play Simutrans locally.
If there isn't a 4 or 8 bit available, Windows will generate one. How ever I'm not opposing the 4- or 8- bit versions, just the not so common sizes...

***EDIT***
@An_dz
The Simutrans versions Release, Release Candidate and Nightly are set by a define in the code. When compiling the target can be release or debug where debug adds debug information. Any of the Simutrans versions can be compiled as a debug version.

To easily see if  the target was a release or debug I was thinking to put an debug overly on each of the 3 Simutrans icons.
- My code doesn't have bugs. It develops random features...

prissi

I always release debug builds on sourceforge, so an overlay would not make sense.

Max-Max

#42
Quote from: prissi on September 28, 2013, 08:10:10 PM
I always release debug builds on sourceforge, so an overlay would not make sense.
Does every one know that it is a debug build? And if you have one release build and one debug build, how do you tell the difference ???
It makes sense for anyone working locally and debugging before a patch is created. A debug version can slow down the code and it is good to be able to see why Simutrans runs slower than usual...  :o

***EDIT***
Another way to do it is to add (debug) after the version "Version 112.4 Sep 28 2013 r990:991M (debug)" (in fact this is what I usually do in all software I write). The release target will not have anything added...

Maybe this is better than the icon overlay...
- My code doesn't have bugs. It develops random features...

prissi

I release debug builds for several reasons (they are optimised debug builds, so slowdown is not so bad) Main reason is that some debug messages are not printed, and assertions are off. This make "simutrans is crashing" postings very difficult to remote debug (or find out if a new bug was discovered).

Max-Max

@Prissi

I wasn't questioning why you posted a debug version, that is quite logical. I just wanted to be able to tell if the Simutrans.exe was a release or debug build by adding "(debug)" after the version info in the banner.

@An_dz
QuoteNice idea. Night -> Dawn -> Day
Is this something you are working on? Should I wait for it?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on September 28, 2013, 09:38:37 PM
I just wanted to be able to tell if the Simutrans.exe was a release or debug build by adding "(debug)" after the version info in the banner.

I don't build Simutrans as debug or release (always debug, so I can hook up the debugger immediately), but as optimized or non-optimized (rarely the latter). So for me, I'd want something indicating that.

Max-Max

Quote from: Ters on September 28, 2013, 09:46:39 PM...but as optimized or non-optimized (rarely the latter). So for me, I'd want something indicating that.
Is there an automatic define for it, like _OPTIMIZED?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on September 28, 2013, 10:23:18 PM
Is there an automatic define for it, like _OPTIMIZED?

Probably not, and I don't think there is for debug either. You have to explicitly send that define to the compiler from the build system. IDEs might include this in their default debug profiles, but that's only an IDE thing and may not apply to custom profiles.

There are also multiple optimization and debug levels. (Not so sure about the latter for MSVC, though.)

Max-Max

MSVC defines _DEBUG (debug) and NDEBUG (release) if you make a new project. However the _DEBUG also makes the MSVC compiler to link a debug class and generates a link error in the current Simutrans code.

Since we already have a DEBUG we can use that one instead, but how is it used? AFIK Prissi always compile debug versions, even for release. The question is can we detect the target; debug,release, with the current defines we have?
- My code doesn't have bugs. It develops random features...

Ters

The problem is that what you write might be unique to MSVC. On GCC debug macros are defined by the project (in this case Simutrans) in its build system for use in its own use in its own headers. Including debug symbols is controlled via a command line switch, which according to http://stackoverflow.com/questions/7998100/does-gcc-define-anything-when-g-is-specified doesn't reveal its activation to the code. Linking to debug versions of libraries is controlled by explicitly linking to debug version of libraries, in other words specifying -lfoobar_d (if the debug version is called libfoobar_d.a) rather than -lfoobar on the command line. All these things can be done independently of eachother. One can define DEBUG to, lets say, activate verbose logging, yet still make an executable without debug symbols or linking against debug versions of libraries.

Max-Max

Yes, that was what I said, that we already have a #define DEBUG in the Simutrans code and it would be better to use that one. I guess that gcc, just like most compilers, can set a define from the command line.

Since Prissi (and I guess other gcc users) do, use a make file to compile it would be possible for this to work on all platforms. What I don't know is how we can see the difference between a debug and a release target version. The DEBUG define can have a value, is this value set to something specific for a release target?
- My code doesn't have bugs. It develops random features...

Ters

There are two DEBUG flags in the Simutrans project, which as slightly releated:

Within the code, DEBUG turns on verbose logging and assertions. According to the Makefile, it's either on or off, although there are a few #ifs that checks if DEBUG is greater than or equal to some value.

The other DEBUG flag is in the Makefile. If defined, it sets the first DEBUG flag in the code and adds the compiler flag for debug symbols. Higher values for DEBUG "gradually" disable optimizations.

So the big question is what makes a debug release a debug release? Is it the presence of debug symbols, the presence of verbose logging, both? The Makefile build will make it both, but the code contains clues that sometimes the DEBUG flag within the code is customized to not work as normal. But as Prissi writes, all releases are made with debug symbols and verbose logging on (though not with optimizations turned off). A true debug release in Simutrans would be one in which optimizations are also disabled, which the code won't know about, or with the verbose trace logging turned on, which the Makefile doesn't seem to support out of the box.

An_dz


Fabio

Sweet! :thumbsup:

But dawn imho should have whiter smoke and the headlamp on...

Dwachs

Parsley, sage, rosemary, and maggikraut.

An_dz

Quote from: Fabio on October 02, 2013, 07:50:35 AM
But dawn imho should have whiter smoke and the headlamp on...
Agree, will do.... Tomorrow, gotta sleep zzzzzz....

Max-Max

- My code doesn't have bugs. It develops random features...

Fabio

Another though. 32*32 should be the smallest scale, 24*24 and 16*16 icons could be cropped instead of scaled (the bottom right corner and whatever else fits in the icon).

prissi

Hmm, those look to Smartphonish for me. Somehow I like the semicircle more.

Sarlock

Apple icons :)

I like them...  Nice work!
Current projects: Pak128 Trees, blender graphics

Ters

Quote from: Sarlock on October 02, 2013, 03:05:36 PM
Apple icons :)

Made me think that we might need a fully square icon for Windows 8 Start Screen. (No that I plan using that version in the foreseeable future.)

An_dz

Windows 8 tiles always use the 64x64 icon when using a non-metro (non-shop) app.


Ters

Quote from: An_dz on October 03, 2013, 05:02:21 AM
Windows 8 tiles always use the 64x64 icon when using a non-metro (non-shop) app.



It should really use a bigger icon if possible, but 128x128 is perhaps not in the standard and automatically downscaling a 256x256 might give a too ugly icon.

A quick google revealed that there are apps for creating Modern-looking tiles for starting desktop applications. For Simutrans to really blend in, it would however need a monochrome icon.

prissi

The semicircle with a black background would be a matching starting icon for the App. Is there any way to determine the background color?

Max-Max

@Prissi

I think you can use An_dz icons straight as they are. I have modified the resource script to select the right icon depending the build; nightly, candidate and release.

Here is the new resource script and the icon files it will look for are;
Simutrans_nightly_winapp.ico
Simutrans_candidate_winapp.ico
Simutrans_release_winapp.ico


When it comes to Mac, I have no idea of how this is done so someone with a Mac might be able to modify the Mac files...
- My code doesn't have bugs. It develops random features...

An_dz


Max-Max

Quote from: An_dz on October 04, 2013, 01:34:04 AM

Oohhh... the right one was really minimalistic and nice, reel Win8 feel...  :thumbsup:
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 04, 2013, 04:16:52 AM
Oohhh... the right one was really minimalistic and nice, reel Win8 feel...  :thumbsup:

Looks a bit cloud-like, though. Would it become too cluttered it there were thin lines representing the headlamp and/or wheels?

IgorEliezer

Quote from: Ters on October 04, 2013, 04:45:01 AM
Would it become too cluttered it there were thin lines representing the headlamp and/or wheels?
I'd add the headlamp. It might enhance the character of the loco.

prissi

I still think that for smaller icon sizes the quarter circle is better recognized. The other icon is just a srtange blueish box, while shape could help. (Personally, I do not like the favicon at all, but I do not interfere with forum design.)

About the window8 icon. Could we have the tree and a track? Otherwise it is more like a flying blimp ...

And the last real stable we release was 88.10.5, all other were more or less release candidates although we do not call them. Just after two weeks without bad bugs the announcement was added to (stable).