Bug #6884

faulty reporting of reading beyond image bounds

Added by Snail about 4 years ago. Updated almost 4 years ago.

Status:ClosedStart date:2014-04-22
Priority:NormalDue date:
Assignee:-% Done:

100%

Category:grfcodec
Target version:-

Description

Hi there,
A bug is occurring in grfcodec 6.0.4, which I didn't experience in grfcodec 6.0.3 .

In the attached NFO file there is one spriteblock referencing two real sprites, each put in a different PNG file. The first PNG file is 90 pixels "tall", the second is larger.
The first real sprites references Y pixels 70 through 81 of the first PNG file; the second real sprite references Y pixels 110 through 121 of the second PNG file.

If I run grfcodec on the NFO file, using the following command:

/Applications/grcodec/grfcodec -e fset_test.nfo

(where /Applications/grcodec/grfcodec is the location where I compiled grfcodec) I get this error message:

"
Encoding in temporary file fset_test.new
Loading sprites/plat_2ess_auto_ep0.png

sprites/plat_2ess_auto_ep0.png: Error: Sprite y extends beyond end of the spritesheet.
Spritesheet has 90 lines, sprite wants 110..121
"

It therefore seems grfcodec is using the first PNG file, using the Y and X locations of the second real sprite.

I'm using Mac OSX Mavericks.

Could you please look into it? As I said, this didn't happen with earlier versions of grfcodec.

Thanks in advance.

fset_test.nfo (1.73 KB) Snail, 2014-04-22 12:34

grfcodec_bug_20140422.rar (33.7 KB) Snail, 2014-04-22 12:42

plat_2ess_auto_ep0.png (1.72 KB) Snail, 2014-04-22 12:42

plat_2ess_auto_ep1.png (2.57 KB) Snail, 2014-04-22 12:42

sprites.zip (173 KB) andythenorth, 2014-06-17 16:50

Associated revisions

Revision 982:1bf612c33fc4
Added by Rubidium almost 4 years ago

Fix #6884: GRFcodec did not always reload spritesheets when that was needed.
This issue was made visible by the compiler toolchain used on OS X Maverick.

History

#1 Updated by Snail about 4 years ago

#2 Updated by Snail about 4 years ago

#3 Updated by planetmaker about 4 years ago

My output looks like this (981:6c518131ed69 where the tag 6.0.4 is added, linux):
ingo@aeolus:~/ottd/grfdev/tmp$ grfcodec -e fset_test.nfo
Encoding in temporary file fset_test.new
Loading sprites/plat_2ess_auto_ep0.png
Loading sprites/plat_2ess_auto_ep1.png

Renaming fset_test.grf to fset_test.bak
Replacing fset_test.grf with fset_test.new

Done!
ingo@aeolus:~/ottd/grfdev/tmp$ ls sprites/
fset_test.nfo plat_2ess_auto_ep0.png plat_2ess_auto_ep1.png

#4 Updated by planetmaker about 4 years ago

  • Priority changed from Urgent to Normal
  • Category set to grfcodec
  • Subject changed from grfcodec 6.0.4 to faulty reporting of reading beyond image bounds

#5 Updated by planetmaker about 4 years ago

The same result as above on OSX (10.6, zlib @1.2.6_0+universal (active), libpng @1.4.8_0+universal (active), boost @1.47.0_2 (active))

#6 Updated by Snail about 4 years ago

Very strange. I have OSX 10.9.2, zlib @1.2.8_0+universal (active) , libpng @1.4.8_0+universal (active) , and boost @1.55.0_2+no_single+no_static+python27 (active) , and still get that error with grfcodec 6.0.4 .

However, grfcodec 6.0.3 works fine. Since it seems 6.0.4 doesn't have any features I need, I will revert to the old version for now.

#7 Updated by dandan almost 4 years ago

I have the same problem, also in OSX 10.9.

It started when, for one reason or another, I upgraded my Macports tree. After that, my installed version of grfcodec stopped working. So I recompiled grfcodec and the problem that Snail describes appeared.

My library versions are now zlib 1.2.8, libpng 1.6.10 and boost 1.55.

Before the fatal error "Sprite y extends beyond end of the spritesheet." I also get warnings

libpng warning: iCCP: Not recognizing known sRGB profile that has been edited

for every png-spritesheet.

Unlike for snail, downgrading to older versions of grfcodec does NOT solve the problem for me.

#8 Updated by andythenorth almost 4 years ago

I also have this issue, grfcodec r981, OS X 10.9.2

Downgrading to a self-compiled 6.0.3 does not solve the issue.

Many warnings during compile.

http://paste.openttdcoop.org/show/3444/

I have installed same deps that Snail reports as working for 6.0.3

#9 Updated by andythenorth almost 4 years ago

#10 Updated by Rubidium almost 4 years ago

On Debian (SID) the compiled version of r981 works right with libpng 1.6.10, boost 1.55 and clang 3.3/3.5.

There are not much more variations I can think of to reproduce this issue on Debian, which makes me believe this issue is something related to something specific to Mac OS X (and maybe only version 10.9).

#11 Updated by Rubidium almost 4 years ago

  • % Done changed from 0 to 100
  • Status changed from New to Closed

Applied in changeset 1bf612c33fc4.

Also available in: Atom PDF