It’s time for another status update.
Since my last progress update, I’ve been busy. First with work: End of the semester and such. Not much time for anything else. After that, I went to the south of Sweden for a week to play and learn more about Jazz and World Music. (Yes, that’s me in the picture with a cornet in hand, trying some livelooping.) Great fun, and inspiring. (Some sound clips from the course are also available at the site I linked to, in case you’re curious. It’s me trying an improvised cornet solo in the middle of the Arabian 7/8, and playing the bassoon in the Tango.)
But now I onec again have time for a bit of programming, and am making progress. I’ve been reading the Cocoa programming book by Aaron Hillegass that I mentioned in an earlier post. It’s really good, and I understand why it’s recommended as “the book” to read for people who want to learn Mac programming. As a result, I’m starting to grasp how Mac programming works, and I’ve added an options window for Sludge. I also find Mac GUI programming so enjoyable that the thought of porting the development kit too, and not just the engine, is looking more and more appealing. The idea of maintaining the Windows port is at the same time becoming less appealing, so I’m hoping that someone else will show interest in that department, but if that doesn’t happen I won’t let the Windows port fall behind (much) either.
I’m still waiting for Tim Furnish to add me as a developer at Sludge’s SourceForge site (he said that he would, when he found his password), so that I’ll be able to upload the things I’ve done with the engine.
I may also become sidetracked one weekend. I visited a site related to Allegro (the game development library I used to make Rocket Duel), and learned that there’ll be a new speedhack coming soon. Speedhack is an Allegro programming competition run over three days (starting July 10th), and I’ve registered intent to participate. It might be fun. (The rules aren’t completely known until it has started, but I’m hoping that it’ll be fun, and a bit challenging.)
Hello, I’m working on a port of SLUDGE as a ScummVM Engine Plugin. I was wondering if you could send me the code you have so far, so I could take a look at it and possibly implement some of it into my project. You can email me at charlie AT muspell DOT org.
thanks in advanced,
Charlie Wolf
Hi,
Interesting to hear (although I admit that I don’t understand what you just said). The code I’ve written should hopefully be available shortly. I’m mostly just waiting for access to SourceForge.
Well, assuming you know what ScummVM is (it lets you play LucasArts SCUMM games on an absurd amount of platforms)…
ScummVM now has an architecture where it supports “engine plugins”, so it can run games from Non-Scumm Engines, like AGI and some other proprietary engines.
If SLUDGE could be ported to the ScummVM API, then SLUDGE games could run on Windows, Mac, Linux, iPhone, etc, through ScummVM..
thanks
Charlie
I have heard about ScummVM, yes (and used it to play old games), but I don’t know anything else about it. Is this ScummVM API compatible with current and future SLUDGE then? I don’t know what ScummVM looks like internally, but it’s aimed at old games, and SLUDGE is an actively maintained and evolving engine.
Currently released SLUDGE games use 16-bit graphics, and play (among other formats) MO3 music (ogg vorbis-compressed IT). The upcoming SLUDGE 2.0 will support alpha channels and 32-bit graphics (“my” engine already does that internally – I’ll just have to add the support to the development kit too). Maybe it’s a stupid question to ask, but I don’t want to hold SLUDGE back in order for it to run in ScummVM.
P.S. Are you making a SLUDGE game (nice to meet a new SLUDGE game maker if you are!), or are you just doing this to be able to play Out of Order on additional platforms?
What I was thinking would be that as the development kit was updated, the engine plugin would be too. The advantages of using ScummVM would be that the core runs on a LOT of platforms, and since it uses SDL and other open source technologies with an abstraction layer, once SLUDGE is sending its graphics, sounds, etc, TO scummvm instead of directly to Windows or Mac. Also, who is working on SLUDGE 2.0?
As for me, I programmed with SLUDGE a lot years ago but switched to Wintermute for my game because of various problems i was having with the SLUDGE engine and Development Kit. Now that it’s open source, however, I want to switch back to SLUDGE, and its very important that any game I make, and other SLUDGE developers make, are not limited by user’s computers.
What I’m going to do is in terms of ScummVM is either–
A) Make a plugin for ScummVM. The advantage to this is you will ALSO be able to play SCUMM and other games from the same program. The disadvantage is, since I’m not on the ScummVM Team, I would have to release my compiled SLUDGE versions or code separately. Thus, if there was a bug in, say, the AGI interpreter in ScummVM, I would have to update that in my program to, and would really be maintaining like 20 engines.
B) The idea I’m leaning towards is making an engine based on ScummVM code called SludgeVM. It would still use the abstraction layer from ScummVM, and all that, but would be geared to JUST playing SLUDGE games. The SCUMM engine might be included because it is so stable, and could be used to test the VM with an already-stable engine plugin. Basically, it’s SlLUDGE using an abstraction layer that works on a LOT more platforms, including mobile ones.
Which do you think I should do?
Thanks
Charlie
SLUDGE is probably unsuited for ScummVM:
1) ScummVM currently only support CLUT8 color modes. There’s ongoing work to add 16bit support during the current Google Summer of Code (coming along nicely). 24/32 bit mode would require a massive rewrite of most of the graphics code though, including the complex scalers.
2) ScummVM does not yet support IT music. There’s Protracker and some custom Amiga music, the Paula class could be templated to have more channels and I know a bit about the IT format. Still, it would be a lot of work. And we don’t really want to depend too much on libraries (because we’re highly portable), so using an external library for that is probably out of the question.
3) One person doing the ScummVM integrating while another keeps working on his branch outside ScummVM is totally inefficient. You’d really need to join the team and continue development inside ScummVM. ScummVM is not really an API, but abstracted common code + engines and the common code is not set in stone, but has had many changes that would make engines outside the project’s codebase unusable.
4) Yes, ScummVM is mostly aimed at old games. Their might me some people in the team against integration. Maybe also because you seem to want to make money with your SDK. A discussion whether we as a whole actually want that engine in our project would be necessary.
Anyway, IMHO, all these issues would have to be resolved first before any work in that direction makes any sense.
I for one would welcome a general purpose engine (though I’d rather have one without the monetizing aspect), but I can’t claim to speak for the whole team.
Ah, and another thing, one that also holds true for Charlie R. Wolf’s proposals:
The license. Having a quick look through your site, I couldn’t find under which license the engine is released. ScummVM is released under the terms of the GPL, so your engine would absolutely also be licensed as GPL code.
Any release of ScummVM with your engine added but without a complete source release (including all the changes you made, of course), violates the GPL.
“Also, who is working on SLUDGE 2.0?”
Right now, it’s only me, and I’m not an official SLUDGE developer yet, so it’s not official, but SLUDGE 2.0 is being worked on. I call it 2.0, since there are pretty large changes being made. (I’ll start a proper discussion on this once I’m an official SLUDGE developer. It’s still too early for that. Keep an eye on this blog or the forum at Adventuredevelopers.com.)
You didn’t answer my question: (I don’t mean to sound rude, but I don’t know how deeply you’ve looked into this.) Are you sure ScummVM can handle SLUDGE? I searched the ScummVM forum a bit, and I read that it only supports games with 256 colour graphics. If that’s true, it won’t even be able to handle current SLUDGE games, and future ones will be even further off.
I suspect the music might be a problem, too.
Hi DrMcCoy and welcome! You’re a ScummVM developer, I take it?
(My previous post was written before I found your posts in the moderation queue.)
This confirms what I suspected: That ScummVM isn’t a good fit for SLUDGE, despite the coolness factor such an integration would add.
A clarification, though: Nobody is making money on SLUDGE. While it started out as shareware, it’s now both freeware and open source.
—
Charlie: What OS are you on? (And what’s your programming experience?) Maybe you’d be interested in helping working on SLUDGE outside of ScummVM instead?
Rikard–
I am on Windows at the moment with access to Linux and limited access to a Mac. I would be interested in helping work on SLUDGE outside of ScummVM, because I’m starting to realize graphics are going to be hell to port.
Another way one could approach this project is to, essentially, rewrite the graphics and audio code using SDL and SDL_mixer, virtual machine style. Essentially, we have, say, vm_windows.cpp that does all the graphics/sound/stuff on windows, vm_mac.cpp, vm_linux.cpp, vm_iphone-arm.cpp, etc… Then, you could have people working on the engine and people working on the VM separately. So people could add features to the engine without worrying about porting, and people could port the VM without worrying about having to port every single feature in the engine.
What would be a good way to contact you to talk about this? I suspect phone is out of the question, calls from California to Sweden seem like they would be expensive.
Do you have Skype or AIM? While I was writing this, Skype just logged in, which is strange as I have been trying to get it to work for the past two hours to no avail.
Thanks
Charlie
That’s good. As I mentioned in my initial post, I’d appreciate it if someone else were to maintain the Windows port.
The version on my computer uses SDL+OpenGL for the graphics (a change I’ve made) and BASS for sound (same as the official version). It runs really well on my MacBook (there are only a few small things missing – all released games run) and consists mostly of portable code. After all, it started on Windows, and I’ve been working on it on a Mac while trying not to break it for Windows. OS specific stuff is mostly separated from the rest of the code. It will need a little work to get running on Windows again, but it should be mostly straightforward. You’ll get to see it as soon as I’m able to upload it to SourceForge. (I think sending sources around outside of the SVN is asking for trouble, so it’s probably best to wait for Tim Furnish to add me as a developer to the project.)
Yes, I do have Skype (username Trumgottist), and you’re welcome to contact me there. (But right now it’s getting a bit late, so I’m not logged in tonight. I’ll soon be heading for bed.)