> In a book I'm reading called "Debugging Applications" from MS Press, it > recommends using "minimize Size" for a couple of reasons: Oh OK, that's interesting. Still, wouldn't be the first time Microsoft has contradicted themselves. :-) Anything that makes debugging easier is good though. > I thought I did change the .dsp to point to sdl-1.2.1? That's how I've > been building it locally, anyways; and I thought I had Christoph update > the dsp with those changes. Yes sorry, my snapshot back then was a bit out of date. My second (corrected) e-mail of VC++ stuff is based on your more recent .dsp and .dsw files. While I remember, I notice that the SDL path points to a directory called blah\VisualC\Release\blah. This path does not quite match with the file I mentioned from libsdl.org which contains the pre-compiled .dll and .libs (it stores these files in a slightly different directory). It depends on whether you want to download the source and compile it yourself (which is what has been done so far) or get the pre-compiled stuff (which is what I do because I'm too lazy to recompile it myself). It might be a good idea to use the SDL sources for debugging purposes if you think they may be of use. Personally, I hope the SDL stuff doesn't need debugging! :-) Your choice as to whether you want to use the setup that comes with the SDL sources or the SDL VC6 compiled stuff - just note that the project files I e-mailed contain my slightly different SDL set up. > > Matt - why do you never have a problem with MOD_WAVETABLE in > > midiout_win32.c? I always need to change it to MOD_SQSYNTH to > > compile. > > Maybe you're using the VC6 header files before the SDK header files in > your directories config? No I'm not. I did a string search for MOD_WAVETABLE through all of my DirectX 8.0a SDK directories and it was not found at all. Are you sure the problem is at my end? > I'm not sure what you mean by "high resolution sleeps", but I'll take a > look at that file when I get back from vacation. Yeah OK. I think I meant the word timer not sleep but I probably don't know what I'm talking about there because I came in on this project at around the time you implemented high resolution timers. Nevertheless, it won't recompile - needs sleep #defined. > If you can be on the IRC channel to discuss on monday, that would be > helpful. OK well I'm in Australia. What time and what timezone? Do you know if mIRC contains a list of servers for the OpenProjects network? > You can change the PDB output file manually by changing the paramters > passed to linker directly instead of editing the fields. Did you try that > as well? I did, and it appears to keep the change (for a while). But making other unrelated changes can sometimes change it back. It just feels too dodgy and too easy to make mistakes down the track when we forget about all this, so it's probably best to change it now. > That sounds okay to me. If you would like to also create separate project > files for the SDL graphics and sound drivers, that would be cool too. I > could never get it working, myself. This goes along with the plugin-like > architecture we were shooting for, and I think works on Linux. This way, > we could hopefully just update the plugins as opposed to the whole > package. I'll definitely have a look at this, but it feels a bit out of my depth. Never done anything with DLLs before this. > > I've also included a little helper file on setting up the VC++ debugger, > > originally for a different reason. But hey, it's there and could be useful > > to people. > Will probably be very helpful to me since I'm a bit green in the debugging > arena. :) Yeah no problem. You see, before I made these changes, I found using the debugger to be a pain and useless. The calls on the call stack didn't tell you what functions were being called, they just said FREESCI XYZ XYZ where XYZ is your choice of a memory address. Now it lets you jump exactly to a line in the source code, and see what calls have been made to what functions, and where, with full tracing ability. Please tell me that you found the same thing and that I haven't wasted several hours!! You can also select which thread you want to debug. About debugging the CFSML files - I agree it's a real problem when you can't see what line number is the problem! The compiler does the same thing. I'll see if I can find anything out about this. Cheers, Alex.
