Handling of unexpected sprites (Split from OpenGFX)
Moderator: Graphics Moderators
Handling of unexpected sprites (Split from OpenGFX)
Hi
I have little problem I thought Ill try Your new industries ver 0.10 on TTDPacth and I did get an error message (see picture). I'm using latest nightly! Older version what I once tried worked fine, but that one don't! Is it suppose to work or maybe not?
I have little problem I thought Ill try Your new industries ver 0.10 on TTDPacth and I did get an error message (see picture). I'm using latest nightly! Older version what I once tried worked fine, but that one don't! Is it suppose to work or maybe not?
- Attachments
-
- error.PNG (1.92 KiB) Viewed 6588 times
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
-
- Tycoon
- Posts: 1656
- Joined: 08 Jun 2007 08:00
Re: [8bpp] Graphics Replacement Project - OpenGFX
Hmm.. everything is supposed to work in TTDPatch too, not only OpenTTD, I'll give it a look. BTW, which version of newIndustries do you use?
Re: [8bpp] Graphics Replacement Project - OpenGFX
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
-
- Tycoon
- Posts: 1656
- Joined: 08 Jun 2007 08:00
Re: [8bpp] Graphics Replacement Project - OpenGFX
Hmm.. haven't got TTDPatch available just now (and cba to install it either atm/haven't got time either) but Idecoded that grf and sprite 377 is :/ :/
and
So I have absolutely no idea what's going on :/ DaleStan?
And
And can you test if it works with older TTDPatch revisions? I guess that
?
Code: Select all
377 sprites/indu.pcx 322 2232 09 31 64 -31 0
And
what is the revision (latest isn't a number )I'm using latest nightly!
And can you test if it works with older TTDPatch revisions? I guess that
is aboutthe grf not TTDPatch?Older version what I once tried worked fine, but that one don't!
?
Re: [8bpp] Graphics Replacement Project - OpenGFX
Code 1/0 means that a real sprite is encountered where a pseudosprite was expected.
The problem is this:
Line 375 skips just the action A if the climate is not arctic. Not only the action A should be skipped, but the following 7 real sprites as well! Same problem exists on line 366 and 384.
Here's a bugfix release of version 0.10:
The problem is this:
Code: Select all
375 * 6 07 83 01 \7! 01 01
376 * 5 0A 01 07 7D 08
377 sprites/industries010.pcx 322 2232 09 31 64 -31 0
378 sprites/industries010.pcx 402 2232 09 44 31 -11 -29
379 sprites/industries010.pcx 450 2232 09 44 31 -11 -29
380 sprites/industries010.pcx 498 2232 09 44 31 -11 -29
381 sprites/industries010.pcx 546 2232 09 44 31 -11 -29
382 sprites/industries010.pcx 594 2232 09 44 31 -11 -29
383 sprites/industries010.pcx 642 2232 09 44 31 -11 -29
Here's a bugfix release of version 0.10:
- Attachments
-
- OpenGFX_NewIndustries_v0.10.1.grf
- (348.85 KiB) Downloaded 1567 times
-
- Tycoon
- Posts: 1656
- Joined: 08 Jun 2007 08:00
Re: [8bpp] Graphics Replacement Project - OpenGFX
hehe, I knew I should have put it through renum too
Re: [8bpp] Graphics Replacement Project - OpenGFX
Well that's embarrassing.
Since I made the same mistake on the headquarters grf, here is the fixed version: I've said it before and I'll say it again; It's a miracle anything I code works at all.
Sorry.
(In my defense, renum doesn't throw up any complaints. That's still no excuse for sloppy coding though)
Since I made the same mistake on the headquarters grf, here is the fixed version: I've said it before and I'll say it again; It's a miracle anything I code works at all.
Sorry.
(In my defense, renum doesn't throw up any complaints. That's still no excuse for sloppy coding though)
Re: [8bpp] Graphics Replacement Project - OpenGFX
Thank You works fine but seems like oil rig don't have right graphics some how?!?!
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
Re: [8bpp] Graphics Replacement Project - OpenGFX
does it look like this?
- Attachments
-
- Naamloos-1.png (5.09 KiB) Viewed 6485 times
Re: [8bpp] Graphics Replacement Project - OpenGFX
No, its an old one!FooBar wrote:does it look like this?
TT-Screenshot Of The Month - 2012 July, winner!
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
TT-Screenshot Of The Month - 2013 May, winner tie with Purno!
TT-Screenshot Of The Month - 2014 February, winner!
TT-Screenshot Of The Month - 2014 June, winner tie with alluke!
TT-Screenshot Of The Month - 2014 April, winner!
My screen shot thread ---> Have a look
Re: [8bpp] Graphics Replacement Project - OpenGFX
Waitamoment... *lookingatthehelipad* - where are the blinking lights? Have I forgotten to add them in the final version?FooBar wrote:does it look like this?
Like sun is to the dark soil,
so is true enlightenment to the soil's friends.
N.F.S. Grundtvig
so is true enlightenment to the soil's friends.
N.F.S. Grundtvig
Re: [8bpp] Graphics Replacement Project - OpenGFX
Indeed. NFORenum won't catch that. It probably should, but it won't.buttercup wrote:In my defense, renum doesn't throw up any complaints.
OpenTTD definitely should, though.
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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: [8bpp] Graphics Replacement Project - OpenGFX
No, it shouldn't. It should just ignore erroneous real sprites. I remember this from the wiki: "It's generally not an error to provide more real sprites, but it expenses sprite slots" or something like that. I can't remember if that's on the action 3, 5 or action A page. If it's not an error to provide more sprites in combination with those actions, it shouldn't be an error to provide real sprites without an action.DaleStan wrote:OpenTTD definitely should, though.
Re: [8bpp] Graphics Replacement Project - OpenGFX
And, in the same way, it's not an error (In OpenTTD, anyway) to specify property 05 for stations (undefined, and therefore extraneous) so it shouldn't be an error to just have property 05 all by itself, without an action 0 header.FooBar wrote:If it's not an error to provide more sprites in combination with those actions, it shouldn't be an error to provide real sprites without an action.
Or maybe more precisely, it's not an error to add extraneous bytes to the end of an action 0, (this is true in both games) so it shouldn't be an error to have those bytes existing all by themselves. Even if the first of those extraneous bytes is a 01, 05, 0A, 11, or 12.
Either way, I don't think your logic works.
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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: [8bpp] Graphics Replacement Project - OpenGFX
Maybe we have different logics Mine is this:
An action is a (pseudo)sprite.
A real sprite is a (real)sprite.
So everything is sprites.
Some extraneous bytes are no sprite.
The game reads these sprites and knows what they are supposed to do. If the game encounters (and recognises!) some realsprites without an action defining what to do with those sprites, it could as well just ignore them without bothering the end user with errors and such. That's why we have debuggers, to check code against the book.
Take Windows for example. That's full of bugs, but still works (more or less). Should Windows report every bug to the end user and then abort? No. Running the windows code through a debugger should unveil each and every bug in the code. It's just that Microsoft doesn't have a debugger for it's code
I think the difference between Patch and Open is that Patch does include a grf debugger, and Open does not. Patch gives you an error indicating what's wrong. Open will just crash if a grf is really buggy, otherwise it will just ignore (parts of) the faulty grf.
An action is a (pseudo)sprite.
A real sprite is a (real)sprite.
So everything is sprites.
Some extraneous bytes are no sprite.
The game reads these sprites and knows what they are supposed to do. If the game encounters (and recognises!) some realsprites without an action defining what to do with those sprites, it could as well just ignore them without bothering the end user with errors and such. That's why we have debuggers, to check code against the book.
Take Windows for example. That's full of bugs, but still works (more or less). Should Windows report every bug to the end user and then abort? No. Running the windows code through a debugger should unveil each and every bug in the code. It's just that Microsoft doesn't have a debugger for it's code
I think the difference between Patch and Open is that Patch does include a grf debugger, and Open does not. Patch gives you an error indicating what's wrong. Open will just crash if a grf is really buggy, otherwise it will just ignore (parts of) the faulty grf.
Re: [8bpp] Graphics Replacement Project - OpenGFX
OK, so let's try this one then.FooBar wrote:An action is a (pseudo)sprite.
A real sprite is a (real)sprite.
It is not automatically an error to append this sprite:
Code: Select all
-1 * 257 00 00 01 00 00 00 00 00 00 00 00 0A 0B 0C 0D 0E 0F 10 11 12 13 14 15 16 17 18 19 1A 1B 1C 1D 1E
1F 20 21 22 23 24 25 26 27 28 29 2A 2B 2C 2D 2E 2F 30 31 32 33 34 35 36 37 38 39 3A 3B 3C 3D 3E
3F 40 41 42 43 44 45 46 47 48 49 4A 4B 4C 4D 4E 4F 50 51 52 53 54 55 56 57 58 59 5A 5B 5C 5D 5E
5F 60 61 62 63 64 65 66 67 68 69 6A 6B 6C 6D 6E 6F 70 71 72 73 74 75 76 77 78 79 7A 7B 7C 7D 7E
7F 80 81 82 83 84 85 86 87 88 89 8A 8B 8C 8D 8E 8F 90 91 92 93 94 95 96 97 98 99 9A 9B 9C 9D 9E
9F A0 A1 A2 A3 A4 A5 A6 A7 A8 A9 AA AB AC AD AE AF B0 B1 B2 B3 B4 B5 B6 B7 B8 B9 BA BB BC BD BE
BF C0 C1 C2 C3 C4 C5 92 93 94 95 96 97 98 99 CE CF D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 DA DB DC DD DE
DF E0 E1 E2 E3 E4 E5 E6 E7 E8 E9 EA EB EC ED EE EF F0 F1 F2 F3 F4 F5 00 00 00 00 00 00 00 00 00
FF
Or, if you prefer, this sprite:
Code: Select all
-1 * 107 08 06 "mb" 04 01 "DB Set V0.82 (XL) 05.05.05" 00
"© 2003 - 2005 Michael Blunck - All "
"rights reserved." 0D "Visit www.ttdpatch.de" 00
I guess I'm still not understanding your logic.
and this is a feature?FooBar wrote:Open will crash if a grf is buggy
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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: [8bpp] Graphics Replacement Project - OpenGFX
If that's a valid action 0 (I haven't checked), than yes. Otherwise no. The realsprites in the opengfx industries were also perfectly valid by themselves, but just not used.DaleStan wrote:It is not automatically an error to append this sprite:
No it shouldn't. You may provide extraneous real sprites, not pseudosprites.DaleStan wrote:Therefore that sprite should be ignored if it appears outside an action 5 block.
I think that makes the difference then. The game knows that a real sprite can't be used without an action referencing it. A realsprite always needs an action referencing it in order to function, so if there's no reference, it could as well be skipped. An action 0 (or 8 for that matter) does not need something referencing it, so it should never be ignored.
Is it an error to provide unused (but by themselves perfectly valid) Action 2's?
Re: [8bpp] Graphics Replacement Project - OpenGFX
That is a valid action 0. It is also a valid recolor sprite. All recolor sprites are valid action 0s, basically by definition.FooBar wrote:If that's a valid action 0, than yes. Otherwise no.DaleStan wrote:It is not automatically an error to append this sprite:
And where does it say that, please? Only thing I can find merely says "sprites".FooBar wrote:No it shouldn't. You may provide extraneous real sprites, not pseudosprites.DaleStan wrote:Therefore that sprite should be ignored if it appears outside an action 5 block.
Action 5 data blocks may not contain more sprites than specified by the action 5. The action 5 may supply more sprites than required by the host, but the data block must contain exactly as many sprites as the header says it contains. No more and no less.
Used or unused, all sprites must beFooBar wrote:Is it an error to provide unused (but by themselves perfectly valid) Action 2's?
1) Internally consistent. (An action 5 that is only two bytes long is automatically not valid.) and
2) Consistent with all preceding sprites. (An action 2 that references a CargoID or sprite set that has not been defined is not valid.)
This hold for all sprite types: Pseudos, Reals, Recolors, Includes, and Imports.
So, does the action 2 satisfy both conditions? If so, it is valid.
In the same way, the real sprite is only valid if it is 1) properly compressed, and 2) consistent with the preceding data-block header.
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
Projects: NFORenum (download) | PlaneSet (Website) | grfcodec (download) | grfdebug.log parser
Re: [8bpp] Graphics Replacement Project - OpenGFX
Well, I can make it say that, but that would be silly
When it comes to a code interpreter (like Open in this case), I think it's completely legal for such an interpreter to be smarter than the book. And that would be my logic then.
Let's go back to the old erroneous code:
As a human I read there: "Well, if the climate is not arctic, then the game will skip the next line, which is an action A replacing some sprites, so if it skips that action A it ends up with a bunch of real sprites. Now that's wrong, some real sprites all by themselves. They shouldn't be there, let me fix that *counts number of lines* eight lines. Hey, eight in hex is easy, let me fix it right away. *changes 01 in 08* *hits ctrl+s*"
A code interpreter usually isn't as smart as a human, but it should know the rules from the book. It might as well know something on top of that. A good example to illustrate the opposite would be Internet Explorer: it knows something on top (how to deal with crappy frontpage code), but not the book (incomplete css support). If IE would know the whole book plus how to deal with crappy frontpage code, it would be the perfect browser as it can display every page out there correctly.
Now back to the example code above.
The way I see it, Open processes that fragment as follows:
375 recognises Action 7, should check var 83 *wanders of to get the value of var 83, returns*, picks first byte of var, compares to value 01, concludes it's not equal, skips next sprite
376 *doesn't even check what the sprite is about*
377 Doesn't recognise legal action; does not attempt to process, does not issue error, skips to next line
378-383 (same as previous line)
384 recognises action 7, might be valid, continue processing... etc.
To conclude this: I think we both agree that the code from the fragment above is not valid. It just isn't according to the specification. When it comes to the parser, I think it's fine if it tries to skip things it doesn't understand to see if there's something else it does understand.
Let's go back to the browser example one more time. It can be any browser now. According to w3c specification, a html document should start with the <html> tag (well, actually a doctype, but even google omits that). Now if a document doesn't start with <html> (i.e. invalid code), should the browser issue an error and terminate processing the page, or should it assume [0] a html document and continue processing to see if there's something that it does understand?
Now that's my logic. I don't have to be right, I just want you to understand my logic and maybe conclude that my way of thinking could be valid as well[1].
[0]The headers send by the server indicate a html document, so the browser knows it should use the html parser.
[1]At least I think it's valid.
I agree to that, as that's exactly what it says on the action 5 page:DaleStan wrote:Action 5 data blocks may not contain more sprites than specified by the action 5. The action 5 may supply more sprites than required by the host, but the data block must contain exactly as many sprites as the header says it contains.
The number of sprites that follow.
Note that it is not generally an error to provide more sprites than required, but this does expend sprite slots unnecessarily.
I also agree to that. If it comes to code, it's faulty if it isn't written by the book.DaleStan wrote:...
In the same way, the real sprite is only valid if it is 1) properly compressed, and 2) consistent with the preceding data-block header
When it comes to a code interpreter (like Open in this case), I think it's completely legal for such an interpreter to be smarter than the book. And that would be my logic then.
Let's go back to the old erroneous code:
Code: Select all
375 * 6 07 83 01 \7! 01 01
376 * 5 0A 01 07 7D 08
377 sprites/industries010.pcx 322 2232 09 31 64 -31 0
378 sprites/industries010.pcx 402 2232 09 44 31 -11 -29
379 sprites/industries010.pcx 450 2232 09 44 31 -11 -29
380 sprites/industries010.pcx 498 2232 09 44 31 -11 -29
381 sprites/industries010.pcx 546 2232 09 44 31 -11 -29
382 sprites/industries010.pcx 594 2232 09 44 31 -11 -29
383 sprites/industries010.pcx 642 2232 09 44 31 -11 -29
384 * 6 07 83 01 \7! 01 01
A code interpreter usually isn't as smart as a human, but it should know the rules from the book. It might as well know something on top of that. A good example to illustrate the opposite would be Internet Explorer: it knows something on top (how to deal with crappy frontpage code), but not the book (incomplete css support). If IE would know the whole book plus how to deal with crappy frontpage code, it would be the perfect browser as it can display every page out there correctly.
Now back to the example code above.
The way I see it, Open processes that fragment as follows:
375 recognises Action 7, should check var 83 *wanders of to get the value of var 83, returns*, picks first byte of var, compares to value 01, concludes it's not equal, skips next sprite
376 *doesn't even check what the sprite is about*
377 Doesn't recognise legal action; does not attempt to process, does not issue error, skips to next line
378-383 (same as previous line)
384 recognises action 7, might be valid, continue processing... etc.
To conclude this: I think we both agree that the code from the fragment above is not valid. It just isn't according to the specification. When it comes to the parser, I think it's fine if it tries to skip things it doesn't understand to see if there's something else it does understand.
Let's go back to the browser example one more time. It can be any browser now. According to w3c specification, a html document should start with the <html> tag (well, actually a doctype, but even google omits that). Now if a document doesn't start with <html> (i.e. invalid code), should the browser issue an error and terminate processing the page, or should it assume [0] a html document and continue processing to see if there's something that it does understand?
Now that's my logic. I don't have to be right, I just want you to understand my logic and maybe conclude that my way of thinking could be valid as well[1].
[0]The headers send by the server indicate a html document, so the browser knows it should use the html parser.
[1]At least I think it's valid.
Re: [8bpp] Graphics Replacement Project - OpenGFX
If you insist on using this analogy, I think it should be pointed out that web browsers being so forgiving of bad markup is partially, perhaps even mostly, responsible for the truly appalling state of standards-compliance of web pages. Do you really want to sentence GRF creators to the same hell as web developers have been living for the past 10 years?FooBar wrote:Let's go back to the browser example one more time. It can be any browser now. According to w3c specification, a html document should start with the <html> tag (well, actually a doctype, but even google omits that). Now if a document doesn't start with <html> (i.e. invalid code), should the browser issue an error and terminate processing the page, or should it assume [0] a html document and continue processing to see if there's something that it does understand?
From a programming perspective, the issue in question - extraneous sprites - should probably raise a warning (during compilation and/or interpretation), rather than an error or being ignored altogether.
If you permit mistakes without comment, people will not know that they've done anything wrong.
Who is online
Users browsing this forum: No registered users and 69 guests