Log for #openttdcoop.devzone on 3rd January 2015:
Times are UTC Toggle Colours
09:52:06  *** Alberth has joined #openttdcoop.devzone
10:47:39  <DevZone> Project World Airliner Set build #698-push: FAILURE in 1 min 0 sec:
10:50:24  <DevZone> Yippee, build fixed!
10:50:25  <DevZone> Project World Airliner Set build #699-push: FIXED in 2 min 44 sec:
11:14:04  *** oskari89 has joined #openttdcoop.devzone
12:32:31  *** Supercheese is now known as Guest634
12:32:35  *** Supercheese has joined #openttdcoop.devzone
12:37:18  *** Guest634 has quit IRC
12:51:28  *** frosch123 has joined #openttdcoop.devzone
12:54:22  *** oskari89 has quit IRC
15:37:35  *** Elyon has quit IRC
16:48:45  <DevZone> Project ecs build #75-push: SUCCESS in 32 sec:
16:49:53  <DevZone> Project 2ccts build #371-push: SUCCESS in 1 min 43 sec:
17:04:34  *** Taede has quit IRC
17:08:11  *** Taede has joined #openttdcoop.devzone
18:20:23  *** Elyon has joined #openttdcoop.devzone
18:40:35  <DevZone> Project road-hog build #580-nightlies: SUCCESS in 34 sec:
19:52:53  <Elyon> how do I tell grfcodec (or is it nforenum) that I want Info v32?
19:54:46  <Elyon> trying to add 32bpp stuff, but I get a meaningful error of "Could not read ypos from apparent real sprite", which makes sense as xpos is probably read as "8b" and then "pp" would be read as the ypos
20:02:42  <Alberth> I remember a recent irc discussion where the answer to such a question was -g 2
20:02:59  <Alberth> but I cannot find the discussion any more :(
20:02:59  <Elyon> but that is already set, hmm
20:03:39  <Alberth> why would you have "8bpp" in NFO?
20:03:45  <Elyon> grfcodec -s -e -p 2 -g 2 -c
20:04:07  <Alberth> it means nothing to me :(
20:04:33  <Elyon> according to, that's the way to enable the use of 32bpp sprites
20:04:38  <Elyon> defining them as alternatives
20:06:57  <Elyon> but according to the header comment by grfcodec, it is creating an Info version 7 file
20:13:20  <michi_cc> Elyon: Are trying to decompile an existing grf file or editing old NFO sources?
20:14:45  <Elyon> michi_cc: neither
20:14:55  <Elyon> I am making a new NFO-based grf
20:16:00  <michi_cc> Then take the header comment from any other existing file with NFO 32 (can be any decompiled GRF). Just be aware of the different order of the components in the real sprite definition.
20:17:09  <michi_cc> E.g.
20:18:32  <Elyon> is this really the preferred process? I'm using pm's Makefile setup so I'd have to tweak that a bit to make it work automatically ...
20:19:27  <michi_cc> Eh? You have a .nfo (or .pnfo or whatever file), it has to start with these exact lines for a NFO version 32 source.
20:20:17  <Elyon> michi_cc: something in the build setup definitely generates that comment in the generated nfo (from pnfo) file. I had assumed grfcodec generated this comment?
20:20:25  *** gelignite has joined #openttdcoop.devzone
20:22:23  <michi_cc> No. I'd guess there's a header/template file somewhere in the various files of the makefile setup.
20:23:10  <michi_cc> The makefile is using the C preprocessor to combine the pnfo to nfo, there's no grfcodec involved with this step.
20:23:46  <Elyon> yeah, I'm looking through the files now
20:24:13  <Elyon> I just assumed, based on the first line of that comment, that grfcodec generated it - seeing as it actually says that
20:24:14  <frosch123> Elyon: if the sprites are already numbered consecutively in the .nfo, then it was probably run through nforenum
20:24:23  <michi_cc> grep -R 'Info version' *
20:24:50  <Elyon> michi_cc: only the generated .nfo has that
20:25:39  <Elyon> frosch123: they're not numbered, they're commented out with the message "Could not read ypos from apparent real sprite"
20:26:06  <frosch123> so, it was run through nforenum :p
20:26:22  <frosch123> i guess the makefile assumes that nforenum will add the header
20:26:22  <michi_cc> That would be NFORenum then, which probably defaults to NFO version 7 if the input doesn't have the aforemention header.
20:26:29  <frosch123> but that fails for v32
20:26:36  <Elyon> michi_cc: oh, ah, hmm
20:26:41  <frosch123> you have to add the header yourself in the first included nfo file
20:26:41  <Elyon> frosch123: interesting
20:26:49  <Elyon> I'll do that immediately
20:27:34  <michi_cc> I'd add an extra file for the header to make sure you can't accidentally rename it.
20:27:57  <Elyon> rename it?
20:29:51  <michi_cc> Acually, you probably don't need to. Do you have a main file with the different #includes? If yes, the header should probably go there.
20:30:17  <Elyon> I'm using a bit of a different setup, but yes, I have a main file
20:33:23  <Elyon> to which I've added that comment, which is ignored by something and something adds the version 7 instead. I'll look into my build setup, maybe something is wrong there
20:44:44  <Elyon> yeap, nope, can't find anything out of what I would assume to be ordinary. Something is definitely generating that comment, and printing my 'Info v32' comment neatly below sprite 0
20:46:04  <michi_cc> Upload the stuff somewhere?
20:48:12  <Elyon> michi_cc: myes, which of it? The pnfo itself is rather ... long and unwieldy and irrelevant
20:48:23  <Elyon> I'll paste `head -n 50` or something
20:48:30  <Elyon> as well as the errors
20:48:38  <michi_cc> Makefile and associated files more like.
20:48:58  <michi_cc> Your sources are mostly irrelevent.
20:49:03  <Elyon> figures
20:49:42  <michi_cc> Make a zip/tar unless it's some secret stuff :p
20:50:10  <Elyon> it isn't. In fact, it's on
20:50:32  <Elyon> well, at least the makefiles I use are
20:50:56  <michi_cc> Yes, but even the default makefile can have/has local modifications.
20:51:23  <Elyon> hmm, I guess
20:51:25  <Elyon>
20:51:58  <Elyon> ./Makefile and script/Makefile_* seems to be the relevant ones
20:52:19  <Elyon> I just ... I don't know where to look, to be honest, as nothing in the makefiles seems to generate that comment
20:54:32  <Elyon> (the sources there are not the sources I am compiling, by the way - they don't have the header, but I can paste the head of the file I have that does)
20:54:46  <Elyon> I could also zip the lot but it is largely irrelevant
21:03:09  <michi_cc> Ah, it's some interesting interaction between cpp and nforenum. cpp outputs some comments into the source to track the included files, which means the first line in the nfo isn't the first line from the input anymore. And nforenum/grfcodec needs the header starting really at the very first line.
21:03:49  <Elyon> aah, I see
21:03:58  <Elyon> I actually just noticed that the output is a bit odd, myself;
21:04:08  <michi_cc> To fix, add the header to your main pnfo file and modify the file scripts/Makefile_def. It has a line CC_FLAGS = .... Add -P after the -E in the line.
21:05:20  <Elyon> okay that got me somewhere!
21:05:50  <Elyon> or rather, that did indeed seem to fix the issue I was having. Lovely! Thank you!
21:06:02  <Elyon> what does -P do?
21:06:08  <Elyon> purge?
21:07:20  <Elyon> "Inhibit generation of linemarkers in the output from the preprocessor."
21:07:23  <Elyon> I see
21:23:57  <michi_cc> For the record:
21:25:49  <Elyon> ah, neat
21:25:53  <Alberth> why does nfo tools use that format?
21:54:07  <Rubidium> don't forget the -nostdinc, otherwise gcc 4.9 adds something special for you at the begin as well
21:59:32  *** Alberth has left #openttdcoop.devzone
22:36:06  <michi_cc> Rubidium: That's already in the Makefile project.

Powered by YARRSTE version: svn-trunk