Re: [Shapefusion-devel] status

[tiennou <tie...@gm...>]

Le 23 f=C3=A9vr. 07 =C3=A0 15:51, ti...@da... a =C3=A9crit :

>> I'm in a big need of help there, because I'm thinking of
>> Object-  Orienting the Marathon structs so I could just
>> write   ShapesDocument::LoadObject(), and it will issue
>> ShapesChunk::LoadObject(), which will work as a a chain...
>> I need   some help from you to (re)do that.
> Mumble... Chunks are well-defined, self-consistent,
> independent data blocks.  ShapesChunk::LoadObject() would
> need an offset and size to load its chunk, then it could
> just grab the data block from the stream and decode it (like
> happened with BigEndianBuffer). So I guess
> ShapesDocument::LoadObject() could first load the 32
> collection headers and then issue as many
> ShapesChunk::LoadObject() as needed, giving them the right
> offsets and sizes. I hope wxDoc supports random stream
> access!

I've almost completely moved to the new ShapesDocument architecture. =20
Things left to do are :
- calculation of scale factors
- the part involving CalcActualNumberOfViews
- debuggin'

Actually, this goes this way :
ShapesDocument::LoadObject is called with a wxInputStream as =20
argument, which call COLLECTIONS_PER_FILE times =20
ShapesCollection::LoadObject.
ShapesCollection::LoadObject looks for offsets/lengths, create one or =20=

two ShapesChunk, passing it offsets and lengths, then calls LoadObject.
ShapesChunk::LoadObject load ShapesColorTables, ShapesBitmap, =20
ShapesSequences, and ShapesFrames, passing them offsets and calling =20
LoadObject on them.

> However, couldn't you just reproduce what Shapes::Shapes()
> did inside ShapesDocument::LoadObject()? That code is well
> tested.

This is a straight copy of code from Shapes::Shapes() and =20
Shapes::LoadShapesChunk(), converted to use wxInputStream for random =20
access (and wxDataInputStream for data reading).
The few problems I have is errors, as I don't know what I should do =20
when something goes wrong... I thought of using exceptions, but =20
implemented mGoodData to stick with what was done.

>> I'm also trying to remove everything std (vectors
>> principally) and   changing them into wxList subclasses to
>> ensure portability... It   won't be a problem for you ?
> Well I think std is more portable than wx. But it should not
> be a problem. Are you also using wxFile instead of std
> streams?
Yes, wxInputStream, because the wxDocument::LoadObject methods uses =20
this, from which I create a wxDataInputStream, for big-endian loading =20=

of data.
I've had some problems with long, so I switched these to wxInt32

> I guess we are actually rewriting ShapeFusion from scratch.
> Will *Browser and *View classes work? I really hope so.
I'll take a look at these as soon as I'm able to open Evil shapes =20
without a "This may not be a Marathon Shapes file" ;-).
But since the layout is basically the same, it should not be a problem.

I'm commiting my work right now so you can have a look...

tiennou