What are we working on?

[Collector]

MI, have you considered using SEQs?

[Kawa]

<sarcasm> I consider using SEQs often. </sarcasm>

*sobs quietly in the corner*

[lskovlun]

Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?

Remember that the interpreter cycles in SCI1.1 are not tied to the system clock (unlike in SCI0). The palette cycling effect, on the other hand, is. So your doit: needs to detect how much time has actually passed. GetTime without any arguments will tell you this. The first time you call palANIMATE, use GetTime to figure out the current time in ticks. Then wait until the desired time (by calling GetTime in your doit: to see if the time is right).
GetTime only gives you the low 16 bits of what is internally a 32-bit value, so you'll need to handle the case where it wraps (which it does every 18 minutes; be sure to test this case when you're done coding).

EDIT: Of course, SCI keeps track of active palette cycles, so just call palANIMATE on every cycle, as you usually do. I was referring to the change of direction in the above.

[MusicallyInspired]

Gotta make it hard on yourself, huh?

he says while contemplating rewriting the cel renderer from ASM back to plain C

If I want the outcome I'm envisioning, it's gotta be the hard way. Plus, part of my motivation is that I just really want to open up the possibilities of what colour palette cycling can do. I don't want to just use this on little sprites. Like I said, I want fullscreen impressive visuals. I'm envisioning things like walking form one side of the room to the other with not only the lightsaber glowing, but the walls where the EGO is near glowing as well. I'm not sure how much of that is possible, but if I can think outside the box enough, it's a fun exercise to see if it's possible.

MI, have you considered using SEQs?

Nope. Not near smooth enough.

Ok, I need help. No matter how I code this the shimmering colour cycling effect keeps going out of sync. Can somebody take a look at this and tell me what I'm doing wrong?

Remember that the interpreter cycles in SCI1.1 are not tied to the system clock (unlike in SCI0). The palette cycling effect, on the other hand, is. So your doit: needs to detect how much time has actually passed. GetTime without any arguments will tell you this. The first time you call palANIMATE, use GetTime to figure out the current time in ticks. Then wait until the desired time (by calling GetTime in your doit: to see if the time is right).
GetTime only gives you the low 16 bits of what is internally a 32-bit value, so you'll need to handle the case where it wraps (which it does every 18 minutes; be sure to test this case when you're done coding).

EDIT: Of course, SCI keeps track of active palette cycles, so just call palANIMATE on every cycle, as you usually do. I was referring to the change of direction in the above.

I'm struggling to understand how to code this. Do I wrap the first instance of the palANIMATE and ++CyclePos with a GetTime checking case? This is starting to hurt my brain...I don't do this enough lol.

EDIT: So far the ticks are wildly inconsistent. It doesn't look like I'm going to be able to iterate every tick because each time my code checks the number of ticks it's a lot more than one tick apart. Like, it goes from 68 to 2000 or something. I'm wondering, should I have only one instance of palANIMATE instead of a whole bunch and just let the variables change in each case instead of calling it each time?

[Kawa]

Nope. Not near smooth enough.

Y'know SEQs play at whatever speed you tell them to, right? CPU limits notwithstanding...

[MusicallyInspired]

Ok, fine. Not near as much control as I could have with palette cycling. I want things changing in real-time like while the ego is moving around, not just a cinematic sequence.

[Kawa]

...yeah I don't think that's gonna be worth the considerable effort.

[MusicallyInspired]

Your opinion.

[Kawa]

That it is.

[MusicallyInspired]

If I can regulate it all down to a public procedure or two it won't be that much work at all after the heavy lifting is done. It's about as "worthless" as the dynamic iMUSE music in Monkey Island 2's Woodtick section. Yeah, they stopped doing it after that, but it was an incredibly awesome feat and I don't have the limitations of a deadline or a budget like they did.

[lskovlun]

This seems to work. It's not exactly what I wrote above, but it works. I would agree with the others in the simple case of a light sabre that a view (not a SEQ) would work better. But you wrote that you wanted to do larger scenes, in which case something like this is justified.

This doesn't work in ScummVM. I think the many calls to GetTime trigger ScummVM's speed throttler which is ironic, because the aim of the added code is to be a kind of speed throttler.

Another thing, the number of views on the screen will almost certainly have an effect on timing jitter. In this case, there are none, but I assume you intend to add some.

EDIT: Oh, and proper wraparound handling is not implemented.

[MusicallyInspired]

Another thing, the number of views on the screen will almost certainly have an effect on timing jitter. In this case, there are none, but I assume you intend to add some.

DANG IT. Hmmm...does PalVary, palSET_INTENSITY or any other palette functions work the same way as palANIMATE by not being beholden to game ticks? It would be a HECK of a lot more complicated, but what conceivably would be the odds of recreating an entirely new palANIMATE function that worked by ticks instead of cycles?

Thank you for working out that code, by the way. I appreciate that.

[lskovlun]

You can always test it first, to see if you get the performance you need with the number and size of views you plan to have.  Use stopUpd and startUpd as much as possible to minimize the impact of the views that aren't doing anything at the moment. PalVary is another option, but it requires a palette resource and you might end up having to do the same thing I'm doing here for the change of direction. SCI32 would have a couple of additional options, and planes are nice for big scenes... Phil?

I had to remove the debug code, because waiting for the user to dismiss the dialog box takes a few ticks, so it does matter - but that was before I got the code right. It went through a couple of iterations.

[Kawa]

For fun, I added Dating Pool support to ScummVM.

For boredom, I cut it down from 11.7 MB, with the only enabled engine being SCI and no SCI32 support, to 5.4 MB. Right now, after another round of shaving, it's at 4.3 MB. I don't think I can get it any smaller than this without doing intricate things like removing SCI0 support or messing with the theme engine.

[Nicktatorship]

So aside from working out what I want to do, I started poking around with python/SDL2 two nights ago, and made some babysteps on a reader of the Picture format. Not sure why I'm doing it, other than to stretch some old mental muscles, but it's.. alright? Top is the original, and bottom is what the prototype can do.



Most of what it does is create a list of draw commands (as a class) and populates the details of each command. Only the regular lines are drawn currently, which was to verify I had the right structure. In this case the draw is multiplying coordinates rather than mapping to 160x200 and doubling up from there.

It's not much, but it's kinda on this level.

And here's how all that is looking now. Had a friend advise using PIL to handle images, instead of working direct with SDL so I did that, and gradually added code to handle the different draw actions. It probably diverges in places and isn't *quite* finished but it's getting there. I also split out the reader/imager for AGI pics to a class of its own, so I can very neatly call the shambles from other code that is still neat.

The one little bit of different, is that I *also* made it able to spit out a control-lines only image.

Here's the three it can do:





It's a bit hacky in the picture class, and would like to make it better in time. Also still need to write the pen/plot tools, and give it the means to generate a picture file back out (from the stored commands on the class in python, *not* from other images).

Still don't know what I'll do with it after this. I doubt I have it in me to write a full-blown AGI interpreter, but I'd like to take this somewhere too. It's certainly been giving me a lot of ideas.