Today's top billing goes to L'aigle. The bald guy. I decided to make him buff to compensate. And no, he isn't gay. At least I don't think he is, but who knows?.
.
In unrelated news, there is a teensy weensy possibility of big, big news coming soon. Big as in "oh no, not another major delay" "yes, but it will be worth it" "yawn, that's what you always say." Remember yesterday I bemoaned the surprisingly enormous memory requirement? Well I got my junior detective kit out and ferreted around to find out more, and SHOCK HORROR! SLUDGE LEAKES MEMORY BIG TIME! Possibly. I'm hoping to find out if I am wrong (I hope I am) but if I'm right, this has major, MAJOR implications. So major that I may be compelled to write WHOLE SENTENCES IN CAPITALS. Here it comes...
.
A memory leak is where a programn asks for memory then doesn't release it. So what, you say? So the longer you use a program, the more memory it needs. So your computer slows down, slower and slower, until nothing else can run and the hard disk is going crazy trying to make up for the lack of RAM and everything grinds to a halt. So memory leaks are BAD. Very bad. Now for the details:
.
Remember how I had a month of "fun" creating crowds, and couldn't do it the easy way because of memory leaks. I had heard that if you load lots of sprites using "spawn sub" (the method of making two characters do stuff at the same time) then there was an issue with memory leaks. I plan for my game to be very large eventually, so even a small memory leak would be disastrous. if you visit a thousand rooms and lose a megabyte of memory in each one, pretty soon the game stops working and your computer freezes, unable to supply any more memory. So because of that I used an awkward compromise to avoid spawn sub. Well it apears that the problem is not with spawn sub. the problem (IF I am right and I hope I am wrong) is with costumes. When a costume is loaded it is never removed from memory! A costume means any graphic used by a sprite. The problem was first noticed in spawn sub by another developer who tried making a game that loaded hundreds of tiny costumes at the same time. He thought the problem was spawn sub. But I think the problem is really with costumes not getting deleted.
.
It gets worse... in order to avoid spawn sub, I had crowds that don't do anything, but only APPEAR to so stuff. That is, they stand still, filling the whole screen. with a costume that looks like someone walking from one side to the other. Since they just stand there (from SLUDGE's point of view) then spawn sub was not needed. But filling the whole screen had an unexpected side effect: these animations are tiny on the disk (they are basically all transparent with just a couple of tiny people), but when loaded into memory they are uncompressed, and every pixel, EVEN THE TRANSPARENT ONES, takes up space. So imagine an animation where one tiny person walks from one corner of the screen to the diagonally opposite corner. It might take a thousand frames. Each frame has a tiny character, so all the frames will take up less than 100 kB on the disk. No big deal. But the animation must cover enough pixels to cover diagonally oposite corners, in other words every pixel on the screen is represented (mostly by transparent pixels). So when these giant frames are fully uncompressed the 1 kilobyte tiny picture can easily take up one megabyte. A single 100 ILObyte animation can easily expand to 100 MEGAbytes. Add the memory leak, and every time you visit a room with a new crowd animation, the memory requirement of the game jumps by another 100 MB! Pretty soon the game is asking for 300MB... 400MB... 500MB... Eeek!
.
Clearly this is unacceptable! Not to mention embarassing. So where do we go from here? Solution 1: find a way to remove costumes from memory. That still leaves us with some scenes needing 100 MB, but that's not too bad for a game - most computers for the last ten years have had 256 MB memory, enoughfor Windows plus a game. But if I can't find a way round this memory leak, then we have to go to.... Solution 2: ditch Sludge. That's right. Completely abandon the game engine I've learned to love over the past four or five years. Port everything to some other engine, one that's carefully chosen to avoid these problems.
.
What would happen if I had to port to another engine? First the bad news. Another delay. Remmeber how changing the graphics added three months to the schedule? It would probably be a delay of the same magnitude. The actual business of changing code would probably only take a month - the graphics could all be converted without being redrawn, and the logic of the code wouldn't change. But let's face it, there would be a learning curve. And no doubt the next engine would have its own quirks, so things that run smoothly in Sludge may have to change. Just thinking aloud here. That's the bad news. (And remember, this is all hypothetical, I only identified the memory leak an hour ago.) Now for the good news.
.
If I had to port to another engine, then I would be free to learn from experience and maybe find features that are lacking so far. If I can find one that works in a different way (we're talking those infernal crowds again) then maybe we could get the whole game working in much less RAM: theoretically the whole thing should run in 100 MB RAM, and possibly a lot less. Heck, the entire game compresses to 50 MB for downloading, so everything else depends on how the game engine works. Another benefit is I could maybe find an engine that runs natively in Linux or on the Mac. I know that Windows dominates the market, but I would really like to apeal to other users if I can. Sludge is good because it emulates well, but that stil requires an emulator. Native is better. Another possibility (since I'm basically dreaming up my unrealistic wish list here) is for tools that allow for faster development. The crowds were a good example of a bottleneck. I really wanted to just add people to walk around at random, but that was not possible. If a new tool allowed for that kind of thing then that would save so much time. But that probably is pie in the sky.
.
Enough rambling. That's the news for today. More tomorrow!

2 comments:
I guess that's the price for using a game engine which is no longer developed/supported. On the other hand, this issue doesn't seem to be hard to fix, as long as the engine developer is willing to take the time to do so. So unless you're ready to leave Sludge, keep pushing the developer.
Good luck finding a cross-platform engine, by the way. AGS is multi-platform in theory, but you'll find the Linux/Mac ports aren't maintained by the AGS developer, but by 3rd parties, which means, well, they're not that much maintained/supported in reality. The closest to cross-platform is probably Lassie, but I'm afraid it's not yet ready for a huge project like yours (although I think your new minimalistic approach would benefit from Lassie's vector graphics support).
Thanks for the comment. yes, I've just spent the morning exploring the cross platform elements of AGS. You are exactly right, they are not as good as they seem. But on the other hand, I looked back on SLUDGE's cross platform support and it isn't so hot either. Basically, both engines rely on emulators for the Mac, though there is a fighting chance that the Mac AGS port maybe will be improved one day. And AGS is slightly stronger on Linux. As you say, the real issue is that Sludge is no longer actively supported. I didn't think that mattered, because Sludge is fundamentally a leaner and simpler tool than its competitors. But the sudden appearance of the memory issue has forced me to reconsider. Even if it is fixed, what if something else is found ten years down the road?
.
Lassie sounds very tempting. Though as you say there are scale issues. And it sounds like another one man outfit, so there are the same issues with support ten years later. If I don't hear something very reassuring from Tim in the next 24 hours then AGS it is.
Post a Comment