Feature Request 1007911 - COMPLETED [Need Opinion]

[Observer]

I cannot find that screenshot.. do I have to register to see that?

[mpetrov]

The screenshot is right here:
http://vondel.student.utwente.nl/rpg/bug.png

It's in one of the comments made by vondel on the patch tracker.
The screenshot is by him because he found the bug.

[Observer]

The screenshot is right here:
http://vondel.student.utwente.nl/rpg/bug.png

It's in one of the comments made by vondel on the patch tracker.
The screenshot is by him because he found the bug.

Hehehehe ok ok... I see what all the fuzz is about.

I would try to make the window a bit wider and put a new column behind the train number, and not behind the whole train... it would get confusing... I guess.
Well anyway, thats my opinion.

[Bruno]

Hmmm, why didn't u use a "if"...

Code: Select all

if(i<10) pos=...
else if(i<100) pos=...
   else pos=...

There is any problem with that? :$ :$ :$
(i don't know the code )

[DaleStan]

One of

Code: Select all

pos=a+b*int(log10(i)+1);
pos=a+b*int(log10(i));

would work better; it would continue to work on train numbers>999.
This works because floor(log10(i))+1 is the number of digits in the base-10 representation of an integer. For numbers of digits in other bases, use logs in other bases.

[Moriarty]

Oh, so that's what they were trying to teach me in that logs class at school?
I see why i didn't pay attention in it now.

[mpetrov]

I'm a bit curious, how much strain on the CPU does the log instruction put? It seems to be a bit of an overkill, because I would assume it takes more cycles then an if statement or a case statement.

[Dundee]

I'm a bit curious, how much strain on the CPU does the log instruction put? It seems to be a bit of an overkill, because I would assume it takes more cycles then an if statement or a case statement.

Try it yourself:

Code: Select all

#include <stdio.h>
#include <stdlib.h>
#include <math.h>

int main (void) {
	int i;
	int z;
	for (i = 0; i < 1000000; i++) 
		z = log10(i);
	return 0;
}

It's probably overkill for the expected carriage lengths (single, double or triple digits). A 1000 (four digit) carriage train would, I think, stretch along two sides of a current map.

Nevertheless, a 1000 car train could happen, so watch for string overflows.

[DaleStan]

I thought "i" was a train number, not a train length.

And yes, tolerance for more than 999 trains is probably overkill, and over 9999 is almost definitely overkill, but still, there's the general concept of robustness that I like.

As for CPU load, how often would the log function get called?

[mpetrov]

I think it's the paint event that calls it. I am not familiar with the code enough to tell you for sure, but I'm guessing it's either painted with the refresh rate or only when needed. In that case not more then 100 times a second. So you are right, CPU load should not be a concern. Tomorrow I will work on implementing the suggested changes into a patch, today I simply did not have time due to homework. I will look into expanding the window on the left side instead of the right, that way the need to add a new column will be much less.

[Bjarni]

Nevertheless, a 1000 car train could happen, so watch for string overflows.

I think the limit for train size is around 109 units, including all engines

I think it's the paint event that calls it. I am not familiar with the code enough to tell you for sure, but I'm guessing it's either painted with the refresh rate or only when needed. In that case not more then 100 times a second. So you are right, CPU load should not be a concern. Tomorrow I will work on implementing the suggested changes into a patch, today I simply did not have time due to homework. I will look into expanding the window on the left side instead of the right, that way the need to add a new column will be much less.

Code: Select all

switch(e->event) {
case WE_PAINT: {

WE_PAINT is called every time

Code: Select all

SetWindowDirty(w);

is called and w is a pointer to the window in question. This means that the calculations needed to draw the window is only done when this command is used, otherwise it's cached since OTTD presumes it's unchanged. Most windows are often only redrawn when clicked or a timer tells it to do so. I don't know how often the timer activates, but you have to set it for each window if you want to use it. The vehicle overview window is redrawn every 10th day so it's not a huge CPU killer

If you want to toy with it, you could add printf or something to your case WE_PAINT to see how often it's called
I think train depots are only redrawn if there are changes like you click it or a train enters or leaves, but I have not checked if there are other cases too

[Darkvater]

Windows are only repainted when it is set dirty or you move the window. Also if something changes in the background; eg a vehicles moves behind the window; the window is also marked dirty and redrawn.

[Hackykid]

I have said this before on irc but i'll post it here so everyone can read it:

Counting the number of tiles instead of the number of vehicles is just plain stupid, if you want to build a long train, you want it to be EXACTLY x tiles long, so that means EXACTLY 2*x vehicles in the train.
By dividing that number by 2 and rounding, there is always the possibility you build 1 vehicle too many or to few, depending on which way you do the rounding.

(example: a 19 vehicle train and a 20 vehicle train are both 10 tiles long, so if i want a 20 vehicle train there is no way to see if i accidentily built a vehicle to few)

Dividing by two and rounding just discards usefull information, why the hell would you do that?

[mpetrov]

After 4 days of silence I finally have a new implementation of the patch.
It has been approved by 3 people on IRC and hopefully will be approved by you as well. As usual please give me some feedback on this.

Sourceforge link to the patch tracker

[/url]

[ledow]

+1 vote for this feature and for the patch that's on SF for it.

[Observer]

After 4 days of silence I finally have a new implementation of the patch.
It has been approved by 3 people on IRC and hopefully will be approved by you as well. As usual please give me some feedback on this.

Sourceforge link to the patch tracker

[/url]

That does look even better than before , and I agree with the vehicle count in stead of the tile count. Good job

[acidd_uk]

+2 I like it.

[teeone]

looks good

[mpetrov]

I have made a small update to the diff file, now it is against rev 1494.
Due to numerous widget modifications it has became unusable, but the new file should solve the problem for a little bit. Still waiting on for any word from developers about an SVN addition, it seems to work well and the code should be clean.

SourceForge page for the diff file

[CruDeLioS]

Hello,

I've taken this concept a little bit further.

This is my own code, I used this as a project to start understanding the basic inner workings of the gui. It shows the number of vehicles both in depots and in the train list window.