Moderator: Graphics Moderators
32bpp base set.
Graphics by Zephyris.
Coding by Rubidium & Alberth.
zBase at the DevZone: http://dev.openttdcoop.org/projects/zbase/
zBuild, recent zBase Builds: http://bundles.openttdcoop.org/zbuild/push/LATEST/
I have started a big 32bpp base set project starting from scratch. The graphics will be 100% produced in Blender (with a few minor exceptions) using standard render templates, materials, lighting, etc. I aim to make a complete, functional and useable base set.
zBase is a base graphics set like the original windows graphics or like OpenGFX. To install it:
1. Download a recent zBase Build.
2. The download consists of a .zip file with the folder "zbase" inside. Copy this folder to the data folder of your OpenTTD installation.
3. Run OpenTTD and go to "Game Option", select "zBase" from the dropdown list for "Base graphics set".
4. Close the game options.
Will [an existing sprite/graphics] be included?
- Probably not. Only existing 3D models which are of the correct style and can be imported into my render templates will be included.
- If you do have original models from other 32bpp sprites please do post them though, if they are the right style I will try and fit them in.
Can I help?
- Yes, but only for certain things (this will change in the future). For now I am keeping a hold on graphics development to make sure everything has a consistent style, logical templates and standard textures.
- For now feel free to contribute "resources", think useful bits of scenery like a crane or a pile of boxes.
Why are you ignoring my suggestions?
- My aim is to make a functional base set, not to make perfect graphics (that comes later!). In general I will only pay attention to technical suggestions.
- Please don't be offended if I ignore your suggestions for a sprite, there are thousands to make and getting a complete set is the main priority.
All sprites are to be rendered in 32bpp directly from Blender. No fiddly photoshopping, overlaying onto ground tiles or fighting with sheets of many sprites.
Coding is in the form of a Base set, like OpenGFX or the original windows graphics. See the top of this post for where to download preview versions.
That basically is what my suggestion was based on:
Take the existing 8bpp OpenGFX. And replace or add the sprite references therein by your new sprites as they come along, like exercised for the explosion.
a) don't have to provide NewGRFs and
b) don't have to write any code except adding the sprite definiton and
c) the build process works already.
I know you say that you won't accept sprite suggestions, but i highly recommend that you use the train sprites by Xotic750, as they are largely complete, and rather good
Also, the road vehicles are lurking around somewhere...
It is practically impossible to teach good programming to students that have had a prior exposure to BASIC: as potential programmers they are mentally mutilated beyond hope of regeneration. --Edsger Dijkstra
A suggestion: It's a good idea to compose the tunnels from simple sprites. For example, the front half, the rear half and a base sprite (road, railway...). It helps to avoid to cut over transparent pixels. Also, remember that the ground sprites should be solid at their edges*, otherwise You will have thin lines over the edges.
About bridges: coding them is a pain.
*The upper edges could have smooth transparent pixels if they are over the "base", for example, grass.
Adding this as part of OpenGFX is not a bad idea at all. The style will fit in well, coding will be a breeze and there is no need to create converted 8bpp sprites.
While I'm too busy with other projects to register myself as coder, I'll keep an eye on this. If there's at some point more sprites than code I'll offer my services if time allows it.
There are currently a lot more sprites than code! I have made all terrain and road/rail/monorail/maglev tiles...FooBar wrote:If there's at some point more sprites than code I'll offer my services if time allows it.
I'm not sure quite what you mean, but the tunnels are currently rendered as two separate sprites (except for the north facing ones where I made a mistake I need to correct ). I think that works ok.maquinista wrote:It's a good idea to compose the tunnels from simple sprites.
Yeah, this is a known issue... The current rendering template is ok, but could be improved. I am thinking of simply applying a gamma to the alpha channel which should solve this.maquinista wrote:remember that the ground sprites should be solid at their edges
I totally agree, ideally I would slot the models into my standard rendering template to ensure 100% match in lighting though...Lord Aro wrote:... but i highly recommend that you use the train sprites by Xotic750, as they are largely complete, and rather good
Will this be GPL, and where will the sources be available?
Some of the devzone guys, I think pm in particular, offered to code any and all 32bpp sprites that were going into ogfx+. I suggest you try to take advantage of that offer if you don't have coders.
100% GPL and all blends and source files are available at the repo on the devzone. The source blend files are all very interlinked (sharing materials, models, etc.) which makes a repo style like this one where full directory structures are preserved vital.Jupix wrote:Will this be GPL, and where will the sources be available?
- 256_0001.png (52.97 KiB) Viewed 134589 times
- 256_0004.png (36.11 KiB) Viewed 134589 times
Oh, GREAT!Zephyris wrote:And rail, monorail, maglev and road stations and depots are all sorted...
Nice, it's refreshing to see 32bpp development take place in the way it should always have been.Zephyris wrote:100% GPL and all blends and source files are available at the repo on the devzone. The source blend files are all very interlinked (sharing materials, models, etc.) which makes a repo style like this one where full directory structures are preserved vital.Jupix wrote:Will this be GPL, and where will the sources be available?
New sprites look awesome.
I think they are a good starting point. Hopefully once the basics are sorted other people can contribute to adding detail and improving the models in the same way OpenGFX panned out.Jupix wrote:New sprites look awesome.
That is my hope as well.Zephyris wrote:I think they are a good starting point. Hopefully once the basics are sorted other people can contribute to adding detail and improving the models in the same way OpenGFX panned out.
when you say no Photoshop and no playing around with ground tiles i presume you mean all your sprites will be renders at full frame (256x256, 128x128 and 64x64) which would mean all offsets would be constant for a given zoom level (i.e. -124, -132 for full zoom) and that no cropping would occur (at the expense of file size)
if that were the case i currently have a powershell 3.0 script (as much as i love bash, i am a windows person and powershell gives me bash like capabilities) which i use to compile some 32bpp PNGs and megapacks into a NML that can then be used to spit out a grf, the script basically goes recursively goes through a directory, hashtable all the files, splits the filename into field which i then index and group and feed through a logic operator to generate a replace and all available alternative graphics block for each sprite ID (based upon name), it will test to see if any PNGs have mask files associated with it and append as such (again based upon naming convention). I currently use PNGMeta (because it can output XML tabels which i can easily hashtable) to extract x and y offsets, but if you are rendering full frame without cropping this can be discarded and will significantly speed up the NML generation process. If you dont mind windows and powershell then i can tweak this script to suit your purposes.
if you do plan on optimizing the PNGs through cropping it may still be workable but i would probably require another render layer to produce a sphere (0.01 in size) at the ground tile origin (top most tip of the apparent ground tile location) which i will run through a GIMP script to find the relevant pixel co-ordinates and interpolate that to get the offset values (you could spit it out to the alpha channel of the mask or to another file, just bear in mind like mask the cropping must be consistent across file sets)
just a side note, it currently populates the 8bpp with an empty.png file, if 8bpp compatibility is required then some serious work is probably required, unless someone has a copy of all the 8bpp offsets for a given sprite sheet off hand (which still probably needs some work)