02:28:29	Fingolfin	joined
06:00:16	sweetlilm	joined
06:12:38	!sweetlilm	left
07:39:00	Fingolfin	left
11:43:01	waltervn	joined
11:44:53	waltervn	hi!
11:59:25	lskovlund	joined
11:59:29	lskovlund	hi!
11:59:51	lskovlund	Does anybody have the SVN repository path
12:00:00	lskovlund	or look it up for me, please?
12:00:31	waltervn	for stable?
12:00:44	lskovlund	both, please.
12:00:59	waltervn	stable: https://secure.a-eskwadraat.nl/svn/freesci/freesci/trunk
12:02:22	waltervn	glutton: https://secure.a-eskwadraat.nl/svn/freesci/freesci/branches/glutton
12:03:19	lskovlund	thanks!
12:23:10	waltervn	What version numbers will the releases be getting?
12:26:06	lskovlund	0.3.5 and 0.6.2, I think.
12:26:47	Fingolfin	joined
12:26:48	lskovlund	Christoph and I discussed whether to discontinue Stable afterwards ...
12:27:08	lskovlund	he said it would be a good thing to backport the new sound system ...
12:27:23	lskovlund	but I don't really know what's left to keep afterwards.
12:27:32	lskovlund	"Good point", he replied.
12:28:32	Fingolfin	you mean stable as opposed to gluttong (sorry, are there logs for this channel?)
12:28:36	Fingolfin	Fingolfin goes back to lurking =)
12:29:10	lskovlund	yes.
12:29:56	waltervn	What do you mean by discontinue?
12:30:10	waltervn	Bugfixes only?
12:32:32	lskovlund	I mean "tell people to use Glutton instead" ...
12:32:46	lskovlund	Of, course no decision has been made.
12:32:48	waltervn	Then we have a lot of work to do...
12:33:18	lskovlund	You don't think we should do it, I gather...
12:34:04	waltervn	Not until we can get glutton to the level of stable when it comes to SCI0 games.
12:35:23	waltervn	I noticed several regressions while I wasn't even looking for them ;)
12:42:21	lskovlund	I'm going to need someone else's help writing the NEWS for 0.3.5 ...
12:42:31	lskovlund	I haven't had much to do with it.
12:42:40	weedar	joined
12:53:42	creichen	'morning!
12:54:55	creichen	Yes, Walter's point pretty much goes to the core of the issue: While we don't really have enough people to maintain two branches, anorexia has many nonbugs that glutton is still missing.
12:55:30	creichen	lskovlund: What's the issue with the NEWS file?
12:56:32	lskovlund	It has to be updated for 0.3.5, which mostly other people than me have been working on.
12:56:57	lskovlund	The glutton version I can handle.
12:59:40	creichen	Well, I can do that one if you'd feel more comfortable with that...
13:00:53	lskovlund	Please do.
13:02:32	syke	hi!
13:04:48	lskovlund	hi Matt!
13:05:33	syke	creichen: discontinuing stable, I'd tend to agree with walter --until SCI0 games are as stable as stable, and people can save games, I don't think it's wise
13:08:55	syke	I'm going to do some palette stuf
13:09:01	syke	for KQ4 next, I think
13:09:18	syke	trying to get one in each series for maximum market penetration ;>
13:09:37	syke	first, I desparately need a haircut
13:09:45	syke	so I'll be back in an hour or so
13:10:00	TMM	joined
13:10:30	TMM	hi al
13:10:44	TMM	I thought you might like to see this: http://81.71.31.44/~hp/Image008.jpg
13:10:45	TMM	:)
13:16:51	syke	er
13:16:55	syke	LSL5 running on...?
13:18:18	TMM	PSP :)
13:18:49	TMM	and I wouldn't call it 'running' just yet
13:18:53	TMM	butm I'm getting there
13:18:59	syke	cool
13:19:05	syke	using freesci, presumably?
13:19:10	TMM	obviously
13:19:22	syke	just checking -- you may have written your own ;>
13:19:32	syke	did you have to change the code at all for PSP?
13:19:32	TMM	at some point I was considering it :)
13:19:45	TMM	some, dirent on psp is apparently pretty broken
13:19:53	TMM	sci_find_first get caught in a loop
13:19:58	syke	oopz
13:20:26	TMM	and, I had to disable sound
13:20:52	creichen	Cool! :-)
13:20:53	TMM	poor PSP can't deal with sound + video at the same time, that is some pretty darn inefficient code freesci got going there
13:21:17	syke	feel free to give us a patch to optimize it! :)
13:21:19	lskovlund	dirent: That is what we have #ifdef for...
13:21:22	creichen	I don't think we can integrate that into today's release, thogh ;-)
13:21:31	TMM	lol, this is glutton anyway
13:21:38	TMM	I'm not very interested in SCI0 games
13:21:41	TMM	they'll suck with OSK
13:21:45	waltervn	how fast is the PSP?
13:21:57	TMM	266-333 mhz
13:22:05	waltervn	that should be fast enough for sound
13:22:41	TMM	the sound thread completly starves the rest of freesci
13:22:44	waltervn	You could try to switch the sound to something like 22khz mono
13:22:50	creichen	waltervn: Depends on the CPU, cache sizes etc.
13:22:53	TMM	uh... not op PSP
13:23:05	TMM	psp is 44100/16bits PERIOD :)
13:23:06	creichen	Well, OPL/2 emulation is inherently expensive...
13:23:46	lskovlund	which is why we have support for other devices ...
13:24:01	waltervn	You could output 22khz mono sound at 44100 with some processing
13:24:03	lskovlund	such as PC-speaker and 3--voice Tandy ;->
13:24:13	TMM	and, I've learned from porting scummvm, that resampling is extremly expensive
13:24:21	creichen	Of course, the mixer also uses linear interpolation ATM, which uses lots of integer divisions. Eliminating that (using a hw mixer or using a software mixer w/o linear interpolation) would help on that end.
13:24:45	waltervn	Right, I forgot about the software mixer.
13:24:51	TMM	I'll try and write a psp specific sounddriver
13:25:02	creichen	TMM: Does the PSP have a hardware mixer?
13:25:02	TMM	I'm going to need a new input system anyway
13:25:06	TMM	yes, it does
13:25:10	TMM	8 voice or something
13:26:17	TMM	but, as I've discovered, usually resampling is insanely expensive on PSP, as it doesn't have an fp unit
13:26:27	syke	jeezus christ
13:26:31	syke	you're joking
13:26:32	creichen	Mixer: great-- you might want to see if this can be implemented that as an "sfx_pcm_mixer_t".
13:26:36	TMM	and, resampling appears to be pretty float intensive
13:26:52	creichen	FP is only used for sine/cosine where requested by the games, not in the mixer.
13:27:03	creichen	Everything's done in integers.
13:27:11	creichen	(In the current software implementation.)
13:27:21	TMM	sound resampling as well?
13:27:39	creichen	If you try to implement the mixer, you might want to ask Walter for his experience with that-- I believe he looked into the same issue on the Dreamcast.
13:28:04	creichen	Resampling is done during mixing in our current setup, and yes.
13:28:19	Fingolfin	it's integer based in ScummVM, too
13:28:28	Fingolfin	but then we only do pretty crude resampling =)
13:28:29	TMM	btw, just out of curiousity, is freesci still using the super-rigid clean room method of reverse engineering? or are you guys a bit less rigid these days?
13:28:36	Fingolfin	the "good" resamplers I know all use floats in some way or another
13:29:12	TMM	Fingolfin, the resampling in scummvm still gives probles during mpeg2 playback, I'm still working on ripping out the overlays for the psp backend :)
13:29:30	Fingolfin	which overlays are you talking about?
13:29:33	TMM	Fingolfin, amongs other things, I think I put an outline of the problem on the psp forum a while back
13:29:44	TMM	Fingolfin, let me look it up
13:29:47	Fingolfin	Fingolfin doesn't read the PSP forums. Those are for PSP user discussion
13:30:11	Fingolfin	developer relevant problems should be discussed on #scummvm, or, if you want to reach all devs, on scummvm-devel
13:30:22	TMM	Fingolfin, http://forums.scummvm.org/viewtopic.php?p=4178&highlight=#4178
13:30:25	Fingolfin	and/or by talking to the person(s) responsible for the relevant parts of ScummVM =)
13:30:39	TMM	Fingolfin, joostp is a personal friend of mine :) we talk about it a lot :P
13:31:29	creichen	Crude resampling: Our linear interpolation is fairly crude. However, PCM in the game we've mostly looked at so far have been of bad enough a quality that this wasn't really much of a worry...
13:31:35	Fingolfin	that's fine, what I meant is: don't expect anybody to act based on things you say in the forums =)
13:31:45	TMM	Fingolfin, I am acting on it :)
13:31:49	Fingolfin	creichen: same here
13:32:09	TMM	Fingolfin, I am apparently the only dev who cares about the cutscens on psp :) joostp sure as hell doesnt ;)
13:32:27	Fingolfin	TMM: we should contine this in #scummvm
13:32:32	TMM	yes
13:32:35	TMM	sorry freesci guys :)
13:32:50	syke	TMM: it's disappointing sometimes when developers disagree on what features, platforms, and games to support
13:32:54	creichen	TMM: We're still trying hard to be clean-room; we're not using disassembled source code or somesuch. At this point, our VM is significantly different from the Sierra one anyway, so attempting this wouldn't work except in isolated cases.
13:33:01	syke	especially if they aren't nice about it
13:33:13	TMM	they aren't unnice :)
13:33:22	TMM	joostp just doesn't care :) he doesn't mind me implementing it
13:33:32	syke	TMM: didn't say they were -- just making a general statement
13:33:40	creichen	Bah. Who cares about "Codename: Iceman". Did I ever tell you that I deliberately broke the parser so that it couldn't be completed?
13:33:48	syke	syke laughs
13:34:12	lskovlund	;->
13:34:19	syke	I dunno what they did in that game to make it so buggy for us
13:34:28	syke	you'd figure if qfg1 works, then CB1 would
13:34:38	TMM	I just wondered if it wouldn't be faster to just start with dissassembling scidhuv.exe from sierra, and reimplement that
13:34:47	TMM	it is how the gob backend for scummvm was done
13:35:45	syke	TMM: given that sierra forced several fan sites to take down community-created games and artwork, I don't think it makes sense to give them cannon fodder
13:35:45	creichen	TMM: Initially: Perhaps. But we didn't want to get into the legal issues related to that.
13:35:50	syke	besides, we are doing ok :)
13:36:10	syke	just need more developer time
13:36:11	lskovlund	for suitable values of ok.
13:36:25	syke	lskovlund: I didn't say 'good' or 'great' ;>
13:36:26	TMM	I'm in europe
13:36:34	TMM	would the 'rigid clean room' stuff still apply to me?
13:36:56	creichen	It's definitely a much slower process than the ScummVM approach. Personally, I still find it more enjoyable that way, but ymmv...
13:37:10	lskovlund	Our sound systems are quite different at this point ...
13:37:26	TMM	joostp and I where discussing just doing that, because we want lsl5 support :)
13:37:34	lskovlund	well, they do use sound iterators, but still.
13:38:02	creichen	They do? Dammit. I had already drafted up a paper on that for the International SCI Conference. Bloody related work.
13:38:17	lskovlund	lskovlund laughs
13:38:19	syke	TMM: one way that was very effective was to write unit tests in SCI Studio
13:38:26	syke	and then run them under FSCI and SSCI
13:38:32	syke	the tests wrote their output to a file
13:38:45	syke	and we just diffed the file between FSCI and several SSCI interpreter versions
13:38:50	creichen	TMM: I'm not sure about the legal situation in the EU ATM. (I ought to be, of course...)
13:38:57	syke	I think that fixed 3 or 4 bugs in one fell swoop
13:39:06	syke	(and probably others we didn't even know about)
13:39:34	creichen	TMM: The point is, if we start doing it the "hard" way, all people subject to US law might be screwed.
13:39:44	syke	SCI Studio is a great black-box revenging tool in that way ;>
13:39:46	creichen	(All that are involved with the project, that is.)
13:40:04	creichen	(Of course, you might argue that we're screwed because of US law anyway, but that's a different matter...)
13:40:14	syke	syke screws creichen
13:40:15	Fingolfin	Fingolfin thinks some big company should sponsore an International Game Emulator Conference, and give free invites (including hotel and traveling costs, of course :-) to ScummVM, FreeSCI, Exult, Dosbox etc. developers, damn it. I'd love to meet all these cool people I've been talking to for years :-)
13:40:23	syke	(with the US law, that is)
13:40:27	Fingolfin	including a hackathon session, of course
13:40:36	syke	heh
13:40:40	creichen	syke: ;-)
13:40:51	TMM	I am sure it is OK here
13:40:55	TMM	you should just all move
13:40:56	TMM	:)
13:41:02	syke	IV drip of glucose, venkamine, enzymatic b12, glutatione, selegeline..
13:41:03	creichen	Fingolfin: Most indeed and certainly! :-)
13:41:05	TMM	if things change here, I swear to god, I'm moving to russia
13:41:14	syke	heh
13:41:23	syke	russia's not such a bad place, it seems
13:41:26	lskovlund	The DMCA does have an equivalent in Europe these days.
13:41:38	syke	on my last project, we had several programmers in minsk and it sounded nice
13:41:40	TMM	that still isn't pushed through
13:41:43	TMM	they are trying though
13:41:48	lskovlund	It's called the Infosoc directive (EUCD formally).
13:43:35	creichen	The political transformations going on in Russia leave me wondering, though...
13:44:11	creichen	TMM: I'd be happy to move back. Once I graduate and get a job offer, that is ;->
13:44:58	lskovlund	creichen: I'm sure you can get a lot of offers for coding HTML :)
13:45:05	Fingolfin	creichen: move back to russia?
13:45:22	creichen	Fingolfin: Da.
13:45:46	creichen	lskovlund: It would appear that my statement was underconstrained ;->
13:46:18	creichen	afk for ~20 minutes.
13:46:24	Fingolfin	creichen: didn't know you ever lived there. Can I visit you in your Datscha? :)
13:47:40	creichen	Fingolfin: I'm afraid that I only have secret underground lairs there... but of course you're more than welcome to look for them.
13:47:44	creichen	Really afk now.
13:51:54	TMM	sooo... how about porting freesci to scummvm? :)
13:52:07	TMM	I was talking about that with syke just a second ago
13:52:25	syke	as in, using the scummvm gfx and sound backends?
13:52:29	TMM	indeed
13:52:45	TMM	and, living in scummvm cvs, so, more devs will look at it, and, more people will know about the existance of freesci
13:52:48	syke	we'd have to make sure iterators and cues could be mapped to SCI's semantics
13:53:02	lskovlund	Well, as I understand it, we use the same OPL/2 emulator code.
13:53:03	TMM	and, I think freesci could stand some c++ lovin'
13:53:04	syke	but I think iMuse was fairly similar
13:53:26	syke	TMM: some parts, though in C, are semi-OO by the naming
13:54:00	lskovlund	syke: But I would say, those parts aren't exactly pretty either...
13:54:06	syke	sure ;>
13:54:07	TMM	wouldn't that be MORE reason to port to c++?
13:54:29	syke	TMM: sure -- I was just implying that :)
13:54:38	TMM	I really think it would be a good idea, for both scummvm and freesci
13:54:41	Fingolfin	we already were there, but split
13:54:49	Fingolfin	see http://scummvm.org/?shownews=archive#2004-04-02
13:54:59	TMM	as long as noone is going to bitch about naming of the freesci+scummvm merger :)
13:55:00	lskovlund	lskovlund realizes that the Glutton README still only documents the old sound subsystem
13:55:13	Fingolfin	ScummSCI, of course!
13:55:21	TMM	lol
13:55:22	TMM	CABAL
13:55:24	lskovlund	FreeSCUMM
13:55:31	Fingolfin	no, FreeVM!
13:55:33	Fingolfin	morons!
13:55:44	TMM	please, people!
13:55:54	syke	moron? you're mother!
13:55:55	TMM	can noone see the POSSIBILITIES here? :)
13:55:55	syke	;>
13:55:59	Fingolfin	and you still don't treat curly braces with the respect they deserve!
13:56:02	syke	TMM: we are all joking ;>
13:56:07	TMM	I know :)
13:56:11	TMM	but, we are degrading
13:56:12	TMM	:)
13:56:12	syke	haw
13:56:24	TMM	I am trying to convince people here!: )
13:56:32	TMM	Fingolfin, be nice! :P
13:56:41	syke	I dunno, do people really need convincing?
13:56:46	lskovlund	You know, we should go with the flow and use C#/.NET :)
13:56:47	Fingolfin	we are already quite convinced that, despite how often people repeat it, it's not such a bright idea at all
13:56:48	TMM	I don't know either
13:56:54	syke	it seems like an okay idea to me, so long as we make sure it can be done well
13:57:01	TMM	Fingolfin, why wouldn't it be a bright idea?
13:57:17	TMM	freesci would get more devs and more ports, scummvm would get more engines
13:57:18	Fingolfin	we answered that a dozen times in the forums. Maybe we should add it to the FAQ, too =)
13:57:26	TMM	meh
13:57:26	Fingolfin	because you are vastly oversimplifying the matter
13:57:31	TMM	no, I am not :)
13:57:49	TMM	I understand that it is quite the undertaking
13:57:50	Fingolfin	Fingolfin searches for a the relevant forum threads, because he's tired of answering this again
13:58:00	TMM	but, I think that in the end it will be better for both projects
13:58:16	syke	Fingolfin: I'd be interested to know why it's not such a bright idea
13:58:28	syke	having worked on both projects, myself :)
13:58:37	TMM	I know I shouldn't have brought this up...
13:58:51	TMM	we can call it MAGE :)
13:58:57	TMM	Multi Adventure Game Emulator
13:59:01	TMM	we'd be sooo cool
13:59:08	syke	or
13:59:16	syke	Motherfuckers Are Gonna Eat
13:59:29	TMM	doesn't quite have the same ring to it
14:02:25	syke	anyways
14:02:31	syke	I'm gonna really go get my haircut now
14:02:39	syke	Fingolfin: I'd be interested to see URLs for the previous discussions
14:02:40	Fingolfin	I can#t find a posting which sums it up nicely, but: (1) The projects follow vastly different approaches both in REing and the backends (2) a merge first creates a lot of work before one can reap any benefit. In particular, people who think the FreeSCI folks are "lazy" or "inactive" won't see FreeSCI grow faster by giving them additional work. (3) nobody in the ScummVM project knows SCI, so we'd not really add anything to SCI
14:02:40	Fingolfin	initially, only maybe over time
14:02:50	Fingolfin	there are plenty of discussion on the old and new forum
14:02:57	Fingolfin	they just don't sum it up :-)
14:03:07	Fingolfin	go to http://forums.scummvm.org/search.php and search for FreeSCI
14:03:08	syke	heh ok
14:03:17	TMM	meh... I think the negatives are vastly less than the positives
14:03:23	Fingolfin	and starting by finding a name is, frankly, a bad way to go about it... :-)
14:03:25	TMM	say, someone else would do the initial merger
14:03:28	syke	I do see your point about work up front
14:03:30	Fingolfin	TMM: name the positives, then?
14:03:43	TMM	"freesci would get more devs and more ports, scummvm would get more engines"
14:03:56	syke	also, more opportunities for shared code
14:04:03	TMM	plus, freesci would potentially get _sev and cyx :)
14:04:07	Fingolfin	TMM: more devs? How so? Most engines in ScummVM only have a few devs, less than FreeSCI in fact. SCUMM is the only exception
14:04:11	syke	gfx drivers, sound drivers, filtering, game selection screens, etc
14:04:50	Fingolfin	TMM: not sure what it is about _sev and cyx that makes them particular interesting for freesci, but if you talk about REing -> that's the "different approach / philosophy" part
14:05:02	TMM	we could do away with that then :)
14:05:20	TMM	I don't think anyone is going to try and sue the pants off off scummvm
14:05:35	syke	TMM: famous last words ;>
14:05:40	TMM	Fingolfin, _sev and cyx are pretty damn good with IDA :)
14:05:59	Fingolfin	shared code -> yeah, so, FreeSCI would throw away everything and use our system which is quite different in many aspects... maybe some stuff could be incorporated over time... and you doN#t get more ports automagically, either. the SCI engine itself would have to be tuned for each port, too
14:06:09	syke	I think the revenging approach is the real crux, if there is one
14:06:25	Fingolfin	all in all: Sure, ScummVM wouldn't mind supporting AGI or SCI games, but I don't see so many gains for FreeSCI as you try to make it sound :-)
14:07:13	Fingolfin	TMM: you have no idea about the legal negotioations we are doing all the time, like, e.g. with SCUMM... don't be too sure about us not getting our pants sued off, right now it looks a bit scary
14:07:42	TMM	I thought most where settled pretty well?
14:07:52	syke	s/where/were
14:08:03	syke	ok, really gone now -- I'll be back in an hour or so
14:08:10	TMM	o well, I knew it was a bad idea to start this :)
14:12:43	creichen	Whee! CABAL's back!
14:14:02	lskovlund	bbl
14:14:04	lskovlund	left
14:14:13	TMM	what's so wrong about that? :)
14:15:57	Fingolfin	once again: I don't mind seeing SCI/AGI engines in ScummVM. I have no idea whether the FreeSCI or ScummVM backend system is better, either... I just know this: (1) ScummVM has no interest in moving to the FreeSCI one; (2) I don't want to use FreeSCI/Sarien code w/o consent by the authors; (3) the RE policy / philosopy is radically different, that may lead to conflicts, too.
14:17:05	TMM	I think it would be a good time to dump the strict RE policiy of freesci, I honestly think in the end, no one is going to care enough to defend SCI in court
14:17:10	Fingolfin	If you want to create e.g. a fork of FreeSCI as a plugin for ScummVM, and the FreeSCI devs are OK with that, fine by me... or if they want to join ScummVM, fine by me, too (I doN't have to do all the work, after all :-). I only know, I'd be reluctant to do that if I was a FreeSCi dev g
14:17:21	Fingolfin	TMM: it's not your ass, though :-)
14:17:33	TMM	if I start working on it, it will be my ass :)
14:17:43	Fingolfin	the FreeSCI devs might think differently about it, and that's perfectly understandable to me
14:18:12	Fingolfin	TMM: yeah, but not your ass alone. You can't say "I am willing to risk my ass, now creichen, you must risk yours"
14:18:12	TMM	sissies :)
14:22:36	creichen	TMM: For me personally, I don't see enough of a gain in switching the reverse engineering policy to risk getting kicked out of the country before finishing my degree (and no, I can't afford a decent lawyer, in case you're wondering.)
14:22:54	creichen	If this policy was to change, I would have to leave the project. Yes, I'm a coward like that.
14:23:18	TMM	:'(
14:23:29	TMM	this seems to be pretty unsolvable then :)
14:26:46	creichen	I'm less opposed to re-using the ScummVM backends, though, if (a) it is evident that we don't lose anything in the process, (b) there are volunteers to do this, and (c) all ports conclude that portability won't be lost by using whichever subset of C++ are used by the backends.
14:27:00	Fingolfin	creichen: I wouldn't call that "cowardice", though. Considering your legal situation, I'd call it "careful considertaion" :-)
14:27:16	TMM	I WOULD call it cowardice :D
14:27:23	TMM	not in creichen's face though
14:27:25	creichen	Fingolfin: Thanks...
14:27:26	creichen	creichen laughs
14:28:19	Fingolfin	TMM: really? what are you risking, then?
14:28:42	TMM	nothing :) I am in europe and insured against these types of things
14:28:49	Fingolfin	ah
14:29:20	Fingolfin	thought so
14:29:37	TMM	it does make reading the radgametool's fanmail more enjoyable
14:29:48	TMM	:)
14:30:31	TMM	besides that, I doubt vivendi is going to care about SCI
14:30:39	Fingolfin	creichen: the ScummVM backends are relatively conservative in their usage of C++. GCC 2.95 and MSVC 6 should be usable
14:31:03	TMM	they don't seem to care about the rest of sierra's stuff
14:31:04	TMM	:)
14:31:19	Fingolfin	TMM: you doubt it, but you have no proof, you haven't had any legal conversations with game developers, you never were threatened by their lawyers, and you seem to underestimate the viciousness of certeain companies, in particular, Viacom and Vivendi :-)
14:31:31	Fingolfin	Fingolfin recalls a lot of Sierra sites being forced to closed down
14:31:53	TMM	perhaps I should try and email vivendi about it?
14:32:05	Fingolfin	TMM: sure
14:32:16	Fingolfin	TMM: that's always a good idea
14:35:46	creichen	Fingolfin: That sounds good. I'd like at least Walter to double-check for Dreamcast and GP32 before committing to this, but it seems that we should expect success here.
14:36:25	creichen	Points (a) and (b) remain. What/where is your graphics/sound interface?
14:36:31	TMM	creichen, scummvm has gp32 and dc ports :)
14:37:34	Fingolfin	creichen: our GP32 port is a bit outdated, but a new GP2x port is in the work
14:37:34	creichen	TMM: IIRC we use a different toolchain for at least one of them, and Walter takes care of those ports, so I want to make sure that that won't break things elsewhere.
14:38:17	TMM	creichen, that sounds reasonable
14:38:25	Fingolfin	creichen: sound: the backends mainly provide an audio callback. Atop that sits our mixer, which provides MP3/VOrbis/FLAC support, and some other things. But it's seperate from the backends, so you could use your own mixing code, too
14:38:37	TMM	also, if this is to happen, I wouldn't mind doing a lot of the hard work at all
14:38:49	creichen	I can't personally commit to doing such a transition at this point, unfortunately. I took today and half of tomorrow off for FreeSCI, but that's not something I'll be able to do too often in the next three months.
14:38:56	creichen	TMM: That would be much appreciated.
14:39:05	Fingolfin	creichen: MIDI is available, too, including Adlib based MIDI emulation, and the MT-32 emu. Don't know enough about FreeSCI to know what your needs there are, though, so I can't say much more
14:39:18	Fingolfin	creichen: graphics: dunno, is there anything fancy you need, besides a framebuffer ?
14:39:23	creichen	Fingolfin: MT-32 would be nice. You don't include the ROMs, I hope?
14:39:30	Fingolfin	creichen: no of course not
14:39:37	creichen	Good.
14:39:58	Fingolfin	creichen: MT32 doesn't just mean the MT-32 emu, we also have switches to either use GM emulation of MT32, or to use a real MT-32
14:40:05	creichen	Fingolfin: Actually, our backends don't really use a framebuffer per se... they provide primitive drawing operations (lines, pixmap crossblitting etc).
14:40:11	Fingolfin	Fingolfin has a real MT-32 with a USB-MIDI adapter on his mac and uses it for e.g. Monkey Island 2
14:40:15	Fingolfin	ah
14:40:30	creichen	creichen left his MT-32 in Germany
14:40:43	Fingolfin	we also have some graphic primitives, but not so many at this point, because none of our engines needs them, but it should be trivial to add anything needed
14:40:55	creichen	How do you handle palettes?
14:40:58	waltervn	creichen: C++ shouldn't be much of a problem. Both DC and GP32 ports would need work as I believe the ScummVM ports use different toolchains.
14:41:08	Fingolfin	why do your backends use primitives? To make it possible for e.g. antialiased lines or hypothetical "vector based" backends?
14:41:26	TMM	I think most of SCI is vector based
14:41:47	TMM	or at least ,don't store bitmaps, but drawing parameters, like WMF :{
14:41:51	TMM	:P
14:41:52	Fingolfin	creichen: there's a 256 color palette, you can specify 24 bit values for each. you can specify a seperate palette for the mouse, and there is some 16 bit color support, too, though limited (we'll expand that in the future)
14:41:53	creichen	Fingolfin: Antialiased lines, accellerated line drawing, that stuff. Turned out to be quite helpful back when I was testing on an SGI box over a 10 mbps ethernet line.
14:42:03	Fingolfin	creichen: not sure if you need anything special palette wise?
14:42:11	creichen	No, I don't think we'd need something fancy there.
14:42:24	creichen	Do you support high-resolution frame buffers and scaling?
14:42:29	TMM	or am I wrong ?
14:42:32	creichen	(high-resolution as in > 320x200)
14:42:33	Fingolfin	TMM: I know that SCI is vector based, just was wondering why to put this into backends, not atop them. Guess both approaches have their advantages :-)
14:42:45	Fingolfin	creichen: yeah to both
14:42:50	Fingolfin	creichen: some of our games are 640x480
14:42:54	TMM	I think putting them on top of them would be more flexible :)
14:43:01	TMM	personally :)
14:43:17	creichen	TMM: Only background images are "vector" graphics, but we render them to a buffer anyway: They use flood filling, which doesn't scale very well if the image scales...
14:43:20	Fingolfin	creichen: we also have an aspect-ratio-corrector, and lots of scalers (advmame2x/3x, pixel scalers, hq2x/3x, etc.), and more can be plugged in
14:43:34	TMM	creichen, good point...
14:43:55	TMM	creichen, we could do smooth scaling for those cases?
14:44:37	creichen	TMM: Sure, but I prefer our present solution, which is a painful algorithm which happens to produce better results than that...
14:45:39	creichen	Fingolfin: Where's a good place to start looking for documentation of your graphics interface?
14:45:50	Fingolfin	sec
14:46:27	creichen	It seems that, at the very least, we can hook into it as a FreeSCI graphics driver. The rest of our graphics subsystem would remain unchanged.
14:46:55	creichen	I'm not sure if we can re-use more... we wouldn't need our own scalers anymore, though.
14:46:57	Fingolfin	creichen: http://scummvm.org/docs/doxygen/html/classOSystem.php
14:47:01	Fingolfin	creichen: under "graphics
14:47:02	Fingolfin	"
14:47:41	Fingolfin	creichen: I am afraid our documentation there is a bit thin, but so far it was enough for a lot of new engine / backend developers to use it. I always wanted to write more, and if people ever did as I ask them to (namely: to tell me which parts I should document better), I'd happily do it :-)
14:47:55	Fingolfin	but I think the graphics stuff is mostly very straight forward
14:48:29	creichen	Game graphics are always 8bpp?
14:48:29	Fingolfin	creichen: you should be able to fully ignore the "overlay" stuff, it's for 16bit / GUI stuff mostly
14:48:44	Fingolfin	creichen: at this point, yes. We are planing to revise that soon, though
14:48:44	TMM	ahhh... scummvm overlays
14:48:49	TMM	TMM cringes and dies
14:49:16	Fingolfin	the overlay is (ab)used for 16bit stuff, like MPEG2 video, but it wasn't meant for that. It was meant as an overlay. And despite TMM, it works quite well for that
14:49:29	creichen	OK.
14:49:34	Fingolfin	creichen: I assume 16bit is used by FreeSCI for improved vector rendering?
14:49:56	TMM	lol
14:50:21	creichen	Not quite. We allow each image to have its own palette, and background images are subjected to antialiasing after being translated from 8bpp to whatever format the backend expects.
14:50:34	Fingolfin	the main reasons I haven't looked deeper into 16bit game support yet is that (a) it's not really needed, (b) it's not fully clear to me how to "best" abstract it, and (c) I don't want to loose efficency on palette handling, in particular, palette color rotation
14:50:41	Fingolfin	ok
14:50:50	Fingolfin	creichen: that's what I imagined, more or less
14:51:13	creichen	But we haven't found a good solution of how to integrate this with palettes without requiring full redraws, at this point.
14:51:55	Fingolfin	that's part of my problem :-). Our SDL backend actually has code to detect which parts of an image changed. This actually helps some of the game that try to do fullscreen updates
14:52:14	Fingolfin	at first, when I learned about that, I thought: "how can it be faster, you need to look at the memory anyway?"
14:52:31	TMM	and borkes on PSP for black for some reason :) (or, should I say, colour '0')
14:52:33	creichen	Well, you can keep bounds...
14:52:41	Fingolfin	but when you consider that the data has to be scaled, converted, massaged back and forth and then transfered to the graphics card, it actually makes sense :-)
14:52:51	Fingolfin	we also use dirty rects
14:53:02	Fingolfin	but e.g. palette changes potentially invalidate the whole screen
14:53:32	TMM	TMM is desperatly trying to add something to the conversation, and is failing
14:53:36	Fingolfin	it's up to backends whether they record dirty rect information, compute changed regions some other way, or just blit everything
14:53:43	creichen	Right. But if you draw (as opposed to palletise) rarely and/or keep information about the views you draw, you can make good assumptions about the areas you need to re-draw.
14:54:16	creichen	Hang on, I think I have to get going now. It'll be quick, though, I'll be back in ~15 minutes.
14:54:20	Fingolfin	aye. but for fully bitmap based games (read: all games we support in ScummVM :-), this isn't easily possible
14:54:27	Fingolfin	creichen: no worries :-)
15:14:26	creichen	back.
15:14:48	creichen	Is your framebuffer 8 bit then, or is it merely the interface you're exporting that expects 8 bit input?
15:18:43	creichen	Fingolfin: Actually, it is. You only need a 32 byte wide summary mask listing all the colours used by the pixmaps, and 256 "region summaries" (e.g. bounding rectangles) for bigger things, e.g. background images. Then you already save some time when updating.
15:19:02	creichen	"region summaries" can be more complex than that, of course, such as sets of nonoverlapping bounding rectangles.
15:20:07	TMM	creichen, i am not really too authorative on this, but, from what I gathered, Osystem itself is 8bit, all the interfaces are anyway
15:20:14	creichen	OK...
15:20:21	Fingolfin	creichen: yeah, but that approach is only "logical" if your image is easyily separated into logical "regions". For SCUMM games, you have one big pixel background. So you'd first ahve to implement a clever algorithm to subdivide it into blocks usable by your scheme :-)
15:20:46	Fingolfin	creichen: anyway, again, this is all hidden in the backend API -- a backend could do what you say, and a backend can also use 16 bit framebuffers internally
15:20:46	creichen	Fingolfin: Quite true, but you can come up with an algorithm that does so in one pass.
15:20:54	Fingolfin	creichen: in fact the SDl backend uses a 16 bit buffer internally, too
15:21:15	creichen	Interesting... but I still don't quite see how that works.
15:21:30	creichen	Assume that I do a scaled blit of some image with a filter.
15:21:36	TMM	Fingolfin, how much work would be required to expand Osystem to support 16bit internally?
15:21:52	creichen	Then the filter may translate two nearby colours into some intermediate colour.
15:22:21	creichen	But if I was to later change the palette, the appropriate colour index would have to be recovered... you'd need an additional 8 bit map (or somesuch) to recover the pixels affected by this.
15:22:24	Fingolfin	creichen: well, the algo used in the SDL backend works like this: First convert the whole 8 bit data to 16 bit (possibly limited to a few dirty rects). Then, compare, in one pass, to the old image. Compute new changed blocks from that. Then, upscale and transfer to the screen only the changed parts. Clearly, with more precomputed knowledge, as you explain it, this could be done even better... and it would be possible to change t
15:22:24	Fingolfin	he SDL backend (or others) to do just that, too, if somebody is interested :-)
15:22:36	TMM	Fingolfin, I mean, we could go entirely the other way around, make Osystem 16 bit, and provide a flag to downscale to 8bit if the target backend is so inclided?
15:22:46	Fingolfin	creichen: ah we have a misunderstanding
15:22:53	Fingolfin	creichen: no, we do not support scaled blits at this point
15:22:56	creichen	That's what I was hoping yuou'd say.
15:22:59	creichen	Oh.
15:23:03	Fingolfin	creichen: :-/
15:23:07	creichen	That was not what I was hoping you'd say.
15:23:10	Fingolfin	creichen: I see now your point :-)
15:23:14	Fingolfin	hehe
15:23:30	Fingolfin	so far, scaling support for blits wasn't needed for anything, and wasn't useful for anything
15:23:31	creichen	But there are SCUMM games that do scaling for their pixmaps, right?
15:23:39	Fingolfin	creichen: not that I am aware of
15:23:39	TMM	Fingolfin, also note that that scheme sometimes gives small graphical glitches in bs1 :(
15:23:56	Fingolfin	creichen: the costumes (=actors) are scaled, but before they ever reach the backend
15:24:02	creichen	Oh... OK.
15:24:30	Fingolfin	the SCUMM developers had a special codec to allow multiple versions of the costume to "blend" into each other, roughly said
15:24:58	creichen	Sounds a bit like "trilinear filtering"...
15:25:01	Fingolfin	TMM: the implementation isn't quite as good as it should be. Rewriting it has been on my TODO list for some time :-)
15:25:17	Fingolfin	creichen: not really, it's more of a "drop scanlines" approach =)
15:25:25	Fingolfin	anyway
15:25:27	creichen	OK.
15:26:05	creichen	So... to summarise: I believe that we can use your backend mechanism, as a regular FreeSCI gfx backend (though I didn't check all details).
15:26:22	Fingolfin	adding a scaled blitter API wouldn't be a major issue. Thinking about it, it might even be nice to provide higher quality SCUMM actor rendering, at least hypothetically, though I am not quite sure how to combine this cleanly with palette rotation :-)
15:26:38	TMM	I think comi would benefit from this
15:26:39	creichen	In comparison to existing backends, it's better because it always provides palette support, and worse because it never provides more than 8 bit palette mode support.
15:26:50	Fingolfin	creichen: are there docs on what a FreeSCI backend needs to do somewhere?
15:26:56	Fingolfin	hehe
15:27:31	Fingolfin	creichen: the "more than 8 bit" stuff is achieved by the scaled blits / graphics primitives? or is there anything else that "directly" makes use of it?
15:29:20	creichen	Fingolfin: The header file is meant to be the full documentation. Try http://www-plan.cs.colorado.edu/creichen/gfx_driver.h
15:29:33	Fingolfin	thx
15:29:45	creichen	Sure... thanks for looking into this!
15:30:05	creichen	Fingolfin: More than 8 bit is not needed for anything, of course. It's used by the following:
15:30:05	Fingolfin	GFX_CAPABILITY_MOUSE_POINTER etc. are capability flags, I take it? This particular one means the backend can render a mouse cursor?
15:30:16	creichen	Yes, precisely.
15:30:30	creichen	Backends can choose not to support these, then they're emulated by the engine above.
15:30:45	Fingolfin	I meant "needed" as in "needed for special extra features" :-)
15:30:47	creichen	(a) Antialiased background images
15:31:24	creichen	(b) Per-resource palettes (still possible in SCI0, though the requested colours would only be approximated, but very dangerous in SCI1)
15:31:51	Fingolfin	dangerous?
15:31:54	creichen	Yes.
15:32:00	creichen	Additional colours might be allocated.
15:32:13	creichen	Which might result in the rest of the scene being rendered in a sub-optimal fashion.
15:32:38	creichen	(When we're out of colours, we grab the colour closest to the one that was requested.)
15:33:31	creichen	Furthermore, it seems that transparent dropshadows (done by having nontrivial "alpha" values for rectangle draws) wouldn't be supported in an 8 bit buffer.
15:34:22	creichen	(c) Some extensions we've been talking about recently (more fancy per-resource customisation, effectively) but haven't actually implemented also would not work.
15:34:22	Fingolfin	color grabbing only applies for palette graphics, though, no?
15:34:24	Fingolfin	is GFX_CAPABILITY_PIXMAP_GRABBING used for anything besides mouse cursor emulation?
15:34:32	creichen	No.
15:34:44	creichen	It used to be used for screenshots, but we don't support those ATM.
15:35:08	creichen	(d) Filtered images.
15:35:09	Fingolfin	in ScummVM screenshots are something backends do internally (at this time at least :-)
15:35:53	Fingolfin	are "stippled lines" "gestrichelte Linien" ? :-)
15:36:07	waltervn	Does all this talk mean we're going to seriously consider a merge?
15:36:09	creichen	To understand point (d): Note that if we use scaled background images (for nicer pictures), we have to scale the views (what you'd probably call costumes) ourselves before they reach the backend...
15:36:17	creichen	Fingolfin: Yes, precisely ;-)
15:36:27	joostp	left
15:36:37	creichen	creichen also had to look it up back when he wrote that part...
15:36:37	Fingolfin	waltervn: not really, more like considering to share the backend code, at least partially, I'd say
15:37:05	creichen	No CABAL, I'm afraid ;-)
15:37:29	Fingolfin	and in any case, right now it's mostly creichen and me talking ;-)
15:37:46	waltervn	I understand that, but still... ;)
15:38:09	TMM	nonononono
15:38:11	TMM	we DO want CABAL
15:38:18	Fingolfin	err
15:38:18	TMM	keep going
15:38:19	TMM	:)
15:38:34	Fingolfin	could we all please stop using the word "we" as long as it's not clear who "we" is in each case? ._)
15:39:08	creichen	Yep. We should do that.
15:39:26	TMM	ok
15:39:33	TMM	'we' being 'TMM'
15:39:38	TMM	but 'we' sounds more convincing
15:39:41	creichen	We is not amused.
15:39:48	TMM	actually we are
15:39:52	TMM	:)
15:40:04	TMM	ok, I'll shut up now
15:40:20	TMM	btw, I have a moving mousecursor for freesci on psp now, it actually works
15:40:24	TMM	now lsl5 intro crashes :)
15:40:42	TMM	to highlight that besides bitching, I am actually doing something useful as well :)
15:41:21	joostp	joined
15:43:08	Fingolfin	uh, you mean, bitchig on its own isn't useful ?????
15:43:15	Fingolfin	damn
15:43:17	TMM	well
15:43:23	TMM	not as much as I'd like it to be :)
15:51:59	TMM	continue!! :)
15:59:06	TMM	Fingolfin, you did something useful while bitching as well? :)
15:59:11	TMM	Fingolfin, damn you! :)
16:00:07	TMM	creichen, do you know if freesci opens all the resource files, or does it open and close them as needed?
16:01:32	creichen	TMM: Stable opens/reads all of them. Glutton opens them on-demand and caches the most recently used resources (and resources which have been requested to be retained) after decompression.
16:02:24	TMM	is there a define somewhere on how many it can cache?
16:02:27	creichen	If you're noticing lots of memory being used: The graphics subsystem caches the filtered images to be able to crossblit them in the format native to the underlying platform. That takes up some memory.
16:02:43	TMM	we have about 16 megs
16:02:49	TMM	that should be enough I think
16:03:01	creichen	Unless you're doing high-res graphics, it should be.
16:03:04	TMM	the problem is that PSP won't open more than 8 files, after that it just returns NULL pointers
16:03:21	Fingolfin	creichen: what is GFX_CAPABILITY_FINE_LINES good for? I would have thought drawing 1 pixel lines is easier than drawing thicker lines... ?
16:03:24	TMM	-EFAULT would be too obvious I think
16:04:53	creichen	TMM: SCI games may do their own file opening... not sure if this is what's biting you. Are you sure its files that are causing the problem? I don't personally know how well LSL5 works on other platforms...
16:05:31	creichen	Fingolfin: True, in retrospect, it was not a wise decision.
16:06:10	TMM	LSL5 crashes during the intro, right after patty walks into the screen and the 'P' of the game name is drawn
16:06:46	TMM	according to my debugging experience with PSP that usually means that something tries to open too many files, my fileopencounter on PC shows 94 files open during load... :!
16:06:59	TMM	but, a lot of that is X related
16:07:43	creichen	It is possible that we're leaking file descriptors, or deliberately keeping files open.
16:07:54	Fingolfin	creichen: dunno how wise it is, I am just surprised / wondering about the semantics :-)
16:07:59	TMM	PSP does not want more than 8 file descriptors :)
16:08:08	TMM	I'll try and debug a bit more
16:08:36	Fingolfin	draw_filled_rect does "shading" -- does that mean it blends from color 1 to color 2? in which direction?
16:09:11	TMM	rand()
16:09:11	TMM	;)
16:11:56	creichen	GFX_SHADE_FLAT, / Don't shade /
16:12:01	creichen	GFX_SHADE_VERTICALLY, / Shade vertically /
16:12:07	creichen	GFX_SHADE_HORIZONTALLY / Shade horizontally /
16:12:11	creichen	But it doesn't specify the direction...
16:12:20	creichen	IIRC colour 1 is top or left.
16:12:46	creichen	The graphics test program illustrates this, though...
16:15:13	Fingolfin	ah
16:16:09	Fingolfin	BTW, we already have an "image registry" similar to your pixmap registry, at least in some ways, but "above" the backend
16:16:32	Fingolfin	and we also use blended rects & line drawing, though only for the GUI.
16:16:51	Fingolfin	just comparing things here, mind you :-)
16:17:33	Fingolfin	the event/sleep/palette/mouse APIs seems similar enough :-). FreeSCI uses multiple graphic buffers, though
16:17:38	Fingolfin	it seems to me, at least
16:18:34	lskovlund	joined
16:18:40	lskovlund	back
16:21:25	creichen	wb!
16:22:00	creichen	Fingolfin: Yes, we are. Some of the burden for these buffers is pushed off to the drivers, in the hopes that they might implement blitting between the buffers more efficiently than we could do it.
16:22:21	creichen	Not sure how much of a difference that makes in practice, though... I'm sure that it has been a bit of a pain for some drivers...
16:22:39	creichen	lskovlund: What should we do with the stable NEWS file, then?
16:23:05	lskovlund	Fingolfin: Since I'm barging into this conversation, I'd mention that the widget-based backend of ours is starting to cause trouble with e.g. inventory windows in SCI1.
16:23:50	lskovlund	creichen: The GP32 port is new, isn't it? That's about the only thing I know I recall...
16:23:51	creichen	From the POV of our previous discussion, it's more of an IR than a backend, though... it is a backend from the POV of the SCI VM, though.
16:24:05	lskovlund	IR?
16:24:53	waltervn	What about the game selection screen? Or was that in 0.3.4c already.
16:25:11	creichen	Right, but we added the game selection screen, added full support for Show(), significantly sped up pic drawing, and added version number auto detection from executables.
16:25:28	creichen	IR = Intermediate Representation.
16:25:40	creichen	IR :> IL
16:26:10	syke|haircut	back
16:26:18	creichen	wb, haircutt!
16:26:23	creichen	s/haircutt/syke/
16:26:32	creichen	s/syke/Matt/
16:26:35	TMM	syke, slick haircut man!
16:26:46	lskovlund	Yes, which required me to give an explicit version number to Walter yesterday, incidentally :)
16:27:59	creichen	Ah... that's because of the over-relaxation on the glutton side? IIRC, stable still does the knee-jerk FSM, though.
16:28:26	lskovlund	No, there are just misleading numbers in some of the EXEs.
16:29:44	creichen	creichen commits some changes to glutton
16:30:27	TMM	just out of curiousity how diverse are the sci1 games? when it comes to interpreters?
16:31:43	lskovlund	knee-jerk FSM?
16:32:15	lskovlund	You call the stable VM that? :/
16:33:45	creichen	lskovlund: I meant the version number acceptor automaton...
16:34:41	waltervn	I'm afraid I won't be able to get the DC, GP32 and BeOS ports ready today.
16:38:00	creichen	Hm. MVI detection is broken.
16:38:05	Fingolfin	lskovlund: what is the "widget-based backend"? i.e. what precisely is a "widget" in your terminology?
16:38:16	lskovlund	re "we": Some languages distinguish first person inclusive from first person exclusive. Useful in this case I'd say...
16:38:40	lskovlund	(including/excluding the listener, that is)
16:38:57	syke	TMM: fairly diverse
16:39:14	TMM	syke, could you elaborate a bit more? :)
16:39:18	lskovlund	Fingolfin: The "primitive operations" backend Christoph referred to.
16:39:23	syke	especially near the end when it was all on the PC and they didn't give a fuck about having a common VM for multi-platofrm deployment
16:39:37	syke	the real bitch is that the differences can be fairly subtle
16:40:01	syke	(in implementation, but not as far as causing bugs)
16:40:13	lskovlund	But many of these things are detectable, as the 0.6.2 development shows.
16:40:34	syke	TMM: there are also a fuckton of valgrind warnings in the code. if the PSP is more sensitive to memory corruption, that may be it
16:40:40	syke	lskovlund: true
16:40:51	waltervn	I'll be off now. If the release happens today I'll just release the ports later. Night all.
16:40:59	TMM	syke, say, you've got a working lsl5 sci implementation, would it be a lot of work to get, say, lsl1vga working on it?
16:41:21	syke	TMM: lsl1vga does work on it. lsl1vga may be beatable -- I got pretty far in it
16:41:30	syke	you just have to learn how to work around the pathfinding bugs first ;>
16:41:42	syke	lskovlund: the pathfinding algorithm is the patented one, right?
16:41:51	TMM	nooo
16:41:54	TMM	you are fucking kidding
16:41:57	TMM	you are
16:41:59	syke	nope
16:42:02	TMM	...
16:42:05	TMM	wtf
16:42:08	TMM	seriously?
16:42:31	syke	it was a big deal -- lars, christoph, and I had more time that usual over the course of a few weeks
16:42:47	syke	and I was able to find the blocking issues and they were able to remove them
16:43:01	syke	yes, seriously
16:43:05	lskovlund	syke: Yes. Walter is working on an independent implementation, I've recently learned.
16:43:06	syke	are you high? ;>
16:43:07	TMM	holy .....
16:43:14	syke	lskovlund: awesome!
16:43:18	TMM	I am not high, but I am wondering if you are
16:43:23	TMM	;)
16:44:00	syke	you can't get too far in LSL5 without debugger magic, but lsl1vga works much better
16:44:02	syke	weird, huh? ;>
16:44:08	syke	also, jones in the fast lane is "beatable"
16:44:50	syke	I forget where KQ5 was, last we left it
16:44:54	syke	or SQ4 for that matter
16:45:02	syke	but things are coming along, slowly but surely :)
16:45:13	TMM	I was wondering, how far one would get with a working lsl5 interpreter if one would not base it on freesci :)
16:47:33	syke	I dunno, if you were good at reversing and didn't care about maintenance
16:47:38	syke	it might take a couple of months
16:48:04	lskovlund	TMM: re lsl5: That actually looks like an interpreter hang of sorts, not an I/O problem.
16:48:40	TMM	lskovlund, that doesn't happen op pc
16:49:09	lskovlund	re reimplementation: You'd have to at least parse and use the selector list to get any sort of code re-use.
16:49:23	lskovlund	Or you'd be stuck compiling a version for each game. :(
16:49:37	TMM	actuallty it does...
16:49:38	TMM	fuck me
16:49:49	syke	lskovlund: he said 'just' lsl5, though
16:50:02	TMM	[KERN] Could not determine type of ref 002f:0000; failing signature check
16:50:02	TMM	[VM] Invalid arguments to kernel call 1
16:50:22	lskovlund	creichen: GC issue?
16:50:37	TMM	I forget I skipped the intro on PC
16:50:37	TMM	:)
16:50:49	lskovlund	TMM: Could you do a 'segtable' from the console?
16:50:59	lskovlund	and tell us what it says about segment 0x2f?
16:51:09	TMM	sure
16:51:12	lskovlund	(don't give us the whole thing, please)
16:51:13	TMM	if you tell me how to go about that
16:51:24	TMM	because I have no idea what you are talking about
16:51:24	TMM	:)
16:52:02	lskovlund	when it gives you the error and dumps you to the console, type 'segtable'...
16:52:15	lskovlund	look through the results for segment 002f...
16:52:21	lskovlund	and tell us.
16:52:46	TMM	it doesn't dump me to a console... :(
16:53:01	syke	huh. I just read that Vivendi backed off from the team making King's Quest IX
16:53:02	TMM	On-screen console disabled and driver claims not to support windowed mode.
16:53:14	syke	and just asked them to not use the trademark (King's Quest)
16:53:18	lskovlund	shit
16:53:29	lskovlund	TMM: what platform are you on?
16:54:04	TMM	linux
16:54:10	TMM	SDL driver
16:54:36	TMM	note, that this is a 'port' of my psp version back to PC
16:54:47	lskovlund	Could you try with -g xlib, please?
16:54:54	TMM	sure
16:54:56	lskovlund	that should give you a working console
16:55:00	TMM	let me recompile :)
16:55:16	lskovlund	you don't need to recompile for that, that's the point
16:55:32	TMM	actually
16:55:33	TMM	I do
16:55:51	TMM	I can't give command line params on PSP
16:55:54	TMM	that is the point :)
16:56:29	lskovlund	you could also recompile of course, and use --with-console
16:56:43	TMM	I have to recompile
16:56:47	TMM	because my version doesn't have X support
16:56:56	TMM	since, last time I checked, psp doesn't run X :)
16:57:06	lskovlund	--with-console gives you console support on SDL.
16:58:01	TMM	ok, I got a console
16:58:17	TMM	segtable
16:58:46	TMM	[002f] S script.956 l:4 seg_ID = 956
16:59:03	lskovlund	that's not a clone segment :/
16:59:12	TMM	just as I suspected
16:59:14	TMM	...
16:59:17	TMM	wtf are you talking about? :)
17:00:11	lskovlund	I thought it was a GC bug..
17:00:35	lskovlund	which would imply the offending segment being one where things are actually allocated and deallocated frequently.
17:00:53	lskovlund	which is not the case.
17:00:56	TMM	I still have the console open, is there anything else I can do?
17:01:13	lskovlund	a backtrace? 'bt'
17:01:29	TMM	the whole shebang?
17:01:35	lskovlund	yes, please.
17:01:40	TMM	Call stack (current base: 0x0):
17:01:40	TMM	0:[ffffffff] LSL5::play()
17:01:40	TMM	obj@0001:0ec4 pc=000b:02ee sp=ST:0000 fp=ST:0000 argp:ST:0001
17:01:40	TMM	1:[0] LSL5::doit()
17:01:40	TMM	obj@0001:0ec4 pc=0001:05eb sp=ST:0002 fp=ST:0002 argp:ST:0001
17:01:41	TMM	2:[1] Game::doit()
17:01:43	TMM	obj@0001:0ec4 pc=000b:0562 sp=ST:0006 fp=ST:0004 argp:ST:0003
17:01:45	TMM	3:[2] regions::eachElementDo(0000:003c)
17:01:47	TMM	obj@000b:0134 pc=0004:0325 sp=ST:000c fp=ST:0009 argp:ST:0007
17:01:49	TMM	4:[3] rm100::doit()
17:01:51	TMM	obj@002b:0164 pc=0014:0234 sp=ST:000f fp=ST:000e argp:ST:000d
17:01:53	TMM	5:[4] sCartoon::doit()
17:01:57	TMM	obj@002b:04cc pc=002b:01ac sp=ST:0011 fp=ST:0011 argp:ST:0010
17:01:59	TMM	6:[5] Script::doit()
17:02:03	TMM	obj@002b:04cc pc=0004:06b5 sp=ST:0014 fp=ST:0013 argp:ST:0012
17:02:07	TMM	7:[6] sCartoon::cue()
17:02:13	TMM	obj@002b:04cc pc=0004:07f4 sp=ST:0016 fp=ST:0016 argp:ST:0015
17:02:15	TMM	8:[7] sCartoon::changeState(0000:000f)
17:02:17	TMM	obj@002b:04cc pc=002b:03f6 sp=ST:001a fp=ST:0019 argp:ST:0017
17:02:19	TMM	9:[8] sCartoon::<call[be]?>()
17:02:21	TMM	obj@002b:04cc pc=002b:0aa3 sp=ST:0022 fp=ST:001b argp:ST:001a
17:02:57	lskovlund	Is that where it fails?
17:03:06	lskovlund	(is that all?)
17:03:11	TMM	yep
17:03:14	TMM	this is it
17:03:27	TMM	this is during the intro
17:07:59	TMM	anything good in there? :)
17:08:28	creichen	Another argument for not doing doing a straightforward disassembly/reimplementation is that it won't solve the timing issues (OK, we only solve some of them, but it seems to help).
17:10:55	TMM	I don't think they would be very hard to spot
17:11:22	TMM	plus, I am just thinking :)
17:11:44	TMM	say one would be so inclined to start to work on freesci, what can you actually do?
17:12:10	TMM	I mean, you either implement, or you document, right?
17:14:37	lskovlund	creichen: Are Display() saved rects garbage collected?
17:16:04	lskovlund	Something weird is happening to the bitmap Display() has returned.
17:19:06	syke	TMM: it is possible to do both, if you come at it from writing unit test scripts as I mentioned before
17:19:27	syke	but for a given algorithm or feature, if you reveng it, you shouldn't implement it
17:20:51	TMM	is there a formal document on this?
17:21:23	lskovlund	lskovlund wants some sleep
17:21:39	lskovlund	Sorry, FreeSCI release isn't happening tonight.
17:21:47	lskovlund	Nothing to see here, move along.
17:21:55	lskovlund	left
17:24:15	creichen	OK, fixed MVI detection.
17:24:17	creichen	Ah crap.
17:24:18	creichen	Oh well.
17:26:58	creichen	For the log:
17:27:23	creichen	lskovlun: Display() doesn't actually return saved rectangles. IIRC, it returns a "snapshot" of the widget state and allows all widgets added later to be unrolled.
17:27:29	syke	creichen: MVI?
17:27:52	creichen	An instruction set extension for the PCA56 and later Alpha CPUs.
17:27:59	creichen	We use it for optimised cross-blitting.
17:28:04	syke	I'm not seeing subversion emails for some reason..
17:28:06	syke	ah yes
17:28:26	syke	creichen: any ideas about TMM's problem that lars was debugging?
17:30:22	creichen	Depends on what kernel call 1 is...
17:30:29	syke	I'll get started on a palette config for KQ4
17:30:43	creichen	UnLoad()...
17:31:50	creichen	UnLoad on offset zero of a script segment. Quite odd... normally, scripts are identified by script number.
17:32:53	creichen	I wonder whether this is a stale reference. A GC bug is not out of the question.
17:33:06	creichen	TMM: Could you check whether altering the GC interval addresses the issue, please?
17:34:55	TMM	exactly where do I do that/
17:35:00	syke	creichen: you'll have to tell him how to do that, probably
17:35:04	syke	heh, jinx :)
17:35:16	creichen	Yes, I'm looking for the precise steps at this very moment ;-)
17:36:25	creichen	Start up with the debug console enabled (parameter "-D").
17:36:42	creichen	Then type in "set gc-interval 1000000000"
17:37:09	creichen	Press carriage return.
17:37:20	creichen	Enter "go" and press return to resume running.
17:37:33	creichen	This should effectively disable gc, unless you run for very, very, very long periods of time.
17:38:16	creichen	See whether you can reproduce the bug. If you can not, it's a gc bug. If you can, we can rule out the gc algorithm itself as cause of the problem.
17:38:29	TMM	ok
17:38:31	TMM	just a sec
17:39:19	TMM	need to recompile again ;)
17:39:46	TMM	this whole command line business is a whole lot less work
17:40:19	creichen	I'm not following you...?
17:40:52	TMM	[KERN] Could not determine type of ref 002f:0000; failing signature check
17:40:52	TMM	[VM] Invalid arguments to kernel call 1
17:40:52	TMM	acc=0000:0000 prev=0000:0000 &rest=0
17:40:52	TMM	pc=002b:0aa3 obj=002b:04cc fp=ST:001b sp=ST:0022
17:40:52	TMM	Step #171984
17:40:53	TMM	0aa3: 43 01 04 callk UnLoad[1] 04
17:40:57	TMM	Kernel params: (0000:0085, 002f:0000)
17:41:07	TMM	sorry :(
17:42:56	creichen	No worries!
17:43:10	creichen	I guess this means that you're still getting it?
17:43:52	TMM	yeah
17:45:39	creichen	OK, no gc, then.
17:48:36	creichen	Tricky. It might be some kind of presently unsupported semantics...
17:48:41	creichen	...Lars would be the one to ask about this...
17:49:31	creichen	...though this is somewhat unlikely, as 0x85 is a valid resource type.
17:50:52	TMM	how would I (having no previous SCI experience) go about debugging this?
17:52:25	creichen	First of all, I should note that it seems to me that there's a bug in the UnLoad code: When determining the resource type, we do not test for and then strip the leading 0x80. We don't really need to do that anyway.
17:52:49	creichen	We could just try relaxing the signature constraints on UnLoad to see whether that then works.
17:53:11	creichen	TMM: First, you need to understand the problem, and what FreeSCI tells you about it.
17:53:18	creichen	The problem is a "failed signature check".
17:53:40	creichen	The SCI VM uses low-level VM operations, but also a small library of "kernel calls".
17:54:44	creichen	Now, to remove clutter in the implementation of these kernel calls (while still retaining some amount of safety), we're checking all parameters that go into a kernel call to see whether they match the expected parameters for that call.
17:54:48	creichen	This is called the "signature check".
17:55:08	TMM	sounds reasonable :)
17:55:15	creichen	Its implementation is in src/engine/kernel.c.
17:55:21	TMM	but, why the distinction?
17:56:00	creichen	Please give me a second while I check up some background facts...
17:58:28	creichen	Ah. src/include/kernel_types.h contains the definitions of the various characters.
17:59:10	creichen	So, "UnLoad" takes, as parameters, "i.*", which means one integer (determined by being in segment 0) followed by zero or arbitrarily many other things.
17:59:22	creichen	This is odd, because it should let your call pass.
17:59:51	creichen	Which distinction?
18:00:23	creichen	If we have a look at the other error message, "Could not determine type of ref", we see why this is: The dynamic type of the object 2f:0 could not be determined.
18:01:45	creichen	So what you now want to do is to (a) figure out where the system decides that it doesn't know the dynamic type of this object, and (b) figure out what this dynamic type is supposed to be.
18:03:08	creichen	For the "where", you may want to start with kernel.c, function "determine_reg_type()", which is in charge of such matters.
18:03:25	creichen	We'll worry about (b) when we get there.
18:03:43	creichen	Another useful piece of information is how precisely this value 2f:0 came into being in the first place.
18:04:15	TMM	ok, I will try
18:04:29	creichen	This may be due to an unsupported or poorly supported vm operation or kernel call.
18:04:30	TMM	I suppose it should be doable, expect a lot of bugging from me :)
18:04:44	creichen	All right ;-)
18:05:26	waltervn	No release today then...
18:05:48	creichen	Could someone please double-check a minor patch for 'stable'?
18:05:49	waltervn	that means I still have time...
18:06:10	waltervn	creichen: sure
18:06:33	syke	creichen: sure
18:06:40	TMM	ow 'stable' that sounds encouraging
18:06:42	TMM	:)
18:06:45	syke	btw, still haven't seen subversion emails for the other commits you mentioned
18:06:54	creichen	http://www-plan.cs.colorado.edu/creichen/freesci/mvi.diff
18:06:57	syke	TMM: as you can see, glutton is Not stable ;>
18:07:38	creichen	glutton doesn't distcheck ATM.
18:07:41	syke	creichen: looks good to me
18:07:55	waltervn	glutton does many things that make me go "huh?!" at this point. :)
18:08:07	creichen	gfx_test.c is broken. Will fix this momentarily.
18:08:27	waltervn	gfx_test.c has been broken as long as I can remember. :)
18:08:32	creichen	Then I'll go home and make some food, though I should be around enough to answer questions ;-)
18:08:39	creichen	syke: Thanks, then I'll commit.
18:09:36	TMM	creichen, thanks
18:30:23	creichen	0.3.5pre2 is working fine on DEC Alpha EV5 with both DEC cc and gcc.
18:34:15	Fingolfin	left
18:36:12	creichen	Similarly glutton on DEC cc. Compiling gcc...
18:51:28	creichen	The gcc build dies with a floating point exception. Compiling on this thing takes disturbingly long...
18:51:57	creichen	-mieee ought to fix that (it's a problem in the sound subsystem, in case you're wondering-- not sure where the floating comes into the points there, though).
18:52:14	creichen	I'll check that build tomorrow, seeing as we're not releasing today anyway.
18:54:13	creichen	afk for ~15 minutes.
19:02:59	syke	ok
19:15:55	creichen	back
19:22:36	syke	re
20:35:02	weedar	left
20:41:16	waltervn	left
20:42:58	waltervn	joined
20:47:21	syke	heya walter
20:47:59	waltervn	hey
22:21:57	waltervn	left
23:45:12	syke	phew
23:45:16	syke	finally done with qg1

---

All time information in the left column in UTC.