Project Organization Thread

[planetmaker]

I've quickly extracted the extra newgrf from OpenGFX. Find attached the source for such newgrf with the makefile adopted for easy building of it. You might want to adjust the Text and possibly the filename of the grf itself. See Makefile.config for that. Also the readme is still OpenGFX's readme, most pcx which are attached probably contain more sprites than this newgrf uses as the files are used by different parts of OpenGFX. Even though it built for me, also the Makefile might still have some quirks and issues.

As it's now you need
gcc
make
grfcodec
nforenum

in order to build this newgrf. The need for gcc could be lifted with a bit of editing and the #defines are replaced by real NFO again and the desire to have automatic version detection is given up.

The code should be somewhat documented, so that the single parts can be identified, moved or removed as seen fit. For anything after the action8 a particular order of the single code blocks is not needed.

The GRFID is already adjusted such that it is not detected anymore as a base set file, license is GPL v2

I hope this may be of help to get the newgrf started and give you something to work with.

EDIT: typo
EDIT2: obviously bundle_zip created an empty file as I missed to fix one place in the makefile (and I was too tired to check the file size yesterday night).

Use the following patch for the Makefile:

Code: Select all

diff -r b3d9ddbdd79c Makefile.config
--- a/Makefile.config	Sat Jan 30 03:36:42 2010 +0100
+++ b/Makefile.config	Sat Jan 30 12:55:21 2010 +0100
@@ -67,7 +67,7 @@
 
 DOC_FILENAMES = $(addsuffix .$(TXT_SUFFIX),$(basename $(LICENSE_FILENAME) $(CHANGELOG_FILENAME) $(README_FILENAME)))
 
-BUNDLE_FILES  = $(GRF_FILENAME) $(DOC_FILENAMES) $(OBG_FILE)
+BUNDLE_FILES  = $(GRF_FILENAME).$(GRF_SUFFIX) $(DOC_FILENAMES)
 
 # Remove the @ when you want a more verbose output.
 _V := @

[planetmaker]

1. is this the way how OpenGFX constructed and thus when finished will potentially allow the 32bpp be load in the game options as the base graphic set?

If you want to make a full base set, you can just replace all OpenGFX sprites. Once all sprites exists, it certainly makes sense to compile a version which matches exactly the extra newgrf which is part of OpenGFX, so that the full base set is replaced by 32bpp; on its own it cannot be. And making yet another baseset where you can replace existing ones (you'll always have to provide 8bpp)... I don't see the need nor much reason in it for this purpose.

1. We want to create a complete newgrf, so no symlinking is needed anymore. Easier for future tar creators, lot more work in creating the newgrf
2. Or we only want to create a newgrf for the extra sprites, like the ones in openttdw, to solve the problems with different spritenumbers between ogfxe_extra and openttdw.grf, and keep symlinking the rest
3. Or: we have no idea what GeekToo is talking about

I'd vote for option 2.

[neob]

Run down of the resources we have:
Patch main page
Extra zoom Tracker
Abandoned buildings
Props page

Opengfx compatible Tars and Original graphics compatible TAR's which i hope to transfer into -> http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files


Guides: (Main 32bpp development page)
How to Create 32bpp Graphics with Extra Zoom
Ground Sprites Automation process
some Ground sprites conversions list
some Rendered Angles table

and info regarding the Repo - http://wiki.openttd.org/32bit_Graphics_ ... Repository
and Pngcodec info - http://wiki.openttd.org/PNGCodec


so i want to make sure where go what, where do you want to show what sprite has been chosen for the 32bpp base set? in the tracker?
where do you want to link to the available tars? on the files page? how about the additional tars for feature grf use?
i also noticed there was a mention of 3D models... and what about the props page?
any thought on how to arrange and what?


p.s. thanks planetmaker.

[GeekToo]

Thanks a lot Planetmaker for giving us this jumpstart,
I managed to create a grf file using your setup. I only had to rename the pnfo file name in the sprites directory to match the name in the config (and some macros in the test target in the makefile were incorrect), and then it worked.

I tried to figure out the exact sequence, and then I realized that nforenum is a dangerous command for our purpuse. Do you know of a method to force it to start a certain sprite always at the same number?

[planetmaker]

I tried to figure out the exact sequence, and then I realized that nforenum is a dangerous command for our purpuse. Do you know of a method to force it to start a certain sprite always at the same number?

Nice to hear that it works for you.

Concerning nforenum: it doesn't add or remove sprites. Unless you add sprites at other places than the end of the file, it won't hurt you. If you need space, add dummy sprites. Action 0C are comment sprites without function - but they have a number and can be replaced by useful sprites later on.

It is also always an option to skip the use of nforenum, it's not required, it's mostly a code correctness check.

I'm not sure whether it has a command line option to preserve sprite numbers. A quick look at the documentation didn't tell me, but it has many parameters and I didn't check all.

[GeekToo]

A proof of concept:
I created a 32bpp_extra.grf, that solves the coast line issues both for opengfx and default_windows graphics users. I used Planetmakers setup posted above.
I had to add a couple of sprites in the pnfo, because the 10 sprite coast replacement is only for base graphics, not for newgrfs. They have to use the 16 sprite variant of action 5.

I also created a tar to use with the newgrf with the 32bpp coast tiles. I put the tar and the newgrf in the data directory, activated the newgrf, and hooray, coast issue is gone ( for 8bpp it will not look good, because I just copied some sprites in in the nfo file, without changing the coords to the pcx file). For me, it works in 32bpp for ogfx and for original_windows baseset, no symlinks needed.

[FooBar]

You can put the newgrf in the tar. Then you have everything in just one file.

[GeekToo]

Yes, I did consider that, but since I expect that while the project is progressing, there will be more tars with pngs in them that need this, it is not useful to have them all include the grf file. Until a 'final' big pack is made I think a more modular approach is easiest to maintain.

[Ammler]

I would "remove" all the pseudo sprites which aren't necessary like the version checking, 2cc color map etc. use only the most necessary sprites so you will have the most possible stable extra grf.

Edit: also add some placeholder sprites between every feature, so you won't break compatibility, if the gui or whatever will change...

Edit2: then you need to talk with devs about a "autoloading" feature

[ArmEagle]

I hardly understand the technicalities. But I did encounter the issue of different sprite IDs between openttd and opengfx myself with the catenary sprites. I ended up just creating two different tars with the right sprite IDs for each. Maybe that is a situation that could be included in this grf?

I haven't looked further than just the catenary sprites, but are there many sprites that have completely different IDs (I can imagine that whole groups are 'shifted down'), or is it just some groups that are changed? Not that it really matters, but I was just wondering.

[GeekToo]

I would "remove" all the pseudo sprites which aren't necessary like the version checking, 2cc color map etc. use only the most necessary sprites so you will have the most possible stable extra grf.

Edit: also add some placeholder sprites between every feature, so you won't break compatibility, if the gui or whatever will change...

Forgive my ignorance on this Ammler, this was my very first newgrf mod ever, but if I remove the 2cc color map, does that mean that 2cc liveries won't be supported with this set?
Removing the version checks does make sense to me, and I was thinking about placeholder sprites already, so we can have a couple of 'nice' number ranges.

I hardly understand the technicalities. But I did encounter the issue of different sprite IDs between openttd and opengfx myself with the catenary sprites. I ended up just creating two different tars with the right sprite IDs for each. Maybe that is a situation that could be included in this grf?

Yes, that is exactly the reason for creating this newgrf, to prevent that kind of mess, where we have to renumber pngs and then they wont work for ogfx or vv. This way we can number the sprites the way we want them (only the ones in the ogfxe_extra grf, but that is the one with different spritenumbers from openttdd/w). Why it was rearranged I don't know, the opengfx guys probably had their reasons for rearranging the sprites.

[Ammler]

I would "remove" all the pseudo sprites which aren't necessary like the version checking, 2cc color map etc. use only the most necessary sprites so you will have the most possible stable extra grf.

Forgive my ignorance on this Ammler, this was my very first newgrf mod ever, but if I remove the 2cc color map, does that mean that 2cc liveries won't be supported with this set?

No, your NewGRF doesn't need to handle those things, as that will already be done with the extra base grfs, which you would still use.

Greets
Ammler

[GeekToo]

OK, thanks, then I'll rip them out.

I think it best to create a seperate thread for the newgrf development, I'll do that when I've made a new update, so we can focus on sprite organisation in this thread again.

And while we're on that subject, I moved all download links from the extra zoom patch page to http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files, so we have a complete overview of all available downloads on one page. Layout must of course be improved, but at least the info is at one page.

The page [[32bpp_fullzoom_base_graphics_set]] can be dumped I think, it is available in the section --Tars compatible with the original base set-- of the 32bpp_Extra_Zoom_Levels_Files page.

That section also provides a nice overview of tars that need to be modified to work with both ofgx and original graphics, in my opinion, in the end we only want tars that work for both, and not for one of the two. Since that is already the case for Ben's landscape tars (right Ben?), those can be removed from that section, the screenshot can be moved to the subsection of the development tracker, pictures in the download overview is not workable when more than a few tars are available.

[Ben_Robbins_]

Yeah, The field sprites, road sprites and ground sprites I uploaded to the Repository the other day should work for all. I haven't tested in both, only with OpenGFX for that set. I've converted quite a few files, but stopped uploading when confronted by the issue of creating duplicates because there uploaded under another name. I'll continue when that is resolved.

[neob]

OK, thanks, then I'll rip them out.

I think it best to create a seperate thread for the newgrf development, I'll do that when I've made a new update, so we can focus on sprite organisation in this thread again.

And while we're on that subject, I moved all download links from the extra zoom patch page to http://wiki.openttd.org/32bpp_Extra_Zoom_Levels_Files, so we have a complete overview of all available downloads on one page. Layout must of course be improved, but at least the info is at one page.

The page [[32bpp_fullzoom_base_graphics_set]] can be dumped I think, it is available in the section --Tars compatible with the original base set-- of the 32bpp_Extra_Zoom_Levels_Files page.

that what i was aiming for although i am not the one who is going to use it so i'll wait for some feedback.

[Ben_Robbins_]

neob: I don't have 'an answer' but a preferred criteria, which as long is in consideration I think will mean it'll work fine. That is just that 'drive through traffic' doesn't easily get mislead down tangents, but if people wish to find graphics not in the 'main trunk set of tars' can do so, and artists/editors/beginners have a separate section. We shouldn't have a set of dead ends though, each for each criteria, they should link on from each other as further reading.

I think moving the jupix repository list from the main getting started 32bpp page is a good move, but having that list AND the picture list and extra grf's on the same page will lead to problems where a resent post is a perfect example, as multiple ground sprite tars have been downloaded.

Also having things such as the ground sprites in the 'picture list' is pointless if it's also in the 'Jupix Repository list' IF the files are the same, so this is only advantages if it offer's smaller clumps of sprites, which allow for a more customized assemblement of graphics.

[neob]

I think moving the jupix repository list from the main getting started 32bpp page is a good move

any thoughts on the layout?

but having that list AND the picture list and extra grf's on the same page will lead to problems where a resent post is a perfect example, as multiple ground sprite tars have been downloaded.

yep some clarification in order.

Also having things such as the ground sprites in the 'picture list' is pointless if it's also in the 'Jupix Repository list' IF the files are the same, so this is only advantages if it offer's smaller clumps of sprites, which allow for a more customized assemblement of graphics.

[/quote]
at the moment the second layout its a copy past, the content wasnt updated for two month so you ppl need to update it with whatever you got in the repo.

as for its location i am content to leave it there for the time being and when it will grow enough it will be split, although i think that the 'smaller clumps of sprites, which allow for a more customized assemblement of graphics' should be merged with the props page.

[Ben_Robbins_]

No contradiction there, if that's what being implied. I said it should be moved...it has been. I said it shouldn't be on the same page as the other list. It can be moved without being merged. Splitting up one page, doesn't have to require the merging of it and another.

Don't mean to make it sound like I'm suggesting but not editing. I'll change as I upload files, but the multi-users being able to change files on the repository is a prier-issue. No point cleaning the 'front-page-interface' of it all if the archive behind it isn't very organised.

It was updated more recently than a month, since I changed the links for both farm and ground sets when I uploaded the openGFX compatible versions about a week ago.

There is a big difference between the 'smaller sets of sprites' and props. 1 is for people playing the game who wish to customize there sets of graphics. The other is for artists to work with, and work off. One is a list of sprites, one a list of 3ds files. (although there appears no links..need to work on that). I have no idea the justification for the farm being on that page. What that is a prop to I don't know.

[neob]

No contradiction there, if that's what being implied. I said it should be moved...it has been. I said it shouldn't be on the same page as the other list. It can be moved without being merged. Splitting up one page, doesn't have to require the merging of it and another.

nope contradiction, merging it with prop page its only a suggestion which doesnt seem as good after this:

There is a big difference between the 'smaller sets of sprites' and props. 1 is for people playing the game who wish to customize there sets of graphics. The other is for artists to work with, and work off. One is a list of sprites, one a list of 3ds files. (although there appears no links..need to work on that). I have no idea the justification for the farm being on that page. What that is a prop to I don't know.

but in any case before we do anything with it its need to be updated, no point in sprouting stubs all over.

Don't mean to make it sound like I'm suggesting but not editing.

it didnt and i just pointed that the second layout content e.g. the landscape tiles etc wasnt updated since viarviar first created it and that i dont really know what you pp want there so i cant do it myself

No point cleaning the 'front-page-interface' of it all if the archive behind it isn't very organised.

agreed, just hope you ppl make some convention (like for MP3 performer-album-song#-song name) to allow us to distinguish wth is everything

[neob]

GeekToo, i seen you updated the second layout, i guess you noticed that this layout is nice for static list otherwise moving something in there is hell, since now you have to update all of the table ...
that why i prefer the first layout list like layout one entry = one row and we can add a another picture cell (much like the train tracker list)


also i should we use the same category system for the additional sprites in that pictury template?
maybe some grouping is inorder because no point to spread all the grass less sprites around, better to provide them together, no?

---

anyway i updated the main page and file pages, removed and redirected the old base compatible page to the File page
and going to update the navbar soon.

btw any ideas on the progress bar ?