OpenGFX - Graphics Base Set

[DeletedUser21]

Well okay, but if this one is right then the transmitter is done I guess.

[theBohemian]

Hi,
this is the 3rd attempt at getting a replacement of the proprietary graphics in OpenTTD and I really appreciate this happening: I have put OTTD 0.6.0-beta4 into OpenEmbedded and this game would shine a lot more if media would already be included.

However what alarms me that this effort seems to *not* make use of a version control system to store its progress. It looks to me as if it is tried to finish the OpenGFX effort in one rush without leaving room for gradual improvement. Sure someone is updating the first post in this thread, manually repacks the data, uploads it to the forum and perhaps updates the Wiki. But there is so much manual work required for that (which is error prone and time consuming) that I fear that this effort's initial maintainers will sooner or later lose interest and nothing is preserved for others to pick it up.

There are free media projects for other games that where proprietary once upon a time, e.g. free arena, freedoom or descent2. You should have a look how they manage their work.

My own suggestions look like this:
- put all the collected media into a repository(you can ask the OTTD maintainers whether they will give you a directory within their repo or simply register an openttd free media project at sourceforge)
- instead of updating the wiki page use a text file (or many text files) to track the current state of available replacements
- if not done decide on a proper license (note: creative commons has many licenses, those that have noderivs and/or noncommercial in the name are unsuitable aka non-free by DFSG/OSD/FSD)
- write a makefile that can automatically generate the GRFs from the images (or whatever the redistributable format is) so people can build and test stuff on their own like they do with OTTD itself
- make intermediate releases once in a while
- if possible collect source data for the sprites (e.g. blend files and such) without this no one can properly enhance someone's work

Good look!

[LordAzamath]

Good look

Yeah we know it looks good :D.. Thanks

My own suggestions look like this:
- put all the collected media into a repository(you can ask the OTTD maintainers whether they will give you a directory within their repo or simply register an openttd free media project at sourceforge)

Well... what's the difference if it's put up here or in some repo?

- instead of updating the wiki page use a text file (or many text files) to track the current state of available replacements

Wiki is a nice thing and it really isn't hard to keep track

- if not done decide on a proper license (note: creative commons has many licenses, those that have noderivs and/or noncommercial in the name are unsuitable aka non-free by DFSG/OSD/FSD)

OpenTTD is distributed with GPL, I think this one should do it too, but only when it's finished. Still under (not very much) discussion

- write a makefile that can automatically generate the GRFs from the images (or whatever the redistributable format is) so people can build and test stuff on their own like they do with OTTD itself
What's wrong with grfcodec?
- make intermediate releases once in a while

The first post is full of intermediate releases

- if possible collect source data for the sprites (e.g. blend files and such) without this no one can properly enhance someone's work

8bpp project is pixel art not rendering. Blend files are in the blender thread, that is 32bpp.

madis... And I truly am the one (with Zephyris and Soeb) who is updating (sometimes ) first two posts.

[peter1138]

Well... what's the difference if it's put up here or in some repo?

You get to keep every single version of everything.

OpenTTD is distributed with GPL, I think this one should do it too, but only when it's finished. Still under (not very much) discussion

License should be agreed before doing anything, else you'll have to go back and find all the artists who dropped out to agree later, or face redrawing artwork.

What's wrong with grfcodec?

With a build system you can simplify and automate adding artwork to the finished files.

8bpp project is pixel art not rendering. Blend files are in the blender thread, that is 32bpp.

8bpp artwork can very easily be derived from rendered artwork. Having source available for that is good.

[Zephyris]

You get to keep every single version of everything.

As you do here, it is just be harder to find it.

License should be agreed before doing anything, else you'll have to go back and find all the artists who dropped out to agree later, or face redrawing artwork.

Very true, I have, from the start, stated that my graphics can be used under GPL, CC or similar licences.

With a build system you can simplify and automate adding artwork to the finished files.

Any volunteers? We are all artists...

In the light of this would anyone like to volunteer to set up:
* An ftp for work in progress/source files (32bpp originals, .blend files, partial works)
* An automated build system which can take multiple newGRF files, identify the sprite replacements, and automatically generate trtg*r.grf files
???

[richk67]

From my experience with NewGRF_ports, where I include my developing .grf files, there is only one item that actually benefits from having a history; the commented .nfo files. The .pcx files cannot have a diff, nor can the .grf files. They are full replacements each time. The .nfo is only worth keeping (but obviously stored with its associated .pcx) if it is commented. Without comments, you may as well just grfcodec -d the .grf file.

The build system for openttd.grf is fine - for those who know how to work it. I have no idea - the minor components (including the incomplete airports.grf) got sucked into the system*, but apparently a rebuild of the .grf could then move the sprite groups about - not handy for reference by external .grfs. So its fine when the build system is clear and obvious (and works simply on all platforms - Linux users take note - we dont all love command lines).

*(Ive now recoded my .grfs to not use any of the openttd/airports.grf components as I cannot rely on them being in the same location, and writing tons of relocation newgrf code to find the new locations is stupid compared to referring to a known static sprite location - now within my own .grfs. Anyone who wants to complain about that decision can have the joy of recoding the airportsextended.grf to find, say, a relocated helipad sprite. And I mean DO it, not just say how easy it is. Ive looked at it, and there are issues that are not addressed on the NewGRF wiki, like how to build a sprite-stack from relocated sprites. (Sprite-stack: aka a sprite layout - which is confusing when I have airport layouts of sprite layouts, hence my calling them sprite-stacks, which I feel is a more appropriate description). Have fun (not).)

[Zephyris]

As richk67 said....

I think the problems are more due to the intrinsic nature of GRFs and graphics. Graphics on their own, whilst time consuming and hard work to make, are useless. Similarly nfo code is hard to make, but useless without graphics. The unfriendly nature of GRF files (no stored comments, only decodable via command line), the confusing nature of nfo files (hex code and pixel coordinates) and the fiddly nature of pcx files (fixed palette and old-fashioned file type) doesn't help. In addition nfo code comments are of limited use for this type of project - graphics replacement - there is no "code" to explain, only hundreds of pixel dimensions and coordinates.

The most important thing probably is to make as many useful releases as possible - this is why I have been making the OpenGFX - new* "compilations" - newTerrain, newLandscape, newInfrastructure and soon newVehicles are (nearly) stand-alone grfs. This ensures, whether the project stalls again or not, that there are useful graphics for the next attempt to use.

[richk67]

In addition nfo code comments are of limited use for this type of project - graphics replacement - there is no "code" to explain, only hundreds of pixel dimensions and coordinates.

Maybe not in the main OpenGFX, but the more advanced features in OpenGFX+ could be quite educational if well commented.

[Trond]

I guess if noone have any objections that arctic forest is done then...

Oh, and about comments in nfo files, if there are comments in an nfo file, and its encoded to grf and then decoded again, will the comments still be there, or do they get removed in the process?

[DaleStan]

Try it and see?

[LordAzamath]

Try it and see?

They get removed. But if you add ActionC then you can comment again with comments staying in the file..
the size will get so big though that it's hardly useful to put all your comments into ActionC. Infact, it mainly should be used in intermediate releases and final release to say what starts where for example

Code: Select all

-1 * 00 0c "Intro GUI starts here" 00

I'll answer the rest things when I'll get back

[athanasios]

Battery Farm: (with a small exception in lower resolutions (1024x768 and under) - looks a bit more pixelated - but better draw for the future!)
NOTE1: Can you make available 2 more states? (1. battery tops only (like original), 2 a bare ground without batteries) in case we add it in +?

regards
athanasios

[DJ Nekkid]

In the light of this would anyone like to volunteer to set up:
* An ftp for work in progress/source files (32bpp originals, .blend files, partial works)
* An automated build system which can take multiple newGRF files, identify the sprite replacements, and automatically generate trtg*r.grf files
???

I can probably provide an FTP, and with not too much work could i provide "nightlies" or "weeklies" or something.

My thoughts:
A few directories for sprites, typical vehicles, infrastructure/terrain, buildings etc, and sprites is put here.
Included - dir for included .nfo files
Not included - dir for not included .nfo files

the root directory should contain the "raw" .nfo file containing all new graphics, plus the new openGFX-all(+).grf file.

and every now and then could i copy/paste the "not included" at the bottom of it's section/overwrite the old one.


If this is acceptable i'll do it tonight. i have a 16/1mbit internetconnection with static IP

[theBohemian]

Well... what's the difference if it's put up here or in some repo?

- other people can build the graphics pack too (if the neccessary infrastructure is added, of course)
- this allows contributors to try things, e.g. enhance someones work
- people like me could build opengfx from source and include it in binary packages for OpenEmbedded
- this may give opengfx more exposure

I expect that the work on the graphics will be an ongoing task that accompanies OTTD's development. Are you going to put stuff into this forum for years?

Apart from that: Each and every free software game out there has its media in the repo along the sourcecode. What is the reason for OTTD to be different?

The question for an initial repository came up: What about OTTD's repository? Add a new directory and import stuff therein.

[Red*Star]

Well, here is an intermediate version of the rig. I have to add many details (again)..., I know. but I think this time I'm on the right way .


I've also used some time for research on the subject "oil rigs in general".

There are plenty of different types - floating, being installed on continental shelf or offshore, with the pillars used as oil depot or not...











The most cowing thing is the size of some of these "monsters" (the wikipedia says the Petronius Platform is the tallest with 610 metres). (See comparison in third pic.)

At the two last pictures you see that the colorfulness of my platform isn't so unrealistic .

[Connum]

Quite nice, I like it!

[FooBar]

Looking good!, but I certainly would make the pillars which come out of the sea a whole lot bigger. The sea will eat these small steel supports in the order of weeks; after that it's bye-bye oilfield. At least, that would happen in real life.

You can see the rusty spots on the concrete supports in the last photograph. The sea has already eaten through the concrete a bit and is now corroding the rebar.

[RSpeed tycoonfreak]

Its looking good Redstar , has enybody made a farm replacement yet?

[Red*Star]

Thx!

@the pillars: I think the problem is that we all think that we know "how an oil rig should look like" ... I thought that too, when starting work on mine, but... ya see, there seems to be not sooo much rules how ALL rigs look like.

Well, about the pillars: Here is an exemplar with pillars like mine.



It seems to work, without the oil rig ending upside down on oceans floor because of corrosion. That only happen's when you "mix oil rigs and hurricanes" :

A new scrapyard. [The photo above]

It seems this oil rig thing is getting more and more complex every day... Damn, probably I should make a complete oil rig newgrf project... *rolleyes*

[Trond]

has enybody made a farm replacement yet?

AFAIK no. So feel free to make one

Red*Star: Random Oilrigs in my game sounds like something I would like... Nice project, when are you gonna be done