Re: [AD] Todo?

[Shawn Hargreaves <shawn@xxxxxxxxxx>]

George Foot <george.foot@xxxxxxxxxx> writes:
> > I'm trying to figure out exactly how much work remains to be done before 
> > we can call this a 4.0 final version, and came up with the following.
> 
> Ten weeks later on, and it's just about there. :)

It's the old 90/10 rule again. It seems like just a few weeks got us up and 
running on all these funky new platforms, but then it takes forever to sort 
out all the stupid little piddly details :-)

> Regarding the notation, I don't think there is a consistent way to do it, 
> and anything we do will break backward compatibility.

Actually, I think it's really easy! Having just gone back to look at this, 
it occurs to me that I know exactly when I'm reading from a sub-chunk file, 
so I know exactly when to skip the header ID. It's actually really trivial 
to fix: I've written a test program (attached) which tries every possible 
loading method I can think of, and works correctly with my patched datafile 
code (I won't include the patches, since I'm almost ready to upload a new 
WIP anyway). Let me know if you can think of any cases that this script 
fails to test...

> I think `nested' should be in binary format, but IIRC that's not how it 
> works at the moment -- `nested' has to be a non-binary datafile.

I'd rather never have things in binary format: it's actually quite hard to 
get them that way (you have to give special options to dat and grabber), and 
as long as it's possible to make loading work, it seems more consistent to 
always use the single format. Of course the most consistent would be if the 
format was properly recursive without stupidly changing those few bytes in 
the header, but oh well :-) I think this should always work now, anyway.

> but this might not be trivial because packfiles are essentially linear -- 
> the chunks of the nested datafile's objects are chunks at the top level of 
> the file, not within the nested datafile's chunk. Is that correct?

No, it's a fully recursive system. The only difference is that at the very 
start of the whole file, there's a 32 bit ID number which is tested before 
it starts the recursive bit, and I didn't duplicate that ID for all the 
nested files.

> > It would be nice, now that the code has stabilised a bit, to get Mingw32 
> > building a native version of the DLL.
> 
> Was Henrik working on this? 

I believe so.

> It might be nice to do the same for RSXNTDJ, which could be based on the 
> same code to a large extent. 

For sure. The windows version has suffered a bit since Stefan vanished, as 
all the other more experienced developers are Linux people, so I've just 
been fixing stuff in the Windows code out of duty more than because I 
actually care about it :-) But things are starting to look up over this 
last few weeks, as people like Keith Gerdes and Isaac Cruz have started 
sending me cool patches for the Windows code, so maybe this isn't entirely 
hopeless :-)

I do remember reading that RSXNT had some nasty problems with the DirectX 
headers, as they use some very weird stuff that required a few gcc tweaks to 
work at all, and I think Mingw32 has been following those changes more 
closely than the djgpp compiler builds, but that info is probably five years 
out of date by now. I might install RSXNT or Mingw32 sometime if I run out 
of other things to do, but I want to get the MSVC version working 100% 
before I start spending time on other compilers.

> > There is no MIDI support at the moment: how hard would this be to add?
> 
> I have a non-OPL sound card, so I could perhaps look in to it,
> if nobody else is doing so already.

Peter did a driver for the OSS FM interface, and looking at this, it seems 
like it would be quite easy to extend for supporting wavetable MIDI and 
output to external devices. Unfortunately Linux doesn't want to know about 
MIDI at all on my card :-)

> Gorka wasn't happy about the current RPM system -- should we change it? 

I have no opinion: since I don't tend to install RPM packages myself, I'm 
the wrong person to comment on this.

On the one hand, I can see his point that the current system is a hack, and 
if we are going to do that, we might as well just give them a .tar.gz along 
with an install.sh, which would have the exact same effect.

But on the other hand, the one thing I do feel quite strongly about is that 
binary distros are a bad idea. Or at least that I don't want to be involved 
with them: ie. I don't want to have to produce them myself, or answer all 
the questions from people who can't get them working.

In other words, however the RPM-using people would prefer this to be done is 
fine by me, with the caveat that if it involves binary versions, someone 
else has to be in charge of that part of it, so I can disclaim all 
responsibility for the results :-)


--
Shawn Hargreaves - shawn@xxxxxxxxxx - http://www.talula.demon.co.uk/
"A binary is barely software: it's more like hardware on a floppy disk."

Attachment: datafile_tests.zip
Description: Zip archive