[ToME 2] Getting serious about the SDL interface (again)

[Therem Harth]

After spending way too much time on this, I managed to get it compiling by couching the offending line in if 0/endif. Unfortunately the executable now borks because it can't find the normal save directory used on UNIX, which does not and cannot exist on Windows.

(So far I haven't even come close to getting SDL working on Windows.)

[AnonymousHero]

Did you do a clean clone + revert that single commit?

Btw, you could also try the one tagged v2.3.9-ah just to see if you can get it up and running.

[Therem Harth]

Yes. Umm, looks like that gave an error.

error: could not revert c70d7a8... Remove conditional compilation based on PRIVATE_USER_PATH. It is always set.

Oddly, trying that again (which I did for who knows what reason) results in a different error:

error: 'revert' is not possible because you have unmerged files.

I really have no idea what's going on... But anyway, doing a reset to the commit just before c70d7a8 fails to make it compile - I get an error about an undefined reference to private_check_user_directory in modules.c.

2.3.9-ah compiles fine on Windows, though.

[Therem Harth]

BTW, I must mention something: the Win32 interface is slow. Slower than Chengband's, slower than SDL, so slow that you can see the screen rerender from top to bottom every time you move into a new wilderness square. Even dragging the window around shows visible lag... With Aero and all compositing effects turned off.

Anyway I'm going to try one more time to get SDL working on Windows. No idea why it didn't work the first time...

[AnonymousHero]

Originally Posted by Therem Harth

Yes. Umm, looks like that gave an error.

error: could not revert c70d7a8... Remove conditional compilation based on PRIVATE_USER_PATH. It is always set.

Oddly, trying that again (which I did for who knows what reason) results in a different error:

error: 'revert' is not possible because you have unmerged files.

I really have no idea what's going on...

The first revert fails (there's probably some later commit which interferes) and leaves various files lying around in the working directory. The second message is saying that you can't attempt a revert while you have such files lying around since it might overwrite some of your hard work.

But anyway, doing a reset to the commit just before c70d7a8 fails to make it compile - I get an error about an undefined reference to private_check_user_directory in modules.c.

2.3.9-ah compiles fine on Windows, though.

Ok, this is good in that we should be able to narrow this down to a specific commit using git "bisect" if you're interested in helping. You'll need to do a few test compiles (roughly 6 compiles) along the way. If you're willing to help please say so and I'll try to give instructions -- git bisect can be a little intimidating to get started for newcomers. Once we your bisect started it should be a doddle .

[Therem Harth]

I'm quite willing to help, but Windows 7 isn't. This OS and its annoying quirks have been fighting me every step of the way... I'll see what can be done though.

[AnonymousHero]

Cool. Here are the steps you need to get started:

1. Make a fresh clone of the gitorious repo somewhere.
2. Change direcory into the clone and make sure it is set up to use the 'master' branch (you can use e.g. "git branch" with no arguments and note the star).
3. Type in "git bisect start HEAD v2.3.9-ah"

This last line tells git you want to track down a problem in a commit somewhere between v2.3.9-ah and HEAD.

From here on you just repeat the following steps until git tells you precisely which commit is the first bad one:

1. Delete CMakeCache.txt (if present)
2. Run CMake with the arguments you're normally using. If this step fails, type in "git bisect skip" and restart from step 1.
3. Compile
4. If the compile fails with an error, type in "git bisect bad". If the compile succeeds, type in "git bisect good".

Hopefully that should be enough to let you pinpoint the first proplematic commit. At every step in the process git will let you know how many steps it thinks are left, but beware that it may sometimes say "0 steps left" even though you aren't quite done (probably rounding or something). When you're done it will specifically say something like "First bad commit is <SHA hash here>".

[Therem Harth]

BTW, I should mention that tome2 cannot be compiled on Windows inside of a directory with spaces in it. This makes windres bork. I know using spaces in directory names is stupid anyway, but Windows does this by default with e.g. Program Files, My Documents, Documents and Settings...

(And annoyingly, I just wasted half an hour trying to compile in a Win2k VM and wondering why all my builds were failing. Grr.)

Edit: On Windows 2000 and XP, tome2 has to be compiled in the root directory. I'd say this is a bug.

[AnonymousHero]

Originally Posted by Therem Harth

BTW, I should mention that tome2 cannot be compiled on Windows inside of a directory with spaces in it. This makes windres bork. I know using spaces in directory names is stupid anyway, but Windows does this by default with e.g. Program Files, My Documents, Documents and Settings...

(And annoyingly, I just wasted half an hour trying to compile in a Win2k VM and wondering why all my builds were failing. Grr.)

I believe they at least changed "Program Files" to "Programs" in more recent Windows editions.

But, yeah, it's annoying. Without error messages it's going to be difficult to do anything about this -- even then it's probably not trivial to fix.

I've added a note to the README about this.

Originally Posted by Therem Harth

Edit: On Windows 2000 and XP, tome2 has to be compiled in the root directory. I'd say this is a bug.

Really? This is the first I've heard of such a thing. What error messages do you get? (Hopefully nobody's still using Windows 2000, but I guess XP still refuses to die.)

You can perhaps work around this by creating a "virtual drive" using

subst T: "C:\Wherever You\Unpacked\The\Source"

and then compiling on T:

[Therem Harth]

First, something else noteworthy: revision c06c5c1 somehow causes MinGW's linker to hang forever.

Originally Posted by AnonymousHero

Really? This is the first I've heard of such a thing. What error messages do you get? (Hopefully nobody's still using Windows 2000, but I guess XP still refuses to die.)

The error, verbatim:

gcc: error: and\: No such file or directory
gcc: error: Settings/Administrator/My\: No such file or directory
gcc: error: Documents/Downloads/tome2-tome2/src: No such file or directory
C:\MinGW\bin\windres.exe: preprocessing failed.
mingw32-make[2]: *** [src/angband_rc.o] Error 1
mingw32-make[1]: *** [src/CMakeFiles/tome.dir/all] Error 2
mingw32-make: *** [all] Error 2

You can perhaps work around this by creating a "virtual drive" using

subst T: "C:\Wherever You\Unpacked\The\Source"

and then compiling on T:

Thank you, I had no idea such a command existed on Windows.