New graphics format

[Alltaken]

What about a single file with multiple sprites?

this is an option, however then EVERY SPRITE (of almost 100 ) would need to have its co-ordinates known. it also doesn't allow for only some sprites to be loaded (saving memory) and you must also load much whitespace for each sprite. having multiple seperate sprites means that you can have more sprites available than currently implimented in the code (more angles...) without OTTD caring.

also its more effort to make the sprites into one file. a script can spit out single sprites with easy and unique names very quickly. yet to composite sprites together into a single file you must make a lot of effort.

each sprite set would be in a compressed container format like .zip .7z .Gz.... so would effectivly be one file.

Code: Select all

------up/down--------
first file NW-SE 25 degrees: CTNWSE001.png
last file NW-SE -25 degrees: CTNWSE011.png
first file NE-SW 25 degrees: CTNESW001.png
last file NE-SW 25 degrees: CTNESW011.png
degree incriment: 5
------------------------

You'll need four sets there, not two, unless the vehicle is symmetrical.
If we're going for realism, I'd suggest reducing the grade range to [-10,10] degrees, or possibly smaller. Ten degrees is a 17.6% grade--enormously steep for vehicles.
There is a little redundancy between this and the 72 (or however many) flat sprites, but that can be compiled out with minimal difficulty.
Will it be possible to build things along slopes in the 4 cardinal directions as well? How about sloped curves a-la Loco?
Either of these increase the number of sloped sprites required.
If sloped curves, then we might as well just render all (num-rotations)x(num-tilts) (in this case 72x11=792) sprites and list them together.
(You are proposing pre-rendered sprites from 3D models, correct?)

yes i am suggesting pre rendered sprites, however i don't think we need 792 sprites this would be in the order of 10Mb per vehicle. IMO unescisary. since the source files will be distributed there is nothing stopping the remaining sprites being rendered later.

i would have isometric rotation, and (yes thanks for the correction) 4x going over slopes.

as for the steepness, i will go as steep as the hills are now. i don't know the exact degrees of it, but i think its about 25. (the game is not realistic nor it should be IMO.)

I'd also suggest listing num-rotations and num-tilts, instead of degree increment, to get floating-point numbers out of the GPD.

how its written doesn't bother me as long as it works.

Code: Select all

--------custom colours-------
Fed ex: /FE
New Zealand Post: /NZP
Alltakens: /Alltaken
army: /army
-----------------------------------

Why couldn't someone just re-render all the sprites and release that?
Or did you mean that the graphics used will depend on the cargo being carried?

there are two types of sprites.

A) one with company colours that can be changed in colour. i.e. the user could choose any one of 256 colours (or however many you want) and the vehicles would be altered in colour to reflect this.

B) the vehciles can be pre-rendered with textures, logos.... but with a set colour.

some people may wish to create graphics for specific carriers, like Fed-ex etc.... and could re-render all the original sprites from the source file. then add this carriers set to the distributed graphics file.

eventually for any vehicle you might be able to select a company for it to be, rather than a colour. (look at transport giant, how they provide their vehicle colour schemes)

Code: Select all

-----animations----------
smoking: /../shared/smoketruck
turning left: /turningL
turning right /turningR
---------------------------

Do we really need this part? I'd say that the smoking animations should be the same for all vehicles of any one type, and turning was already covered above, in those first 72 sprites.

smoke, hence it is in the shared folder (not distributed with the graphics file) there MAY be different types of smoke, there may be firey smoke... there may be dark smoke, and there may be very white smoke. i don't know

if you have a vehicle like the two carrige buses in australia with a rotating joint in the middle of it, you MAY require turning graphics. and yes they may make 68 of the 72 sprites useless. but if you turn off the function "turning vehicles" or somthing then those 72 would be needed?

if its a truck with a weird joint in the middle of it

For that, we should use road trains.

yes i think this would be fine for most situations. two seperate graphics the cab and the trailer.... but may not suit all situations. remember this is an example of the functions i might want, they would not be used by all items.

a GUI program to set all this (perhaps built right into OTTD i dunno)

This seems to me like featuritis. I'd suggest a separate program.

seperate program is fine with me. as long as it does it, i am happy

but dropdown menus, and browse buttons (to select files/folders for certain sections like shadows, or files like rotated...) would be very cool.

Point and click programming. Ugghh!
Whatever floats your boat, as long as notepad is still a valid editor.

don't see why you can't have point+ click AND a text window in the same program

but yes i agree it should be text editable.






Alltaken

[DaleStan]

this is an option, however then EVERY SPRITE (of almost 100 ) would need to have its co-ordinates known.

Every sprite still has to have an offset. This could be done by declaring that the "center point" (or whatever) will have an alpha value of $FOO, but then what alpha should be used for that point in game?
Similar problems appear with company colors and palette animation. Probably we'll just have to declare that some color range (the purples have been suggested) will be special, and map to company colors, palette animation, &c.

In general, I would avoid storing data in the alpha values, because then some value has to be manufactured to replace the missing data. A better idea might be to place special data in the 24 color bits of pixels where alpha=0. Assuming HSVA is a permissible color format for PNG, we could also use the hue byte of the grayscales. This might be a good way to do company colors/palette animations.

Of course, defining any special colors, or otherwise breaking PNG format, requires that the render understand these changes.

It may be necessary to use sprite pairs, one with the static graphics, and the other with a CC/palette-animation overlay.

yes i am suggesting pre rendered sprites, however i don't think we need 792 sprites this would be in the order of 10Mb per vehicle.

Yes, 792 sprites per vehicle might be a little much, but requiring user-rendering essentially requires building a renderer into OTTD. Mostly out of curiosity, how long would it take to render those 792 sprites at the scale and quality we're talking about?

since the source files will be distributed there is nothing stopping the remaining sprites being rendered later.

Not necessarily. Even if distributed under the GPL (or an appropriate Creative Commons license), the copyright holder has the power to waive any conditions of the GPL/CCL, and there's nothing that requires the graphics set be released under any particular license.

smoke, hence it is in the shared folder (not distributed with the graphics file) there MAY be different types of smoke, there may be firey smoke... there may be dark smoke, and there may be very white smoke. i don't know

I missed the "../" the first time around.
What happens if the shared sprites are not there?
There is also annoying file system fun here. *nix requires "/" as the directory separator, Windows prefers "\" and (IIRC, ICBW &c.) Macintosh uses "::". Which should OTTD use?

If all the sprites are compiled into the same file, then just CGDCodec has to be able to correctly parse the filenames, and that's a simple matter of passing them straight to the system.

Code: Select all

<script>
//determines what graphics to use for an engine on a train depending on where it is in the consist
	if (position == 0) {
		use_spriteset(headloco);
	} else if (position == trainlength) {
		use_spriteset(caboose);
	} else {
		use_spriteset(trailloco);
	}
</script>

has a lot less 'syntactic salt' (as Dalestan puts it) and I would say it is easier to work with.

The problem with this is that it requires Yet Another interpreter.

OT: "Syntactic salt" and its opposite number "syntactic sugar" were terms used in one of my first CS classes. "Salt" is stuff that has to be typed, but could be omitted without losing any information; usually it is to help prevent errors (eg $TAG in </ $TAG >). "Sugar" is an additional way of doing something (eg the suggested expansion of <tag value=data /> to <tag><value>data</value></tag>)

I think XML, by itself, isn't that great for scripting.

I agree. But I'm willing to run with XML (besides, it's a well defined format, so my suggested usages can be less precise) until either a working format appears, or we decide that the power we need cannot be reasonably[0] gotten from XML and something else is required. I'm still in favor of a slightly cleaned-up and prettied-up NFO, but I just don't see that happening.
At least for me, the spec sheet looks a LOT like the spec sheet for the NFO format. There some things that NFO doesn't support (yet?) but that should (must?) be available in GPD. New industries, cargo types, road-vehicle stations, and airports are the ones that I listed in my attempt at extending NFO. (If you are interested, the link is in this post, but there's really not much more relevant stuff than that.)

[0] I am convinced it is possible, just not that it'll be easy.

[Alltaken]

It may be necessary to use sprite pairs, one with the static graphics, and the other with a CC/palette-animation overlay.

yes my plan was to use the single set of offsets for all sprites of the same thing. i.e. company colour is a grayscale png of areas effected by company colours. this is then overlayed on the standard sprite in the same location (image dimensions etc... would be the same size, would line up equally...)

standard sprite
shdaows(if needed to be seperate won't need to be for trucks etc..).
company colours
alternate sets (painted company colours)

would all share the same offset information. (in my pln at least)

yes i am suggesting pre rendered sprites, however i don't think we need 792 sprites this would be in the order of 10Mb per vehicle.

Yes, 792 sprites per vehicle might be a little much, but requiring user-rendering essentially requires building a renderer into OTTD. Mostly out of curiosity, how long would it take to render those 792 sprites at the scale and quality we're talking about?

no users don't need to pre render them, i pre render the ones i make. then i save them as .png however if the OTTD requirments are changed then the source files can be obtained and more sprites rendered to fill the gaps. these new renderings would then be added to the distributions.

since the source files will be distributed there is nothing stopping the remaining sprites being rendered later.

Not necessarily. Even if distributed under the GPL (or an appropriate Creative Commons license), the copyright holder has the power to waive any conditions of the GPL/CCL, and there's nothing that requires the graphics set be released under any particular license.

well all my sprites and file will be available, i will try to set a standard for credit from the begining that will encourage artists to distribute their source files. if the credit and history of sprite designers is built into the format, then its easier to track who has made or editied sprites. this way it is an Open Source project.

other people can do as they wish, but in the end the Open source ones will most likely be more popular as they will be extended more i would think. (who knows)

smoke, hence it is in the shared folder (not distributed with the graphics file) there MAY be different types of smoke, there may be firey smoke... there may be dark smoke, and there may be very white smoke. i don't know

I missed the "../" the first time around.
What happens if the shared sprites are not there?
There is also annoying file system fun here. *nix requires "/" as the directory separator, Windows prefers "\" and (IIRC, ICBW &c.) Macintosh uses "::". Which should OTTD use?

If all the sprites are compiled into the same file, then just CGDCodec has to be able to correctly parse the filenames, and that's a simple matter of passing them straight to the system.

as long as it works then i'm happy with it. i dn't mind what it looks like. a \ a / or a :: who knows. software is cross platform compliant i don't see why this can't be done to be so.


Alltaken

[Jeffrey]

AllTaken: in another topic you gave me this link http://doug.mudpuddle.co.nz/albums/uplo ... 4doug1.jpg
are all those graphics in that picture the featured gfx for openttd, and as you can see on the buildings there windows there are reflections,

is there going to be a special feature like reflections in the new openttd?

[Dundee]

Just thinking... an excel-like functional language would probably be sufficient for most things

So you could have

Code: Select all

<graphics use="=iif(year>1990, 'new', 'old')" />
<graphics use="=iif(position==0, 'headloco', iif(position == length, 'caboose', 'trailloco')))" />

Code: Select all

<script>
[...]
</script>

has a lot less 'syntactic salt' (as Dalestan puts it) and I would say it is easier to work with.

The problem with this is that it requires Yet Another interpreter.

That's true, but everything bar using pure XML would require another interpreter of some description. It'll be interesting to see how things can be done with just XML.

[...] "Salt" is stuff that has to be typed, but could be omitted without losing any information; [...]

I hadn't heard the term before. C languages are fairly 'low-salt' with the use of curly braces to represent blocks (vs parts of Basic).

[Alltaken]

is there going to be a special feature like reflections in the new openttd?

probably not, however buildigns can be made to look that reflective without actually reflecting anything.

things like reflections under the bridge can be done easily.

Alltaken

[Joker]

Just thinking... an excel-like functional language would probably be sufficient for most things

So you could have

Code: Select all

<graphics use="=iif(year>1990, 'new', 'old')" />
<graphics use="=iif(position==0, 'headloco', iif(position == length, 'caboose', 'trailloco')))" />

Yes, that looks good...
Also, it can be done solely in XML:
I worked on one project and there we used special parameters, it would like something like this:

Code: Select all

<graphics val="year" const="1980" condition="4" [0]>
*this would apply only if year => 1980*
</graphics>
<graphics val="year" const="1980" condition="2" [0]>
*this would apply only if year < 1980*
</graphics>

[0] We used codes for conditions (1 >, 2 <, 3 =, 4 =>, 5 <=, 6 !=)

This would be very easy way to code scripts into the file; disadvantage is that its possibilities are limited and it would propably be longer than some kind of script.

A little note about the size: I suppose that size matters mostly when people download OTTD from the net - most people don't care about several megabytes on their hard drive (as 40GB hard drive is pretty small these days). So the larger size of the code is not a problem, should help other things. And I guess that OTTD will be downloaded as some kind of archive (zip, rar, gz or something), which will reduce the size problem, as XML compress quite easily

[Korenn]

[...]A little note about the size: I suppose that size matters mostly when people download OTTD from the net - most people don't care about several megabytes on their hard drive (as 40GB hard drive is pretty small these days). So the larger size of the code is not a problem, should help other things. And I guess that OTTD will be downloaded as some kind of archive (zip, rar, gz or something), which will reduce the size problem, as XML compress quite easily

I don't think you want to use XML in the actual game, but only for the design phase and then encode the XML and graphics into some other format that's more easily readable by OTTD. Parsing XML sucks... bigtime.

[Joker]

[...]A little note about the size: I suppose that size matters mostly when people download OTTD from the net - most people don't care about several megabytes on their hard drive (as 40GB hard drive is pretty small these days). So the larger size of the code is not a problem, should help other things. And I guess that OTTD will be downloaded as some kind of archive (zip, rar, gz or something), which will reduce the size problem, as XML compress quite easily

I don't think you want to use XML in the actual game, but only for the design phase and then encode the XML and graphics into some other format that's more easily readable by OTTD. Parsing XML sucks... bigtime.

True... for ingame usage, other format would be better. But I supposed for some reason that the files with XML will be also part of the download. Surely they (at least most of them) will be available for download, as OTTD is opensource project and most of the graphics will be too.

So let me describe a way new vehicle set can be created with these technologies:
Draw the graphics. Then, visit web page with form where you put specifications of the vehicle and it spits out XML code - save the code. If you don't have permanent internet connection, you can download a XML template and fill it in manually in text editor. Then you copy the files into some directory and launch a program (call it gpdmaker) you downloaded. Done.
The gpdmaker would be two files - the executable and gpdmaker.xsl; and id would have only two things to do - XSLT of *.xml using gpdmaker.xsl (that would create the format suitable for OTTD) and merge all the files into one. In fact even the XSLT can be done by another tool, so the only thing the gpdmaker would do is merging the files.

NOTE: This is only example, I wrote it without detailed knowledge about how OTTD works, so maybe the result would look a bit different.
I see these advantages:
* easy and quick to code (once the format etc. is agreed)
* easy to use
* easy to maintain
* easy to port

I think that lots of work saved by using external programs - if there are tools for some task already, let them do it! Describing the data? Now, why do we have XML!? Transforming the design-time template into run-time data? XSLT will do it! Editing the data? Text editor will do! Want graphical user interface for the editor? We've got a web browser!

Well, that was theory. Now can you tell me if it's realistic or just dreams?

[traskjd]

Joker - good to see some more support

- JD

[MHTransport]

I thought about this for a while and did some investigation.

Zip files allow you to create a directory structure and assign arbitrary attributes (name & value pairs) to files. And you don't have to compress files if you don't want. They are easy to create and alter (pkzip, winzip etc). And there several existing libraries to manipulate them.

You could then collect the sprites in to groups say firstly terrain then vehicle/building then by orientation.

So you could have

+ temperates
+ trains
+ ice
+ north.png
+ east.png
+ common
+ trains
+ maglev-track
+ noth-south.png

I didn't start the feature as there were other priorities and I didn't have the sprites seperated. If some-one can get me the png's for a couple of buildings then I could prototype a solution.

[Alltaken]

hey guys.

currently since i am doing graphics. and trying to set things up so others can follow i am effectivly creating a graphcis fromat through necesity as i find out what the real needs are.

i am not even touching the coding elements, or anything so you guys can sort that out. and for what container format it uses i am also not touching that.

what i am doing, and have been doing is working out the angles of rotation, the directory structure within the file (yeah its pretty simple) how the company colours are handled and applied, and how other various things like filling carridges and such is handled.

people can always change things later, but i am basicly doing what works the best for organisation.

Alltaken

[onodera]

Please forgive me for butting in, but maybe Lua can be an option? You still will need a scripting language, and Lua is now widely used in gaming industry.

Consider the following snippet:

Code: Select all

		'passcar' = {
			'type' = types.wagon,
			'name' = 'Passenger car (main line)',
			'year' = 1950,
			'powered' = false,
			'maxspeed' = 50,
			'getlivery' = function (train, wagon)
					if train = nil then -- Detached wagon
						return sprites.pass[1950]
					end
					if train.head.allowedcars.passenger = false then
						showerror(train.head.name..' cannot take passenger cars!')
						train.detach(wagon)
						return sprites.pass[1950]
					end
					if train.head.name = 'Polar Express' then
						wagon.maxspeed = 200
						if train.pos(wagon) = train.length - 1 then -- If it's the last carriage in a train
							return sprites.pass.express.tail
						else
							return sprites.pass.express.normal
						end
					elseif year > 1975 then
						wagon.maxspeed = 100
						if train.pos(wagon) = 3 then -- If it's the third wagon (in a one-headed train)
							return sprites.pass[1975].buffet -- then it's a buffet-car
						else
							return sprites.pass[1975].normal
						end
					else
						return sprites.pass[1950]
					end
				end
		}

It is much more flexible than its XML counterpart.

[MeusH]

I'd suggest Q3-engine-based-games solution:

All files are in zip files (directories + compression)
Each graphic would be in another file. Special effects would require "shaders" - text files.

I'll make an example

zip file

Code: Select all

-images
---fx
---textures
-----land
-----water
-----routes
---vehicles
-----road
-----rail
-----ship
-----airplanes
---buildings
-----generic
-----temperate
-----arctic
-----tropic
-----hq
-----stations
-----depots
-shaders
-vehicleinfo

Maps will use images\textures to cover with grass\rock\water\whatever

All your smoke, fire, whatever images would be stored in images/fx directory.

Special texture effects, like realistic water, would be in shaders directory
Example:

Code: Select all

    textures/water/blue //this will create virtual image by mixing those:
    {
        map textures/water/blue1 //this image has no transparency
        tcMod turb 0.06 -2 1 0.7 //moving
        tcMod stretch noise 1 0.01 1 1 //special disortion
    }
    {
        map textures/water/blue_trans //this image has alpha layer to make  transparency
        tcMod turb 0.01 0.03 5 0.1 //moving in another direction
        tcMod stretch noise 1 0.01 1 1 //special disortion
    }
    {
        map textures/water/stars //image of white stars - reflections
        blendFunc GL_ONE GL_ONE //make black color transparent
        rgbGen wave sin 0 1 10 0.5 //appear and disappear smoothly
    }

Vehicleinfo would contain text files, like you see in post above, plus patch to images.
Example

Code: Select all

'type' = rail
'patch' = tgv

game engine would look for images in images\vehicles\rail\tgv for images



I think it is the best solution. Also, it will be the most easy to make mods (like new vehicles, sceneries)

[Alltaken]

pretty much agreed.

shared GFX i think go into the FX folder.

i.e.

smoke (various types of smoke)
lightning (electricity for trains)
fire (which turns into smoke)
explosions (domolition)
buldozers... (for streets/ roadworks...)

this folder can increase over time with common items being added to it for all vehicles to share and utilise.

also a folder for interface tools and such.

but i personally agree with your general folder layout idea. and the FX idea for water.

the other effects idea for water is just to have 3 images, they just cycle through... shouldn't be to hard. and things like waves can also be animated.

Alltaken

[MeusH]

I'll stay hard with my way of making water - no need to make 3 or more images to animate - you can make 2 images and make a script to tell them to move - one, bottom layer, faster, foreground layer slower, or whatever you like, to make it smooth, and of course disk-space friendly

[Alltaken]

I'll stay hard with my way of making water - no need to make 3 or more images to animate - you can make 2 images and make a script to tell them to move - one, bottom layer, faster, foreground layer slower, or whatever you like, to make it smooth, and of course disk-space friendly

well discspace on the 4Kb difference

its more of a question of RAM, and CPU useage of either method IMO. and to be honest i would expect both methods to be possible from a GFX designers POV.

neither system should be a limiting factor. if the format is coded correctly

Alltaken

[Burgundavia]

There are 2 issues here, each sort of intertwined:

1. Tell the computer where to put the sprite, and which one to use
2. Tell the computer what the sprite does.

For the first, I have no experience.

For the second, I like the look of WML, which is used by the Battle for Wesnoth. It is a simple key=value pair system, and is highly extensible.

Corey

[MeusH]

You mean something like this?

Code: Select all

{
'type' = rail
'patch' = tgv
'longname' = T.G.V
'power' = 40000
'maxspeed' = 345
'cost' = 15000 //cost in 1950
'runningcost' = 410 //cost in 1950
'realiabity' = 95
'start' = 1980
'end' = 2020
'specialwagonset' = tgv
'capacity1' = 20
'capacity2' = 10
'capacity1t' = passegner
'capacity2t' = mail
}

Code: Select all

{
'type' = truck
'patch' = wood_volvo
'longname' = Volvo wood truck
'maxspeed' = 110
'cost' = 2000
'runningcost' = 56
'realiabity' = 89
'start' = 1975
'end' = 2014
'capacity1' = 35
'capacity2' = 0
'capacity1t' = wood
'capacity2t' = null
}

[Alltaken]

Ok guys, enough pussy footing around.

we need a new GFX format, and we need one ASAP.

Most of the options people have presented sound fine to me.

i need someone to take on the responsibility of the GFX format, this person will need to be able to code the format into the game engine (or convince a developer to do it)

this person will need to become an expert in the GFX requirements, and the coding requirements of the game.

i have "features" that i want the format to have, but the form of the format is up to the person doing it.

this is not a time for beurocracy, nor debate, that is slow. its a time for testing and getting things to work reliably.

interested? then contact me. and i will start talking to you about it.

Alltaken