If you want a system that fulfills all your requirements, write for AGI.

AGI is available for a LOT of platforms (even more than scummvm), and runs 'classic' Sierra games very well, and there IS a creation system compiling to it! ;)

For more information, see The Ultimate AGI & SCI Web Site at http://agisci.cjb.net/)

But I can understand if you don't want to, because AGI sucks. O.K., "sucks" is a bit harsh, and not everything AGI is inherently bad (ah, the fun we had), let's just say AGI is very "limiting". (16-color 160x200 pixel, parser,...)

If you want an Open Source system, another option might be MAD at http://mad-project.sourceforge.net/)

However, I don't know how well-developed or not it is. And the only thing that it has in common with LucasArts adventures is that it uses LUA (like GrimE). And I'm not aware of any game written with it at the moment.

Besides AGI, AGS seems to have the only community producing games at the moment. Hmmm, maybe someone should talk Chris Jones into (or offer to) port AGS to Linux and/or MacOS...

But I'm degressing... And now I forgot what my point was, initially. :(

Howdy, I'm new
...
Uh, well, after this exciting bit of news, to the point: I've done a bit of Textadventure (IF) creating (hope that's not a big no-no over here :-), and being somewhat adept at drawing, decided to look into creating a graphic adventure.

It's a lot better than a couple of years ago, with at least a couple of toolsets mature enough to make finishing a creation possible. BUT I believe that the best system to create for would be scumm(vm) as I argue here:
http://sourceforge.net/forum/forum.php?thread_id=708792&forum_id=115756)

This post lead me to Scummbag, and you can put me on the list of enthusiasts who can('t) wait for it!!! And it lead me to this forum...

I'm thinking of creating resources first, for a small game, and implement them once ScummBag becomes available. I think most other tools can handle higher-spec stuff than the scummengine (if that should become necessary)

SO the bottomline are the scumm specs for graphics,

Here are my questions: (no, not Is it done yet? :-)

- short: where can I find that information (I've tried scummrev a bit, and googled around, but it's all, uh, over the place)

- long: All I know is that scumm runs at 320x200 with 256 colors (Indy4 style)

- what's the max. background size?
- what's the max. spritesize (and # of frames)
- what are the palette limitations? i.e.
one palette for the game?
one palette for each scene?
one palette (or part of the palette) just for sprites?

TIA for any help,

and I'll try to keep future posts shorter ;-)

First of all, I'm not working on ScummIDE at the moment - as usual, I'm way too busy with other stuff. And contrary to what khalek may believe, it won't be done this year. If ever. However, I don't doubt that sometime in the future, either I or someone else will do a compiler, bundler etc. SCUMM is getting too popular to imagine that noone will try :) But right now, it won't be me. Maybe in the Winter, maybe next year, maybe the year after. Or probably, someone will decide he can't wait, and do it himself :)

As for the graphics specs... It's really a question to ask the SCUMMVM team more than me (but then, at least Endy frequents this board). I haven't studied the graphics limitations at all. I would assume that the width of the background is only limited by memory (since the resource block is loaded into memory, but only the part visible on screen (plus, as far as I recall, 8 pixels extra on each side for scrolling) is actually rendered). Also remember that while the old games are 320x200x8bit, CMI is 640x480x8bit... ScummIDE was at first going to focus on doing games for the CMI SPUTM engine.

As for palettes, each room has its own palette, the costumes use a lookup table to setup which colours in that palette to use for drawing the costumes - so, not a completely new palette for sprites (since the room already uses all 256 palette items available), but merely part of the room palette.

Now that the date seems to be working normally again, perhaps I should bump this thread back to the top.

hey I said _hopefully_ not will be :)
sounds like that may have been a little too optimistic though