I think the majority of sprites do follow this rule but I think there will always some sprites which are exceptions. Sprites that immediately jump to mind are the rail and field hedges and fences...the offsets will be constant for every sprite of a given zoom level (i may be wrong in this assumption but this is what i got from the discussion so far, would be great if someone can clarify this further)
zBase (32bpp base set by Zephyris)
Moderator: Graphics Moderators
Re: zBase (32bpp base set by Zephyris) - Coder needed!
-
- Engineer
- Posts: 13
- Joined: 12 Jul 2012 15:42
Re: zBase (32bpp base set by Zephyris) - Coder needed!
regarding size, the average sprite size with a decent compression (80%+) is around 20KB the worst offenders are around 100KB
worst case scenario is 7000 x 100 x 2 aprox 1.3GB
as for blender files, use the compress file under the file preference, this reduced the Road_Stations blend file from 691KB to 116KB, as for the blend1 and blend2, these are version files, under same file preference turn save version to 0 and they wont save any old versions. I noticed that your blend files are directory dependent for texture, you could probably eliminate this by baking the textures into the models themselves (though that would increase file size but allow you to eliminate the need to distribute the textures, the same process can be used to create high contrast models by baking the textures with a different light setup then the one used for final render)
(im actually an artist who very handy at coding too, though i prefer the phrase workflow optimization, but an artist by nature)
*edit
we can use a different process for these sprites that have different placement values for the same image, probably give them their own GRF to make life easier too, i believe with NML you can reference one GRF into another, so this can be later reference into the Base grf
worst case scenario is 7000 x 100 x 2 aprox 1.3GB
as for blender files, use the compress file under the file preference, this reduced the Road_Stations blend file from 691KB to 116KB, as for the blend1 and blend2, these are version files, under same file preference turn save version to 0 and they wont save any old versions. I noticed that your blend files are directory dependent for texture, you could probably eliminate this by baking the textures into the models themselves (though that would increase file size but allow you to eliminate the need to distribute the textures, the same process can be used to create high contrast models by baking the textures with a different light setup then the one used for final render)
(im actually an artist who very handy at coding too, though i prefer the phrase workflow optimization, but an artist by nature)
*edit
we can use a different process for these sprites that have different placement values for the same image, probably give them their own GRF to make life easier too, i believe with NML you can reference one GRF into another, so this can be later reference into the Base grf
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Something to remember is that if you need to re-render any or all of the blends, when you commit to the repo then it keeps a history. So for example if you re-render all the 7000 files again due to a light or material change, your repo now becomes 2.6Gb and so on.
-
- Engineer
- Posts: 13
- Joined: 12 Jul 2012 15:42
Re: zBase (32bpp base set by Zephyris) - Coder needed!
im just wondering how useful it is to keep history of all the image files, these are after all a by product of the blender rendering, in reality you could probably recreate the files using the blend file (yes time consuming), it make more sense to just keep history of blend files, any NML, ini and the texture files, the PNGs are just be kept as snapshot of the current blender renderings
Re: zBase (32bpp base set by Zephyris) - Coder needed!
You are completely correct here. That saves 18 lines (the {064,128,256}-{xsize,ysize,xoffset,yoffset} variantions) in the [root] section at the cost of less transparency in what the code does in that case. I prefer explicit code, so I added them (at the cost of some code to handle them). In addition, it makes life eaiser when you want to code single sprites if the need arises.CargoLiner wrote:forgive my ignorance, i understand the usefulness of such a setup when using spritesets or sprite templates, but from what i understand, all the sprites and variation of will be rendered to their own individual PNG file at full frame, the offsets will be constant for every sprite of a given zoom level (i may be wrong in this assumption but this is what i got from the discussion so far, would be great if someone can clarify this further)
Nope, this holds for zBase graphics (mostly), but not for 8bpp OpenGFX graphics.CargoLiner wrote:so for all intent and purposes there will not be 19 different blocks to define terrain, as all definitions will be identical so a single definition would be used
'xpos', 'ypos', 'ysize', and 'yoffset' change there with every sprite (at least xpos, the others seem to change more in blocks).
Obviously, opengfx and zbase have no nice relation, they each change independently.
8bpp is also a definition, so you have 4 major definitions.CargoLiner wrote:in fact we could take this a step further and say that there is generally speaking only 3 major definitions one for each zoom level for all sprites.
I think I do have single definitions (unless I don't understand what you mean by that); [temperate_grass_0] is one type of terrain (namely no grass at all) and it defines the all parameters of all 4 sprite sizes. The 5 other temperate terrain types are basically the same, and will re-use the [terrain] section. Terrain types of other climates will also re-use the [terrain].
I think the biggest difference is that my alternative makes it explicit (and quite transparent) how you get from that single definition to a set of real sprite definitions. It will cost some code to implement it, but your expansion code also costs code, and you then have to write expansion code for every type of feature (eg sea-coast has 9 sprites, depots have 6 sprites). In my case, you just add some more INI sections and you're done.
Another consideration is that somewhere along the project we may find things are not so nicely organized as you'd want. With some more INI sections, you can work your way around it easily. If you hard-code the expansion, you need to change program code for that special case without breaking everything else that uses the same code. This is mainly why I switched from programming Python code to defining stuff in a data file format. It's mostly transparent, and almost everybody can understand how it works, and write new definitions.
I picked feature as elementary value as that's how things are organized usually, eg the sprite-sheet of OpenGFX goes per feature.
For maintenance it is also easier to group things in this way.
To give you (and others) an idea of what to generate:
Code: Select all
replace spr3941(3941, "../opengfx/sprites/png/terrain/bare-03-temperate.png") { [1357, 1, 64, 31, -31, -8] }
alternative_sprites(spr3941, ZOOM_LEVEL_NORMAL, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/64_0096.png") { [0, 0, 64, 64, -31, -32] }
alternative_sprites(spr3941, ZOOM_LEVEL_IN_2X, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/128_0096.png") { [0, 0, 128, 128, -63, -64] }
alternative_sprites(spr3941, ZOOM_LEVEL_IN_4X, BIT_DEPTH_32BPP, "../zbase/terrain/terrain_temperate/256_0096.png") { [0, 0, 256, 256, -127, -128] }
The code in OpenGFX is not directly usable, as it defines sprites as 'baseset' rather than 'replace', and the name "spr3941" does not exist there.
So I see currently no other alternative than to add OpenGFX sprites into the equation, rescue the magic values like "1357, 1, 64, 31, -31, -8" from its source and insert them into the generation process.
Yep, but there are no 'if' statements though, everything is one big blob of sprites; the game knows which sprites to use in which climate.CargoLiner wrote:the biggest hurdle would be to itemize and group them into replace and alternative graphics blocks (along with if statements for different climates)
I think so tooCargoLiner wrote:if we are doing more than just replace graphics in the NML then that's a different kettle of fish, but i was lead to believe this is a base graphics replacement project
-
- Engineer
- Posts: 13
- Joined: 12 Jul 2012 15:42
Re: zBase (32bpp base set by Zephyris) - Coder needed!
OK i forgot about the 8bpp stuff
need some time to chew through this, i understand the need for data-centric system, but it seems an awful lot of work required for just the 8bpp stuff, i was hoping someone could just dump the info into a file we can cross reference (after all this information should be static and not changing) otherwise your decentralizing this information across a variety of sources
need some time to chew through this, i understand the need for data-centric system, but it seems an awful lot of work required for just the 8bpp stuff, i was hoping someone could just dump the info into a file we can cross reference (after all this information should be static and not changing) otherwise your decentralizing this information across a variety of sources
Re: zBase (32bpp base set by Zephyris) - Coder needed!
New approach, just extend the opengfx nml sources.
It seems that having a file format for storing the real sprite numbers/names was a bridge too far. Only a 1 time generation step is needed, which obviously makes all effort for generation useless.
It seems that having a file format for storing the real sprite numbers/names was a bridge too far. Only a 1 time generation step is needed, which obviously makes all effort for generation useless.
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Maybe that would be simplest!Alberth wrote:New approach, just extend the opengfx nml sources.
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Simplest? sure.
Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
Re: zBase (32bpp base set by Zephyris) - Coder needed!
I think opengfx sprites are the right choiceAlberth wrote:Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
I have made a few buildings and tested out a render template for taller objects. All seems good! .blend1 and .blend2s are now removed from the repo, should help a lot with storage usage.
- Attachments
-
- 256_000a.png (101.86 KiB) Viewed 5810 times
Re: zBase (32bpp base set by Zephyris) - Coder needed!
I also tested out a render template for multi tile objects... Seems ok too.
- Attachments
-
- Stadium.png (195.71 KiB) Viewed 5808 times
-
- 256_0006.png (48.39 KiB) Viewed 5808 times
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: zBase (32bpp base set by Zephyris) - Coder needed!
When toying with the code, I noticed that some of the ground sprites are slightly mis-aligned in their file, giving gaps between tiles (one pixel too high in 1x view).
Merge OpenGFX and zBase and apply this hacky patch and build to see (I'll try to identify the proper offsets and sprites later). It's not a principle problem (could be solved by making the sprite template more lengthy, but... )
EDIT: I actually created a screenshot...
Merge OpenGFX and zBase and apply this hacky patch and build to see (I'll try to identify the proper offsets and sprites later). It's not a principle problem (could be solved by making the sprite template more lengthy, but... )
EDIT: I actually created a screenshot...
- Attachments
-
- 32bpp_tempgrass.png (225.11 KiB) Viewed 1104 times
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Hmm, looks like I miscalculated the slope height I'll give it a look.
- SwissFan91
- Tycoon
- Posts: 2395
- Joined: 08 Feb 2009 18:36
- Location: Alberta, Canada
Re: zBase (32bpp base set by Zephyris) - Coder needed!
All these graphics look awesome! Great work everyone!
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Moving doors and windows are right too then?Zephyris wrote:I think opengfx sprites are the right choiceAlberth wrote:Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
Re: zBase (32bpp base set by Zephyris) - Coder needed!
An oil well, graphics by Zephyris of course.
@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.
The base plate is still 8bpp@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Perfect.Alberth wrote:@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.
I am struggling on the maths to work out the height slopes should be, can anyone give me a hand? If I am working with a 1x1 ground tile how high should the top of the slopes be?Zephyris wrote:Hmm, looks like I miscalculated the slope height I'll give it a look.
-
- Engineer
- Posts: 13
- Joined: 12 Jul 2012 15:42
Re: zBase (32bpp base set by Zephyris) - Coder needed!
ok if i understand this correctly
each tile is defined as 16 units by 16 units and each height step is 8 units, if we use the wiki definition that each ground tile is 12.5m x 12.5m in size then the top should be at the 6.25m mark, just off the top of my head....
each tile is defined as 16 units by 16 units and each height step is 8 units, if we use the wiki definition that each ground tile is 12.5m x 12.5m in size then the top should be at the 6.25m mark, just off the top of my head....
Re: zBase (32bpp base set by Zephyris) - Coder needed!
A flat ground tile at normal zoom has 64 pixels across and 31 pixels from top to bottom. A raised/lowered corner has an offset of +/- 8 pixels compared to the flat corner.Zephyris wrote:I am struggling on the maths to work out the height slopes should be, can anyone give me a hand? If I am working with a 1x1 ground tile how high should the top of the slopes be?
-- Michael Lutz
- planetmaker
- OpenTTD Developer
- Posts: 9432
- Joined: 07 Nov 2007 22:44
- Location: Sol d
Re: zBase (32bpp base set by Zephyris) - Coder needed!
Please forget any scale in real-life dimensions quickly - whatever value you attribute there, it will always be more wrong than right (the wiki does a very bad job here, it seems)CargoLiner wrote:ok if i understand this correctly
each tile is defined as 16 units by 16 units and each height step is 8 units, if we use the wiki definition that each ground tile is 12.5m x 12.5m in size then the top should be at the 6.25m mark, just off the top of my head....
OpenTTD: manual | online content | translations | Wanted contributions and patches
#openttdcoop: blog | wiki | public server | DevZone | NewGRF web translator
DevZone - home of the free NewGRFs: OpenSFX | OpenMSX | OpenGFX | Swedish Rails | OpenGFX+ Trains|RV|Industries|Airports|Landscape | NML
Who is online
Users browsing this forum: Amazon [Bot], GarryG and 42 guests