Picture Editor written in Java

[lance.ewing]

Hi all,

You may or may not be aware that I recently released a Java version of my PICEDIT AGI picture editing tool. I posted about it in the AGI tools forum:

http://sciprogramming.com/community/index.php/topic,365.0.html

The reason I have raised the topic again here is that as I was writing the tool, I thought to myself that it wouldn't take much to make it support SCI0 pictures as well. Would that be something that people in the SCI community would be interested in?

I guess support for SCI0 could range anywhere from an import/export from/to SCI0 pictures...   all the way up to supporting full editing of SCI0 pictures.

[MusicallyInspired]

That would be pretty neat actually. It'd be nice to have an actively developed SCI0 picture editor that we could make suggestions for additions for. SCI Studio is quite buggy and SCI Companion has its quirks as well at times.

[lance.ewing]

I might give it a go then. I'll add it to the list of features for version 1.3. I already have a fairly long list of features I've put together myself.

I should point out that an import/export capability isn't going to be perfect for what should be obvious reasons. What I'm imaging is that you'd export the picture to SCI0 and then (assuming PICEDIT didn't have SCI0 editing capabilities at the time) you would load it into a SCI0 editor and fix it up.

Of course if PICEDIT supported full editing of the SCI0 picture then it wouldn't need to be exported.

[Collector]

And the other problem with Companion is no source and the author is not longer around. Bug fixes and feature additions aren't going to happen, so any extra tools would be welcomed. They could help work around any deficiencies of both Companion and Studio.

[lance.ewing]

Tonight I started adding some SCI0 awareness to PICEDIT. I'm still a few weeks away from having something ready but thought I'd mention something. I've got a feeling that the priority bands are misplaced in SCI Companion. Could this be possible?

I think this might be the priority band calculation:

priorityBand = RoundDown( (Y - 42) / ((190 - 42) / 14) ) + 1

I guess I could dig into the scummvm source code to confirm this but my first point of verification was SCI Companion, and as I say, it doesn't seem to match this calculation, which makes me think I might have it wrong.

[lance.ewing]

I have just checked the scummvm source code and their formula for SCI0 is as follows:

1 + ((Y - 42) * 2000) / (((190 - 42) * 2000)/14)

There is a comment in the source code saying not to modify the calculation because should not involve any kind of rounding of doubles.

It looks roughly the same as the calculation I came up with. It's too late in the evening to figure out if they generate the same values or not.

[MusicallyInspired]

Yeah, when I'm picture-ing with Companion I notice that I have to draw 1 or 2 pixels above the guide lines for it to actually work properly.

[lance.ewing]

I have confirmed now that both formulas give the same priority band values for all 190 lines, in fact they both give the wrong values for values under 42. So I think the actual logic would be that anything under 42 is priority 0 and everything 42 and above follows one of the two formulas (which, as I say, appear to be equivalent enough to generate the same values).

Thanks for confirming the issue with SCI Companion. Does SCI Studio have the same issue? I haven't checked yet.

[MusicallyInspired]

I haven't picture'd in Studio for a long time so I'm not sure. I can try later. Or maybe someone else can who can do it right away.

[Cloudee1]

In companion the prioriy bands work right. Brandon your problem probably appear off because of the ego's foot print. it's based off the ystep so could look slightly off in actual play hence the necesary adjustments

[lance.ewing]

In companion the prioriy bands work right. Brandon your problem probably appear off because of the ego's foot print. it's based off the ystep so could look slightly off in actual play hence the necesary adjustments

SCI Companion doesn't appear to match the priority band formula that scummvm uses. The differences are very minor though. I'm talking about a single line out every 3rd or so priority band. As an example, line 169 should be priority band 13 according to scummvm (regardless of whether each step is performed solely as an integer calculation or with retaining the fractional parts, it still produces the same result of 13):

1 + ((169 - 42) * 2000) / (((190 - 42) * 2000)/14) = 13

Now if you open up SCI Companion, create a new picture and then take the mouse down to the 169th line, you'll notice that the priority band is still 12. It doesn't change to 13 until line 170. In total I think there are 5 that are misplaced, i.e. bands 1, 6, 8, 11 and 13.

I think I've just spotted another issue with SCI Companion. When I turn on the grid lines, not only does priority band 13 get drawn on line 170 but the short line drawn upwards from the right hand end of the priority band line implies that everything before and including line 170 is priority band 13 (since 13 is light magenta). That short line on the right hand end should be drawn downwards shouldn't it? As its currently drawn, it is implying a white priority band, which doesn't exist in SCI0 as far as I know. A priority value of 15 exists for VIEWs but a priority band on the screen of value 15 doesn't exist. I am assuming here that SCI Companion is a SCI0 picture editor.

I just found this comment in the ScummVM source code:

* Applies to all versions before 0.000.502
* Old SCI versions used to interpret the third DrawPic() parameter inversely,
* with the opposite default value (obviously).
* Also, they used 15 priority zones from 42 to 200 instead of 14 priority
* zones from 42 to 190.

Seems like I'll never get this sorted then! Even different versions of SCI0 have different rules on something quite fundamental!! - It appears, though, that SCI Companion is assuming versions newer than 0.000.502 since the lines only go up to 190, and the Priority value on the status line at the bottom only goes up to 14.

The reason I'm bringing all these things up for discussion is because I want to get things as accurate as possible with PICEDIT's SCI0 support.

[Cloudee1]

Pretty sure white is used as pic priority... And about the little lines, never noticed them, the line is the front boundary of that priority band so yeah, they should go up.

[Collector]

Not that this has anything to do with the current issue, but the thing that I would like to see the most is an ability to import a more modern format than PCX. Even just to be able to paste from the clipboard.

[lance.ewing]

Pretty sure white is used as pic priority... And about the little lines, never noticed them, the line is the front boundary of that priority band so yeah, they should go up.

I might fire up the original SCI interpreter in debug mode and do some priority band testing with ego to verify this.

[lance.ewing]

Not that this has anything to do with the current issue, but the thing that I would like to see the most is an ability to import a more modern format than PCX. Even just to be able to paste from the clipboard.

The Java version allows the background image to be any modern format and any size. In fact I doubt it still supports PCX.