Transport Tycoon Forums

Reading all this much activity in the 32bpp branch and zoomlevel branch: what about making a 32bpp base set? What I can offer is that we at the devzone would certainly be happy to host such project and give help in organizing it. But some of you active 32bpp people would have to actually work on it, of course (I have my hands already in too many things at once). OpenGFX is there, too and you can easily copy much of its structure and the way it works. You'll " just" have to make sure to accomodate the 32bpp (I've no idea how that would work, but it can be done - somehow, I guess)...

You can register at the DevZone, write Ammler or me via forum mail or visit uns on IRC #openttdcoop.devzone at oftc.net in order to sort out commit rights and setup a new repository. Even if you decide to not make it a base set, of course it is feasable to host it as a project, but 32bpp base set sounds most fun to me

planetmaker wrote:Reading all this much activity in the 32bpp branch and zoomlevel branch: what about making a 32bpp base set? What I can offer is that we at the devzone would certainly be happy to host such project and give help in organizing it. But some of you active 32bpp people would have to actually work on it, of course (I have my hands already in too many things at once). OpenGFX is there, too and you can easily copy much of its structure and the way it works. You'll " just" have to make sure to accomodate the 32bpp (I've no idea how that would work, but it can be done - somehow, I guess)...

You can register at the DevZone, write Ammler or me via forum mail or visit uns on IRC #openttdcoop.devzone at oftc.net in order to sort out commit rights and setup a new repository. Even if you decide to not make it a base set, of course it is feasable to host it as a project, but 32bpp base set sounds most fun to me

Having a 32bpp base set would certainly be great and better than the current tar file system. Too bad I have no knowledge in writing grf files (I hope this is possible with 32bpp graphics). Having the 32bpp project hosted on the devzone would be great too. I'm willing to put time in this (like I'm already doing), but I won't be able to do work on the coding side, only graphics (and coding tar files if we decide to keep using them).

Btw, I think that, if we keep using tar files, this should be reorganized a bit. For example there are 9 tar files right now for the farmland tiles. I think it would be better to merge these files into one tar file. There are more tar files which could be merged to make downloading easier. Maybe there should be official tar files. Each of these files could cover a complete category, like "temperate_houses.tar"(which would contain all available temperate city buildings) or "ground_sprites.tar" (which would contain all available ground sprites).

Secondly I think the tar files should be compatible with the OpenGFX tileset in the future, instead of using the nonfree original graphics set.

Other problem is that some Wotan graphics has a non-commercial license. These graphics shouldn't be mixed with original graphics. This means that the road crossings sprites are a bit... without license. But It is only a provisional solution while someone writes a patch for the road crossings. They should be rendered with a base sprite and two sprites for barriers (front and rear). It would be two states (opened and closed) and It would be needed a new GRF file for these new sprites. I don't know if It can be done a specific patch for this in 32 bpp E.Z.L. branch.

The Wotan's stations are different, They could be made with a single GRF and tar file, but I need more examples of newGRF stations, because I don't have a high level of NFO coding in stations.

Also, there are some optional graphics:

• Landscape with lines or without them.
• Road vehicles depot (two styles)
• HQ4 (alternative without truck)
• Road arrows (there are three styles)

This could be solved with GRF files.

I don't think (though I have no clue) that .grf has 32bpp support, but I don't see how a base set wouldn't work.

maquinista wrote:Other problem is that some Wotan graphics has a non-commercial license. These graphics shouldn't be mixed with original graphics. This means that the road crossings sprites are a bit... without license. But It is only a provisional solution while someone writes a patch for the road crossings. They should be rendered with a base sprite and two sprites for barriers (front and rear). It would be two states (opened and closed) and It would be needed a new GRF file for these new sprites. I don't know if It can be done a specific patch for this in 32 bpp E.Z.L. branch.

So the current crossing tiles are somewhat illegal? What's is the license for the other graphics? CC-BY-SA or GPL?

Also, there are some optional graphics:

• Landscape with lines or without them.
• Road vehicles depot (two styles)
• HQ4 (alternative without truck)
• Road arrows (there are three styles)

This could be solved with GRF files.

I think we should make a decision which one to put in the main package. The alternatives can be done with optional grf files, like you suggested.

If a 32bpp base set won't work (because of coding limitations), we can keep using (larger) tar files. For example I made a tar file with all the current available city buildings. I made it compatible with the OpenGFX base set, instead of the original graphics set. The advantage is that some buildings sudden work again (like the cinema) and that the user doesn't have to download the copyrighted original grf files.

In short:
- if a 32bpp base set isn't technically possible, we should keep using tar files
- these tar files should cover a whole section, and not just buildings from one artist
- these tar files should be compatible with OpenGFX

- a devzone repository would be great
- it should contain the 32bpp full zoom patch, the precompiled windows version and the "official" tar files (maybe together with the OpenGFX grf files)

Link to the tar file: see post below

Please comment on this

I think that your idea is better, because OpenGFX graphics are free, and They have the same numer of sprites.

Maybe It could be needed a plan to renumber the sprites, to assign the work (for example, I can try the landscape tiles). Maybe some of the sprites (landscape, vehicles...) could be renumbered with special applications or scripts.

maquinista wrote:I think that your idea is better, because OpenGFX graphics are free, and They have the same numer of sprites.

Maybe It could be needed a plan to renumber the sprites, to assign the work (for example, I can try the landscape tiles). Maybe some of the sprites (landscape, vehicles...) could be renumbered with special applications or scripts.

I don't get why the sprites should be renumbered. The current sprite numbers are fine and compatible with both OpenGFX as the nonfree graphics. Renumbering would be a waste of time in my opinion.

I just remembered Jupix had a 32bpp repository too here. Here's the new link to the buildings tar:
http://jupix.info/openttd/gfxdev-repo/i ... file&id=29

I didn't know that the OpenGFX numbers was the same than original graphics. This makes the things easier.

maquinista wrote:I didn't know that the OpenGFX numbers was the same than original graphics. This makes the things easier.

No problem . The only thing needed to make the sprites compatible with OpenGFX is changing the folder name "~/sprites/trg1r/~" to "~/sprites/ogfx1_base/~" in the tar file.

I've drawn tree new trees, see attachment. Here's the link to the coded file:
http://jupix.info/openttd/gfxdev-repo/i ... file&id=30
This file is compatible with OpenGFX (unpack and rename ogfx1_base to trg1f for the original tileset) and contains all 32bpp fullzoom trees currently available. I will upload an updated varivar_trees.tar file soon.

One question... where I should put the tar files to use them?

I tried to place the tar file with city buildings in data folder, but It doesn't work.

They have to be in the data folder, just like the other tars. You have to enable the OpenGFX base graphics set in the settings menu. You need to put the opengfx tar files and the *.obg file in your data folder too. You can download these files here

Thanks, It works. The problem is that the OpenGFX TAR files downloaded by OpenTTD desn't work.

The trees modeled are great. I will upload the farm tiles by Alltaken, the temperate tiles (road and rail) by Ben Robbins.

maquinista wrote:Thanks, It works. The problem is that the OpenGFX TAR files downloaded by OpenTTD desn't work

Please define "doesn't work". What exactly did you do? What do you see? What do you expect to see? What's the difference?

The farm tiles are coded. I'm working on the grounds of rails and empty tiles. Also, I have the effects coded, and I will upload them soon.

planetmaker wrote:

maquinista wrote:Thanks, It works. The problem is that the OpenGFX TAR files downloaded by OpenTTD desn't work

Please define "doesn't work". What exactly did you do? What do you see? What do you expect to see? What's the difference?

I downloaded the OpenGFX with OpenTTD, and the 8 bpp graphics works well, but the 32 graphics are not loaded (I had the TAR files for City buildings and trees).

Then, I extracted the OpenGFX GRF files in the data directory (OpenTTD_32/data), and I renamed the TAR files downloaded by OpenTTD (with .bak extension, to disable them). I started OpenTTD, and the 8 bpp graphics work well, and the 32 bpp TAR files replaces 8 bpp graphics well. Also, I have modified more TAR files, and They work well.

Hmm, so in a nutshell, when the (8bit) opengfx sprites were .tarred, the 32bpp replacement sprites were not shown, but when you extracted the 8bit opengfx sprites, the 32pbb replacement worked?

Correct?
If so, that's kind of like the problem I had with wotan's stations and the dutch catenary. It wouldn't work while the 32bpp sprites were .tarred, I had to untar them first, then they were shown. Maybe it's a bug in the patch, or even in trunk (did anyone check this without extrazoom?)

I have coded the foundations, the rail stations, the industries and the GUI sprites, I only need to write the file with authors. I will upload them tomorrow. Also, I want code the coast tiles, because I have to finish the Arctic sprites.

Roujin wrote:Hmm, so in a nutshell, when the (8bit) opengfx sprites were .tarred, the 32bpp replacement sprites were not shown, but when you extracted the 8bit opengfx sprites, the 32pbb replacement worked?

Correct?
If so, that's kind of like the problem I had with wotan's stations and the dutch catenary. It wouldn't work while the 32bpp sprites were .tarred, I had to untar them first, then they were shown. Maybe it's a bug in the patch, or even in trunk (did anyone check this without extrazoom?)

I will try to repeat the bug tomorrow. I have lots of tar files in the data folder, and I want get rid of some of them before this.

Weird, the tars worked fine for me without unpacking files. I'm using the precompiled Windows binary, so maybe the bug only occurs in the patch?

Maquinista, the tar file with the ground tiles only contain the arctic tiles, the other climates are missing. Did you forget to add them?

Yes, I have forgotten that I have 3 files for 3 climates.

I will upload these two files for temperate and artic, or maybe I will join the all the climates in a single file. It will have 17 mb.

I tried to upload the 20 mb file for all climates, but It doesn't work, maybe because its size.

If You want, I can upload it in a direct download server, or upload 3 files, one for each climate.