News:

Use the "Forum Search"
It may help you to find anything in the forum ;).

[Project] GUI Theme

Started by Max-Max, May 31, 2013, 11:12:48 PM

Previous topic - Next topic

0 Members and 3 Guests are viewing this topic.

Max-Max

Some advice needed...

To my understanding we are going to move away from colour index to use the direct RGB565 value instead. I need to store the system colours somewhere and since we use direct RGB valuse I don't need to add them into the same index table as the other special colours.

There is a simcolor.h only with colour defines. Wouldn't it be logical to use this module for colour management, storing colour tables etc... Display.h has grown quite big and imho should only contain low level implementations.

So the question is; should I put my system colour storage + conversion routines in a simcolor.cc ?
- My code doesn't have bugs. It develops random features...

prissi

One can indeed argue that color management can go into its own module. But on the other hand the display routine access the color tables a lot, so the data needs these as globals (as they are now as well). It could as well have the infrastructure for conversion etc. I would place such a file still in display though, since it is low level.

Since this is somewhat a little away from the topic of GUI, perhaps better continue this in a new thread.

Max-Max

It can still be global, just placed in its own module. I'm touching this subject here because the theme manager is reading in the system colours from the theme and my first implementation stored this in the theme manager itself.

With the new RGB system I need to change my implementation and I thought this can go into a global array of PIXVAL. I don't intend to move around anything from the simgraph, but if we are to move over this I can do my implementation in a simcolor.cc instead of putting in more stuff in simgraph...
- My code doesn't have bugs. It develops random features...

prissi

Then do a patch which moves this to simcolor.cc first. (I would not use an array though, I recommend to use single variables.)

Max-Max

Quote from: prissi on October 29, 2013, 01:34:31 PM
Then do a patch which moves this to simcolor.cc first. (I would not use an array though, I recommend to use single variables.)
Why single variables?
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 29, 2013, 01:35:42 PM
Why single variables?

Avoiding magic indicies is one good reason I can think of. Even if the indicies are defined in an enum, I don't think a debugger will do a reverse look up.

Max-Max

Quote from: Ters on October 29, 2013, 04:36:20 PM
Avoiding magic indicies is one good reason I can think of.
To collect them in an array prevents that new system colours are put in different places.
If we decide to change the type, it is easier to maintain.
One legal way to remove magic numbers is precisely to use enums or constants.
If we further down the road decides to turn this into a class, the operator[] can be used so we don't need to change "everywhere".

Quote from: Ters on October 29, 2013, 04:36:20 PM
Even if the indicies are defined in an enum, I don't think a debugger will do a reverse look up.

Yes, the most debuggers do this, at least the ones I have been using, both PC and embedded.
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 29, 2013, 07:36:52 PM
Yes, the most debuggers do this, at least the ones I have been using, both PC and embedded.

For array indicies? Variables can be typed to the enum, so that's expected, but that debuggers know which arrays use which enum, if any, as indicies is something I did not expect.

Quote from: Max-Max on October 29, 2013, 07:36:52 PM
To collect them in an array prevents that new system colours are put in different places.

Why is that a problem? It can in fact be an advantage, as it restricts the ability to parasitize on other existing system colors when one rather should define one's own. But, yes, it's a double-edged thing, which can also interfere with legitimate sharing of settings.

prissi

When I learned programming (which was more like 30+ years back I have to admid) then the purpose of any data structure is to collect data that is used together. However, using a text color does not mean I will use the player color next. So I fail to see an intrinsic connection between these data.

In the code I would still use symbolic constants HIGHLITE_TEXT_COLOR and the like, since the predefined COLOR_RED (and complemented by RGB_RED maybe) is still easier to see (and type) than simcolor_t::gui_color[TEXT_HIGHLITE].

Finally an array is prone to errors: You may end up using ints or whatever (TEXT_HIGHLITE+1) which could later get you into trouble. So save practice is to avoid the unnecessary array.

Max-Max

Well, I have a complete different view of this, how this in the end can be turned into a colour list object further down the road. But I guess "This isn't the Simutrans way", so I will rip out my RGB system colour code because I can see that no one would ever consider to implement it...
- My code doesn't have bugs. It develops random features...

Ters

For me, it's not that it isn't the Simutrans way (arguably, it very much is), it's just that I haven't seen any arguments making a monolithic master array a better choice. There can certainly be compelling arguments for it, but I can only speculate what they are.

Max-Max

Thy are all colours, the same type of data, used in the same way. If we are to create a colour manager that can operate on a list of colours, regardless of what they are used for, some sort of list is needed.

An array can be turned into an object seaming less via the index operator[]. A colour manager can operate on the list such as blending colours, create colour ramps etc... It would also allow a system where the artist can define their own colour ramps (as I proposed in another thread).

If they where to be separate variables, they would still be defined and manipulated in the same spot by the same code anyway. To do an operation on several colours would mean that each colour variable has to be hard coded, and easily forgotten when new are added.

Think colour as in A colour that can be manipulated and organised, not its actual colour, purpose or use...
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 30, 2013, 02:45:08 PM
A colour manager can operate on the list such as blending colours, create colour ramps etc... It would also allow a system where the artist can define their own colour ramps (as I proposed in another thread).

If they where to be separate variables, they would still be defined and manipulated in the same spot by the same code anyway. To do an operation on several colours would mean that each colour variable has to be hard coded, and easily forgotten when new are added.

Color ramps should perhaps be a distinct class, regardless of how everything else is solved.

As for blending colors, I would think

result = blend(my_color, BLACK, 50%)

is more flexible than

color_manager.set(MY_COLOR, my_color)
result = color_manager.blend(MY_COLOR, BLACK. 50%)


There could be a color manager to load some special_colors.dat file, rather than have color definitions scattered among configurations for components and what not. But once loaded, operations like blending should be possible regardless of whether the colors are from there or not. Reading colors out of that color manager into other long term variables (like member variables and globals) will probably be trading space for very little benefit.

Max-Max

The idea of a colour manager isn't only to get a specific colour, it is also to encapsulate colour handling. When I request a colour, I don't need to know if it is a night/day colour, factory colour, player colour, animated colour etc... If the colours are ordered in internal lists, the colour manager updates them when needed. The colour ramp is hidden inside the colour object hence you only need to get a specific colour, nothing else.

The manager updates the internal colour on every animation tick, season tick, day/night, specific clock interval etc... Have some visions and think forward of what we can have. How ever my point is that if they are collected in arrays, these can later on be turned into objects.

Well, but I guess this is too object oriented for Simutrans, so we stick with variables all over the place instead... I will rewrite my already functioning colour code...
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on October 30, 2013, 05:10:47 PM
The idea of a colour manager isn't only to get a specific colour, it is also to encapsulate colour handling. When I request a colour, I don't need to know if it is a night/day colour, factory colour, player colour, animated colour etc... If the colours are ordered in internal lists, the colour manager updates them when needed. The colour ramp is hidden inside the colour object hence you only need to get a specific colour, nothing else.

The manager updates the internal colour on every animation tick, season tick, day/night, specific clock interval etc... Have some visions and think forward of what we can have. How ever my point is that if they are collected in arrays, these can later on be turned into objects.

I rather believe things would be much more clear if there was a color manager for each type of color. Only when doing indexed colors in images is it a necessary evil to combine everything into one list, or rather one list per player (though only one of the lists exists at any one time).

The one asking for a color must know what kind of color it's asking for. If your doing GUI, you don't normally want a color that's changing with the day-night cycle. When asking for a player color, you have to specify which player. It's apples and oranges.

Max-Max

If there was a colour list object, then there could be one instance for each type of colours; player, system, gui, tiles etc...
I never said that ALL colours should be in one single list...

But I will remove this from my code...
- My code doesn't have bugs. It develops random features...

prissi

In order to make Simutrans a little more tablet enabled (and for those with single button mouse), I enabled dragging with the left mouse button, if the query tool "a" is active. (I could make it that any non-dragable tool will activate world dragging but I am not sure this will cause more confusion.)

Ters

Quote from: Max-Max on October 30, 2013, 09:41:23 PM
If there was a colour list object, then there could be one instance for each type of colours; player, system, gui, tiles etc...
I never said that ALL colours should be in one single list...

Tiles are images, they are not colors (they may contain player colors and lights). Apart from that, and the fact that the GUI (ab)uses colors meant for the world, Simutrans already has this. Even the list with all colors. It's an hierarchical thing, with a manager for player colors, a manager for lights, and a manager combining this into one list along with all possible colors, using one set of player colors, and applying day/night darkening. With the exception of player colors, none of this is of relevance to the GUI. Doing something to this code strewn through simgraph?.cc so that it's easier to follow is a good idea, but that is almost wholly off-topic for a GUI theme discussion.

prissi

I though so too, that this is fairly independent from the ongoing discussion. Hence the suggestion to make an independent patch. As a first step I would just collect the working code though.

Max-Max

It is relevant because the GUI uses system colours that needs to be loaded somewhere by the theme manager.

I have an idea and vision of what can be done with such a colour object, giving the artist more possibilities than now. But this is the wrong thread to discuss this. My point was originally that an array can easily be turned into an object further down the road. If colour management is never to be updated there is indeed no point make a transition to object oriented management easy...

How ever, as I said, I will rip out the colour loading I have now and put back all the variables.
- My code doesn't have bugs. It develops random features...

Markohs

I suggest just implement it with the current trunk code (not your GUI patch, just current trunk with the proposed change), and post it as a independent issue. If it's worth it and improves current simutrans in any way, who whould say no.

But only if you decide it's worth doing it or not. :)

Ters

For those interested, here's a topic on how colors are handled in Simutrans: http://forum.simutrans.com/index.php?topic=12796.0

Max-Max

#547
I have honestly tried to make a theme manager patch with the utter most essential files included so it can compile and run. If you want a smaller patch than this, I have to chop it up in smaller pieces that won't compile because of missing updates...

Even if this is the bare minimum, you need the simstring patch I posted here

*** DO READ THIS BEFORE COMMENTING ON THE PATCH ***
1. ThemeManager_Part1 This is the bare minimum to make it compile. A smaller patch will not compile without errors.
2. The colour update isn't included 100%, only files that are needed for the theme manager to compile are included. The result is that when run, all colours are screwed up because they expect an RGB value but get an index instead. ThemeManager_Part2 will contain the colour update for the remaining theme related files. I will post Part 2 shortly...
3. No, I have not done anything about the dialogues yet. To be able to post one patch for each dialogue, we need the theme manager in place first... I will get right to it as the next thing on the list...
4. Do not rewrite the code before we have discussed it!
5. Do not rewrite the code before we have discussed it!
6. Do not rewrite the code before we have discussed it!

Theme Manager Part 1

For a quick test, use the theme files I posted earlier. Drop them into Simutrans/themes

-"The theme pak format is back to the old format, you will need these new ones. I have built both default and aero in this archive ready to drop in and use.
Ready to use theme paks

Here are the photoshop source to the themes
New aero theme source
New default theme source
"


These themes are for reference, I'm sure Prissi will replace them with his version...
- My code doesn't have bugs. It develops random features...

Max-Max

This is part 2 of the theme manager patch with the remaining update for rgb colours (only theme related).

*** DO READ THIS BEFORE COMMENTING ON THE PATCH ***
1. No, I have not done anything about the dialogues yet. To be able to post one patch for each dialogue, we need the theme manager in place first... I will get right to it as the next thing on the list...
2. Do not rewrite the code before we have discussed it!
3. Do not rewrite the code before we have discussed it!
4. Do not rewrite the code before we have discussed it!

Now as soon this is in, I can continue to update the dialogues and fix any related issues...
- My code doesn't have bugs. It develops random features...

prissi

Sorry, this is a little deja vue. I though you was preparing a color manager patch. Instead it is the old theme manager with a color manager added to it. I though Dwachs and me asked to divide images in makeobj instead in simutrans.

But I will first do your makeobj patch before looking more deeply.

Max-Max

Quote from: prissi on November 04, 2013, 11:30:36 AM
Sorry, this is a little deja vue. I though you was preparing a color manager patch. Instead it is the old theme manager with a color manager added to it.
But I was told to repost it in smaller updates... So I posted the makeobj in one patch and the simstring in another and then tried my best to post the theme manager and colour handling in two patches.
There is no colour manager in the code, but meanwhile we had a month long debate about object oriented design the colour system was updated with rgb colours, so I had to adjust my code to it and this made the patch even bigger because of the non indexed system colours you wanted.

Quote from: prissi on November 04, 2013, 11:30:36 AM
I though Dwachs and me asked to divide images in makeobj instead in simutrans.
But I will first do your makeobj patch before looking more deeply.
I did what Dwachs suggested me to do...
Quote from: Dwachs on October 25, 2013, 08:48:24 AM
My proposal would be the following: Could you provide an updated patch(1) that contains the theme-related code, implements the theme for the gui-components, and does not introduce a new pak/cutting system (ie which uses the existing skinverwaltung stuff for compatibility)? That way we would have a smaller patch to discuss. Maybe you posted such a patch earlier - I did not notice as I did not follow this topic from the very beginning.
...
(1)A patch that contains that contains exactly one feature: the theme manager and its relation to the gui components. No white-space changes in unrelated files, no debug code for makeobj, no change to resource file etc.
- My code doesn't have bugs. It develops random features...

Dwachs

The patches now mix (a) new color system, (b) cutting of images, and (c) theme manager.

The patch to move the color system to full rgb colors should come first imho, then the theme manager.
Parsley, sage, rosemary, and maggikraut.

Max-Max

Quote from: Dwachs on November 04, 2013, 02:50:27 PM
The patches now mix (a) new color system, (b) cutting of images, and (c) theme manager.
(a) not my fault, I wanted to build on the existing array system to minimize the impact.
(b) The guard colour cutting is not in there, it uses the current way of designing a skin with he exception of the theme object type in the .dat file (that Prissi added and no one objected about it, even if all previous skin-PAK files became useless) and there is no theme management if the images isn't cut.
To keep the current format without the manager to do the 3x3 grid and still be able to do a frame is impossible!

The more we debate about how this patch is being submitted, more stuff will be updated in trunk forcing me to update my patch and it will grow bigger and bigger...

You guys are telling me to submit small patches with context and working. It is quite impossible to do all this at once. Either you will have small patches (as I started to submit) out of context and maybe even not able to compile or you get a larger one that can be compiled.

Quote from: Dwachs on November 04, 2013, 02:50:27 PM
The patch to move the color system to full rgb colors should come first imho, then the theme manager.
A new colour system isn't in the scope of my project, I simply asked if I should continue on the colour array or not. I was told that it was a stupid idea and everything should be separate variables in RGB, so I did and now I get the blame for doing as I was told  :o

It doesn't matter what I do, or what advice I follow, I feel like the escape goat for everything here...
I really don't think it's my fault this patch has grown this big and as soon it has been implemented I can continue with much smaller patches... We have wasted far too much time already...
- My code doesn't have bugs. It develops random features...

Max-Max

Now when the makeobj patch has been incorporated, what is the status on this one? Are some one looking at it or is it hanging in limbo?
I'm just asking so there isn't any misunderstanding on what is going to be done as the next step...
- My code doesn't have bugs. It develops random features...

Max-Max

Hello?

Should I take this as no one is working or intend to work on my patch?
- My code doesn't have bugs. It develops random features...

prissi

There was an internal questioning how to proceed. As you know there is your and my version on implementing themes. In the end it was two votes for mine, one abstained, and one that my patch should also get proper code review (which certainly not a bad idea).

As it currently stand I am the only one working on the GUI at the moment. As such I am obviously biased for the "classical" way to incorporate skins (and leave the cutting to makeobj). However, I am also still working on some theme designs to have a really useful choice (and to finalize a theme format, which can be the same until the next stable release and is future-proofed. I would of course also welcome code review). So I did not yet commit it.

The other reason I did not commit is simple: I fear by doing the commit you might consider leaving the community, which I would like to avoid (as mentioned several times, you have some original ideas and contributed a lot already). Hence, I would still like to develop the simutrans GUI for tablets, and I would also look forward to semiautomatic cutting in makeobj. Also a more consistent color management is certainly welcomed.

Max-Max

Quote from: prissi on November 10, 2013, 10:38:36 PM
There was an internal questioning how to proceed. As you know there is your and my version on implementing themes. In the end it was two votes for mine, one abstained, and one that my patch should also get proper code review (which certainly not a bad idea).
Has it been a closed voting? Is this "internal" process public or above my head? I have explained my goals and design many times, but it seems like only a few actually has read and/or understood it. How do you know that your design will not interfere with my plans? I have said this so many times now; this isn't the final theme code.

Quote from: prissi on November 10, 2013, 10:38:36 PM
As it currently stand I am the only one working on the GUI at the moment. As such I am obviously biased for the "classical" way to incorporate skins (and leave the cutting to makeobj). However, I am also still working on some theme designs to have a really useful choice (and to finalize a theme format, which can be the same until the next stable release and is future-proofed. I would of course also welcome code review). So I did not yet commit it.
So making new themes is a higher priority than incorporating the basic design first? Finalizing the theme format?!? How can you do that when you don't know what it has to be capable of?
...and useful choices? I provided 2 very useful choices, both as PAK files and full source, but that was of course for my working theme code. What was wrong with them? Based on your arguments, I actually suspect that you never looked at them at all.

Quote from: prissi on November 10, 2013, 10:38:36 PM
The other reason I did not commit is simple: I fear by doing the commit you might consider leaving the community, which I would like to avoid (as mentioned several times, you have some original ideas and contributed a lot already). Hence, I would still like to develop the simutrans GUI for tablets, and I would also look forward to semiautomatic cutting in makeobj. Also a more consistent color management is certainly welcomed.
Regarding cutting, how do you achieve this if all cutting is made in makeobj?
The artist has put a horizontal constraint on a GUI element, but the user needs it to be of the frame type so he can use his big fingers on a touch screen. Now, all images are already cut so Simutrans needs to reassemble them into one image again and then do a new cut. By cutting in make object, you get 8 times more image indexes, something you feared earlier. By cutting in makeobj, you need to recompile makeobj everytime there is an update in how theme images are handled.

By doing the cut in Simutrans we only need one image (resulting in less indexes than we have now per GUI element). We can freely introduce new ways of logic in the cutting without having to update makeobj. This would not make current theme-PAK files obsolete, instead Simutrans can apply the new/updated handling on already generated theme-PAK. So in the end, PAK files becomes smaller and less sensitive to changes compared to a pre cut PAK file.

So let us turn this around. Why is it so much more beneficial to let makeobj generate a myriad of indexed tiny images? Should the theme logic really be in makobj? Isn't makeobj a PAK tool? How these theme images are used is up to Simutrans, not makeobj.

I started this project and invited any one to join me, but no one else was interested. On the contrary I was encouraged because no one really liked to do the GUI stuff I was told. It feels like you have hijacked my project as your own. If we are going to shed sweat and tears over every single little detail, I will eventually give up and just walk away. I don't see any point in investing more than 400 hours in something that is refused because some one doesn't like my object oriented design, have functional code rewritten without even asking, or not take the time to even try understand my work. Not even just apply the full patch and try it out to see how it works...

It doesn't feel fair and square that you guys can commit whatever you like without a single line of critique, even when things break. Prissi changed the Skin format so all skin-PAK files became obsolete and no one even mentioned it. While my working code, still used the same skin-PAK files for backward compatibility was rewritten without even asking a single question about it.

However I did accept the new theme Object because I had planned to introduce this myself, but later down the road when I had a text node in place so we could leave the index based variables...

If I leave or not is entirely up to you... If my work was respected I would feel more encouraged to continue. If you change my implementation you have successfully thrown away my entire project and my visions and I just can't continue...
We have wasted by far too much time already...
- My code doesn't have bugs. It develops random features...

Ters

Quote from: Max-Max on November 11, 2013, 11:35:22 PM
The artist has put a horizontal constraint on a GUI element, but the user needs it to be of the frame type so he can use his big fingers on a touch screen. Now, all images are already cut so Simutrans needs to reassemble them into one image again and then do a new cut. By cutting in make object, you get 8 times more image indexes, something you feared earlier. By cutting in makeobj, you need to recompile makeobj everytime there is an update in how theme images are handled.

By doing the cut in Simutrans we only need one image (resulting in less indexes than we have now per GUI element). We can freely introduce new ways of logic in the cutting without having to update makeobj. This would not make current theme-PAK files obsolete, instead Simutrans can apply the new/updated handling on already generated theme-PAK. So in the end, PAK files becomes smaller and less sensitive to changes compared to a pre cut PAK file.

So let us turn this around. Why is it so much more beneficial to let makeobj generate a myriad of indexed tiny images? Should the theme logic really be in makobj? Isn't makeobj a PAK tool? How these theme images are used is up to Simutrans, not makeobj.

Makeobj is always recompiled whenever how ways, vehicles, buildings, goods and factories are handled changes, so that's not something new. The underlying design principle is effectively that Simutrans is just the game, with virtually no error handling. All data must be passed in a pre-processed form. The exception I'm aware of is ground tiles, which are actually assembled in-game at start-up.

Quote from: Max-Max on November 11, 2013, 11:35:22 PM
I started this project and invited any one to join me, but no one else was interested. On the contrary I was encouraged because no one really liked to do the GUI stuff I was told. It feels like you have hijacked my project as your own. If we are going to shed sweat and tears over every single little detail, I will eventually give up and just walk away. I don't see any point in investing more than 400 hours in something that is refused because some one doesn't like my object oriented design, have functional code rewritten without even asking, or not take the time to even try understand my work. Not even just apply the full patch and try it out to see how it works...

The problem, as I see it (others may have completely different views and issues), is that work on the GUI is very much welcommed, but it has spilled over into the common ground of rendering, image handling, color management and pak files. In hindsight, it was perhaps unavoidable, but it's also areas where changes are more controversial, and consequences more far-reaching, than in the GUI itself. The Simutrans community is very spare-time based. (I've hardly started Simutrans since spring, let alone looked at the code.) That may be an extra cause of conservativism, as people want to be able to recognize how thing are done when comming back after six months, although this is just speculation on my part. I'm more or less just a consultant developer of sorts.

prissi

Regarding the cutting: In the original proposal there was a cutting indicated by color lines. This is probably the best choice, as this is will work on asymmetric boxes and similar. As such is can go into the general list cutter, maybe just specified cutimage instead of image. Just image a button like the attached (following the recent pak192.comic tool design). The green help line would prevent wrong cutting and would still allow makeobj to generate correct images.

And what Ters wrote about the code is very much true. If thing change too much, there is much work for all other to follow it. That and large projects (not only simutrans) tends to stick to working code, i.e. not changing (and reusing) what was already working. Obviously this is not always possible, and the benefit of change must be weighted against the advantages of having a working and understood (if only be getting used to it even) system.

Max-Max

Quote from: Ters on November 12, 2013, 06:17:10 AM
Makeobj is always recompiled whenever how ways, vehicles, buildings, goods and factories are handled changes, so that's not something new. The underlying design principle is effectively that Simutrans is just the game, with virtually no error handling. All data must be passed in a pre-processed form. The exception I'm aware of is ground tiles, which are actually assembled in-game at start-up.
...and just because Simutrans don't do error handling, this is a good thing that never should be improved?

Quote from: Ters on November 12, 2013, 06:17:10 AM
The problem, as I see it (others may have completely different views and issues), is that work on the GUI is very much welcommed, but it has spilled over into the common ground of rendering, image handling, color management and pak files. In hindsight, it was perhaps unavoidable, but it's also areas where changes are more controversial, and consequences more far-reaching, than in the GUI itself. The Simutrans community is very spare-time based. (I've hardly started Simutrans since spring, let alone looked at the code.) That may be an extra cause of conservativism, as people want to be able to recognize how thing are done when comming back after six months, although this is just speculation on my part. I'm more or less just a consultant developer of sorts.
Hmm, lets do a recap on what happen here...
- I used the current skin-PAK format, no changes at all. Prissi introduced a new system that broke all previous skin-PAKs.
- I used the indexed colour system for my new system colours. I was told it was stupid and a new RGB system should be used, so I ripped out my working indexed system colours to replace them with the RGB system, that I didn't introduce.
Again, no one complained about these changes, saying that people wouldn't recognise the code after 6 month...

My questions has still not been answered:
Quote from: Max-Max on November 11, 2013, 11:35:22 PM
Has it been a closed voting? Is this "internal" process public or above my head?
How do you know that your design will not interfere with my plans?
So making new themes is a higher priority than incorporating the basic design first?
Finalizing the theme format?!? How can you do that when you don't know what it has to be capable of?
...and useful choices? I provided 2 very useful choices, both as PAK files and full source, but that was of course for my working theme code. What was wrong with them? Based on your arguments, I actually suspect that you never looked at them at all.
Regarding cutting, how do you achieve this if all cutting is made in makeobj?
The artist has put a horizontal constraint on a GUI element, but the user needs it to be of the frame type so he can use his big fingers on a touch screen. Now, all images are already cut so Simutrans needs to reassemble them into one image again and then do a new cut. By cutting in make object, you get 8 times more image indexes, something you feared earlier. By cutting in makeobj, you need to recompile makeobj everytime there is an update in how theme images are handled.

By doing the cut in Simutrans we only need one image (resulting in less indexes than we have now per GUI element). We can freely introduce new ways of logic in the cutting without having to update makeobj. This would not make current theme-PAK files obsolete, instead Simutrans can apply the new/updated handling on already generated theme-PAK. So in the end, PAK files becomes smaller and less sensitive to changes compared to a pre cut PAK file.

So let us turn this around. Why is it so much more beneficial to let makeobj generate a myriad of indexed tiny images? Should the theme logic really be in makobj? Isn't makeobj a PAK tool? How these theme images are used is up to Simutrans, not makeobj.
- My code doesn't have bugs. It develops random features...