HGL - a graphics language

[Velnias75]

Hi,

it just began as prove of concept, but now I would like to continue on an personal project, since it slowly gets quite usable.

It is a "programming language" for generating resp. rendering pictures based on the HGL language.

I tried to find some people taking a look over it via my "friends" on Facebook, but absolutely everybody there seems to ignore it. Only my sister struggles with it, but she is no big help, because she has even problems to tile to windows horizontally, i.e. she is not good with new things to do on a PC.

So, I try to find some people to take a look, give comments, critics and bug reports here.

The public Facebook note is here: https://www.facebook.com/notes/heiko-sch%C3%A4fer/hgl-0416svn-f%C3%BCr-windows-download/402075729876951

The direct download is here: http://www.rangun.de/hgl-0.4.16~svn.zip (3.6 MB)
MD5: 4aa5cdcf2429be143079a3b498df5602

The ZIP contains all dependent DLLs too, so you can either start it from the directory itself or just copy missing or if newer DLLs into the system.

The note is in German language, but the link is below in the note and HGL itself is in Englisch. It is currently a Windows version, but since all development is done on Linux I can provide Debian und Ubuntu packages on demand.

Every questions, remarks and comments we can discuss in this thread.

[MiiNiPaa]

I think it belongs to Lounge.

[Velnias75]

Now it is in the lounge, but I had the aim later to get the discussion into implementation details as well.

[chrisname]

So, is it something like a shader language but for general graphics rather than just shaders? Like HLSL/GLSL? Got any code examples?

[Velnias75]

Oh my goodness no! It is an independent application, resp. a set of two independent applications. A compiler and an interpreter.

Proof of conecept means to design a program from the first line to the last line based on design patterns, reusability of code, effective implementation of algorithms, extensibility by plugins, portability as well as the pure theoretical compiler building.

All together I try to bring into an application which finally is of some use. In my mind i.e. are websites which want to generate dynamically more or less complex pictures with the possibility of controlled interaction by a user. But the scope of use I finally let open.

Currently it has 7396 LOC of pure C++ code. EDIT: The bison and flex code excluded. I use cxxmatric for quick metrics and it cannot handle this two. The Bison source has an estimated LOC of 400 and the Flex source an estimated LOC of 80.

An example hgl input file looks like this:

/****************************************************************************
 * A small example for demonstrating HGL
 *
 * (c) 2013 Heiko Schäfer <[e-mail]>
 *
 * 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
	}
}

[L B]

Velnias75 wrote:

Proof of conecept means to design a program from the first line to the last line based on design patterns, reusability of code, effective implementation of algorithms, extensibility by plugins, portability as well as the pure theoretical compiler building.

Design patterns are created because a language has a problem that allows you to write code without the design pattern and have poorer result than when using the design pattern. In other words, the more design patterns associated with your language, the more problems you language has. The goal is to design a language that does not make people want to say "I need to use a design pattern for this."
http://stackoverflow.com/questions/1579162/are-design-patterns-really-language-weaknesses
By "design pattern" I mean "the boilerplate code you have to write over and over"

[Velnias75]

@L B: I guess you misunderstood me, the code of the applications, the compiler and interpreter are using this concepts. The language itself should stay as easy as possible, but powerful enough to create images, complex or not.

For the moment I want feedback on the product as it is, not how it is implemented. This was only additional information on the history of it.

But of course, if somebody is ambitious enough, I'm at a level where help is appreciated.

EDIT: found the time now to read on stackoverflow.com (one of my fav sites too). Ok, it seems not all people are fans of DP, but the GoF stated in their book they didn't invented them, but just want to make them a catalogue for easier communication between developers. Just read the final chapters of the book too.
Many developer used patterns without knowing how to name them, now there is terminology where people have the same "language".

But actually this is too much offtopic and I'm willing to discuss DP in another thread. Here I would prefer to stick on HGL.

[NGen]

The source code looks like some sort of structured HTML5 canvas rendering in JavaScript.

What sort of support do you plan on adding for animations? What would the syntax of this animation look like? Is this just a language to define a scene that must be manipulated within another language, or is this an entire language that can be ran on its own?

[Velnias75]

Actually it is of sort "entirely developed by Heiko without looking left or right" ;-)

In fact, I just developed the language according the needs to perform its task. So I'm happy it looks like similar to something known.

In this example all regarding the "real" programming language is missing. My personal test file for it looks so horrible nobody can imagine, because it has to test the parser to its limits.

This example was developed to give users an insight what and how is possible currently with HGL. Therefore it is missing the complete procedure definition part and focuses only on rendering to get an image out of it. You can try this example with the download I put in my first post. It will render you a picture in currently one of three (as plugins) implemented output formats: JPG, PNG, and PPM.

BTW: the comment style, of course, is copied from the C++ comment style.

[Velnias75]

@NGen: animations are a bit far away now. HGL renders normal bitmap pictures, but sure, with help I could produce a sequence of images to support animations, maybe even with a plugin for direct video output.

But so far I'm not with my project. I have even to improve the rendering engine, since it has sometimes some problems with floating point calculations.

Your second question: it is planned as an independent program, but it is separated into libraries which can be linked to every app who wants to. Look at the binaries: the executables are ridicously small, because all is within the DLLs (Windows) or the SOs (Linux).
The separation into libs at the moment is for a GUI if somebody is helping me to develop one.


Graphics programming is a new field for me, which have chosen because of all the algorithms which are unknown to me yet. I like algorithms, to understand them and finally to implement them, therefore, except font rendering all graphics algorithms are implemented by myself and to my surprise even quite fast and efficient.

[naraku9333]

Can you explain the usage? Will you be releasing the source?

[Velnias75]

It is a console application (for the moment). Usage is quite simple. Here is a typical line I use often for testing:
cat src/examples/example.hgl | debug/src/compiler/hglc | debug/src/interpreter/hgl -O png > /tmp/example.png (without line break of course).

In that case I input via stdin the source, compile it to stdout and again use stdin as input to the interpreter and redirect stdout to the generated file. Of course specifying input and output as files is possible too:

debug/src/compiler/hglc src/examples/example.hgl -o /tmp/example.hglz

debug/src/interpreter/hgl /tmp/example.hglz -O png -o /tmp/example.png

About distribution I'm quite unsure at the moment. So I give away source code not to the general, but to people willing to audit it, submit patches and giving feedback to me. A friendly PM should be enough ;-)

One note on the example code: I forgot to show that references work quite well already, even if their full power if the programming language is fully implemented. Replace starting line 107:

line e { // blue to green line
	// a reference to another point is prefixed with @ followed by the full path
	// to the referenced point. In that case we connect point p1 as reference to
	// point p2 of line d in polygon aPolygon
	point p1 @aPolygon.d.p2;
	point p2 (1, 1) #00ff00;
}

EDIT: on usage using option -S or omitting -O to get it it on stderr, you can get a dump of the internal structure. I personally prefer -S to easily redirect it into a file.
The option -? shows all available options.

[Velnias75]

New Version uploaded: http://www.rangun.de/hgl-0.4.13~svn.zip (3.5 MB)
MD5: b793f36b29d2341f8259a079b345f77c

Changes are:

* in the last build there was a "duplicate section has different size" linker error, so recompiled it from scratch
* consequently added line numbers to warnings and errors in the compiler

[Filiprei]

Please don't make this a blog, it will remind me too much of a certain other thread in this forum...

[Velnias75]

Please point me out where it is like a blog. The last post was only an announcement.

[Filiprei]

I didn't mean that this is a blog, I was just saying that if you make to many announcements people will get annoyed and call it a blog. Don't worry though, the people at cplusplus.com is very forgiving. Good luck with the project. I am not that advanced yet so I can't comment much on the project itself.

[Velnias75]

Ok, the announcement was because the app could crash on some or all systems, so it was important to provide that.

I have to admit, I rarely test it on Windows, but thouroughly on Linux. So by accident I saw that linker error and wanted to provide a surely working version.

For the people worrying now: only 2 parts are Windows specific and this parts are tested on Windows.

@Filiprei (especially): you can also contribute just by trying it from the view of a user and reporting back your experiences.

[Zereo]

@Velnias I think the whole point behind Filiprei posting what he did was because just recently we had a forum post by someone called Jackson Marie (then changed her name to something else) that was about 20 pages long with like 300+ posts and about all them posts was her just giving useless updates to everyone here that we couldn't understand because we didn't have the source. She just recently got banned. You can probably still see the thread in lounge (I think?).

So don't think he ment any offense or anything.

[Velnias75]

I would like to remove some legacy bytes in the compiled binary, because they are now obsolete.
Who started working with HGL and would be annoyed by that? Otherwise I think as early as possible to get the binary stable, would be better than to force to recompile all their projects with Version 1.0.

Version 1.0 is without compromise the release where I would introduce the last neccessary changes to the binary and from that release all following would stay compatible.

[chrisname]

What would you be removing?