Ttd2x Build 1002: Another Day Another Update...

[zodttd]

Heh thanks DaveC. ...I was just joking around anyways.

 

[A_SN]

Hi everyone,

Glad the feedback has been so positive for TTD2X. Only DaveC said otherwise, so I call it a perfect release.

I think it is a great job. I just think it is a bit awkward on this device to play. To give positive feedback, I will say that you did a fine job of squeezing it in the Gp2X though. Good work

I agree, I don't mean to sound like a douchebag or anything, but although the SDL zooming thing is a good idea, I find it pretty awkward, and I thought that you would have scaled the whole thing to 320x240 in a smooth anti-aliased way. I think you can obtain something pretty good by averaging a square of 4 pixels into one pixel, and have something usable, much more usable than when it's un-antialiased.

Maybe you could try that and make it conditional, like, it would only be turned on when it would be zoomed out to the fullest. I think it would be pretty neat.

 

[paxl13]

After playing 30 Min of playing the '2x Version, WOW

Thanks Zodttd for bringing this games to the gp2x

Continue TTD2x'ing....

paxl13

 

[sam fisher]

Hi everyone,

Glad the feedback has been so positive for TTD2X. Only DaveC said otherwise, so I call it a perfect release.

I think it is a great job. I just think it is a bit awkward on this device to play. To give positive feedback, I will say that you did a fine job of squeezing it in the Gp2X though. Good work

I agree, I don't mean to sound like a douchebag or anything, but although the SDL zooming thing is a good idea, I find it pretty awkward, and I thought that you would have scaled the whole thing to 320x240 in a smooth anti-aliased way. I think you can obtain something pretty good by averaging a square of 4 pixels into one pixel, and have something usable, much more usable than when it's un-antialiased.

Maybe you could try that and make it conditional, like, it would only be turned on when it would be zoomed out to the fullest. I think it would be pretty neat.

Fine, and you try and read the text then.

 

[Zarneth]

Damn. Just barely after I posted my list of suggestions. Guess I'll have to revise it and post again? XP

Great work so far thoguh. :lol:

Mouse/Screen control
-Joystick Click toggles Rez
Not a fan of the gradual zoom. (looks ugly without AA anyway and too slow) A nice snappy toggle from the joystick click would be GREATLY appreciated. (like the old volume up click, but without the lag)
-Zoomed Rez follows mouse better
Move zoomed view when the mouse is within 20% of the edge of the screen instead of just when it hits the edge.
-Mouse Speed control seperate in 640 and 320 modes.
The Vol to change speed is great. Would want a faster mouse speed in the 640 mode thoguh.
-Swap L/R functions. (maybe have a option for this one?)
This would balance the workload between the two hands. I find it a bit cramped using the joystick and L button together.

Track/Road laying
-Button to Cycle parts.
Manually choosing each different track/road piece from the pallet is very fiddly and slow. So you could make the select key change though the basic pieces of that type whenever the cursor is set to one of them. (just stick the the common ones, ie, standard pieces, bulldoze and if it's rail - the signals)

Misc
-Start closes window under cursor
It's easy to close windows but it's annoying to pinpoint the x when you have a lot to close
-Center new windows on screen when 320x240 mode.
I keep opening windows and wondering why they're not showing because they appear off screen. Wont' be such an issue if it's easier to toggle resolution though.
-Button(s) to toggle between toolbar buttons.
Close whatever window was last selected from the toolbar and open the next one.
-Status Bar always visible when new event happens.
So you don't miss important events, but shorten the date so it doesn't waste space.

Thanks again for the great work.

 

[A_SN]

Hi everyone,

Glad the feedback has been so positive for TTD2X. Only DaveC said otherwise, so I call it a perfect release.

I think it is a great job. I just think it is a bit awkward on this device to play. To give positive feedback, I will say that you did a fine job of squeezing it in the Gp2X though. Good work

I agree, I don't mean to sound like a douchebag or anything, but although the SDL zooming thing is a good idea, I find it pretty awkward, and I thought that you would have scaled the whole thing to 320x240 in a smooth anti-aliased way. I think you can obtain something pretty good by averaging a square of 4 pixels into one pixel, and have something usable, much more usable than when it's un-antialiased.

Maybe you could try that and make it conditional, like, it would only be turned on when it would be zoomed out to the fullest. I think it would be pretty neat.

Fine, and you try and read the text then.

It'll be better yet than the way it is now when zoomed out to the fullest

 

[DaveC]

It'll be better yet than the way it is now when zoomed out to the fullest

There is not much you can do. When you take an image and take 3/4 of the information away it will have issues. There is no magic trick. Anti-aliasing would just take the already hard to read image and make it blurry. It would be even worse. It is just math you can't really cheat it.

 

[Blah]

You can cheat it with interlacing (we've done this since the 1920s) but our lcd is too slow.

 

[A_SN]

It'll be better yet than the way it is now when zoomed out to the fullest

There is not much you can do. When you take an image and take 3/4 of the information away it will have issues. There is no magic trick. Anti-aliasing would just take the already hard to read image and make it blurry. It would be even worse. It is just math you can't really cheat it.

Now I understand why so many people hate you.

For your information, mister, there's a major difference between just discarding 3/4th of the information and anti-aliasing, or in other words, blurring first and discarding later. The big difference is this, when you just discard pixels, the frequency components above the new nyquist frequency "fold back" under the new nyquist frequency to mix with the correct and valid lower frequency components, and you want to avoid that, mainly when dealing with images containing as much high frequency components as in our case.

As when you use some kind of anti-aliasing, you first filter the high frequency components out so that nothing "folds back" under the new nyquist frequency and thus no artifacts are created.

Basically what you're claiming is that it looks better and it's easier to read with artifacts than without any, that's pretty much as if you said that you understand the lyrics of songs you listen to better when listening to music on a construction site than in a quiet room.

But the best is yet for you to see it in effect and tell me which looks best/is the most readable. (the one on the left is obviously the non-antialised one and the one on the right the anti-aliased one)

Btw, zodttd, couldn't you like, make some fonts larger or something?

 

[fusion_power]

Oh, and about the "?" issue with German fonts:
From OpenTTD.org:
"
We are getting a lot of questions about bad fonts, only '?' characters for non-latin languages, etc. We would clearly like to state to READ the readme bundled with the game, section '9. Troubleshooting', or online here.

To state this here shortly: you need to specify a font in openttd.cfg in the small_font/medium_font and large_font sections to get proper characters for Japanese, Russian, etc. Some languages have sprite-versions of the fonts available, you can put that in the [newgrf-static] section of the cfg file.
Completely unrelated, but Release Candidate 4 has a bug that it starts up in russian for the first time. The solution is to either try to find your way through all the '?'-s and change the language, delete russian.lng file or set 'language=english.lng' in the config file.
"

I thought it was an GP2X Problem with the missing fonts because I never had such bugs in the PC Version ( often I read readme's )
Besides, in the cfg-file are no sections for font sizes

-I noticed, the timidity-files included in TTD2X are loocking like the timidity files I already have on GP2X for Duke2X (only smaller). I will try to use my old Timidity so I can delete the double files - could save 1,5MB

-I have noticed a small delay when Sond-effects are played, only noticable for "click"-sonds -nothing serious.
-I miss a "ctrl" Button
-and I miss "ctrl+shift+alt+c".... :lol:

Besides, good Work again. Working "newstation"-graphics are nice!

 

[senquack]

Zottd: I finally got around to getting the game installed right and played with it for quite a while.. Amazing job!!!

Zeladin's suggestions a few posts up are very good, if any of them are possible it would make things even easier, especially a button for rotation through the available road and rail tiles.

A_SN: that screenshot comparison is very impressive, I had no idea it was possible to scale quite that smooth. I can seriously read all the text on the right side.

 

[zodttd]

A_SN: What type of filter is used to get the effect on the right side? If you can provide some sample code or the type of routine used, I will give it a shot!

Senor Quack: You're one of the reasons I made this GP2X version. Thanks.

You can hardcode paths to the timidity patches in "timidity.cfg"

I've been contacted by Darkvater of the OpenTTD project about some GPL violations, so I will have the downloads taken down for just a second while I add the COPYING file to the builds. Oops. Feel free to donate to the OpenTTD.org project as well since they did the actual game ya know. I've received about 3 donations so far for my OpenTTD projects over the years, so I don't think they need to worry much on that end. Good to know OpenTTD project leaders care enough about my project to keep a close eye on it.

 

[fusion_power]

Zottd: I finally got around to getting the game installed right and played with it for quite a while.. Amazing job!!!

Zeladin's suggestions a few posts up are very good, if any of them are possible it would make things even easier, especially a button for rotation through the available road and rail tiles.

A_SN: that screenshot comparison is very impressive, I had no idea it was possible to scale quite that smooth. I can seriously read all the text on the right side.

You should try the "autorail"-tool in the railroad-build-window (the crossed railroads) With this feature you can build every tile in every direction very easy, even on the GP2X with a little training. Build your Network in transulent mode (without visible trees - via patch-options window enabled/disabled)

 

[A_SN]

A_SN: What type of filter is used to get the effect on the right side? If you can provide some sample code or the type of routine used, I will give it a shot!

I did that in Photoshop using Bicubic filtering, but don't despair I've just implemented in a few minutes the equivalent for it, here it is :

void scale_down(uint8_t *image, uint8_t *screen)
{
	uint16_t iy, ix;
	uint8_t ic;

	for (iy=0; iy<240; iy++)
		for (ix=0; ix<320; ix++)
			for (ic=0; ic<3; ic++)
			{
				//screen[(iy*320 + ix) * 4 + ic] = image[(((iy*2)+0)*640 + ((ix*2)+0)) * 4 + ic];	<<no anti-aliasing
				screen[(iy*320 + ix) * 4 + ic] = (image[(((iy*2)+0)*640 + ((ix*2)+0)) * 4 + ic] + image[(((iy*2)+1)*640 + ((ix*2)+0)) * 4 + ic] + image[(((iy*2)+0)*640 + ((ix*2)+1)) * 4 + ic] + image[(((iy*2)+1)*640 + ((ix*2)+1)) * 4 + ic])>>2;
			}
}

I'm not using SDL, so let me explain what it does. The first argument is the original 640x480 image in 32-bit RGBA, the second is the 320x240 screen in the same format. It goes through every output pixel and computes them, which coordinates are indicated by IY and IX, and it takes from the image 4 pixels indicated by :

IY*2,IX*2
IY*2,IX*2+1
IY*2+1,IX*2
IY*2+1,IX*2+1

, sums up all of their values for each channel and divides by 4 (or shifts right by 2). Pretty fast and straightforward.

The result is slightly different, almost as readable, but considered how fast (and simple to implement) the algorithm is you shouldn't try to get better. If we wanted to have a better result we'd have to deal with stuff like convolution, although we could get a nice result with only a 3x3 kernel, but then we might need about 2,800,000 additions and multiplications for each frame..

 

[Dunny]

I'm not using SDL, so let me explain what it does. The first argument is the original 640x480 image in 32-bit RGBA, the second is the 320x240 screen in the same format. It goes through every output pixel and computes them, which coordinates are indicated by IY and IX, and it takes from the image 4 pixels indicated by :

IY*2,IX*2
IY*2,IX*2+1
IY*2+1,IX*2
IY*2+1,IX*2+1

sums up all of their values for each channel and divides by 4 (or shifts right by 2). Pretty fast and straightforward.

You might also want to apply some gamma correction to the final image - I was doing a similar thing (for an editor for a Spectrum game) and as you can see, I'm using scaled down "thumbnails" of the main "map" area. Check out the brightness of the second thumbnail, compared to the brightness of the map itself:

As you can see, the "averaging" routine, as you suggest is used, has darkened the thumbnail considerably. This is alleviated using a simple gamma formula applied to the palette before the blending is done, and is very simply this:

for r,g,b of each pixel, r' = r^2.2 (and also for g',b'), perform averaging using r',b',g', then r = r'^1/2.2 (again, for all three colour components).

The image is far clearer after this:

However, I'd recommend an immense LUT usage for this, as the power and division functions in C are horrendously slow, and not much better when written in asm.

D.

 

[A_SN]

You might also want to apply some gamma correction to the final image

No. Original image, Image obtained with my algorithm

They both looks as bright. As for your example, I don't know what you did wrong.

 

[Dunny]

You might also want to apply some gamma correction to the final image

No. Original image, Image obtained with my algorithm

They both looks as bright. As for your example, I don't know what you did wrong.

Yes, your second image looks washed out, it's really easy to see.

The code I used was a simple shift like yours - an averaging function. It's normal for the gamma correction to be off after that sort of image manipulation. I used info from poynton's and help from comp.graphics.algorithms to get the correction code needed.

D.

 

[A_SN]

Yes, your second image looks washed out, it's really easy to see.

No it's not, I don't even see why it should be. Stop seeing issues where there's none

 

[Dunny]

Yes, your second image looks washed out, it's really easy to see.

No it's not, I don't even see why it should be. Stop seeing issues where there's none

Hey, just trying to be helpful... I honestly did come across this problem, and an averaging function is extremely simple, so it's unlikely there's an error in my code.

And your image still looks slightly washed out

D.

 

[zodttd]

Heh, if I notice it being washed out or dimmed I'll change the gamma. It's easy to do via GP2X hardware, or I can just do it during the pixel conversion.

Keep in mind I'm taking an 8bit paletted user specified zoomed-out/clipped 640x480 image and scaling or clipping it to the GP2X's 15bit 320x240 screen.

Also A_SN, I'll optimize the routine a bit too. Just some stuff like using bitshifting instead of multiplying by powers of 2.

Thanks A_SN, and thanks for the heads up Dunny.