Project Organization Thread

[neob]

btw should we associate sprite numbers to sprites in the tracker ?

That would be helpful, but also a lot of work. I'd only do that for the sprites that are not yet done.
And for the sprites in the ofgxe_extra / openttdw/d grf, the numbers are yet to be established for the 32bppextra.grf.

BTW Neob, the 3rd list you've found is not a duplicate, it only contains links to tars for default zoom level tars.[/quote]

if there is some visual list (or at least some categorized list so i can easily compare against the sprites i have) i can do some of it ,i was planing somethings there anyway (btw i really hate those 3 additionals you put there)

and for the 3rd list, i forgot about it and was surprised i put it in that category, so for a sec i thought it was a leftover of those other lists.

[GeekToo]

One way is to use grfcodec. Download it, and from the commandline call: grfcodec -d xxx.grf
where xxx is one of the basegraphics files. Then it will create a pcx file for you, where all the sprites of that grf are shown.

[neob]

3. Arctic landscape without grass
isnt it inlucded in the 'Landscape wihtout grass by Alltaken' if not it should be grouped together.

For the moment It isn't included, but I can include It in the future.

i think it will be best, in the meantime i'll group them together (and any other grassless set i found)

neob: On roads, I am using v4, They are uploaded here. The Wiki doesn't link to them, because the main files link to road sets which use more than just the sprites in those v4's and are not under my name. Issue's previous stated.

i am not sure i understand the last part with the main files and the links but assume that v3 includes only your work and v4 includes yours and someone else.

[GeekToo]

i am not sure i understand the last part with the main files and the links but assume that v3 includes only your work and v4 includes yours and someone else.

The problem is that the main page links to : http://jupix.info/openttd/gfxdev-repo/i ... file&id=35
which is only updatable by Varivar, so Ben can not merge his V4 version into a tar with the other sprites that are also present in that tar, unless he forks it. This can only be solved by having multiple people have access to the file, or split the tars so that each graphics creator can at least access his own tars (and that would give problems if someone else than the graphics artist wants to pngcodec a set of pngs, he would not be able to put them back without forking).

The V3 version in the pictures section of the page can be replaced by the V4 version though.

I haven't said much about the organisation part in this thread. I think we can solve a lot of problems when we consider this offer:
http://www.tt-forums.net/viewtopic.php?p=832905#p832905

When the 32bpp_extra.grf and the tars consisting of work of multiple artists would be put there, it has the advantage that:
-multiple people can work at the same tars
-it offers version control
-it offers an issue tracker
-Jupix server can return to the state is was intended for, as a repository for graphics sources and resources,
and also save a lot of bandwidth

[neob]

One way is to use grfcodec. Download it, and from the commandline call: grfcodec -d xxx.grf
where xxx is one of the basegraphics files. Then it will create a pcx file for you, where all the sprites of that grf are shown.

yes and than something like IrfanView, with a supper zoom to be able to see something ...
thats going to be annoying as hell, i was hoping that there is some list availabile something like:

Farm Stages 1-9:
4126-4144
4145-4163
4164-4182
4183-4201
4202-4220
4221-4239
4240-4258
4259-4277
4278-4296

well i see what i can manage.

[Ben_Robbins_]

The way I check sprite numbers is by looking at trg1r usually, or one of the other graphics sheets.

I have just finished uploading most of the .bat's I have used onto the repository into the newly created section. I have named them first by the 1st and last sprite number, then a brief label. This may help you link number to sprite quicker.

Note: Jupix, I seem to have had an issue uploading one of the tar's. Any clues?

This is also a really helpful little tool, which Ammler made and helpfully linked me to, (change the numbers at the end of the address to look at other/greater ranges.)

[Ammler]

we have also some "lists" in the OpenGFX project for the sprites:

http://mz.openttdcoop.org/opengfx/autho ... itesbyfile
(src: http://dev.openttdcoop.org/projects/ope ... HTMLoutput)

or another one which is a bit outdated:

http://mz.openttdcoop.org/opengfx/newgr ... 00&h=30:50
(the url should be self explaining)
Edit: Ben already linked it too.

jupix
if someone didn't define a license, it is private, no derivate possible. Public Domain needs to be defined and can't be assumed.

Greets
Ammler

[neob]

Indeed, OpenGFX is already (at least for me) a well known name, with it's own style. Naming the 32bpp replacements 32BppOpenGFX or something like that would lead to confusion. It would look like it aims at replacing the 8bpp OpenGFX style, which is not true. It will replace the OpenGFX and the Original base set.
Besides, there already is a project that has that name (or at least close enough) on the OpenttdCoop DevZone, that indeed is aiming for the OpenGFX style.

personally i have no idea what is this 'own style' is, 32bpp without a zoom is just 8bpp with barely noticeable added sharpness.
and considering we are keeping to the originals our Z0 have the same style and our added style is the Full Zoom feature.


and by the way it looks the 'OpenGFX 32bpp' that enjoys all the devzone little features, is exactly the same with the same graphics but without the FULL ZOOM feature.

so multiple projects/tools/tracking's/documentation/ppl doing the same job, when 32bpp without zoom = copy *Z2.png from 32bpp fullzoom

we have also some "lists" in the OpenGFX project for the sprites:

http://mz.openttdcoop.org/opengfx/autho ... itesbyfile

thanks its will be very useful.

[GeekToo]

I did not mean to join that project, but to start a new one for extra zoom levels on that site, with all advantages I wrote in my previous post.

[Jupix]

Note: Jupix, I seem to have had an issue uploading one of the tar's. Any clues?

You mean 2929 - 2932 - Train - Brush Class '47'? It was caused by the apostrophes in the file name, name it just Class 47 and it should work.

jupix
if someone didn't define a license, it is private, no derivate possible. Public Domain needs to be defined and can't be assumed.

You're preaching to the choir.

I haven't said much about the organisation part in this thread. I think we can solve a lot of problems when we consider this offer:
viewtopic.php?p=832905#p832905

When the 32bpp_extra.grf and the tars consisting of work of multiple artists would be put there, it has the advantage that:
-multiple people can work at the same tars
-it offers version control
-it offers an issue tracker
-Jupix server can return to the state is was intended for, as a repository for graphics sources and resources,
and also save a lot of bandwidth

Well, a couple of thoughts about this.

1) Shared ownership of items will be coming online on my repo in the next few days. The code is already there.
2) Version control and automated hierarchical set managing are both unlikely to ever be implemented there because as you said, they go beyond the intended use of the script and would probably require a complete redeisgn.
3) We shouldn't have 2 separate repositories for the same project, because that's annoying to anyone who wants to keep tabs on anything. If something else than my repo is better for what the project needs, then with the best will in the world, mine would have to be abandoned. (When I put up mine, there wasn't a better repo out there.)
4) The intended use of my repo was not only graphics sources and resources, but finished and work-in-progress graphics too, only packed to contain 1 or nearly 1 item per package. So no big multiple-author sets like public releases tend to be. (My repository was not designed as a public resource.)
5) What good is an issue tracker for this kind of project?
6) I'm sad to hear there's an effort to build a 32bpp anything-related-to-OpenTTD when the original graphics set hasn't been converted yet. Why aren't they working on completing a set that's been worked on for nearly half a decade?

[planetmaker]

1) Shared ownership of items will be coming online on my repo in the next few days. The code is already there.
2) Version control and automated hierarchical set managing are both unlikely to ever be implemented there because as you said, they go beyond the intended use of the script and would probably require a complete redeisgn.
3) We shouldn't have 2 separate repositories for the same project, because that's annoying to anyone who wants to keep tabs on anything. If something else than my repo is better for what the project needs, then with the best will in the world, mine would have to be abandoned. (When I put up mine, there wasn't a better repo out there.)
4) The intended use of my repo was not only graphics sources and resources, but finished and work-in-progress graphics too, only packed to contain 1 or nearly 1 item per package. So no big multiple-author sets like public releases tend to be. (My repository was not designed as a public resource.)
5) What good is an issue tracker for this kind of project?
6) I'm sad to hear there's an effort to build a 32bpp anything-related-to-OpenTTD when the original graphics set hasn't been converted yet. Why aren't they working on completing a set that's been worked on for nearly half a decade?

ad 3) Definitely agreed. It never helps and only confuses people to what is current and what not.
ad 4) especially WIP things are nice to have with a version control, for both easier comparison and a clear time line. Best done automatically. For the same thing a tracker makes sense where a sprite is discussed until the artist is satisfied.
ad 5)
- Detailed discussion of single contributions until the author / critiques are satisfied and the coder can encode it.
- Noting alignement issues
- Noting other issues which may or may not arise, like incompatible style of related graphics,... sprite number mix-up, what-ever. Why would OpenGFX have one?
ad 6) I don't quite get what you mean there. As far as I understood the OpenGFX32bpp found on the DevZone, the intention is to gather 32bpp sprites which resemble the style of OpenGFX. So it is not necessarily a competition to what you plan here, but a sub project. Anything used there, can be used in a general 32bpp project (but not vice versa). But it doesn't cater 'full-zoom' but trunk-ready 32bpp only.

Now, the reason I went with this approach in the beginning is money, basically. As you may know the repo's already running on a 1mbps upline which translates to about 80 - 110 kB /s real download speed divided between all the concurrent users and users of my other websites. That's not a lot if I were to distribute megapacks that can reach 100's of megabytes in size. To get a bigger pipe to the server requires taking it into a server hotel which costs a fortune and as usual I'm not getting a penny out of doing this.

This could be solved by openttd.org hosting the user-friendly version of the repo, but seeing as no developer is that interested in the project, I don't see that happening. Though, I haven't asked since I think late 2008 or something.

This could also be solved by hosting the actual files somewhere else, like rapidshare, and have the files actually managed in a communal manner at a user-friendly repo, the sort you suggested. But I don't think this would improve anything compared to just using the wiki and forums for management.

Furthermore, automating the process of creating big packs at the repo takes considerable knowledge of how tars are handled using PHP and to be honest I don't have that knowledge, at least not yet. Also, it takes considerable server effort and we're running on a 600 MHz processor and less than 200 MB's of RAM. Compression is obviously right out of the question and I'm not sure how low specs like those would handle hundred megabyte uncompressed bundles.

Well the DevZone is hosted currently on a vserver in a data centre with 100Mbit connection and we have plenty of traffic volume to go, at least for now; its traffic might increase when OpenTTD 1.0.0 is out, though probably not much as OpenGFX is also mirrored on the official OpenTTD mirrors, so yes, we can offer this central place to host a repo like that, without much worry about traffic volume (how high is your traffic to your server?)

The automatic creation of tars could certainly also be implemented. Most newgrfs we host have a makefile which can be used to automatically create a nightly snapshot. That could most probably be done by the 32bpp project, too. It 'just' needs someone to write a decent makefile to automatically process the repository in the desired tars (or rather in this case, compressed tars ).

Maybe there's a good way to combine your existing repo and some possibly desired additional parts of the DevZone?

[neob]

That would be helpful, but also a lot of work. I'd only do that for the sprites that are not yet done.
And for the sprites in the ofgxe_extra / openttdw/d grf, the numbers are yet to be established for the 32bppextra.grf.

just another thought on adding the sprite numbers to the wiki tracker, how should it be implemented?

sprite numbers just not enough, there need to be some way to distinguish between the relevant grf
for example the ground page includes sprites from ogfx1_base/trg1r and ogfxc_arctic/trgcr etc...

so how shoud it be marked? (that of course if its still needed)

[Ammler]

Wouldn't it be better to think about a "helper" file for the pngs with the replacement (new)grfname, the sprite number and the offsets. This file could then be proceed by either a batch file or a precompiler or whatever.

Tracking such things in the wiki wouldn't help much

My proposal for the format:

Code: Select all

"<base|dutchcat>" <spritenum> "example.png" "<author>" xrel yrel

Maybe pngcodec could be modified to handle that. How do you get the offsets from a encoded png?

Greets
Ammler

[neob]

Wouldn't it be better to think about a "helper" file for the pngs with the replacement (new)grfname, the sprite number and the offsets. This file could then be proceed by either a batch file or a precompiler or whatever.

Tracking such things in the wiki wouldn't help much

you probably right, i prefer the automated system its provides much more freedom
but we need to keep in mind that the wiki entry's was made with a different purpose in mind, its a big project and making it accessible to as much potential dev's is a pro.

Maybe pngcodec could be modified to handle that. How do you get the offsets from a encoded png?

i was trying to figure the same thing before when i wanted to make the script, but i thought that this problem was solved.
anyway if its not possible if notice most TAR files includes bat files with this information courtesy of one of the guys (i dont recall who was it)

[GeekToo]

Wouldn't it be better to think about a "helper" file for the pngs with the replacement (new)grfname, the sprite number and the offsets. This file could then be proceed by either a batch file or a precompiler or whatever.

Tracking such things in the wiki wouldn't help much

My proposal for the format:

Code: Select all

"<base|dutchcat>" <spritenum> "example.png" "<author>" xrel yrel

Maybe pngcodec could be modified to handle that. How do you get the offsets from a encoded png?

Greets
Ammler

List the offsets: pngcodec l nnnn.png (nnnn being the spritenum).

Besides, I don't see much use for such a helper file.

The way to encode a png file:
pngcodec a nnnn.png x_offs=... y_offs=...

So the spritenum is already in the filename. The author's name can also be pngcodeced, by adding something like author="John Doe" to the pnccodec command, the game will ignore it.

The newgrf/base grf it is supposed to replace is not pngcodeced in the sprite, but determined by the directory you put the sprites in.
Most, if not all, frequent pngcodecers put their commmands in a shellscript/batch file, there are several of them uploaded to the wiki.

I prefer to keep the filenames a decimal number, that way they can be easily renumbered by a shell script if the sequence is the same, else manual action will be needed either way.

I did think adding spritenumbers to the wiki pages would be useful for graphics artists that wanted to name their pngs with the correct number (without having to use grfcodec), but seeing the link to the openttdcoop page that Ben en Planetmaker gave, I no longer see that need.

For tracking/progress reasons, a list of sprite number ranges that have / have not been done could be useful though, but that can be very easily scripted with some grep-ing through the original nfo file, and sorting some directory lists, if needed/wanted.

[neob]

may i request that uploading all 32bpp related images to the wiki under:

Code: Select all

[[Category:32bpp Images]]

which only requires to copy paste this to the image description when uploading.
tip: if you using bolk upload just hit Back after the upload and choose another file, save the time to copy paste it into the description.

i know that considering that right now the overwhelming majority of the pictures are UnCategorized its not very effective
but its doesnt hurt its easy and better to start it sometime.


you can make up your own category by changing the text [[Category:__HERE__]]
so for example if you want to add sprites it maybe nice to add it as something like [[Category:32bpp tracker Images]] or [[Category:32bpp BaseSet Images]]
just check here that there is nothing similar.

I did think adding spritenumbers to the wiki pages would be useful for graphics artists that wanted to name their pngs with the correct number (without having to use grfcodec), but seeing the link to the openttdcoop page that Ben en Planetmaker gave, I no longer see that need.

For tracking/progress reasons, a list of sprite number ranges that have / have not been done could be useful though, but that can be very easily scripted with some grep-ing through the original nfo file, and sorting some directory lists, if needed/wanted.

that what i was thinking, the only thing is regarding the grouping on that link which sometime determined by categories but mostly be the creator.
i can try to make a better sense of it by grouping it together according to categories and points of interest (all GUI together, all ground together etc...)

[Ammler]

My proposal for the format:

Code: Select all

"<base|dutchcat>" <spritenum> "example.png" "<author>" xrel yrel

List the offsets: pngcodec l nnnn.png (nnnn being the spritenum).

Besides, I don't see much use for such a helper file.

The way to encode a png file:
pngcodec a nnnn.png x_offs=... y_offs=...

So the spritenum is already in the filename. The author's name can also be pngcodeced, by adding something like author="John Doe" to the pnccodec command, the game will ignore it.

Yes, but where does pngcodec get those from? It would be a generic file, instead of e.g. the batch file Ben uses. So it doesn't depend on a special plattform.

Greets
Ammler

[GeekToo]

You're absolutely right, I knew I was missing something...

[32Bpp-Pack]

Those 4 files are the latest in ground tiles, I am completely sure of that. That is why they have the highest V number of those files. I can list the changes between each version if necessary! The list of files I recently uploaded all have symlinks.

how did you mange that, i havent managed to make TAR files with symlinks on windows using 7z (its treats it just as any folder)
it might be that 7z still doesnt support symlinks on windows (post from 2008: http://sourceforge.net/projects/sevenzi ... ic/2055235)

any ideas how to make it work?


thanks.

[32Bpp-Pack]

i am really have hard to time understand what is what on the repo

for example my latest nemesis is 'Rails_Ben_Robbins_temperate.tar' which is not temperate but artic and tropical as well.
on the other hand i have the newer 'Railways - With Lines v2.tar' file which includes only temperate tracks

i bet that if i just include all those files in the 'Full Pack' that most ppl will understand what to do without a detailed instruction
which means many more PM's i'll have to answer beside that it only unnecessarily inflate the pack size.

i can do it but i would really appreciate the hosted sets on Jupix go smaller as intended and use some standard naming convention as was suggested
those two things will make life much MUCH easier



EDIT1:
the file: http://jupix.info/openttd/gfxdev-repo/i ... file&id=37
seems to be mislabelled under vehicles instead of infrastructure

EDIT2:
i see a new "face" in the repo list, warm welcome to 'tsjook'

to be able to add your work its will be much appreciated if you can save your work as the rest:

Code: Select all

sprites\ogfxc_artic\sptire#_Z0        

(sprite number can be found here) because i am not a GFX developer so i dont really know where your work exactly goes, thanks