[OTTD] OpenGFX releases - Graphics Replacement Project

[Brumi]

What is the extra NewGRF supposed to contain? If I activate it (with it being the only one), I get strange results, see those blue question marks in the screenshot:

screenshot.png

(385.08 KiB) Downloaded 9 times

And if I start a game, I get the error "Unexpected sprite".

[FooBar]

The extra grf contains all sprites that are not in TTD but were added since.
You're not supposed to activate that as separate newgrf (although it should not produce these strange results if you do).

[Ammler]

I also thought, that the special GRFID does hide the extra grf from usual newgrfs and so not able to load with there, also though, that should also not hurt...

[planetmaker]

OpenGFX 0.4.2

Today we released OpenGFX 0.4.2. It's a bug fix and maintenance release wrt 0.4.1 mainly geared to fixing problems when being build on different build platforms:

OpenGFX 0.4.2 (08 Feb 2012)
---------------------------
- Fix: [Makefile] Force makefile to build with one thread only as gimp might barf on running in parallel (issue #3439)
- Fix: [Makefile] Don't remove the reference md5 file when using maintainer-clean (issue #3440)
- Fix: The grfID of the extra grf was wrong... and would be found as NewGRF
- Fix: sprite are out-of-bound, sadly nmlc doesn't warn/error about (issue #3667)

[planetmaker]

OpenGFX 0.4.4

Todays release brings you a couple of important fixes to sprites and includes also updated and additional font glyphs in order to better support some languages. Many of these fixes, including the important font updates, have been contributed by PaulC.

Maintainers may note some changes to the build targets:
- maintainer-clean WILL delete from the tar bundle the file to check the md5 sums against. Do not use that
- distclean will restore the source bundle to its prestine state
- clean-gfx will remove the pngs from the source bundle which can be re-generated from the source xcf files
Thus if you want to build the package completely from source, grab the tar bundle (or a repository checkout) and run clean-gfx to ensure that the png files are cleaned and thus re-generated from source.

- Change: Don't let the road works flash that much (issue #3395) (PaulC)
- Add: [Makefile] Introduce target 'clean-gfx' which deletes png files which can be re-built from source and allow 'maintainer-clean' to delete the opengfx.check.md5
- Add: More font sprites (issue #3578) (PaulC)
- Fix: Landing lights were inoperational for helipad and some broken at the heliport (issue #3709) (PaulC)
- Fix: German semaphore signals were not available anymore (issue #3429)
- Fix: Broken river borders at sea level (issue #3562)
- Fix: Add GridDesert to terrain.xcf and fix spelling of GridTropical (issue #3769)
- Fix: Wrong wanter pixels on some river and coast tiles (issue #3714)
- Fix / Revert: [Makefile] Use Makefile.dist for tar source bundles again
- Fix: [Makefile] Don't create an empty graphics file, if it is missing and can't be created from any source
- Fix: [Makefile] Avoid infinite build loops by not requiring the %.src.dep files twice

[FLHerne]

In the manager faces, Hair 2 for European females seems to be one pixel too far to the right, leaving a line of 'face' visible to the left. Only seems particularly noticeable under certain conditions though, which I haven't managed to duplicate properly yet .

[kamnet]

Speaking of which, I posted this glitch to the wrong thread a long time ago, shoulda reported it here. There are a few gaps between the head and shoulders that lets the backgroun color through. I'm not sure if the hair needs to be drawn a few pixels longer, or if part of the shoulders were left out.

[planetmaker]

OpenGFX 0.4.5

Brings you one visible change which will make it easy for trunk users to get rid of the "missing sprites" warning:

Code: Select all

- Feature: Happyness indicators in town list (issue #3928)

Note to package maintainers: as this sprite is only used in trunk (and in OpenTTD 1.3+ when it becomes available), there is no need to update your package, if you ship OpenTTD 1.2 or earlier.

[planetmaker]

OpenGFX 0.4.6
The Christmas release brings you one visible change which will make it easy for trunk users and those of the future OpenTTD 1.3.0-beta1 to get rid of the "missing sprites" warning:

Code: Select all

- Feature: GUI sprites for delete buttons introduced in OpenTTD r24749

Note to package maintainers: as this sprite is only used in trunk (and in OpenTTD 1.3+ when it becomes available), there is no need to update your package, if you ship OpenTTD 1.2 or earlier. You want this, if you want to ship OpenTTD 1.3.0-beta1.

[planetmaker]

Note for maintainers: if you want to build this OpenGFX, you need NML 0.2.5.r2050:7c249349d2a9
We likely will release NML 0.2.5 in the upcoming days as the stable release to produce binary-compatible output.

[Ammler]

OpenGFX 0.4.6.1
We made a "subrelease" 0.4.6.1 for people which want to build opengfx self, it will work with NML 0.2.4, package maintainer should use this and not wait for new NML release.

http://bundles.openttdcoop.org/opengfx/releases/LATEST/

[SwissFan91]

Apologies if this is the wrong place for this - I think it is a bug report but it may not be!

When I am applying snow to the roofs of my sprites I tend to use the OpenGFX terrain sprites as a guide. However, I discovered this:

bug report.png (11.6 KiB) Viewed 3647 times

All of these terrain sprites are lighter on the far side as this is the agreed* direction of sunlight. However, snow appears like this:

bug report 2.png (3.03 KiB) Viewed 3647 times

Evidently, the sunlight does not seem to affect the snow. The tiles are identical. Is this the desired effect?

When placed on the roof of a building the roof appears to just lack shading (left):

bug report 3.png (2.96 KiB) Viewed 3647 times

Granted, I can just make it look better by making the snow lighter on the correct side (right), but I thought I would mention this anomaly in the ground sprites.

*disputed by some!

[SwissFan91]

As a further point (I would edit my last post but I need another attachment) snow in the original GFX is, if anything, lighter on the other side of the hill. Strange.

bug report 4.png (5.07 KiB) Viewed 3629 times

[FLHerne]

That's quite interesting - I'd noticed that I found it much harder to understand slopes in snowy areas, but hadn't spotted why...

[Drury]

[OT]Also, if you play on a mobile platform where flipping the screen upside down isn't a problem (smartphone, for example), you'll see height differences reversed, i.e. all the hills become valleys and vice versa. Also, every button would look like it's pressed.[/OT]

It's kinda funny, how we're programmed to see the sun shining from upper right corner of the screen.

[planetmaker]

Apologies if this is the wrong place for this - I think it is a bug report but it may not be!

Yes I personally think it's a faulty light direction. No one yet was found to draw sprites where this was fixed. Could be yours to fix, if you wish

[bokkie]

Just thought about a suggestion: with the ability to provide sprites for each zoom level, wouldn't it also give higher quality graphics when zooming out if the sprites were provided by OpenGFX (using a nifty algorithm) instead of the OpenTTD blitter dropping every second pixel of the standard zoom sprites? I'm thinking of the effect as seen in http://www.tt-forums.net/viewtopic.php? ... er#p647910

Not sure of possible drawbacks or if I've misinterpreted the feature but with some scripting magic it might be relatively easy.

[planetmaker]

Just thought about a suggestion: with the ability to provide sprites for each zoom level, wouldn't it also give higher quality graphics when zooming out if the sprites were provided by OpenGFX (using a nifty algorithm) instead of the OpenTTD blitter dropping every second pixel of the standard zoom sprites? I'm thinking of the effect as seen in http://www.tt-forums.net/viewtopic.php? ... er#p647910

Not sure of possible drawbacks or if I've misinterpreted the feature but with some scripting magic it might be relatively easy.

I think you got that right. The same also applies here though: no-one did yet do that. I should actually appreciate much, if *someone* [TM] tackled that.

As there's no-one currently doing any improvement on any base set, please anyone, feel encouraged to step up

[Zephyris]

IIRC I drew all the terrain sprites copying the overall brightness of the original ground tiles for each slope direction from the original graphics... This definitely worked for the grass tiles, maybe I did mess it up for the snow; what do the original graphics look like in that situation?

Re: sprites at different zoom scales. It should be possible write a script to resize all the series automatically in a content aware way, ie using bilinear interpolation for most of the sprites, but using the current miss one pixel out method for the boundaries between the transparent and non transparent and the recoloured and non-recoloured... Practically how easy would it be to get the extra zoom level sprites coded if i can make them? And is there a list of which re colouring are applied to which sprite somewhere?

[ChillCore]

... for the snow; what do the original graphics look like in that situation?

Like this.