32bit base set development thread

[Wasila]

So what are we actually waiting for to start a base set? We have a license, a place to store the files, artists, administrators, etc. What are we waiting for?

Thanks,
Wasila

[Jupix]

1. Technical, visual and philosophical guidelines/standards have not been agreed upon for base set content. This needs to be done before any work commences. Before you start a discussion on that, note that it's already been brewing for at least half a year in the org thread. And that thread is where discussion on it should stay. This is not a matter of snapping your fingers.

2. We currently ship content in tars. Base sets are a completely different animal. The OTTD graphics ecosystem revolves around GRFs, including BaNaNaS where the base set replacement would be distributed. We need someone to encode the base set GRFs out of our content, and put black boxes where content doesn't exist. If that seems familiar, it's because that's how OpenGFX worked when it was under development.

3. It's unclear to me at this time whether (1) trunk builds support 32bpp GRFs or (2) the EZ patch supports EZ GRFs. If "no" to either, there's coding to be done. Also, EZ GRFs need to work in trunk builds at z2.

4. Unlike normal 32bpp releases, those that are not part of the base set replacement, releases that aim to fill holes in the base set need to fit a certain set of rules, as mentioned in #1. Competing for the honour of being included can be numerous entries. There needs to be an authority of some kind that enforces the aforementioned rules and calls the entry that will go into the replacement set. For practical reasons that authority can't be the community at large. And currently, no such authority has been named.

[Wasila]

Thanks for your informative reply Jupix!

note that it's already been brewing for at least half a year in the org thread.

Surely if it's been brewing for half a year not much progress is being made? Perhaps not a matter of 'snapping fingers', but the issues should be laid out more clearly and perhaps votes should be taking on it between artists.

2. We currently ship content in tars.

It says that the base sets come in tars. I'm not sure the difference is clear.

(1) trunk builds support 32bpp GRFs

They do, which is why I contacted you about making z2 sprites compatible.

There needs to be an authority of some kind that enforces the aforementioned rules and calls the entry that will go into the replacement set.

Any progress on that front?

[GeekToo]

(1) trunk builds support 32bpp GRFs
They do, which is why I contacted you about making z2 sprites compatible.

Common misunderstanding, but absolutely untrue. I repeat, this is not the case. Trunk supports drawing of 32bpp sprites, but only as replacement for 8bpp sprites. So, the way things are coded in trunk, and in EZL, you always need an 8bpp basegrf set and / or 8bpp newgrf.
There does not exist a thing like 32bpp newgrfs or 32bpp baseset. So you cannot create a 32bpp baseset even if you wanted. It would only mean copying the complete baseset of original or OpenGFX grfs, and then replacing the 8bpp pcx-es with 32bpp pngs. Which is what we currently do, but then without the creation of the 8bpp baseset, because that is useless.

[Wasila]

Trunk supports drawing of 32bpp sprites, but only as replacement for 8bpp sprites. So, the way things are coded in trunk, and in EZL, you always need an 8bpp basegrf set and / or 8bpp newgrf.

Does the extra zoom levels patch allow proper base sets?

[planetmaker]

Does the extra zoom levels patch allow proper base sets?

AFAIK that is not yet implemented anywhere. You'd have to change the grf specs, introduce a 3rd palette which is then the 32bpp one; which would need changing the grf coding tools to accept these graphics (NML might do).

[Wasila]

Surely this should be the first priority?

[planetmaker]

I suggest that we set-up a proper system of nomination and then voting.

Help! It needs DOING. Not voting on who is supposed to works. That person who steps forward to actually not only propose, but also is willing to work towards his / her proposal is naturally then the leader. And it's absolutely irrelevant whether the person is an artist, a coder or a musician or an alien.

EDIT:
- So if you want native grf support for 32bpp, that's a whole undertaking IMHO on its own and can be done completely independently of anything here.
- Organizing the thing into a more monolithic set, making sure it's possibly distributed under one license, all files packed: much easier. It needs access to the computer who creates these packages, needs knowledge about the use of pngcodec and probably some scripting knowledge. But nothing of that is too complicated, many parts of that are already done. And it seems you already HAVE a leader (team) for that. Why crack hats about who has the say?

[Wasila]

I was thinking we should take our time with this, since we want to get it right, but if you guys don't mind then I won't push it. Jupix, your opinion would be very helpful at this moment in time .

[Ben_Robbins_]

We've taken our time...it's not like we all just got up this morning, signed up to the forum, and read a few names. It's clear who does what, what needs doing, and that there needs to be some standardisation and final calls made, and it often ends up in noone feeling it would be justifiable for them to stand out and claim that they are calling it.

[Wasila]

Just because we've wasted all this time already doesn't mean that we should rush things now. There is actually quite a lot to do, not just standardisation but working on the wiki, the patch & making sure that the standard tar is followed.

and it often ends up in noone feeling it would be justifiable for them to stand out and claim that they are calling it.

Would a vote not give some one the mandate to lead?

[Ben_Robbins_]

I didn't say we have wasted time...and it's not a rush now. The point is that judgement has been past in that time; now we conclude. It doesn't require full blown vote!. If you really want a vote, consider this a vote. People are just talking rather than ticking.

I'll be working to standards set by a person capable of making them, not by just the most popular.

[maquinista]

This discussion is a bit long for me.

I think that the priority is do vote a good saturation for the models. We have a good shadow transparency, lightness and darkness of faces, but we must decide what is the correct saturation to use.

I haven't coded houses for z1 and z2 levels for this reason.

[Wasila]

It's not that long! Essentially, would you be willing to allow Jupix to be the leader of any official base set project?

A white paper/specs sheet has been posted on the previous page, not sure if it mentions saturation.

[Jupix]

I moved the spinoff discussion on management to the org thread in order to keep this discussion about the base set.

[Wasila]

Base set project and managing of said project are very closely correlated, since that was what the managing discussion was about (managing a base set project).

[Jupix]

Well, the discussion on management was actually meta-discussion on management. When it comes to the actual management, like scrambling sprites, then it's under this thread, but on choosing someone to do the job or pitch policies, that's for the organisation thread. Otherwise we wouldn't need an organisation thread. And the spec was plain off topic.

[Wasila]

I see what you mean, but I would think that everything for a big project would be under one roof, so to speak. Anyway, it doesn't matter. If people are satisfied that everything is out of the way and there is nothing more to talk about (as some already are - such as Ben_Robbins_), then why haven't we started?

[Jupix]

Well, first order of business is drafting a spec for the new NewGRF format. But I need some serious consultance from someone who understands the format to do that. So that'll be on hold till I find someone willing and able to help out.

[Wasila]

Is there no one we have on the team to do that? Is there anyone we know who could help?