Euclid (Ace Computing)

From Just Solve the File Format Problem
Jump to: navigation, search
File Format
Name Euclid (Ace Computing)


Euclid was the name of a 3D editing application for RISC OS systems (not to be confused with the Euclid CAD software). Euclid files (file type DE1, Euclid) share some features with Draw files but appear to be structured differently.


Assuming use of 2 and 8 to indicate move and draw, as in Draw paths; use of 6, 0x106, 0x206 to mean a Bezier curve. Three coordinates per operation.

Values at 0x00 and 0x30 appear to differ by 0x5c.

   0x0:    value_0
   0x4:    0x12
   0x8:    0
   0xc:    0
   0x10:   0

Names of objects appear in the files. These are often preceded by values like these:

   0x40000001  !Camera\r
   0x31000002  CamDef\r\r
   0x32000002  S0srros\r

Each file appears to start with a root object at 0x50:

   0x50:   0x4000000a  $\r
   0xc0:   0x40000004  $\r
   0x50:   0x40000004  $\r
   0x90:   0x22000005

Some objects have names:

   0x50:   0x40000010  $\r
   0xf0:   0x40000004  $\r
   0x6f8:  0x40000002  Folly\r
   0x82c:  0x40000003  FollyBase\r
   0xb20:  0x40000001  !Camera\r
   0xe20:  0x40000001  CSros\r
   0xfcc:  0x40000001  SRros\r
   0x11a8: 0x40000001  SLros\r
   0x1210: 0x40000001  MusoRos\r
   0x13bc: 0x40010001  trellis\r
   0x1a8:  0x32000002  SeatFloor\r
   0x27c:  0x32000002  SeatsA\r
   0x350:  0x32000002  SeatsEnd\r
   0x474:  0x32000002  StageFloor\r
   0x568:  0x32000002  Bank\r
   0x157c: 0x32010002  S0trellis\r

Some objects contain what appear to be paths, with Draw-like path objects:

   0xff4:  0x22000010  ; path (0x22) with (0x10) points defined (including
                       ; control points)
   0xff8:  0x00000002  ; move
   0xffc:  0x00000041  ; x
   0x1000: 0x00000166  ; y
   0x1004: 0x00000000  ; z
   0x1008: 0x00000006  ; Bezier curve endpoint
   0x100c: 0x00000034  ; x
   0x1010: 0x000001a0  ; y
   0x1014: 0x00000000  ; z
   0x1018: 0x00000106  ; Control point 1
   0x101c: 0xfffffffc  ; cx1
   0x1020: 0x000001c4  ; cy1
   0x1024: 0x00000000  ; cz1
   0x1028: 0x00000206  ; Control point 2
   0x102c: 0xffffffc2  ; cx2
   0x1030: 0x000001b7  ; cy2
   0x1034: 0x00000000  ; cz2
   0x10f8: 0x22000002  ; next path with 2 points defined

0x22...... objects appear to only contain command,x,y,z data, so the length of the data appears to be a multiple of 16 bytes.

0x32...... objects are named objects that contain a number of other objects, the first of which appears 0x6c bytes from the start of the object, though it is possible that there is an 0x50000000 object that appears 0x4c bytes after the start and this contains 28 bytes of its own. This may be excluded from the object count.

0x40...... objects are named objects that contain a number of other objects. There appear to be a number of pairs of words at the start of the object that correspond to the number in the opening identifier. Definitions follow these words:

   0x50: 40000004 00000d24 00000000 00000000   ; 4 objects, name $\r
   0x60: 00000000 00000000 00000000 00000000
   0x70: 00049acc 00049a80 00049ba0 00049b54   ; 2 objects (8 bytes each)
   0x80: 00049c74 00049c28 00049c94 00049c28   ; 2 objects (8 bytes each)
   0x90: 22000005 00000002 fffffdc7 ffffffff   ; first object

These seem to be addresses like the ones found at offsets 0x0 and 0x34 in each file.

0x50...... objects appear to contain 7 words and appear in addition to the declared number of objects inside another object.

0x3201.... objects appear to be defined like 0x3200.... objects and this therefore means that identifiers may be defined like this:


where tt is the object type, ss is the subtype and llll is the number of objects/elements it contains. However, 0x3201.... objects appear to lack objects inside them except for 0x50000000 and 0x50010000 objects.

0x31...... objects appear to contain the specified number of 0x21...... objects in their header, plus a 0x5000.... object, followed by the specified number of objects.

0x21...... objects appear to be collections of 20 byte data structures.


Personal tools