FIRS Industry Replacement Set - Development

[andythenorth]

So, is there interest in 32bpp?

[Zephyris]

So, is there interest in 32bpp?

I started having a go at it last night... I think it would be quite possible to make 32bpp graphics in the zbase style; with the render templates in place it is quite quick to do the drawing...

[NekoMaster]

So, is there interest in 32bpp?

I started having a go at it last night... I think it would be quite possible to make 32bpp graphics in the zbase style; with the render templates in place it is quite quick to do the drawing...

with zBase being the only 32bpp base graphics grf at the moment, it would be nice if there was zBase style stuff to go with it.

[TadeuszD]

So, is there interest in 32bpp?

I hope, that FIRS will be still compatible with 8bpp. For me, 32bpp could never exist.

[andythenorth]

I hope, that FIRS will be still compatible with 8bpp. For me, 32bpp could never exist.

It will remain 8bpp compatible.

It goes like this: I like traditional TTD appearance, so I draw FIRS in pixels to suit that (I'll never play with zBase etc unless it's an MP game, or my eyes get too old to see teeny-tiny pixels).

But zBase is nice, and many players will want it, and 8bpp FIRS looks totally stupid with it, so a 32bpp zBase style version is desirable there, and I like Zeph's style, so why not

[Zephyris]

... and I like Zeph's style, so why not

... and I like FIRS, so why not

I have made most of the sprites for these industries:
Aluminium Plant
Arable Farm
Biorefinery
Brewery
Brick Works

Would you like them to test out?

[TadeuszD]

It goes like this: I like traditional TTD appearance, so I draw FIRS in pixels to suit that...

Thanks! I was afraid, that 32bpp will become the "main" sprite set, and 8bpp will be created by simple scaling down 32bpp pictures... It would be awful and "not compatible" with spirit of 8bpp.

[andythenorth]

Thanks! I was afraid, that 32bpp will become the "main" sprite set, and 8bpp will be created by simple scaling down 32bpp pictures... It would be awful and "not compatible" with spirit of 8bpp.

No, most of the sprites are now done. There are a few industries left to do. These will probably be drawn from scratch as pure pixel art, although I have no objection to pixel-painting renders (that's how some of FISH is done).

@Zeph - I don't know how to add 32bpp sprites, but if you post yours here, or on devzone issues, I think it will get figured out.

[NekoMaster]

If we have someone to render the graphcis and someone to code them, I'd be more then happy to test some stuff out.

Also, I was thinking that 32bpp firs would be an addon or a parameter for zBase or FIRS, since not everyone wants to play with 32bpp. Some people can't since 32bpp does take up more reasources (anything worse then a modern netbook (1.6Ghz hypder threaded, 2GB ram and 128 MB video) will have a hard time)_

[Yexo]

Also, I was thinking that 32bpp firs would be an addon or a parameter for zBase or FIRS, since not everyone wants to play with 32bpp.

For zBase it's very simply: don't use it but use OpenGFX instead. For FIRS you can always force the 8bpp blitter in which case OpenTTD will fall back to 8bpp graphics. If the amount of resources is a problem you might want to limit the number of zoom-in levels too. That's already possible via an OpenTTD setting.

This is all besides the fact that it's impossible for a FIRS parameter to influence any of this. The only way FIRS can do anything about it is by providing two grf files, one with and one without 32bpp sprites.

[Pyoro]

I might just be confusing something here, but I read some people considering 32bpp for pixel art graphics - don't think there actually are any yet that do this, but it'd be stylistically problematic to use both those and FIRS then, potentially? As it wouldn't be possible to let theoretical-32bpp-pixel-art-GRF use 32bpp, but FIRS in 8bpp mode (unless the 32bpp version will be done as a seperate GRF)?

[Michi_cc]

The only way FIRS can do anything about it is by providing two grf files, one with and one without 32bpp sprites.

It somewhat can by declaring an 8bpp blitter in the A14. As long as OTTD can automatically choose the blitter it will only use the 32bpp graphics if zBase is used. Fails somewhat for OS X as we sometimes force a 32bpp blitter there.

-- Michael Lutz

[andythenorth]

The only way FIRS can do anything about it is by providing two grf files, one with and one without 32bpp sprites.

I see no problem with building two grfs from the same codebase. But some work yes

[Yexo]

The only way FIRS can do anything about it is by providing two grf files, one with and one without 32bpp sprites.

I see no problem with building two grfs from the same codebase. But some work yes

There would be no need to build twice, simply run the complete grf through the grfstrip utility to strip all 32bpp sprites. This has no effect on savegame compatibility. There has been talk of even integrating this in bananas so every grf can be offered in two variants: one with and one without 32bpp sprites.

[andythenorth]

There would be no need to build twice, simply run the complete grf through the grfstrip utility to strip all 32bpp sprites

Even better.

So does 32bpp compile take longer?

[Yexo]

So does 32bpp compile take longer?

A little bit of course, since nml has more work to do. However it should be very little extra time once the spritecache kicks in.

[Zephyris]

It might be easiest if I can get access to the repo, then I can directly upload the full set of blend sources in the correct directory structure for the texture linkage between files to work....

[andythenorth]

It might be easiest if I can get access to the repo, then I can directly upload the full set of blend sources in the correct directory structure for the texture linkage between files to work....

You've got developer permissions here http://dev.openttdcoop.org/projects/firs/repository

[planetmaker]

It might be easiest if I can get access to the repo, then I can directly upload the full set of blend sources in the correct directory structure for the texture linkage between files to work....

You've got developer permissions here http://dev.openttdcoop.org/projects/firs/repository

Juhu
I'm looking forward to the results.

[Brumi]

I have a slight problem with the language file changelogs. There are some strings which were changed in the English version, but I don't want to change them in the Hungarian version, cargo and industry names are examples of these strings. Although I update the Hungarian translation, these strings still show up as changed, but I merely didn't want to change them, so those strings are up to date. It's getting difficult to keep track which strings have really changed since my last translation.
Is there a way to fix this?