Make world limits not forced to water level

[TurfIt]

It was pak64, WinSDL, south border. Inspect tool.
If the mouse cursor was over the map, the tool would correctly highlight the ground tile the cursor was over, and move the highlight to the next tile as the cursor moved over the boundry.
If the mouse cursor was off the map, but within ~1/2 a tile of the edge, the onmap tile was still highlighted, but now moving the cursor parallel to the edge of the map was resulting in the highlighted being off set from the cursor position. The higher the ground tile above the water surface, the worse the offset. If the water was at the edge, moving the cursor off the map would stop the highlight - correctly detected cursor off map.

[Markohs]

hhmmm... I see it now. I'll have it a look haven't checked the code yet again, my guess is this one is not easy to fix.

But height makes the difference, you are right, the problem is almost for sure in karte_t::get_ground_on_screen_coordinate ,  I'll try to figure out how height affects this... Not so easy because that algorithm is basically the same (I just changed a few lines), and I *think* that bug already existed in old versions of simutrans. Just now it's noticeable because we hide the cursor now.

But I'll see what can I do.

It's not a killer bug, difference is not huge.

EDIT: Okay, I know where is the problem now and how to fix it. It was indeed a bug introduced by me. It doesn't really happen on borders, it happens anywere in the map.

But I'm not really sure if previous code before my intervention had a "gap", where the game coudn't find a matching tile under the pointer. I think it did, just wasn't so obvious before. Now that TurfIt pointer me to it, I see it everywere. I'll fix tomorrow.

[Markohs]

The reason the intersection algorithm sometimes does not return the tile in wich mouse pointer is over it's ilustrated in this image I made to understand the problem better:



The zone not colored between the blue and red zones, it's the zone the algorithm will fail to return a ground tile. That's because the shape of the tile it's assumed to be rectangular (well, a diamond), while it's not. I'm still thinking how to fix this, any ideas?

My current implementation searchs for a extra tile with height+1 in addition to the coloured one, but that's not 100% sasisfactory, and creates the bug Turfit described. But creates more problems too.

This is not a new algorithm, it's the same we have been using for years.

It's all in karte_t::get_ground_on_screen_coordinate

[Dwachs]

I do not have any idea how to solve this.  Keep in mind that there are (valid) situations, where the pointer is not over a tile (if it is over a vertical wall).

[An_dz]

How the code that generates the grid borders work? Can't it be used to check these slope tiles?

[Ters]

If you're referring to the tile grid Simutrans has been able to display for as long as I've played it, those are just images like everything else.

[Markohs]

Yep, an_dz, can't be used for that.

Well, I made a fix that eliminates most of the error TurfIt discovered. On flat tiles cursor will disapear as the mouse gets on background, and on slopes, the range it's decreased sightly, but still extends a some pixels.

https://dl.dropboxusercontent.com/u/30024783/cursor_fix.patch

If you don't mind I'll commit it and consider it as fixed to the extent it can be fixed. It's a very small diference, and fixing it I fear whould require more CPU.

[Markohs]

I'm making some experiments and wanted to try a 512x512 image as background, but when generating the pak:

Code Select Expand


F:\makeobj>Makeobj.exe pak512
Makeobj version 53 for simutrans 111.2 Nightly and higher

Makeobj version 53 for simutrans 111.2 Nightly and higher
(c) 2002-2006 V. Meyer , Hj. Malthaner, M. Pristovsek (markus@pristovsek.de)

Image size is set to 512x512
writing invidual files to ./
   reading file ./background.dat
   writing file ./ground.Background.pak
      packing ground.Background
WARNING: ignoring alpha channel
ERROR: packed image size (263680) exceeded 65535 bytes!


Well, no problem I'll try a 256x256, but... why this limitation? bild_t::len is a 32-bit value, can I remove this limitation in makeobj or it's there for a reason?

The image is this one for the case someone is interested, and has a better idea (with gimp source)

https://dl.dropboxusercontent.com/u/30024783/bg/Sin%20nombre.xcf

[Dwachs]

It seems that this range check in image_writer.cc is out of date. I think it can be removed safely as all related data structures are uint32.

[Markohs]

Thanks!

[Markohs]

Two screenshots with the work in progress, it's looking good in my oppinion! With the world slope will look way better.

Comments welcome as allways.




EDIT: Modified the code to allow for bigger images in pak files, it's uploaded to trunk, if someone needs a new executable of makeobj for windows, I have built this one:

https://dl.dropboxusercontent.com/u/30024783/bg/makeobj.exe

It's compiled using MSVC 2012, you you might need to install:

http://www.microsoft.com/en-us/download/details.aspx?id=30679

Source and .dat for the file:

https://dl.dropboxusercontent.com/u/30024783/bg/background.zip

Executable:

https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe

Copy ground.Background.pak to your pak folder to activate this.

Source patch: https://dl.dropboxusercontent.com/u/30024783/bg/bg.patch

known issues:
- You need to change zoom once to activate this
- Mini-viewports in vehicle frames and inspected places, draw the scaled version of BG when they should do the unscaled, and with correct offset
-coordinates are not allways updated corectly

[prissi]

Somehow this is again very close to the initial outside images

But as art is in the eye of ... Well, maybe peole are tuned down form so many logos from internet adds. But somehow I cannot get very warm with this. I would rather see the proposed landscape forms. (Would need 5 images for all slopes, and maybe also some climate dependent ones.)

[Ters]

Having a grid in the background image just looks plain odd, unless terrain is forced to the same level at the edges. Not necessarily water level, but a level the grid is aligned with.

[jamespetts]

Would these new graphics be compulsory, or are they pakset dependent? Plain black would be preferable to this look, I think.

[Markohs]

I'm not a graphical artist, I'm pretty sure we have people in the forum that will make a better job than me on that, my version is just a demo of what can be done.

@prissi: By "the proposed landscape forms" you refer to the world slice slope?
@ters: well, you have to think world slopes are still missing, when they are implemented (soon I hope), it will all look better. Anyway it's alligned atm, at certain levels, just the grid line it quite thick and maybe I didn't aligned it 100% perfectly in the .png. But it aligns with flat world borders, at certain heights.
@jamespetts: No, it will be optional. Like the current solid background color, that can be changed in the pak .tab file, You can not define this image and simutrans will revert to the solid color version. The same goes for the future world slopes.

My idea is to make all this features optional. And after I implement world slopes I'll plan how to implement the old landscape again, so people can enforce the world to be like it was before.

[prissi]

Well currently the grid seems to be not favourable by the last three posts ... If you intend to add something like this, I would rather suggest using the outside image for tiling. If a pakset than want borders, they could be added directly to the outside pak.

[Markohs]

Well currently the grid seems to be not favourable by the last three posts ... If you intend to add something like this, I would rather suggest using the outside image for tiling.

Ok, I understand that, but that forces the outside image to be the same size than a basic ground size, horizontally. I thought allowing a bigger image size would give greater flexibility so every artist can implement whatever he likes. If he designs the image like I did, he can draw a grid, but he's also free to use a sea image, with no grid, ofc. Given the grid it's aligned to the image at -2 level (grundwasser), he can choose whatever he likes. A sliced world floating on top of water will look quite weird too, if borders are not forced to water level.

Bigger image will give better performance to the background redraw, too.

Hm... will think about this.

If a pakset than want borders, they could be added directly to the outside pak.

I don't understand this, you mean "if the pakset creator wants a grid he can draw a grid to the ground.Outside.pak" ?

Images using the old "outside" graphics, doesn't this look even weirder?

[prissi]

If you draw two lines on the outside image, you would get a grid. Try pak96 outside image. pak.Mars had also a black outside tile, if I remember.

[Markohs]

yes yes, pak96.comic has it too. But you can also draw it on the background image, it's the same, no? And the bigger the image, the lower image_displays, thus more performance.

[prissi]

The original code did already draw tile size tiles (ground.outside.pak must be tile size). This is done in the threaded code, thus I would not expect my impact. I could be done again there again. (I would do it however at ground water level, like the old code.) If done only outside, it would again emulate a cut out feeling.

[Markohs]

 I don't know, prissi, I'd personally prefer allow giving the artist the flexibility of supplying a image of whatever size he wants, with grid or without grid, and use it in the background code than going back to a tile-shaped image, and just drawing it like the old code does.

I see no advantages on your approach, it's slower and makes a size mandatory. And it's harder to implement in the future OpenGL code too.

But ofc, we can do it that way if you all want to.

[An_dz]

Here's my test with the background code, something a little like SimCity:

[Markohs]

thx an_dz what size is that background image?

[Dwachs]

Something completely different: Currently it is possible to scroll the map such that nothing of the map is visible anymore, this was not possible before this change.

[Markohs]

Nope, it's allways been possible, I just checked 112.2 and 112.0 and you can drag outside the map.

Or I did something wrong in the check or it's in my game settings, or I didn't understand you.

If I did understand you, not being able to drag screen so much as only background is visible is a desired feature, it's a still to be implemented feature.

[An_dz]

thx an_dz what size is that background image?

256

[Ters]

Nope, it's allways been possible, I just checked 112.2 and 112.0 and you can drag outside the map.

I don't think it has always been possible, because I was surprised when I found that I could do that a while back. Although I don't remember exactly when I did that, I think that it was before I built Simutrans with these changes.

[Markohs]

@ters: I remember the same but the fact it's old versions allow scrolling outside the map now. So aliens altered all our memories with some weird device or something it's happening here. Just can't explain why. Any ideas?

256

If you want the image to align to the world I think it needs to be a dimension multiple of the pak size, so if you are using pakcomic.96 you can use 96, 192, 384, 768 ... Height and width can be different too, you can maybe try a 768x192 version, just remember to invoke makeobj with the higher of the both, "makeobj pak768" in that example. If you tested other variations I'd be happy to see them.

I fixed the misalign in the grid when zooming, and the bug at start, now only mini-renders are failing.

New executable: https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe

[Ters]

112 isn't that old. It might easily be a year, or even more, since I last tried to scroll outside the world. So there are a lot of changes to go through to find the culprit.

[An_dz]

If you want the image to align to the world I think it needs to be a dimension multiple of the pak size

I saw no differences, at least with this image.

If you tested other variations I'd be happy to see them.

I just made it slightly lighter to match more the comic style.

I attached the image if you want to build the background and debug your code.

[IgorEliezer]

New executable: https://dl.dropboxusercontent.com/u/30024783/bg/Simutrans.exe

I got Runtime error. R6034. All required dll's are in the simutrans folder. :<

[Markohs]

did you put ground.background.pak in the pak folder? it doesn't start without it atm.

Well, looking further looks like it's something derived from visual studio, I'll compile using mingw, wait a bit plz.

[IgorEliezer]

Now I did, but the error still persists.

[Markohs]

There you have, this should work with no problems.

https://dl.dropboxusercontent.com/u/30024783/bg/sim.exe

If it doesn't work, try to download again same file in 5 mins, I just uploaded to dropbox and it might be giving you an older version.

[IgorEliezer]

It started up. But it crashes if I zoom in while hovering the cursor over the "space", the background thing, in max window.