On 8 Dec 2006, at 14:05, Alban Bedel wrote:
On Wed, 6 Dec 2006 17:36:43 +0000
Stuart J Urquhart <[EMAIL PROTECTED]> wrote:
Sorry for the delay i was a bit busy in the last days.
Me too. No need to apologise.
I'd also like to mention a little side-effect i noticed when using my
modified palcat. Palettes aren't appended in the order that one would
expect from the command-line. This is due to the code always adding
palette data to the beginning of the destination file's palette for
each new filename it encounters.
The end result is that palettes essentially get pre-appended in
reverse, i.e.:
palcat -o out.bmp -i in.bmp 1.bmp 2.bmp in.bmp 3.bmp
Would give you a palette in out.bmp which looks like:
2.bmp 1.bmp in.bmp 3.bmp
Rather than what one would expect:
1.bmp 2.bmp in.bmp 3.bmp
So keep that in mind when you are pre-appending more than 1 palette.
I would fix the code, but this problem is very trivial to work around
- just re-order the command-line parameters - so i don't see much
point :)
The patch is attached to this message, which also corrects a typo in
scc_param.c I have tested the modifications, and they seem to work
fine.
I applied it with some modifications. However you should avoid mixing
unreleated changes in a patch. For a small patch like this it doesn't
matter much, but it still mean some extra work as i need to take the
changes apart to commit the separetly. I try to avoid mixing changes
bcs it make reading/understanding the diff much harder, in particular
when you read them later on when looking for something in the svn log.
In case you wonder i see 4 changes in that patch: Adding Pre-append,
scc_param fix, error message fix and the extra scc_img_free.
Interesting approach, though i always feel that a good diff frontend
will more than likely point out the specific changes in each file
related to the revision.
But then again one could see it as a balancing act: too many small
patches make it difficult to see the bigger picture. Too many large
patches make it difficult to see the tiny details in the picture.
I removed the scc_img_free. Some ppl like to be very strict with that,
but as the OS will just kill the heap when the program exit, i find
it better to keep the code simpler.
I always find it helpful to free stuff i am finished with, even if it
will be freed when the application terminates. This is very useful
later on down the line when using memory profilers and tools such as
Valgrind to track down memory leak issues - i don't have to sift
through tons of false matches to get to the real problem.
I also simplified the pre/append code to spare a few lines of code :)
However I haven't commited the error message fix yet but that should
happend soon.
Nice, but i had the code like that for a reason. Namely, i didn't
want the old palette to be destructed by the memory copy.
Though after looking through your implementation, i see using memmove
would ensure that case would never occur.
Modifying the image data via de-referencing a pointer is a preference
of mine (perhaps i am hoping that it will be more optimal), though
then again I'm sure your assignment using the array operator works
just as well :)
I'm a bit puzzled as to why you commited the error message fix
separately, though then again stranger things have happened. :)
PS: Your MUA set application/octet-stream as mime type for the diff.
A text type would be better :)
No idea why apple mail decided to do that.
Anyhow, happy coding.
-SJU
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
_______________________________________________
ScummC-general mailing list
[email protected]
https://mail.gna.org/listinfo/scummc-general
