1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147
|
/****************************************************************************
* A small example for demonstrating HGL
*
* (c) 2013 Heiko Schäfer <heiko@rangun.de>
*
* DO NOT MODIFY THIS FILE, USE A COPY AND KEEP THIS FOR REFERENCE
*
* KNOWN BUGS/LIMITATIONS IN HGL:
*
* - changing the aspect ratio will currently destroy the fill of polygons
* - not all object types support gradient fill
* - text is limited to real pixels, not the virtual coordinates used elsewhere
* - many others I would be glad to get reported about
*
***************************************************************************/
project EXAMPLE {
objects {
/**
* In section 'objects' HGL will perform following steps:
*
* 1) the compiler collects all declarations and writes them into the binary
*
* 2) the interpreter collects all objects declared in this section for postprocessing
* (will be provided in a future relase) and finally rendering
*
* In general objects are rendered with the uppermost in the source first
* and the downmost rendered last, i.e. the downmost appears on top of the image,
* all other behind it in the order of declaration
*
**/
// this point is not drawn, because it has no color, so it is a
// marker point which gets used for calculating the bounding box
// so the triangles are not touching the pictures edges
point BoundingBoxUpperLeft (0, 0);
point BoundingBoxLowerRight (64, 48); // the default pic size is 640x480
// if you change the output size, take factors of it
// to get nice output (known bug to get fixed soon)
ellipse anLeftEllipse {
point center (12, 24) #FF1BCA;
(10, 15) // te x,y radius of the ellipse
fill { // a color statement
#0000ff #00ff00 // from blue to green
}
}
poly aTriangle {
line a {
point p1 (32, 1) #ff0000; // a gradient from red
point p2 (1, 47) #0000ff; // to blue
}
line b {
point p1 (1, 47) #0000ff; // a gradient from blue
point p2 (63, 47) #00ff00; // to green
}
line c {
point p1 (63, 47) #00ff00; // a gradient from green
point p2 (32, 1) #ff0000; // to red
}
fill {
#00ff00
}
}
ellipse aCenterCircle {
point center (32, 24) #8B8B00;
(23, 23) // NOTE: a circle can be drawn by equal x,y radius
fill {
#8B8B00 #000000
}
}
ellipse anRightEllipse {
point center (44, 24) #FF1BCA;
(15, 10)
fill {
#000000
}
}
poly aPolygon {
line a { // red line (both points are the same color)
point p1 (1, 1) #ff0000;
point p2 (32, 20) #ff0000;
}
line b { // black line (both points are the same color)
point p1 (32, 20) #000000;
point p2 (40, 14) #000000;
}
line c { // black line (both points are the same color)
point p1 (40, 14) #000000;
point p2 (63, 24) #000000;
}
line d { // blue line (both points are the same color)
point p1 (63, 24) #0000ff;
point p2 (32, 46) #0000ff;
}
line e { // green line (both points are the same color)
point p1 (32, 46) #00ff00;
point p2 (1, 1) #00ff00;
}
}
text aText { // NOTE: for the moment Text can only work with real pixel coordinates
"Hello HGL World" // the text to render
"Comic Sans MS" // the font face or alternatively the full path to the font file
30 // the font size (height) in pixels
(10, 40) // the x,y position in real pixels, note to currently add the font size to y
#bbbbbb // last but not least the color of the font
}
}
main {
/**
* In section 'main' HGL will perform following steps:
*
* 1) - in the compiler run it is parsing this file and namespacing all identifiers
* this is useful for future releases there the HGL language is implemented and
* to refer to this objects and sub objects
* - the compiler is creating a compact binary for interpreter, therefore if
* the interpreter is run often with the compiled binary it doesn't need to get
* parsed all the time. In future I may will provide an Win32 binary which combines
* this to steps. On Linux this is not neccessary, because we can use piping for it
*
* 2) - the interpreter "evaluates", i.e. analyses all procedures (will be provided in a
* future release)
* - than it executes the functions the in the main function, i.e. the debug, render
* and all self defined procedures (will be provided in a future release, too)
* - than it collects all evaluated primitives and adds them into the render queue and
* calculates the bounding box for correct scaling and positioning
* - last but not least it renders out the image either on the debug console (option -S)
* or in the specified image format (option -O) of one of the available plugins
**/
render(); // finally render the picture
}
}
|