Euclid (Ace Computing)
Euclid was the name of a 3D editing application for RISC OS systems. 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:
(files/Location) 0x50: 0x4000000a $\r ... 0xc0: 0x40000004 $\r
(files/Seating) 0x50: 0x40000004 $\r ... 0x90: 0x22000005
Some objects have names:
(files/SET) 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:
(files/SET) 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:
(files/Seating) 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.