New graphics format

Forum for technical discussions regarding development. If you have a general suggestion, problem or comment, please use one of the other forums.

Moderator: OpenTTD Developers

Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by Alltaken »

mdhowe wrote: I don't care how energy efficient a 2.8Ghz computer is
you missed my entire argument.

running a 75mhz computer from the 90's COSTS MORE than just buying a $10 computer.

i threw out a 700Mhz computer because it was to old to do anything. these speeds of computers are available for FREE, so there is no excuse for anyone to not be using somthing faster than that.

besides if they are using a computer so old, then they need not bother with the new graphics since their computers cannot handle them anyway. so how would a more bulky graphics format effect them anyway?

if the game outgrows their computers, then there is always the versions of OTTD that still do run on their computers. nothing is forcing people to upgrade to a new version of the game, just as nothing is forcing them to upgrade computers.

by owning a computer so old you have already made the decision to not be able to do many things.
Why require that people have tools to edit files

IMO as a graphic designer, it would be nice if I could draw the graphics, then code the XML file (or whatever it is) without much effort in learning it.

it would then be nice if other people wishing to edit my graphics could edit it further.

this would reduce the need for specialised manpower a lot. IMO manpower is more important than CPU power.

at $50 an hour (the value of my donated time) it makes more sense to make my job easier, as well as the job of the coders.

donating time to a project is really annoying when you are artificially slowed down from achieving what you want. look at all the graphics waiting for coders in the patch forums

Alltaken
traskjd
Engineer
Engineer
Posts: 40
Joined: 17 Nov 2004 04:18
Location: Wellington, New Zealand
Contact:

Post by traskjd »

Two things

1) I'm bias towards XML, work with it a lot. If written correctly a stupid monkey could probably work out what it does and even if it were to act as a meta modelling system it would be useful.

2) I find it hard to believe that your PC uses so much CPU time running this game. I have a 3Ghz P4 - after 5 hours of play (and I'm reading it right out of task manager here) it's used 21 seconds of processing time and sits below things on my machine like firefox, internet explorer and the task manager process itself. It doesn't even break 0% utilisation. Granted 3Ghz is fairly quick, it doesn't really stack with your comment that it uses 80% of the 1.8 or whatever you said you had. One note though - are you using Linux? From what I know about running it on there it's not so much the game that cranks the requirements but SDL etc.

- JD
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

Alltaken wrote:
mdhowe wrote: I don't care how energy efficient a 2.8Ghz computer is
you missed my entire argument.
<...>
i threw out a 700Mhz computer because it was to old to do anything.
OT: *cough*SETI@Home*cough* I've got a *thinks* 233MHz (466 BogoMips) Linux box quite happily doing just that.
Alltaken wrote:IMO as a graphic designer, it would be nice if I could draw the graphics, then code the XML file (or whatever it is) without much effort in learning it.

it would then be nice if other people wishing to edit my graphics could edit it further.

this would reduce the need for specialised manpower a lot. IMO manpower is more important than CPU power.
Indeed. Hence this:
DaleStan wrote:If NFO were augmented with XML, that would be a Good Thing ... The XML version should be back-form-able from the binary version.
OTOH, "without much effort in learning it" is not likely to happen. At the very least, you'll have to learn the enormous power of the format.
traskjd wrote:I find it hard to believe that your PC uses so much CPU time running this game.
I do too, but ...
*starts TTDPatch*
*starts stopwatch*
*Loads game*
*Starts taskman*
*waits for stopwatch to show 0:05:00*
*reads 0:03:47 from "CPU Time" column for process TTDLOADW.OVL*
And there you have it. Average of 76% usage for the first 5 minutes. While I was watching it, it was always above 80% usage, and usually above 90%.
And no, not Linux. This is WinXP.

With a little more thought, I now foresee three problems with an XML version:
1) The 140+ variables (potential for 256) for Variational Action2, often without consistent meanings or ranges between vehicle types, (rail/road/air/ship) much less for stations and canals.
2) Callbacks. See #1, except now, for no immediately apparent reason, and with no immediately apparent meaning, values >32767 are returned, instead of values between 0 and 255 inclusive.
3) Action 6.

The first two can be solved with a lot of work, but I do not see how it is possible to implement Action 6 through XML. Are there any NFO coders lurking this thread who can come up a way to do Action 6?

There are also plans (and even some source) to make GRFCodec accept more user-friendly NFO files.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
mdhowe
Route Supervisor
Route Supervisor
Posts: 446
Joined: 09 Jul 2004 07:12
Location: Hobart, Australia

Post by mdhowe »

Alltaken wrote:
mdhowe wrote: I don't care how energy efficient a 2.8Ghz computer is
you missed my entire argument.
No I didn't.
Alltaken wrote:running a 75mhz computer from the 90's COSTS MORE than just buying a $10 computer.
This was what I was responding to and I think you'll find that it's not true, running a 75mhz computer all day wouldn't cost as much running a lightbulb for the same period of time.
Alltaken wrote:i threw out a 700Mhz computer because it was to old to do anything. these speeds of computers are available for FREE, so there is no excuse for anyone to not be using somthing faster than that.
That's crazy, a 700mhz computer can do just about everything except for 3D modelling and running new games. And there is no way to get a FREE 700mhz computer unless you know someone stupid enough to throw it away.
Alltaken wrote:by owning a computer so old you have already made the decision to not be able to do many things.
If you think that people own crappy computers by choice then you are very small-minded...... Or just a snob.
"Set fashion, not follow. Spit vitriol, not swallow" - Marilyn Manson
Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by Alltaken »

mdhowe wrote:Or just a snob.
sounds good to me.

Alltaken
User avatar
Jeffrey
Engineer
Engineer
Posts: 85
Joined: 09 Aug 2004 14:23

Post by Jeffrey »

mdhowe wrote:
Alltaken wrote:i threw out a 700Mhz computer because it was to old to do anything. these speeds of computers are available for FREE, so there is no excuse for anyone to not be using somthing faster than that.
That's crazy, a 700mhz computer can do just about everything except for 3D modelling and running new games. And there is no way to get a FREE 700mhz computer unless you know someone stupid enough to throw it away.
well that's not true, i got a 350 mhz pentium II with a voodoo 2 3d card ( thats the 3d card before the geforce sersies i thought)
and i'm using the 3D modeller anim8or, and that works great, i can model allot without a slow cpu speed. I know an8 isn't as powerfull as 3dsMax but that doesn't matter, because i'm going to buy the "best" computer that I can effort with the money I will have from now till 6 months! about playing the newest games you're right, i can't play verry new games, except for the game civilization III (also a bit old :P :D )
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

DaleStan wrote:but I do not see how it is possible to implement Action 6 through XML. Are there any NFO coders lurking this thread who can come up a way to do Action 6?
:idea:
I was being too literal with Action<->XML unit(?) translations. Action 6 would not be too difficult with something like:

Code: Select all

<parameter [condition=$FOO] number=0 />
Admittedly there will still be some Action6s that would be difficult, at best, to translate. For example, this

Code: Select all

74 * 6	 09 00 01 05 02 03
75 * 6	 09 00 01 03 00 01
76 * 5	 06 00 01 07 FF
77 * 11	06 00 01 06 00 01 09 FF 01 0B FF
78 * 13	03 03 01 26 02 FF 0200 00 0200 0300
(from my local version of the Chinook) would require pretty impressive parsers, in both directions, to be put together properly.
This (pseudo-)XML could[0] produce/be produced from that.

Code: Select all

<condition ID=0 parameter=0 type="<" value=3 />
<condition ID=1 parameter=0 type="=" value=1 />
<vehicle>
 <id>0x26</id>
 <graphics>
  <cargo type="purchase list" gfxID=2>
   <parameter condition=0 number=0 />
  </cargo>
  <cargo type="passengers" gfxID=2>
   <parameter condition=0 number=0 />
  </cargo>
  <cargo type="default" gfxID=3>
   <parameter condition=1 number=0 />
  </cargo>
 </graphics>
</vehicle>
There are still some problems with this XML. The <parameter /> entry should really be in an <identifier> $NUMBER </identifier> block instead.
It would also be interesting (FCVOI) to attempt to deal with Action6s that modify the action byte of the following pseudo-sprite.

[0] In all fairness, this was not really a translation of NFO to XML, but a recoding from the spec-sheet into XML.
Last edited by DaleStan on 07 Dec 2004 18:50, edited 1 time in total.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
traskjd
Engineer
Engineer
Posts: 40
Joined: 17 Nov 2004 04:18
Location: Wellington, New Zealand
Contact:

Post by traskjd »

Two things (I like things that come in pairs)

1) I think this thread has gotten a little too harsh - everyone has a view so lets try not to get s*** with each other. We're all just looking for what we think would be best for OpenTTD.

2) I would really like to find out why your openttd is eating so much power DaleStan. Since many people here mention they use lower spec machines (233 and less) which, by what your machine is eating, would mean it wouldn't even be playable on those machines.

- JD
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

traskjd wrote:I would really like to find out why your openttd is eating so much power DaleStan.
230 trains (mostly 10 vehicles long, including engine), 101 road vehicles, 21 aircraft (10 choppers, 11 planes), and 21 ships. Admittedly, this is TTDPatch (for the fourth time), and maybe the USSet is doing something Wrong(tm), but it seems like two programs that do about the same thing ought to use about the same quantity of processor power.

On one hand, I prefer terse languages for programming, on the other, I prefer readable ones. As I understand XML, it has too much syntactic salt for my tastes. Specifically, since every tag must be terminated, either as "<tag> ... </tag>" or as "<tag />" why can't I just type "<tag> ... </>"? (Or can I, and I just missed that somehow?)
There is some syntactic salt in NFO files as well, but that no longer bothers me, now that I have written NFORenum.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Archonix
Chief Executive
Chief Executive
Posts: 733
Joined: 01 May 2003 17:29
Location: Manchester, UK
Contact:

Post by Archonix »

XML is only a descriptive markup language, not a programming language. Its design is to allow the contents of a file to be interpreted and presented by many different programs without having to convert the file in to different proprietary formats. As such you can use it to visually display the parameters etc in a web browser with an accompanying stylesheet and use the same file within another program to define those parameters for that program. It's an international standard, so using it is actually good programming practice. :)
Joker
Transport Coordinator
Transport Coordinator
Posts: 259
Joined: 01 Oct 2004 12:16
Location: Earth, Europe, Czech Republic, Prague

Post by Joker »

Well, I think that if it can be done with NFO, it can be done with XML too. Advantage of XML is that XML code can be very simply converted to... well, *anything you want*. Also, the code is easy to read and edit.
DaleStan wrote:As I understand XML, it has too much syntactic salt for my tastes. Specifically, since every tag must be terminated, either as "<tag> ... </tag>" or as "<tag />" why can't I just type "<tag> ... </>"?
Well, but if you want to save space, you use one-letter tags, so you'd only save one byte.

As for hardware, truth is that Pentium I is dead. Here (Prague) you can still get one in second hand computer shop, but they want to get rid of them and are nearly giving them for free (150CZK, that's approx. 5 Euro). You can't sell computer like that or its components and upgrade potential is zero. Therefore no need to make lower CPU requirements than, say, P2/300
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

Joker wrote:
DaleStan wrote:As I understand XML, it has too much syntactic salt for my tastes. Specifically, since every tag must be terminated, either as "<tag> ... </tag>" or as "<tag />" why can't I just type "<tag> ... </>"?
Well, but if you want to save space, you use one-letter tags, so you'd only save one byte.
I know!!
We'll do it this way!! (same NFO as before)

Code: Select all

<9 p=0 s=1 c=5 v=2 k=3 />
<9 p=0 s=1 c=3 v=0 k=1 />
<6>
  <c p=0 s=1 o=7 />
</6>
<6>
  <c p=0 s=1 o=6 />
 <c p=0 s=1 o=9 />
 <c p=255 s=1 o=11 />
</6>
<3 t=3 n=1 v=38>
  <g t=255 i=2 />
  <g t=1 i=2 />
  <d i=3 />
</3>
We'll save LOADS of space that way!!111!1!
And even better, it's incredibly simple to form from the NFO files!1!one!!11

</sarcasm>

Good grief!
DaleStan wrote:On one hand, I prefer terse languages for programming, on the other, I prefer readable ones.
One letter tags do not readability promote. The "<tag> ... </>" format typing saves, while readability maintaining.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
traskjd
Engineer
Engineer
Posts: 40
Joined: 17 Nov 2004 04:18
Location: Wellington, New Zealand
Contact:

Post by traskjd »

DaleStan wrote: We'll save LOADS of space that way!!111!1!
And even better, it's incredibly simple to form from the NFO files!1!one!!11

</sarcasm>
Two things (as usual).

1) If you want to behave like a child, expect to be treated like one. I think I've personally been fair and tried to ensure that this conversation doesn't degrade into an all out fan-boy war but you seem to just want to escalate things.
2) Don't you think that as the developer of a tool designed to work with NFO files that you're extremely bias? I mean come on, it would seem you prefer to glory hunt rather than advance "the cause". There are so many valid reasons for using XML over and above "I don't like tags - wah" and "It won't compress well". The first is opinion - as mentioned by others, at least with XML you can edit it with anything really - notepad through to XMLSpy and do some funky stuff with it. The second, as we discussed, was a negligible amount.

Stop thinking of yourself and start thinking about the project. I realise this won't sit well with you and thus far I have attempted to avoid any comments like this but your last post just really pissed me off.

Get over yourself,

JD
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

I've replaced some context I feel is important here.
traskjd wrote:
DaleStan wrote:
Joker wrote:Well, but if you want to save space, you use one-letter tags,
We'll save LOADS of space that way!!111!1!
</sarcasm>
One letter tags do not readability promote.
If you want to behave like a child, expect to be treated like one.
Free hint: That </sarcasm> tag is there for a reason.
Proof by sarcasm is one of my methods of getting my point across. It is a bad sign when I actually use it, because it is one of my least favorite methods, but it seems to be the one method guaranteed to get attention, so I use it when others fail.

This may not excuse my post, but I thought I made it quite clear that I knew I was way
that ---------------------------------> way
and that the line was at least as far back
<--------------------------------- that-a-way.
traskjd wrote:Stop thinking of yourself and start thinking about the project.
I'm trying to. But when people attempt put words into my mouth, I get a little disgusted, especially when the exact same words have been put into my mouth before, and I've already explained that I didn't say them.

I'm going to try one more time here, though I suppose I should have put this in my previous post.
If you ever think that the only reason I want to do something is because it makes the output smaller, you are sorely mistaken.
Go back and read that sentence again; it bears repeating.
Even if what I say is "Smaller is better, therefore let's do $FOO," there is some other reason hiding there, and there is usually (if not always) an implicit "You say that" preceding the "smaller is better" part.
traskjd wrote:I mean come on, it would seem you prefer to glory hunt rather than advance "the cause".
If you look upthread a few posts, you'll find the beginnings of an IMAO useful XML format, showing an implementation of one of the few things that I was not previously convinced was possible, and the problems with that particuar implementation.
traskjd wrote:with XML you can edit it with anything really
And you have to have some special tool to edit NFO files?
I feel like you're trying to compare GRF and XML here, which is not a fair comparison. I'll admit that there may be tools better suited to XML than notepad, but that doesn't mean you have to/need to/want to/should use them.
traskjd wrote:Don't you think that as the developer of a tool designed to work with NFO files that you're extremely bias?
No offense, but DUH!!
I'm also extremely biased in that I like my high and exalted place as NFO coder.

Bias aside, I haven't seen any attempts answer to my questions about variational 2 and callbacks. At least give it a try. The worst you can do is fall flat on your face, and even if you do that, I'll think better of you for trying.[0] Besides, someone else may catch the idea you were reaching for, and run with it.

I definitely agree that NFO is not friendly, and that a friendlier format would be an improvement. (Haven't I said this before?) The failure on my part is figuring out how to implement one. If you can convince me you are willing to put some thought into it, you can probably convince me to put some work into making a full-blown proposal for how an XML system could be done.

[0]Right now, I feel like you (plural you here) are one big broken record--"XML is good, NFO is bad," and when I ask "Why?" you tell me that it's because "XML is good, NFO is bad." I like to discuss, I am willing to argue, but if you become a broken record I will commence ignoring you.
traskjd wrote:I realise this won't sit well with you
You are perfectly entitled to inform me that I crossed the line, and I will usually agree with you.

Please, if you feel I crossed the line or catch me twisting quotes to serve my purposes, call me on it. Just don't put words in my mouth in the process.
Whether you like it or not, I will return the favor.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
iridium
Engineer
Engineer
Posts: 11
Joined: 06 Aug 2004 22:44

Post by iridium »

DaleStan wrote:

Code: Select all

<condition ID=0 parameter=0 type="<" value=3 />
<condition ID=1 parameter=0 type="=" value=1 />
<vehicle>
 <id>0x26</id>
 <graphics>
  <cargo type="purchase list" gfxID=2>
   <parameter condition=0 number=0 />
  </cargo>
  <cargo type="passengers" gfxID=2>
   <parameter condition=0 number=0 />
  </cargo>
  <cargo type="default" gfxID=3>
   <parameter condition=1 number=0 />
  </cargo>
 </graphics>
</vehicle>
Personally I think something like this, with the possibility to convert between this and some arbitrary binary format would be the best way to go. Parsing heap loads of XML (for 4000+ sprites) will consume time at start up. Maybe that time might be insignificant, who knows.

How about having it so that OpenTTD has the tool to convert built in, and have it so that it can read either the arbitrary binary format or the XML format?
Joker
Transport Coordinator
Transport Coordinator
Posts: 259
Joined: 01 Oct 2004 12:16
Location: Earth, Europe, Czech Republic, Prague

Post by Joker »

DaleStan wrote:I know!!
We'll do it this way!! (same NFO as before)

Code: Select all

...
We'll save LOADS of space that way!!111!1!
And even better, it's incredibly simple to form from the NFO files!1!one!!11
</sarcasm>
You may feel sarcastic about this, but one letter tags aren't my idea, it's just the way it's usually done.
DaleStan wrote:Right now, I feel like you (plural you here) are one big broken record--"XML is good, NFO is bad," and when I ask "Why?" you tell me that it's because "XML is good, NFO is bad."
Not at all!
I'm not saying "XML is good, NFO is bad", I'm saying "You've put XML away too fast, IMHO it's not a bad idea"
OK, so my oppinion: Size is clearly disadvantage of XML... it has defined structure and therefore will almost always be larger than some proprietary format suited especially for OTTD. Advantages of XML are that it's quite easy to read both for people and for applications. There are tools written for creating and editing XML code that can be used. Should it be needed, other applications (maybe trainset editor?) can read the code quite easily. Also, if needed, XML can simply be converted to other formats, be it some binary format, HTML or anything.
Now it is to consider whether these advantages are good enough for OTTD.

To be honest I must say this: I do web programming and so you may say that I'm biased, favouring XML.
But, please, consider the advantages anyway.
User avatar
Celestar
Director
Director
Posts: 574
Joined: 02 Jul 2004 10:56
Contact:

Post by Celestar »

This is my opinion about XML:

Pros:
1) Easy to code
2) Easy to maintain
3) Easy to change and / or expand

Cons:
1) Another dependency (libxml or libxml2).

Currently, I rather vote for: do it.

Celestar
Alltaken
Tycoon
Tycoon
Posts: 1285
Joined: 03 Dec 2003 06:24
Location: Christchurch, New Zealand
Contact:

Post by Alltaken »

ok guys my idea (i have no idea of coding but this is what i would like to see in a file/ editor in order for me to edit things myself. and editor would be fine IMO if it makes things faster)

Code: Select all


//what people see in the game
--------ingame info-------
Sprite name: Crazytruck1
vehicle type: Road vehicle
Max speed (km/h): 120
city speed (km/h): 60
cost: $1,245
running cost: $5
reliability: 95
----------------------------

//marks first and last sprites for rotating, computer can work out the rest
-------rotation---------
first file 0 degrees: CT001.png
last truck degrees: CT072.png
degree incriment: 5
--------------------------

//when going up and down slopes the sprite tilts.
------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
------------------------

//sprite sets (uses previous info looks into sub directory for relavent files)
--------crash-----------
base sprite: /base
crash: /crash
shadows: /shadows
company colour mask: /company
forground of sprite :/foreground
---------------------

// if you are not happy with the changing colours within game or someone has created custom graphics from the 3d files (joy of open source vehicle files ;) )
--------custom colours-------
Fed ex: /FE
New Zealand Post: /NZP
Alltakens: /Alltaken
army: /army
-----------------------------------

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

// lists the actions supported by the item
-----supported actions--------
crash
turning
smoke
------------------------

-----fedex actions--------
crash
smoke
------------------------

-----NZ post actions--------
crash
turning
smoke
------------------------

-----Alltakens actions--------
crash
smoke
------------------------

-----amry actions--------
crash
turning
smoke
------------------------

//copyright info, who has worked on it
-----copyright-----
license: Open source, credit given
copyright created by: Alltaken
source file available: OTTD.mudpuddle.co.nz/crazytruck
credit given to...
original set created by: Alltaken
shadows by:Alltaken
NZ post graphics: nzguy1
Fed ex graphics: fedexlover
army graphics: US military
Alltakens graphics: Alltaken
turning graphics by: anotherperson



i don't think that could be coded to be writable like that, but these are some of the major functions i want available.

the actions settings i think go together with some of the other things in the file. i.e. if turning is an action (turning being somthing understandable by OTTD already) then the directory to custom turning graphics becomes available. (if its a truck with a weird joint in the middle of it for example)

people on slower computers or ones with limited memory can simply turn off the actions they don't want in OTTD. i.e. all specialised turning graphics could be turned off, all smoke could be turned off..... (for all sprites at once)

the minimum files for a graphic would be the rotated ones and up/down. the rest could be turned off.

the rest like shadows. crash, company colours, turning..... would also be expandable over time. since it is an open source project you might in the future get added things, which could just be added to the file. perhaps there is a hover-vehicle like in back to the future, that it folds its wheels up and turns into a flying version of the same vehicle. so it might need an action like "convert" added to it. (wouldn't break the older files from working)

a GUI program to set all this (perhaps built right into OTTD i dunno) and output a file would be fine IMO.

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

also things like location to tiles and such would need to be editable. i don't know how to organise this. perhaps my method is totally wrong/bad.

i'll trust the coders to know good ways to do these things.


P.S. the thing about my design was, if an artist download the source file to the vehicle and adds an extra set, this can then be incorperated to the existing stuff easily. the only problem is if sets are edited after the fact of a company graphic and such, not all edits will have all functions.

Alltaken
DaleStan
TTDPatch Developer
TTDPatch Developer
Posts: 10285
Joined: 18 Feb 2004 03:06
Contact:

Post by DaleStan »

A few comments on Alltaken's suggestion, and then more in the XML department.
Alltaken wrote:

Code: Select all

//marks first and last sprites for rotating, computer can work out the rest 
-------rotation---------
first file 0 degrees: CT001.png
last truck degrees: CT072.png
degree incriment: 5
--------------------------
What about a single file with multiple sprites?
Alltaken wrote:

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?)

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

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?
Alltaken wrote:

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.
Alltaken wrote:if its a truck with a weird joint in the middle of it
For that, we should use road trains.
Alltaken wrote: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.
Alltaken wrote: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.

More on Action 6:
If using XML, every value with numeric data must be acceptable in two formats:

Code: Select all

<tag value=data />

---OR---

<tag>
 <value>data</value>
</tag>
This way, a <parameter> tag can be inserted to modify the data if necessary, but the XML doesn't end up unnecessarily bloated if the parameter tag is not needed. This also allows modification with Var02, as follows.

Var02 and Action 3 overrides could look something like this:

Code: Select all

<graphics>
 <override ID=1>
  <gfxID>
   <conditional>
    <train position=0 count="back" />
    1
   </conditional>
   <conditional>
    <carriage_set length=1 />
    2
   </conditional>
   <conditional>
    <carriage_set position=0 count="front" />
    3
   </conditional>
   <conditional>
    <carriage_set position=0 count="back" />
    <reversed />
    3
   </conditional>
   <conditional>
    <carriage_set length="4+" position=1 count="back" />
    <train length=10 />
    5
   </conditional>
   4
  </gfxID>
 </override>
</graphics>
We also may want to provide the following as valid:

Code: Select all

<gfxID>
 <conditional ID=1>
  <train position=0 count="back" />
 </conditional>   
 <conditional ID=2>
  <carriage_set length=1 />
 </conditional>
 <...>
</gfxID>
This approximately codes the double-decker passenger car from the USSet, when following the Sunset. For this demonstration, vehicle ID is 1 the double-decker passenger car, and the graphics IDs are: 1--the streamlined trailing car; 2--double-decker low on both sides, high in the middle; 3--low in front, high in back; 4--high all the way across; and 5--the dining car.
It is valid for the numeric values there to be postfixed with "+", indicating "at least $VALUE", postfixed with "-", indicating "at most $VALUE", or to be in the format "$MIN-$MAX". To accommodate action 6, $TYPE="$MIN-$MAX" may be exchanged for <$TYPE min=$MIN max=$MAX /> which can then be expanded as listed above. If min is omitted, it is taken to be 0; if max is omitted, it is taken to be the largest possible value. The first applicable <conditional> unit is the one to be used.
The less common tests could be implemented, for now at least, with <conditional TTDPatch=$VARIABLE value=$VALUES />

There are some problems with this system, especially when you want to check one variable for multiple values/value ranges. It would also be nice to get the Var02 tags out of the <vehicle> tag.
To get a good answer, ask a Smart Question. Similarly, if you want a bug fixed, write a Useful Bug Report. No TTDPatch crashlog? Then follow directions.
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
User avatar
Dundee
Engineer
Engineer
Posts: 112
Joined: 28 Nov 2004 04:35
Location: Sydney, Australia

Post by Dundee »

I think XML lends itself to describing vehicle attributes and graphics sets:

Code: Select all

<vehicle>
	<name>Crazytruck1</name>
	<type>truck</type>
	<speed>120</speed>
	<power>100</power>
	<cost>1245</cost>
	<maintenance>5</maintenance>
	<reliability>95</reliability>

	<cargo type=wood amount=100 />

	<graphics>
		<spriteset name="summer" default=true>
		</set>
		<spriteset name="autumn">
		</set>
		<spriteset name="winter">
		</set>
		<spriteset name="spring">
		</set>		
	</graphics>

</vehicle>

<about>
	license: Open source, credit given
	copyright created by: Alltaken
[...]
</about>
I don't think it works very well for scripting events, graphics variations etc.

Something like this:

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. I think XML, by itself, isn't that great for scripting.

An additional 'importance=<minor|necessary>' attribute for the <script> tag would allow for unimportant scripts to be bypassed by OpenTTD if the user so desires (as Alltaken suggested).
Post Reply

Return to “OpenTTD Development”

Who is online

Users browsing this forum: Google [Bot] and 7 guests