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.

InstallingzBase 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.

FAQWill [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.

CodingAll 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.

Then you 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 was planning on writing some basic batch scripts to convert the 64px sprites to 8bpp, in general the sprites will be very similar to the OpenGFX ones though (my art style hasn't changed!) so the OpenGFX ones could always be used instead. Render templates for objects like vehicles (and other objects with important recolouring effects) will automatically generate the required 8bpp mask sprites.

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.

_________________Sorry if my english is too poor, I want learn it, but it isn't too easy.

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.

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.

Nice, it's refreshing to see 32bpp development take place in the way it should always have been.

I'm a complete rock ape with graphics, but I can help with the coding. I have a few GRF's in mind that I was about to try my hands on, but spending that time on 32bpp graphics would of course be a way better investment

_________________Beer is not the answer. It's the question, and the answer is YES.

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)

Who is online

Users browsing this forum: No registered users and 2 guests

You cannot post new topics in this forumYou cannot reply to topics in this forumYou cannot edit your posts in this forumYou cannot delete your posts in this forumYou cannot post attachments in this forum