default dot xbe
Level: Roachling
Rank Points: 11
Registered: 12-05-2004
IP: Logged

but seriously i was thinkign of doing an xbox port (since i want one of my friends to play but he doesnt play PC games) but to do the xbox port id need the source code, so i figured id poost here and see if this was a project worth pursuing

bdcribbs
Level: Smiter
Rank Points: 390
Registered: 04-08-2003
IP: Logged

It is very much open source. Visit sourceforge.net, do a search for Caravel. Refer to the docs on that site for lib dependancies. The codebase there seems to be 1.6 only, the availability of the 2.0 code is a mystery to me, but I assume it's pending on a release past beta.

And good luck! I recently have been attempting a BSD/OSX compile, since it seems about a year since anyone has tried. Haven't gotten it yet.

Edit: it does make it difficult to find, that there is (to the best of my knowledge) nowhere on drod.net a link to the sourceforge site.

[Edited by bdcribbs at Local Time:12-05-2004 at 07:47 PM]

default dot xbe
Level: Roachling
Rank Points: 11
Registered: 12-05-2004
IP: Logged

cool,. thanks a bunch, yeah i as looking all over drod.net and found no refs to source at all

agaricus5
Level: Smitemaster
Rank Points: 1838
Registered: 02-04-2003
IP: Logged

bdcribbs wrote:
Edit: it does make it difficult to find, that there is (to the best of my knowledge) nowhere on drod.net a link to the sourceforge site.

[Edited by bdcribbs at Local Time:12-05-2004 at 07:47 PM]

There is, but it's quite obscure.

You can find it on the "Sending You Away" page, which is linked to at the bottom of the "Fun Stuff" section of the site.

____________________________
Resident Medic/Mycologist

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

When DROD: Journey to Rooted Hold is publicly released, we'll simultaneously release the source code, following terms of Mozilla Public License. Note that we will not be releasing the media. Unlike AE, media will not be public domain.

The source code for DROD: Architects' Edition (1.6) is already available here:

www.sourceforge.net/projects/drod

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Ack. I typed that out in a hurry as I was about to leave to eat some breakfast. I wanted to say a few more things so it doesn't sound like the Caravel guys are erecting a big stone wall between us and spinoff open source projects.

We have to protect the media so that we can have something to sell. We're in a strange position of attempting to sell a game where all the source code is given away for free. So forgive us for that, but it's how we make the jump to supporting ourselves so more time can be spent developing DROD and other cool games.

That said, I'm still keen to help out other projects based on the DROD source. We'll be making available some public domain graphics that can be used as a reference for modding DROD along the lines of "Beethro in Space", "Demons of Colour" etc. The AE graphics will still be available to use for modding too. We'll answer questions about source code and work people through build problems. I am happy when I see somebody extending DROD in new and interesting ways.

Getting it to run on the XBox? That is interesting. I am curious how you get around the licensing stuff. Is it possible to just make some homebrew game and get it going, or do you need the developer kit and enter into contract with Microsoft and all that?

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

default dot xbe
Level: Roachling
Rank Points: 11
Registered: 12-05-2004
IP: Logged

well MS XDK (xbox developement kit) is available, and many people have it (including myself, shhh, dont tell MS)

so its possible to code and compile homebrew applications, but they wont run on a stock xbox (they dont have MS signiture) but with a modchip you can run so-called "unsigned code" its really alot of fun, and most people are suprised at the amount of stuff thats been ported to xbox (debian and mandrake linux distros are some notables)

check out xbox scene and/or xbox scene forums



thanks for all the help, hopefully i wont find myself in over my head with the porting

[Edited by default dot xbe at Local Time:12-05-2004 at 11:52 PM]

[Edited by default dot xbe at Local Time:12-05-2004 at 11:52 PM]

[Edited by default dot xbe at Local Time:12-05-2004 at 11:53 PM]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Well, cool. Let us know how it goes.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

Rabscuttle
Level: Smitemaster

Rank Points: 2460
Registered: 09-10-2004
IP: Logged

agaricus5 wrote:

bdcribbs wrote:
Edit: it does make it difficult to find, that there is (to the best of my knowledge) nowhere on drod.net a link to the sourceforge site.

[Edited by bdcribbs at Local Time:12-05-2004 at 07:47 PM]

There is, but it's quite obscure.

You can find it on the "Sending You Away" page, which is linked to at the bottom of the "Fun Stuff" section of the site.

There's also a link on the front page in the box to the right - "Download DROD!"

wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

I have a "private" branch of Caravel DROD 1.6 that I have been playing with recently. The changes that I have made so far have mostly dealt with MSVC6-isms in the code. I use g++ and Linux to compile it, and a while ago I verified that the code compiles with MSVC7.1 and Windows. It is possible that this could be of use to someone who is porting DROD to other systems.

The bad news is that I haven't been working toward the goal of sharing the code with others. Consequently, I have made numerous changes that are largely or entirely stylistic in nature. It is likely that many of the changes have broken compatibility with MSVC6. (In various ways, it does not conform to the C++ standard.) Other than a few periodic snapshots of my source, I have not attempted to track the changes that I have made. It would probably be difficult for me to extract out only those changes that I made in an effort to improve portability. However, it might not be too difficult for me to look through the changes that I've made, and try to post a summary of what those changes were. Or, I could simply post a current snapshot of the whole thing.

How much would other people be interested in these things? It appears to me that DROD's CVS repository (as reported by cvs.sourceforge.net) is not particularly active. (Unsurprising; I expect that the maintainers are all involved in JtRH.) If I (or others) were to go to the effort of generating and posting patches that improve portability, (or make other changes) would these be likely to become part of the main repository? I haven't yet stumbled upon any obvious answer here in the developers' forum. (I haven't looked too hard, but it looks like other people are content to maintain their own "deviant" branches.)

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

wmarkham wrote:
I have a "private" branch of Caravel DROD 1.6 that I have been playing with recently.

Well, first off--nice job getting going quickly! A lot of people give up when they start futzing with the build. All those gnarly dependencies.

The changes that I have made so far have mostly dealt with MSVC6-isms in the code. I use g++ and Linux to compile it, and a while ago I verified that the code compiles with MSVC7.1 and Windows. It is possible that this could be of use to someone who is porting DROD to other systems.

Everything should compile right now under either VC6 or G++/Linux. Trick used the current source to release DROD:AE for Linux. So I'm not sure what you mean by VC6-isms. It is our constant goal to keep one set of source code for all platforms, using general C++ code where possible, and conditionally compiled sections as needed. If you think we are coming short of that goal, please point out specific places and we might do something about it.

The bad news is that I haven't been working toward the goal of sharing the code with others. Consequently, I have made numerous changes that are largely or entirely stylistic in nature.

You might be going down the lone wolf path there. And this isn't necessarily a bad thing. It just depends what your goals are. I can't hold out any promises that we will be integrating your code, but I can tell you that if you want to keep that possibility open, I and other people will work with you to make any changes needed. Just ask questions about how to handle any points of conflict between what the current source does and what you want to do.

It is likely that many of the changes have broken compatibility with MSVC6. (In various ways, it does not conform to the C++ standard.) Other than a few periodic snapshots of my source, I have not attempted to track the changes that I have made.

We can always diff what you have, but it is better to plan for integration early on. If the changes you have are too much trouble to merge, then we might not do it even if you are offering them to us. Also, we are close enough to JtRH release that I wouldn't really consider integrating changes with AE (1.6).

It would probably be difficult for me to extract out only those changes that I made in an effort to improve portability. However, it might not be too difficult for me to look through the changes that I've made, and try to post a summary of what those changes were. Or, I could simply post a current snapshot of the whole thing. How much would other people be interested in these things?

Well, first tell me what you've got going. Is this something that runs on Linux running on XBox? If so, then I can tell you that I personally am interested in the differences between running on XBox and running on Linux. Because Schik and Trick already gave us a Linux build (Trick worked from Schik's original Irix port). Now if we could make a number of smaller changes that would allow you or somebody else to maintain an XBox build from our source, then that sounds pretty cool. I may misunderstand what you are trying to accomplish here. Please correct me if that is the case.

I doubt that there is a big incentive for us to get involved in any kind of XBox distribution, and in fact there might even be legal risk. We'd need a developer agreement with MS and all that business. For a small developer that probably means getting a publisher deal, which probably means having a game that isn't anything like DROD. But if it is not too much trouble to enable some hackers to run DROD on their XBoxs, yeah sure, we could probably do that.

If we look at your changes and they are legion, I dunno... It might be best for you to stay lone wolf on this one for now. And this question is probably unanswerable until JtRH source is released.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

default dot xbe
Level: Roachling
Rank Points: 11
Registered: 12-05-2004
IP: Logged

ErikH2000 wrote:
I doubt that there is a big incentive for us to get involved in any kind of XBox distribution, and in fact there might even be legal risk. We'd need a developer agreement with MS and all that business. For a small developer that probably means getting a publisher deal, which probably means having a game that isn't anything like DROD. But if it is not too much trouble to enable some hackers to run DROD on their XBoxs, yeah sure, we could probably do that.
-Erik

yeah, i expect most of my help to come from the xbox hacking scene rather then the DROD scene, but ill be sure to post my final code (if it ever gets there) for you folks to compile for your xboxs (yeah, sure) since posting the compiled form is illegal (not that you cant find the stuff anywhere, lol)

anyway, im off to seek some more xbox programmign wizzes

wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

File: whm.tar.gz (575.2 KB)
Downloaded 74 times.
License: Other
From: Unspecified

First off, I'm sorry if I misled you, Erik. I did not mean to imply that I have my code running on an XBox. I simply meant to say that I have been playing around with my own personal copy of DROD.

ErikH2000 wrote:
Everything should compile right now under either VC6 or G++/Linux. Trick used the current source to release DROD:AE for Linux. So I'm not sure what you mean by VC6-isms.

Good point. I'm not entirely sure what I meant by VC6-isms, either. For the moment, I'll just start describing some of the changes:

One of the things that I specifically had in mind when I wrote that was that various places in the code check the return value of "x = new Foo();". According to the standard, x is always nonzero, but the statement could throw a std::bad_alloc. MSVC6, I believe, returns a null pointer if memory is exhausted. There are checks for this possibility throughout the DROD code. For my own purposes, I consider these to be clutter.

More importantly, MSVC6 allows a pointer allocated as "x = new char[7];" to be deleted via "delete x;". I believe that this is undefined behavior according to the standard. I'm not sure what the runtime library's behavior under g++ is. (It does seem to work, but perhaps it leaks or something.) Anyway, I have been correcting these when I find them. (Often by using standard containers instead.)

In addition to these two behavioral differences, I may have been thinking of some of the stylisitic changes as "MSVC-isms". For example, there may be some reason under MSVC6 to prefer a precompiler macro to an inline function. (I don't think this is the case as I think about it now, though.) The naming conventions used seem to follow those used in MFC. This could just be sloppy thinking on my part.

Anyway, I basically just wanted to let folks know that I would be pleased to see code that includes "portability enhancements" published, either within the official CVS, or otherwise. I don't necessarily intend to do any significant amount of work toward that end, and I certainly don't expect other people to do so, either! However, perhaps there is something easy that I can do that might encourage other people to work on such enhancements, or to entice them to publish such.

Up to this point, I have (on purpose) definitely been taking the "lone wolf" route. After thinking about this choice, though, I've realized that I would be pleased if I could give something back to the community, and I might have something to offer.

For example, I think that I could put together a list of individual "delete" vs. "delete[]" changes, if someone were to ask for it. Someone needs to ask, though. I don't know yet if it is an issue for anyone. Because some of the original locations that show this issue have been removed from my code, it is not a simple matter of diffing my changes. I would want any changes that are to be applied to the main CVS branch to fix the problem at hand in the simplest possible manner, without sucking in other changes.

If I find the time, I'll try to post a high-level list of other changes that I could offer, and which might be useful to other people. (Particularly if I think they might relate to portability.) Until I do that, there's no real way of knowing whether or not I do have anything useful.

Offhand, I do recall fixing a couple of SDL resource leaks. I don't recall the details at the moment, but after I go home I'll figure out what they were. I believe that there was a very minor bug somewhere involving a loop control variable not being re-initialized between two loops. These are the only other changes that I can think of that actually fix improper behavior. They don't affect portability; I'm just listing them because bug fixes are of obvious interest to other people.

I'll also attach a .tgz of my current code, in case someone has enough curiosity & bravery to look at it. (I don't know what the ettiquette here is regarding upload sizes. It's about 500k; if that's overboard, then I assume that you can just remove it, Erik.) I'm providing it as-is. DROD/Main.cpp has some unnecessary stuff relating to garbage collection that can be stripped out. The PathMap, CDbPackedVars, and DbRooms files probably best show the sorts of changes that I have made.

[Edited by wmarkham at Local Time:12-15-2004 at 12:04 AM: said "StretchyBuf" when I really meant "CDbPackedVars"]

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

wmarkham wrote:
One of the things that I specifically had in mind when I wrote that was that various places in the code check the return value of "x = new Foo();". According to the standard, x is always nonzero, but the statement could throw a std::bad_alloc. MSVC6, I believe, returns a null pointer if memory is exhausted. There are checks for this possibility throughout the DROD code. For my own purposes, I consider these to be clutter.

Well, I can see your point to some extent. Since I began coding DROD, I've dropped the practice of checking small memory allocations. When they fail on a modern O/S it means the system is in an unstable state and all bets are off anyhow. Larger allocations can still fail and I check those, but even then it typically means that the system is misconfigured or low on disk space and doesn't have nearly enough virtual memory. In any case, it wouldn't be correct for our project to remove all of the "if (!p)" checks because the new operator with the VC's runtime library does return NULL for a memory alloc failure. If on some platforms, an exception is instead thrown, we also have a top-level try-catch. So removing the "if (!p)" checks is probably not a change we'd integrate, except maybe for areas that need optimizing and make small allocs.

More importantly, MSVC6 allows a pointer allocated as "x = new char[7];" to be deleted via "delete x;". I believe that this is undefined behavior according to the standard.

We've corrected these as we've found them. I guess you found some more that we might want to also correct.

I'm not sure what the runtime library's behavior under g++ is. (It does seem to work, but perhaps it leaks or something.)

Yeah, I think it is mainly a problem with arrays of class instances where the destructor fails to call on each element, but I could be wrong.

For example, there may be some reason under MSVC6 to prefer a precompiler macro to an inline function. (I don't think this is the case as I think about it now, though.) The naming conventions used seem to follow those used in MFC. This could just be sloppy thinking on my part.

We'd have to look at the cases, but honestly, our pickiness standards here might not be where yours are.

If I find the time, I'll try to post a high-level list of other changes that I could offer, and which might be useful to other people. (Particularly if I think they might relate to portability.) Until I do that, there's no real way of knowing whether or not I do have anything useful.

If you find bugs in 1.6, not style things, then it would be useful to see a list of those. We'd check our 2.0 code to see if the same bug is present and fix it. I'd consider the "new []" stuff bugs, even though they might present no symptoms. The SDL resource leaks--I am definitely interested in that, because it might still be in 2.0 code. If you find problems affecting portability, that is interesting too, but remember we have DROD 1.6 and 2.0 running on Linux. The code checked into SourceForge CVS right now will build on Linux--Trick used it to make several releases.

So I would say that if it is not too difficult, then kick us a list as you are working on stuff. And we will look and see if the problem is in 2.0. And actually, you already did send us this next thing...

I'll also attach a .tgz of my current code, in case someone has enough curiosity & bravery to look at it.

...and that is good, but I feel that it is fairly difficult to judge what in the archive is going to translate to useful changes. That's why it may be better to just summarize changes as you go. On the other hand, I know that is asking a lot for not much in return, and you might also choose to just Lone Wolf it.

Hmm. I should really request something more specific, given that you've already taken the time to explain a lot of what you've done in general. Here are two things I would definitely like to know:
- Where were the changes related to resource leaks in SDL?
- Which modules had "new []" without "delete []"?

And let's just say that the rest of what you described, while it may be good work and valuable for what you are doing, is harder for me to find a case for integrating it. I don't want this to seem too one-sided. Remember that you may always ask the Caravel team for help when you run into a problem and we will try to answer.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

Hello. I'm the Resident Penguin around here (think "Resident Evil", but with penguins in stead of zombies).

Basically, what Erik said. Also, he's right that g++'s delete[] only affects classes that need deconstruction, so that shouldn't cause any memory leaks for the basic types, but as he said we've been fixing those we could find and it would of course be a good thing to fix any remaining ones as well.

Anyway, thought I'd drop by to tell you how I build the thing in case you haven't figured that out already =). From the top source directory, cd to Master/Linux and type make. That should give you all the info you need. Basically, for the releases, I just do a "make rel" (well, actually it's a little bit more involved since we want maximum binary compatibility, but that's nothing you should need to worry about for the Xbox port). Also have a look at the Config file there.

Good luck with your project!

- Gerry

bdcribbs
Level: Smiter
Rank Points: 390
Registered: 04-08-2003
IP: Logged

I'm really sorry if I come off as a jerk in this post, but I'm trying to be helpful, really. You always always always must check for error on any system call. Always. There is no legitimate reason not to do so.

That's my two cents. And please don't take that as a criticism, I've poked around the code a good deal and everyone who has contributed is obviuosly a skilled programmer.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

bdcribbs wrote:
I'm really sorry if I come off as a jerk in this post, but I'm trying to be helpful, really. You always always always must check for error on any system call. Always. There is no legitimate reason not to do so.

Bryan, what is this in reply to? I only see one post of yours up at the top and it doesn't seem related.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

bdcribbs
Level: Smiter
Rank Points: 390
Registered: 04-08-2003
IP: Logged

ErikH2000 wrote:
Since I began coding DROD, I've dropped the practice of checking small memory allocations.

I was sparked when I read this. There's also a recent crash I reported on the beta board which was caused by not checking an alloc. I'm sort of sorry for making the post here, but I stand by my conviction. I used to be lazy checking things that were unlikely to fail (or if they failed the system was borked so who cares)... but over the last year I've been working on a project with someone who is very persnickity, and after a few of his derisive comments to my cvs commits, and also having to deal with weird bugs that can happen, I've joined his camp.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

Okay, in the spirit of good-natured debate...

What useful thing can you do below?

char *pBuf = malloc(50);
if (!pBuf) ...insert your code here...

Textbooks and guys that like to wear bowties say something like "free as much memory as possible, complete any important tasks, and exit gracefully." If your app crashes, presumably from an access violation someplace, the O/S will free all memory associated with the process for you. Completing important tasks? Well, we are in no position to attempt anything ambitious like committing outstanding database writes when we can't allocate a measely 50 bytes. For DROD, this would be the only thing worth doing before the exit, but in fact, we are more likely to corrupt data if we try that. Exit gracefully? Whether an access violation or seg fault message appears before the app exits or not, well, it's just splitting hairs about what is a graceful exit. You can try to display your own "friendly" message when a small alloc fails, but be ready for more low mem failures and access violations.

In other words, don't be fiddling while Rome burns. Your app is about to crash one way or another, and maybe your O/S too. I would trap for failure of malloc(10000), because things can still be done in response to that failure.

And honestly, with virtual memory, it is about impossible to get new/malloc() to fail unless your process's heap management is corrupted. I wrote a program to try it once. All I got was these crazy 5 minute pauses while Windows mapped a giant file to fulfill the request. I'm not a Linux expert, but I imagine it is the same thing over there. This is why I said "modern O/Ss" in the previous post.

-Erik


[Edited by ErikH2000 at Local Time:12-12-2004 at 11:07 PM]

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

bdcribbs
Level: Smiter
Rank Points: 390
Registered: 04-08-2003
IP: Logged

Well, I don't even own a bowtie but yeah, why not try to exit as gracefully as possible? But only if the memory is mission critical. It might be quite possible to hobble on without it. In the case of the recent crash I experienced, DROD was unable to get the memory to do a fade when exiting a room. Fine, so don't do the fade and continue on, maybe the OS will have more memory for you next time it's needed. I'll apologize a third time for that post, because you've done a great job on this game, it's just a pet peeve of mine.

Incidentally, and I'm really roaming off-topic here, I've been playing on laptop at home that consistently gets the "low memory" warning whenever I start-up DROD. (I'm not sure why, it's an admittedly old laptop, but it has 128 M of ram). While it is a bit slow at times, it's still a pleasant playing experience overall.

ErikH2000
Level: Legendary Smitemaster

Rank Points: 2794
Registered: 02-04-2003
IP: Logged

bdcribbs wrote:
Well, I don't even own a bowtie but yeah, why not try to exit as gracefully as possible?

Because handling the tiny possibility that the small alloc will fail and also leave your app in a state where graceful exit is possible won't be worth the code clutter.

But only if the memory is mission critical. It might be quite possible to hobble on without it. In the case of the recent crash I experienced, DROD was unable to get the memory to do a fade when exiting a room.

I'm not sure what that message is about. I doubt it had to do with a failure to alloc global heap memory. Maybe... well, I just don't know on that one. Mike might understand it better.

Fine, so don't do the fade and continue on, maybe the OS will have more memory for you next time it's needed. I'll apologize a third time for that post, because you've done a great job on this game, it's just a pet peeve of mine.

Sure, and I don't want to get all comp.lang.c.flamewar.die.bdcribbs on you either.

Incidentally, and I'm really roaming off-topic here, I've been playing on laptop at home that consistently gets the "low memory" warning whenever I start-up DROD. (I'm not sure why, it's an admittedly old laptop, but it has 128 M of ram). While it is a bit slow at times, it's still a pleasant playing experience overall.

It's complaining about a lack of physical memory. I think the values I put in there to bring up that message are set a little too high, but basically I wanted people to avoid blaming DROD for slowness (virtual mem thrashing) that could be avoided by closing other apps.

-Erik

____________________________
The Godkiller - Chapter 1 available now on Steam. It's a DROD-like puzzle adventure game.
dev journals | twitch stream | youtube archive (NSFW)

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

ErikH2000 wrote:

Incidentally, and I'm really roaming off-topic here, I've been playing on laptop at home that consistently gets the "low memory" warning whenever I start-up DROD. (I'm not sure why, it's an admittedly old laptop, but it has 128 M of ram). While it is a bit slow at times, it's still a pleasant playing experience overall.

It's complaining about a lack of physical memory. I think the values I put in there to bring up that message are set a little too high, but basically I wanted people to avoid blaming DROD for slowness (virtual mem thrashing) that could be avoided by closing other apps.

FYI, I doubled these values for JtRH because it tends to take up twice as much memory as AE (mostly due to the increased resolution).

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

ErikH2000 wrote:
In any case, it wouldn't be correct for our project to remove all of the "if (!p)" checks because the new operator with the VC's runtime library does return NULL for a memory alloc failure. If on some platforms, an exception is instead thrown, we also have a top-level try-catch.

There is, by the way, a way to change the behavior of Microsoft's supplied "new" functions with respect to throwing exceptions vs. returning NULL. It is described in:
http://support.microsoft.com/?kbid=167733
I'm not necessarily recommending this, although the benefit would be that a single error-handling mechanism can then be used across all compilers.

I'm not sure what the runtime library's behavior under g++ is. (It does seem to work, but perhaps it leaks or something.)

Yeah, I think it is mainly a problem with arrays of class instances where the destructor fails to call on each element, but I could be wrong.

Yes, that is definitely a problem when the elements have destructors. The cases that I found were (mostly?) arrays of BYTE, so that is probably not an issue in these particular cases. However, the C++ language still treats this use of "delete" to be a programmer error. The leak that I am thinking of might happen because "delete" knows the amount of memory that is occupied by the object being deleted (e.g., a single BYTE), and the rest of the array (beyond that first object that the pointer refers to) might not get marked as being available for subsequent allocations.

For example, there may be some reason under MSVC6 to prefer a precompiler macro to an inline function. (I don't think this is the case as I think about it now, though.) The naming conventions used seem to follow those used in MFC. This could just be sloppy thinking on my part.

We'd have to look at the cases, but honestly, our pickiness standards here might not be where yours are.

I certainly wouldn't want JtRH to get held up on account of my pickiness....

An additional thing that I did notice while looking at the code this weekend: there appear to be several identifiers and preprocessor macros that are used, and that begin with underscores. "__max" is one that I noticed, and I believe that there are some others that have names that are intended to match wide-character functions in Microsoft's runtime library. Use of these is nonstandard, because these identifiers are reserved for use by the compiler and standard library. "__max" could wind up being fairly insidious, because I think it is #defined. Any subsequent #include of a standard header could wind up in bizarre compiler errors if the header used it internally. I haven't tried to clean these up in my version of the code. It should be reasonably straightforward to do, though.

Hmm. I should really request something more specific, given that you've already taken the time to explain a lot of what you've done in general. Here are two things I would definitely like to know:
- Where were the changes related to resource leaks in SDL?
- Which modules had "new []" without "delete []"?

I tracked down most (if not all) of the places where I replaced "delete" with "delete[]". The line numbers given are approximate, but I would guess that this should be enough information to go on:

DbBase.cpp, 440
DbPlayers.cpp, 460
DbRooms.cpp, 243
DbRooms.cpp, 890
DbSavedGames.cpp, 235
DbSavedGames.cpp, 255
DbSavedGames.cpp, 265
DbSavedGames.cpp, 610

The SDL leaks occurred in TTF_OpenFontRW. It appears that there are 2 calls to this. On is in FrontEndLib/FontManager.cpp, the other is in DROD/DrodFontManager.cpp. I believe that the second parameter in these calls should be 1, to indicate that the library should automatically destroy the RWBuf provided in the first parameter.

And let's just say that the rest of what you described, while it may be good work and valuable for what you are doing, is harder for me to find a case for integrating it. I don't want this to seem too one-sided. Remember that you may always ask the Caravel team for help when you run into a problem and we will try to answer.

Understood. Even the issues that I did find are minor. I do have a few other comments & questions about the code, but I'll start a separate thread for them.

trick
Level: Legendary Smitemaster
Rank Points: 2580
Registered: 04-12-2003
IP: Logged

wmarkham wrote:
Yes, that is definitely a problem when the elements have destructors. The cases that I found were (mostly?) arrays of BYTE, so that is probably not an issue in these particular cases. However, the C++ language still treats this use of "delete" to be a programmer error. The leak that I am thinking of might happen because "delete" knows the amount of memory that is occupied by the object being deleted (e.g., a single BYTE), and the rest of the array (beyond that first object that the pointer refers to) might not get marked as being available for subsequent allocations.

I don't think that will be a problem (new[] just allocates one big chunk of memory in that case anyway), but if new/new[]/delete/delete[] is overloaded, bad stuff might happen. They aren't, but it's still a good idea to fix these, of course.

An additional thing that I did notice while looking at the code this weekend: there appear to be several identifiers and preprocessor macros that are used, and that begin with underscores. "__max" is one that I noticed, and I believe that there are some others that have names that are intended to match wide-character functions in Microsoft's runtime library.

Yurgh. I'm fairly sure I went through the source and fixed those at one point, but it appears some have snuck (have snicken ? snake ?) back in

The SDL leaks occurred in TTF_OpenFontRW. It appears that there are 2 calls to this. On is in FrontEndLib/FontManager.cpp, the other is in DROD/DrodFontManager.cpp. I believe that the second parameter in these calls should be 1, to indicate that the library should automatically destroy the RWBuf provided in the first parameter.

Yeah, you're right. Good catch.

- Gerry

mrimer
Level: Legendary Smitemaster

Rank Points: 5056
Registered: 02-04-2003
IP: Logged

wmarkham wrote:
I tracked down most (if not all) of the places where I replaced "delete" with "delete[]". The line numbers given are approximate, but I would guess that this should be enough information to go on:

DbBase.cpp, 440
DbPlayers.cpp, 460
DbRooms.cpp, 243
DbRooms.cpp, 890
DbSavedGames.cpp, 235
DbSavedGames.cpp, 255
DbSavedGames.cpp, 265
DbSavedGames.cpp, 610

The SDL leaks occurred in TTF_OpenFontRW. It appears that there are 2 calls to this. On is in FrontEndLib/FontManager.cpp, the other is in DROD/DrodFontManager.cpp. I believe that the second parameter in these calls should be 1, to indicate that the library should automatically destroy the RWBuf provided in the first parameter.

Thanks for reporting these. They are mostly memory leaks that occur during import/export, and it is nice to have them fixed. I've made these changes in the DROD 1.6 codebase (and for JtRH as well, where applicable).

____________________________
Gandalf? Yes... That's what they used to call me.
Gandalf the Grey. That was my name.
I am Gandalf the White.
And I come back to you now at the turn of the tide.

wmarkham
Level: Master Delver

Rank Points: 125
Registered: 12-06-2004
IP: Logged

wmarkham wrote:
The PathMap, CDbPackedVars, and DbRooms files probably best show the sorts of changes that I have made.

Hmm. I didn't realize this until last night, but one of my demos no longer works. It must be something I did in CPathMap. I thought that I had tested it pretty thoroughly, but I guess not.