Skip to main content ↑ ↓
Topic: Graphics Bug on rotation (Read 6289 times) previous topic - next topic

Graphics Bug on rotation

I've noticed the following bug in the way graphics are shown after a map rotation:

Picture 1: rotation 1 - note the shop fronts lining up with the road.
*ROTATE 90 degrees*
Picture 2: rotation 2 - now the shops face the wrong way!

This is due to the rotation sequence being the opposite sense to the way the images rotate in the dat file. 

BUT: if you change rotations in the dat file to be 0,3,2,1 instead of 0,1,2,3, you just get the images facing the wrong way in rotation 1 rather than rotation 2. 

Solution:  Code needs to re-draw images with same sense of rotation as in the dat file.  I'm ****uming this is very easy to change.  Unfortunately, I am not a coder!

EDIT: using r2293, but now I think about it, this behaviour has been around for a while, I've only just worked out what's going on though!

Re: Graphics Bug on rotation

Reply #1 –
The rotation of buldings hould be the same for ages, see the loading bay. You are sure you do not need to define them the other way round?

Re: Graphics Bug on rotation

Reply #2 –
Can you please tell me if this image is still correct?

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: Graphics Bug on rotation

Reply #3 –
Looks correct. MHZ vorplatz in pak64 in the player folder (mhz-stations.dat) has also four rotations.

Still a Graphics Bug on rotation!

Reply #4 –
Apologies, looks like I was being an idiot!  I've just tested it again, and it is fine with the rotation the other way round in the dat file, but I'd got confused because of the order of the images in the dat file making all images point away from road!  Now fixed :)

Edit:  Actually there is still a problem, but it is a different problem!  That must be why I was confused.  Look at the next two examples.  In rotation 1, building 1 aligns with road and building 2 does not.  In rotation 2, the same happens (i.e. building is either always in correct alignment with road, or always incorrect).  So there is a choice:
1) dat file rotations 0,1,2,3 -> leads to behaviour described in original post (not ideal)
2) dat file rotations 0,3,2,1 -> leads to behaviour described in this post (also not ideal).

It looks like it must be a problem with detecting the "front" of images to align with roads.  I don't see what else I can do with my dat file to get it to work correctly!

Edit 2: With attachments!  I am going insane!

Re: Graphics Bug on rotation

Reply #5 –
Quote from: prissi – on
Looks correct. MHZ vorplatz in pak64 in the player folder (mhz-stations.dat) has also four rotations.
Thanks! Documentation should be kept correct ;)

My projects... Tools for messing with Simutrans graphics. Graphic archive - templates and some other stuff for painters. Development logs for most recent information on what is going on. And of course pak128!

Re: Graphics Bug on rotation

Reply #6 –
SENW was instead NESW in the city file. Corrected.

Re: Graphics Bug on rotation

Reply #7 –
Should this be fixed in the latest nightly?  I've just downloaded r2319 and I still get the same problem.  Or do I need to change something else in the dat file or a config file?

Re: Graphics Bug on rotation

Reply #8 –
The Order in the Datfiles must be as VS wrote. Then it should work.

Re: Graphics Bug on rotation

Reply #9 –
If I have the dat file as VS wrote, I get the behaviour in my 2nd set of screenshots.  All buildings in orientation "1" (and 180 degrees from this) in the screenshots get aligned OK for all map rotations, but all buildings in orientation "2" (and 180 degrees) are facing the wrong way in all map rotations.  Does that make sense?  I was hoping that both "1" and "2" should always be generated facing the road!

Re: Graphics Bug on rotation

Reply #10 –
It works for me? Which house is it, I will look into the dat-file.

EDIT: AT least 1920-detatched-house-2f rotates the wrong way (not counter clockwise).

Re: Graphics Bug on rotation

Reply #11 –
Actually the files on sourceforge are all wrong (they are the situation described in the first post).  This is the corrected dat file for 1880 commercial buildings (i've only been testing on these).  This should replicate the problem I'm having.

Re: Graphics Bug on rotation

Reply #12 –
Sorry to be a pain, but has anyone got anywhere with reproducing / solving this?  I'm waiting to release some corrected pakBritain stuff but want to make sure I get the rotations right first!

Re: Graphics Bug on rotation

Reply #13 –
I think rotation is correct now. But building code is ... is this correct ?

Re: Graphics Bug on rotation

Reply #14 –
Well teh code just checks for the first road going the SENW sequence and takes this. Anyhow, there is no good way to determine which to take for two or more roads but to use instead 8 Layouts (or rather 16 for all case with two and three roads).

Given the amount of images needed for houses which seldomly will show on of those orientations and the pain with rotation I am not sure I want to go there though ...

Re: Graphics Bug on rotation

Reply #15 –
How about this. At least, it allows 2x2 block, isn't it ? (Not tested)

Code: [Select]
static koord neighbours[] = {
	koord( 0,  1),
	koord( 1,  0),
	koord( 0, -1),
	koord(-1,  0),
Code: [Select]
int streetdir = 0;
for (int i = 1; i < 4; i++) {
	str****e_t* weg1 = (str****e_t*)welt->lookup_kartenboden(k + neighbours[i-1])->get_weg(road_wt);
	str****e_t* weg2 = (str****e_t*)welt->lookup_kartenboden(k + neighbours[i])->get_weg(road_wt);
	if(weg2 != NULL  && weg1 == NULL) {
		streetdir = i;
	}
}

Code: [Select]
# This is 1
...
.hs
.S.

# This is 2
.s.
.hS
...

# This is 3
.S.
sh.
...

# This is 0
...
Sh.
.s.

# Result
ssss
s21s
s30s
ssss
 

Re: Graphics Bug on rotation

Reply #16 –
THis needs some further polishing for singe stree tiles, but I get the point.