You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Shockwave file format includes many common patterns/structures and is somewhat consistent with them. For example, arrays and some smaller common structures ones such as Point, CastMemberId and Rect are represented using common structure in binary. In addition to those, most "complex" and important one of them is internally called VList aka "Vector List". It's not actually "complex" but just annoying to write (de)serialization logic for and I have been thinking how to handle them best for few years now. VLists appear in many important resources of the file format, such as Cast member metadata (VWCF, later embedded to CASt) and Cross Cast Links (ccl ) and more.
Now heavily inspired by csnover's earthquake-rust pvec! macro (seriously, this man's a genius!), I'm planning to implement something similar to make the handling VLists significantly easier by using build time Roslyn source generation.
This issue is just a tracking issue for my design for this model which is a work in progress.
TODO: Design
Basically VLists consists of header and a offset table that points to entries in following it.
I'm also currently in process of designing a source generation process for all the Lingo bytecode instructions which will share components with this but still essentially be seperate generator.
The text was updated successfully, but these errors were encountered:
Some source generation infrastructure is in place and currently used for Lingo instruction generation which is much simpler than generalized (de)serialization. This will essentially require developing a value type model which is constructed from Roslyn AST.
The Shockwave file format includes many common patterns/structures and is somewhat consistent with them. For example, arrays and some smaller common structures ones such as
Point
,CastMemberId
andRect
are represented using common structure in binary. In addition to those, most "complex" and important one of them is internally calledVList
aka "Vector List". It's not actually "complex" but just annoying to write (de)serialization logic for and I have been thinking how to handle them best for few years now.VList
s appear in many important resources of the file format, such as Cast member metadata (VWCF
, later embedded toCASt
) and Cross Cast Links (ccl
) and more.Now heavily inspired by csnover's earthquake-rust
pvec!
macro (seriously, this man's a genius!), I'm planning to implement something similar to make the handlingVList
s significantly easier by using build time Roslyn source generation.This issue is just a tracking issue for my design for this model which is a work in progress.
TODO: Design
Basically VLists consists of header and a offset table that points to entries in following it.
I'm also currently in process of designing a source generation process for all the Lingo bytecode instructions which will share components with this but still essentially be seperate generator.
The text was updated successfully, but these errors were encountered: