Transport Tycoon Forums

The place to talk about Transport Tycoon
It is currently Tue May 22, 2018 9:45 am

All times are UTC




Post new topic  Reply to topic  [ 435 posts ]  Go to page Previous 1 2 3 4 522 Next
Author Message
PostPosted: Wed Jul 18, 2012 4:18 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
Quote:
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)
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...

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net


Top
   
PostPosted: Wed Jul 18, 2012 4:23 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 12, 2012 3:42 pm
Posts: 13
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


Top
   
PostPosted: Wed Jul 18, 2012 4:32 pm 
Offline
Traffic Manager
Traffic Manager
User avatar

Joined: Sun Nov 13, 2011 6:46 pm
Posts: 206
Location: Sweden
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.

_________________
OpenGFX+ Trains Nightly Build | OpenGFX+ Trains Development Thread | OpenGFX+ Trains Release Thread
OpenGFX+ Trains Repository | OpenGFX+ Trains Backup Repository


Top
   
PostPosted: Wed Jul 18, 2012 4:43 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 12, 2012 3:42 pm
Posts: 13
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


Top
   
PostPosted: Wed Jul 18, 2012 5:10 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4612
Location: home
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)
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:
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
Nope, this holds for zBase graphics (mostly), but not for 8bpp OpenGFX graphics.

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

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.
8bpp is also a definition, so you have 4 major definitions.

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:
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] }
This is sprite 3941. The final 3 lines are zBase graphics (with the major things changing for each sprite: the sprite label 'spr3941', and the '0096' number of the .png file), the first one is the OpenGFX sprite (where almost anything can change between sprites, except the filename since it uses sprite sheets). The numbers between [ and ] have been copied from its repo (manually).
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.


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)
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:
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
I think so too :)


Top
   
PostPosted: Wed Jul 18, 2012 6:30 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 12, 2012 3:42 pm
Posts: 13
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


Top
   
PostPosted: Wed Jul 18, 2012 8:34 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4612
Location: home
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.


Top
   
PostPosted: Thu Jul 19, 2012 8:43 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
Alberth wrote:
New approach, just extend the opengfx nml sources.

Maybe that would be simplest!

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net


Top
   
PostPosted: Thu Jul 19, 2012 8:47 am 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4612
Location: home
Simplest? sure.

Let's just hope you want to keep the opengfx sprites, or else I have to do it all again


Top
   
PostPosted: Thu Jul 19, 2012 11:14 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
Alberth wrote:
Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
I think opengfx sprites are the right choice :D

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
256_000a.png [ 101.86 KiB | Viewed 2830 times ]

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net
Top
   
PostPosted: Thu Jul 19, 2012 11:18 am 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
I also tested out a render template for multi tile objects... Seems ok too.


Attachments:
Stadium.png
Stadium.png [ 195.71 KiB | Viewed 2828 times ]
256_0006.png
256_0006.png [ 48.39 KiB | Viewed 2828 times ]

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net
Top
   
PostPosted: Thu Jul 19, 2012 1:00 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Wed Nov 07, 2007 10:44 pm
Posts: 9025
Location: Sol d
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...


Attachments:
32bpp_tempgrass.png [225.11 KiB]
Downloaded 3 times

_________________
Image
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
Top
   
PostPosted: Thu Jul 19, 2012 2:06 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
Hmm, looks like I miscalculated the slope height :) I'll give it a look.

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net


Top
   
PostPosted: Thu Jul 19, 2012 2:34 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Sun Feb 08, 2009 6:36 pm
Posts: 2374
Location: Alberta, Canada
All these graphics look awesome! Great work everyone! :D

_________________
Image
Total Alpine Replacement Set: Industry, Town, Objects
**ATTENTION**: If anyone would like me to help draw snow stages in any of their GRFs let me know. I genuinely enjoy drawing them.


Top
   
PostPosted: Thu Jul 19, 2012 5:38 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4612
Location: home
Zephyris wrote:
Alberth wrote:
Let's just hope you want to keep the opengfx sprites, or else I have to do it all again
I think opengfx sprites are the right choice :D

Attachment:
churches.png
churches.png [ 57.41 KiB | Viewed 2777 times ]

Moving doors and windows are right too then?


Top
   
PostPosted: Thu Jul 19, 2012 6:47 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Sun Sep 09, 2007 5:03 am
Posts: 4612
Location: home
An oil well, graphics by Zephyris of course.
Attachment:
oilwells.png [583.04 KiB]
Downloaded 3 times

The base plate is still 8bpp

@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.


Top
   
PostPosted: Thu Jul 19, 2012 7:03 pm 
Offline
Tycoon
Tycoon
User avatar

Joined: Wed May 16, 2007 4:59 pm
Posts: 2825
Alberth wrote:
@Zephyris: FYI: I am throwing problems that I find in the zbase issue tracker.
Perfect.
Zephyris wrote:
Hmm, looks like I miscalculated the slope height :) I'll give it a look.
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?

_________________
GRVTS/eGRVTS --- Generic Tram Set --- UK Town Set --- zBase ---RichardWheeler.net


Top
   
PostPosted: Thu Jul 19, 2012 8:33 pm 
Offline
Engineer
Engineer

Joined: Thu Jul 12, 2012 3:42 pm
Posts: 13
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....


Top
   
PostPosted: Thu Jul 19, 2012 9:19 pm 
Offline
OpenTTD Developer
OpenTTD Developer

Joined: Mon Jun 14, 2004 11:27 pm
Posts: 578
Location: Berlin, Germany
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?

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.

-- Michael Lutz


Top
   
PostPosted: Thu Jul 19, 2012 9:40 pm 
Offline
OpenTTD Developer
OpenTTD Developer
User avatar

Joined: Wed Nov 07, 2007 10:44 pm
Posts: 9025
Location: Sol d
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....

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)

_________________
Image
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


Top
   
Display posts from previous:  Sort by  
Post new topic  Reply to topic  [ 435 posts ]  Go to page Previous 1 2 3 4 522 Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


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

Search for:
Jump to:  
Powered by phpBB © 2000-2018 phpBB Limited

Copyright © Owen Rudge/The Transport Tycoon Forums 2001-2018.
Hosted by Zernebok Hosting.