On Fri, 16 Nov 2007 23:04:51 +0000
James Urquhart <[EMAIL PROTECTED]> wrote:
>
> On 16 Nov 2007, at 11:01, G33K wrote:
>
> > On Fri, 16 Nov 2007 02:40:23 +0100, "Alban Bedel" <[EMAIL PROTECTED]>
> > said:
> >
> >> Icons must be separate objects. You wont be able to get around
> >> this one.
> >> Scumm was designed to run on hw with extremly limited memory and
> >> loading the whole game in memory was not pratical. Hence the engine
> >> load the rooms as needed and release them from memory when you
> >> leave them. But you can't practically open up to a dozen of rooms
> >> just for some icons. In the extreme case of a floppy version they
> >> might be on differents disk, and even on modern hw that would
> >> waste lot of ressources. What you should do instead is use a few
> >> rooms to store the
> >> objects (and scripts) you will need all the time and lock them in
> >> memory.
> >>
> >> Now I agree that having code related to the same objects split in
> >> several places is not so nice. The link could be the other way
> >> around,
> >> with the icon object reporting the real object it is linked to. But
> >> then the whole room would still need to be locked. Or with a
> >> separate script from the object's room. The script could then be
> >> locked without
> >> locking the whole room. It would be better but it would still
> >> mean the
> >> engine need to open many room at once when loading a game.
> >
> > But, for example, the way I'm doing it right now is to use icons
> > from the InventoryItems room. This room is never explicitly loaded
> > or locked,
> > but it still works, at least in ScummVM. If you call a verb on an
> > object
> > that's been picked up (e.g. the hand scanner the dude starts
> > with), you
> > get the desired response, even though it's in the unloaded
> > InventoryItems room. If you call a verb on an object that's not
> > yet been
> > picked up (i.e. the batteries), there's no response. Instead,
> > ScummVM will catch an error and output a debug message that the
> > code for the object is not in the room. So, I guess, you *can* use
> > objects that are not in a loaded room, as long as your ego owns
> > them. Dunno if this implicitly makes the entire room stay in
> > memory, though.
>
> I would be cautious relying on ScummVM behaviour, considering a lot
> of code in it consists of random hacks and workarounds for various
> different SCUMM games, rather than the original implementation which
> while still being a hack works as intended. :)
Indeed, I wouldn't be surprised if scummvm behave differently, in
particular with the memory management. Anyawy, my point was not that
you can't use object from many different rooms, but that it is
inefficient and the engine was not meant to work that way.
> Remember if you ever want to try out your SCUMM creation in the
> original interpreter, grab DOTT or SAMNMANX's interpreter executable
> and rename it to "scummc.exe". Then edit your Makefile adding "-key
> 0x69" to the parameters for the linker, SLD and recompile. Then run
> scummc.exe in dosbox (or equivalent).
Nice one, I always renamed my data file tentacle.00?, thanks for the
tip.
> (*sigh* sometimes i wish scvm actually worked)
:) The current "road blocker" is devising an algorithm to walk the
actors. Shouldn't be too hard but it's not trivial either.
> > I actually figured the reason that icons must be separate objects is
> > much more profane: the icon function setVerbObject( obj, room )
> > requires
> > you to know the room an object is in. However, there's neither a
> > function to retrieve this information from a given object, nor a
> > function to place objects in other rooms than the one they were
> > defined
> > in. Hence, all inventory items must be in one single room that you
> > know
> > in advance. I think if you find a solution for either one of these
> > functions, the problem would be solved.
>
> Looking more at Alban's function reference, you might be able to use
> the "setVerbImage( obj )" function provided your target image (or
> rather, object) is in the current room. Of course if it isn't, then
> you're out of luck. :(
>
> >
> >
> > Of course, there are other, more practical problems: inventory items
> > need special size pictures, and all the object state's pictures
> > must be
> > the same size. Also, as I noted before, I couldn't get different
> > inventory icons for different states, only the first is displayed.
> > But it still would be nice to at least define the inventory and
> > room version
> > side by side in one room, since they are related.
>
> Perhaps we need some additional syntax for this. I've been thinking
> about this, and i've come up with this rather silly idea.
>
> Instead of this:
>
> // In the resource room
> object axe {
> w = 40;
> h = 16;
> x = 0;
> name = "the axe";
> states = {
> { 0, 0, "inv_axe.bmp" }
> };
> state = 1;
> }
>
> // In the room....
> object axe {
> x = 320;
> y = 27;
> w = 16;
> h = 8;
> class = { Pickable };
> states = {
> { 0, 16, "axe.bmp",
> { "", "axe_mask2.bmp" } }
> };
> name = "the axe";
> dir = EAST;
>
> verb(int vrb,int objA,int objB) {
> ...
> }
> }
>
> How about a little "shortcut" like this?
>
> // In the room....
> object axe {
> x = 320;
> y = 27;
> w = 16;
> h = 8;
> class = { Pickable };
> states = {
> { 0, 16, "axe.bmp",
> { "", "axe_mask2.bmp" } }
> };
> name = "the axe";
> inventory = { // perhaps also accessible via
> axe.inventory if needs be?
> // Normal object definition (except x,y are by
> default 0)... w = 40;
> h = 16;
> // name inherited from parent?
> states = { // still need states, though perhaps a
> shortcut like " icon = "inv_axe.bmp"; " could be used for simple
> inventory items? { 0, 0, "inv_axe.bmp" }
> };
> state = 1;
> } @ ResRoom; // which room to place the inventory object icon
> dir = EAST;
>
> verb(int vrb,int objA,int objB) {
> ...
> }
> }
>
> Which is more or less the same, except it's consolidated into one
> object. Though i'm not sure how easy it would be to make the
> compiler accept this sort of input...
Such syntax sugar is definitly possible, however I really doubt it's
worth it.
> >
> >>> Much worse is that you seemingly need to wrap actors in objects to
> >>> define verbs on them, and to have objects point to actors in
> >>> order to
> >>> get an animation, or even just a transparent background and
> >>> z-ordering!
> >>
> >> I think I don't get what you mean exactly. I used objects to hold
> >> the actor code because it allowed to handle actors much like the
> >> normal objects. You can defintly look at some other way to do this.
> >>
> >
> > Yes? That'd be cool! How does it work? There's no actor definition
> > mentioned in the ScummC grammar section, so I thought they can only
> > be globally defined variables without a code body, like the verbs.
> > How can
> > I, for example, define a verb script on an actor, e.g. LookAt or
> > TalkTo,
> > without using an extra object?
>
> I have to say this has confused me a bit also. Any further
> explanation of this would be appreciated, Alban. :)
You got the right picture, the engine doesn't provide anything to have
code attached to actors. This must be implemented by the scripts, you
don't have to use objects, you can use scripts only if you prefer.
> >
> >> Now for the animations I really don't get what you mean. Just add
> >> some
> >> custom animations to your costume if you need the actor to do other
> >> things than walking or standing there.
> >>
> >
> > I wanted animations for the objects, not the actors. Think animated
> > backgrounds, like the rotating blue cup. Can you do that without a
> > costume, just with object states, for example?
>
> I would imagine yes, though remember that you will have to manually
> change the state in script - which i would imagine is *much* slower
> than just using a costume (especially on SCUMM-era hardware).
>
> (IMO a rotating blue cup being a costume sounds like a better idea
> to me)
Definitly, it's how it should be done. I really don't see what is the
pb with using a costume.
You can also use palette cycles. That's not easy to use for large
things, but for small stuff like blinking leds, etc it can be quiet
usefull.
> >
> >
> >
> >
> >> z-ordering is not very intuitive. Here is how it work: each box
> >> belong
> >> to a layer, when an actor is in a box the mask from the
> >> corresponding layer (and only this layer) is used when drawing.
> >>
> >
> > Uh, thanks for your pictures, but that's not what I meant, sorry.
> > The z-planes mask only the actor. I want the object itself to have a
> > transparent background, so that it can be placed at more than one
> > location. I'd also like the actors to be able to walk in front of
> > it and
> > behind it, without having to draw masks and without knowing the
> > exact location in advance.
> >
> > That's the way it works with actors. They have a transparent
> > background,
> > so you can place them just anywhere on the screen. They also have
> > z-ordering without using masks and boxes, so when one walks in
> > front of
> > the other, he gets drawn on top. Can you achieve that without a
> > costume,
> > just with object definitions?
>
>
> I'm not 100% sure on this so i think i'll let Alban elaborate more. :)
You can't do this, it doesn't make sense anyway because you can't move
the objects.
> > One last thing: do you know how I can enable debugging statements in
> > ScummVM? There were some printout commands in the Road example, but
> > I never saw the output.
>
> I looked for this a while ago, but i never found any explicit code
> which dumps the debug output.
>
> I would suggest entering the debug mode in the original interpreter
> instead as that is really the only fully implemented SCUMM debugging
> solution out there ATM.
> (Sadly i forgot how exactly one is meant to enter and use the
> debugger, perhaps Alban knows?)
-b, --boot-param=NUM Pass number to the boot script (boot param)
-d, --debuglevel=NUM Set debug verbosity level
Albeu
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
