News:

Simutrans Wiki Manual
The official on-line manual for Simutrans. Read and contribute.

BUG in r2044 - ground.outside not working properly

Started by DirrrtyDirk, September 30, 2008, 11:52:08 AM

Previous topic - Next topic

0 Members and 2 Guests are viewing this topic.

DirrrtyDirk

ST r2044 (Win-SDL), beyond the edges of the map, there are now incorrect graphics shown (no longer the one defined in ground.outside.pak). Happens both in pak64 and pak128 (worked fine in r2040).

r2044:


r2040:


EDIT: My guess: maybe connected to the changes from 2041?
  
***** PAK128 Dev Team - semi-retired*****

isidoro

The same happens in Linux/gcc.  The image is a ship instead of a piece of railway.  In r2045 seems corrected.  But, in r2044 trains and ships throw pedestrians with the smoke.  Smoke disappears and pedestrians remain until you move the image with cursors keys.  The bug remains in r2045.


VS

These bugs are really what one expects to be a bug :) Trains throwing people into air, seas covered in junk...

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!

DirrrtyDirk

Appears to be solved in 2052 (the ground.outside problem definitely is, and steam looks ok for me, too)

Thx, prissi!
  
***** PAK128 Dev Team - semi-retired*****

isidoro

In linux/gcc, in r2054, the problem with the smoke is still there.

prissi


isidoro

pak64.  I've tried with the nightly (102) and it also fails.
 

prissi

which pak64 does not matter, the only change was than double images were internally pointed to the same image.

isidoro


prissi

image_reader.cc the last if( len!=0 ) block.
To register all images, just register_image( besch ); would be ok. The additional humbomumbo is to find out doubles.

isidoro

I've tried with pak.german and the problem is again with smoke exhausted by vehicles, not factories.  This time, train carriages are exhausted instead of pedestrians...  Maybe it can have anything to do with the smoke routine expecting the images to be one after the other?  I'm just guessing.  It's strange that in two different paks the problem is with exhausted smoke...

z9999

It seems to be shown different image for each person.
In my case, there are extra cloud. (tested with german.pak)

isidoro

Very nice screen shot, z9999.

About this topic: this is the most strange bug I've seen in a long time.  I have two computers: a desktop and an laptop.  Both have Kubuntu Linux.  I've compiled r2056 in both.  I've run the same pak64 files and the same savegame in both and the laptop persists in the graphic glitches, while the desktop renders smoke graphics Ok...  :o

If I comment out the lines pointed by Prissi, it works well in both computers.  The file involved is smoke.Steam.pak, whose image content is substituted by some other.

Time to call Mulder and Scully?   ::)

isidoro

I can't help killing software bugs  :police:

That's a real problem I have to talk about with my psychologist...  Finally, I found the reason of those strange smoke spectra in some computers and paks.  It goes like this:

In pak64 there are four smoke files, the number of frame images in brackets:

  • smoke.Industry_Smoke.pak (1)
  • smoke.Diesel.pak (5)
  • smoke.Industry_Fire.pak (2)
  • smoke.Steam.pak (5)

It happens that:

  • The first image of Steam.pak is the same as the only image of Industry_Smoke
  • Images of vehicle smokes must get consecutive image numbers as can be seen in wolke_t:gib_bild()
  • The order in which pak files are read is system dependent
  • The improvement made in last releases doesn't assign a new image number if there's an equal image read before (in such a case, the number of the previous image is reused)

In one computer, the order in which files were read was: Industry_Smoke, Diesel, Industry_Fire, Steam.  Steam reused only the fist image of Industry_Smoke and therefore "threw pedestrians" (or can throw whatever image happens to be next).

In other computer, the order is different: Steam,Diesel,Smoke,Fire and there is no problem because Steam has all its images with consecutive numbers and Smoke reuses its only image.

A solution may be to inhibit number reusing when reading smoke files or other animations expecting their images to be consecutive.

VS

Edit: bleh this should have been an icon, not advertisement. Sorry.

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!

isidoro

Here's a patch for r2056.  I don't know if the solution is optimal, though...

prissi

Well, unfourtunately the clean (and better way) is much longer ...

VS

The quickest solution is adding one different pixel to one of the smokes. Just like renaming files to be loaded in some order etc. :p

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!

isidoro

Quote from: VS on October 11, 2008, 08:26:29 PM
The quickest solution is adding one different pixel to one of the smokes. Just like renaming files to be loaded in some order etc. :p

That's for sure...    :D

Quote from: prissi on October 11, 2008, 08:10:48 PM
Well, unfourtunately the clean (and better way) is much longer ...

I've seen it in r2060.  I've tried it and it works, but there has to be a minor error since now the last image doesn't disappear.  Perhaps the image is not marked dirty or something like that?  When moving the scene, they disappear.