INsanityDesign

The issue tracker is overflowing and the deadline is inexorably coming near: The milestone 4 build has to be reached! Feature-set B15 has to be fully implemented and needs to be QA approved but bugs still occur and some features haven’t even been worked on. Everything needs to be crunched in there somehow as bug fixing is not limited by the announced feature freeze… and so it happens that you go into overtime!

Because of actual events in my last weeks and months this topic just pops up again and again with me: Crunch and Overtime! Nowadays, these are even accepted as “normal” in not only Games but general IT and Development. I know only few other industries and departments that take crunch-time for granted… especially in the end of any project.

As soon as overtime happens it is already too late. As no project manager (should) plans with crunch-time something went wrong if it happens anyway. In some cases this is not necessarily bad. Most people do what they do, work at what they work because they like the challenge, they like the environment… they just like what they do.
But no matter how much you love your work, after 12, 18, 24 hours day after day after day no Red Bull nor a single good night sleep can help to keep you really focussed and up to the task that you are actually on.

I do not want to go into detail why something like overtime happens but there are some things professionally and socially that I observed over the last years and especially months I want to share if you have to crunch to release a feature in dependency with others!

Documentation vs. Communication (or “State the obvious”)

Pressure pushing down on me
Pressing down on you no man ask for

It may be so easy: You get your Game Design, your Technical Design, Interfaces, Standards etc. defined and start developing from top to bottom. In the end everything works out, interconnected and your task is finished. Great!
This perfect world is pretty rare and in most cases does not reflect the “real life“. In most cases many things have to be reworked or clarified and therefore communication socially and professionally is one of the most important factors when it comes to development in larger teams.
Nevertheless, especially after 12, 14 hours of work or during a night the receptivity starts to lack the focus it needs for intense communication and dialogues. People start starring at their displays trying to get around that one oddness or gaze into the coffee/energy drink creeping over the floor. People that normally question anything start developing “till the end” and not “to finish a task successfully” meaning they “crunch” all what is left into their current objective, finish it up as quickly as possible top to bottom based on the docs… and as clarification takes time if the design itself can also be interpreted in a specific implementation kind of way: It will be!
So, in the end of any project, after many hours of work, during nights etc. try and start being pro-active: If you crunch with others, state the obvious! If you do overtime yourself, start questioning the most simple things! This may sound annoying but is most important as the most well-formed process is nothing worth after four+ weeks of crunching. Normal things like “Did you add the graphics of that item?” or “Have you added the i18n key?” are the first things that get lost as soon as a narrowed mind is focussing on fixing a bug or finishing up a feature.

Crunch in Overtime (or “The right Task at the right Time”)

Insanity laughs under pressure we’re cracking
Can’t we give ourselves one more chance

Don’t get me wrong: Sometimes overtime can be very healthy for a project and team if e.g. a small group of people focus on one small feature-set altogether and try to reach a goal in a given time frame. Tasks get crunched, time just passes by and everybody is happy (with some pizza and beer of course this can be a wonderful achievement).
Nonetheless, very often overtime is used or has to be used to finish up tasks that are unfinished or even untouched. This leads to crunching in all the different tasks that just have to be done before a milestone or deadline is reached. So, the overtime is used to clear out the issue tracker and not to finish what the main goal was.
If overtime happens use it wisely and plan what to do! You are not in your right state of mind after hours and hours of coding, drawing, layouting, … and deprivation of sleep can lead to similar effects as alcohol e.g. headache or dizziness. The efficiency may seem increased after some energy drinks but based on experience and code review… it is not! You cannot state a number but if the efficiency and focus is decreased, plan in some laborious work, some monotonic tasks, clean up and work off method sets etc. Complete new structures, concept arts (depends on the crazy creativity ^^), calculations or templates especially interfacing with others (see above) are detrimental. Crunching has to be planned and should not just occur!

Social Competence (or “To Develop is Human”)

Watching some good friends
Screaming ‘Let me out’

During daytime everybody is calm, touched by the sun, always having a smile on their faces. But after 15 hours from dawn till dusk the smile starts to vanish from their faces as the sun sets.
It is no matter how “nice” somebody is during the day: during overtime and crunching tasks every mood starts to swing. If set under pressure over weeks, sleepless for days and crunching code into a machine people get nervous and tetchy.
Now it is important to be sensitive. Not only developers, artists, … in-between but also a managing director has to apply his best soft-skills and pressurize focussed but appreciative. Even ironic jokes that would cheer up anybody during daytime can break loose hell if people spend 20 hours working on one bug! This emotional intelligence is a major issue when it comes to delegated work. Nobody intentionally tries to not finish any task so do not sound like this.
To loosen up a little and see the crunching time as a task of the team. Do not take it too serious… it is more important to sometimes just take a walk and have a little water cooler talk. I am a non-smoker but if it is getting dark it can be helpful to just go with the crowd and to keep together. Share thoughts, introduce pair-programming (if not already given, 200% more effective during overtime in my opinion) and try to help each other as together the longest nights can become the best stories for the next day.

Stay Focussed (or “Utopia is nowhere near”)

It’s the terror of knowing
What this world is about

In 90% of cases overtime and crunch-time happens because a goal has to be reached in time. A milestone, a release build, … whatever. Unfortunately, during crunch-time it often occurs that some people see this time as “additional” hours to use (see above). They try to achieve 200% and not to reach bug-free 100%. Such ideas come from management/directors but also from developers that tend to pressurize themselves. If they do not get to see their bed for days at least this time has to pay out.
Always be realistic about what the goal is and try to not loose focus of what can be achieved during this overtime. As stated above crunching should be planned and therefore plan against the origin of that specific overtime. If people are under pressure it is more important to eliminate all mush and narrow down what you want to achieve. Overtime pays out in work and even for the person itself if something has been achieved. A e.g. developer that works all through the night coding and coding without having achieved what he wanted in the morning is only half the developer for the coming hours and days. But if you clearly achieve your realistic goal you are happy and produce endorphins. Your body is powered up and you can shed any sorrows of work. This is the best sleep you will have for months!

Keep the Balance (or “The equilibrium of Life and Work”)

And love dares you to care for
The people on the edge of the night

Overtime happens and crunching some work, too. This can be manageable to some degree. But if your whole purpose in life is work and you are crunching everyday, hour after hour, seeing sunlight only as a reflection of your display you will “dry up”.
As much as overtime has to be planned (see above), the balance of overtime, crunching and regeneration has to be maintained, too. Otherwise the productivity and benefit of the additional time decreases down to a (negative) point of no return… yes, negative. At least in many cases I have seen, people actually fixed and created productive resources and code up to a specific point where the amount of positives fell below the amount of negatives. And this just happened over one day. When days went by the amount of time that produced good quality decreases and got inferior to the amount of time producing crap. And the most important issue is: Those errors have to be cleaned up, too!
This is something general and may sound corny but to keep a good Work/Life balance is most important and overtime is no contradiction to it. But crunched overtime needs different compensation to be regenerated. As mentioned, a good night sleep might not be enough for a 80 hours week. Fresh air, sunlight, healthy drinks and food are a necessity to “survive” not only the crunch-time but the time after (downfall).

Post Mortem (or “The Lessons we Learned”)

This is our last dance
This is ourselves
Under pressure

This is not necessarily something to keep in mind during a crunch-phase but afterwards. Always recapture what happened! Always try to learn from the lessons made! A retrospective or post mortem should help to pinpoint problems, miscommunication, bad planning etc. for the coming tasks and have to be used for positive and directed criticism.
A review about every process, not only meta or technical processes but also socially can help to suffocate future errors. Especially critique is hard to deal with and often taken personal. But what directed criticism (a director that guides the review is most important. Reviewing, not discussing when it comes to focussed critique) should provide is what we require to grow, to evolve. Because that is what we all want: To become better! It may sound unfortunate but people outside ourself often provide a better view on us than we ever can.
Therefore, always have a retrospective, a review, a post mortem, a lessons learned meeting, … call it whatever you (or your project management philosophy) like, but do it!

So, if we have a look at the lessons we learned:

• State the obvious
• Plan your overtime
• Be social
• Be realistic
• Keep a Work/Life balance

and always recapture your work!

All this may sound general and soooo obvious but after weeks of overtime, pressure from the management and the deadline coming near it gets lost pretty easy.
Overtime happens and sometimes it can even be fun to see “this one feature being finished”, “this one bug being fixed”, especially in a nice social environment. Nevertheless, if you have to crunch keep in mind that not everybody is in the right state of mind and always remember some general work rules… maybe even pin them on a wall in front of you!

Written for #AltDevBlogADay

I have to be honest: My C and C++ skills are bad! Besides some personal tries in my “early years” and lessons at the University I never had a good connection to the world of C. Nevertheless, I got my degree, became a developer, working for nearly a decade now in my young life and I call myself a successful Software Engineer, even developing games… but in Java, JavaScript and C#. So, my dreams of getting into what I love most (Gaming) became real, doing what I like all day!
But still I feel inferior to the “real” developers because of my bad C expertise and especially my personal ignorance to really focus on it.

All my history…

I got in touch with computers and gaming early in my life through my brother. I started with a C16, C64 and Amiga 500 besides my GameBoy until I got my first (nowadays) classic PC. I was always intrigued by what was possible, the magic, playing Pong, Maniac Mansion, Zork and watching Scene Demos and Cracktros from legends such as The Black Lotus or the Animators. I wanted to do the same stuff, I wanted to (text-)wander through my own forests, wanted to have colorful spinning balls on the screen… so I began learning how to do so.
I started off on the Amiga with Assembler, got into QBasic later, Pascal, Delphi (loved its structure), Visual Basic (quick results) and very early PHP (the Internet) through early Web-Development tests and HTML/CSS. About ten years ago I got into Java at version 1.1 and am still on it. At every Job I had before and during my studies I was able/forced to use Java and it kept that way until today. Besides Java I had a look at and use Python, Scala (what I like about Java+functional programming), Actionscript, … and even Perl (just in one project) out of personal interest or for personal stuff.
Just from my history my expertise developed early around object-oriented programming which appealed to me the most, so I stayed. Therefore, very early in my “personal development” my development expertise was already conquered by Delphi and Java that formed my view on OOP and general Application Development besides their originators being influenced by C++ (good or bad). But there were still the games I liked the most. So, I had to learn C and C++. Teach myself the language of my favourite entertainment.

Try, Fail, Ignore

I bought books about C, about C++, about Game Development, about DirectX, about OpenGL, got into boards, searched the net for every tutorial I could find, tried everything and even got some minor things to work so that something moved on my screen… and it was programmed in C++. But something clicked in my head, spreading bad thoughts such as:

• This could be easier!
• Linkage and IDE is clumsy, Eclipse is way superior!
• These design patterns are native in Java!

I read more and more, tried more and more and unfortunately failed more often. The initial fun and ambition faded away with every single compilation that turned out to not work as expected, crashed or ended up in memory leaks.
Even with every interest and devotion I had to learn, to me it was “just” another syntax complicating things. Pretty much everything I learned and did I was able to reproduce in Java in less time and with more comfort and less errors. I got lazy!

Coding Personality

So, even if I tried to seriously learn and get into C and C++ it just did not reach me, did not touch me. From my history and my experience with other languages, IDEs and projects I knew that there were different ways to achieve nearly the same things. And it was not only my laziness from very elegant development environments or library usage, also the code itself appeared to be cryptic to my eyes.
No matter if I read Java, Python or PHP code nowadays: Besides the fact that every code can be beautiful and ugly I understand Java code instantly; I recognize the Python functionality; I get what the PHP developer meant to do! Even in the last years as I was checking examples and help sites for iOS and Android NDK coding out of interest I could not get rid of the thought: I can achieve the same thing with the Android SDK! (PS: Objective-C is pretty ugly ^^)
And it is not that I do not like any other languages any more: I was “forced” to use Haskell and dismissed it; tried Scala and loved it! Fooled around with Ruby and had fun; Prolog and Lisp… na; Eiffel and C#, olé!
Especially C# instantly appealed to me: The syntax, the structures, the functionality and the ideas filled the holes that Java left over the years. It may be a coincidence that Anders Hejlsberg, a main man behind “my” Delphi is the lead designer of C# but maybe we think alike. And with the advent of XNA I even had a connection to game development again… and it started with a C! The commonality of course was a similar syntax, similar principles and the idea of a Virtual Machine executing and “managing” my code. No changes for specific operating systems (at least in the perfect sales world ^^), just develop and it would work… now with easy native Windows “ways”!
But the thing that always struck me again were games. Even XNA seemed “unreal” for real game developments.

Games are developed in C

If I would have gotten one cent for every time I read this exact line on a board, tutorial or e-mail… you know what I would be then as you probably think the same right now. And I believed it! It was like this; It stays like this!
But over time I got more experienced in developing and engineering applications and solutions and I realized that in most cases the programming language is just the tool to fulfil the requirements: And my requirement was still to make the things I have in my head!
I started to look around and found games such as Spiral Knights, Puzzle Pirates, Jake2 (a Quake2 Java port), Chrome using Java for scripting and even EVE Online from CCP. A Server and Client nearly 100% developed in Stackless Python; a dynamic programming language in a multi-micro-threaded environment. Easy to read and learn, hard to master.
But probably the biggest counterexample today would be Minecraft. The biggest Indie sensation last year is developed in Java and even if I never really got into the game, I admire Notch for what he did and achieved… and everything in Java. And Minecraft was not the first but Wurm Online already showed where Notch could go… in Java.

With these great examples of Games not developed in C/C++ I felt more confident in following my own way that I have successfully gone for years now.

To be or TioBe

I do not intend to defy C or C++ but if I am not required to use C for the games I want to create and other segments and industries can be conquered by languages such as Java, too (as shown in the Tiobe Index), why should I?
Especially in enterprise environments Java is a strong candidate for projects: From a Manager perspective the Java salesman argues with operating system independence, easy extended library architecture, basic native Database framework and UI support… sold! Enterprise Java is still a keyword for international research projects today. And with JME and Android even the mobile sector is invaded by Java for years now.
And with Android supporting Java as well as Microsoft supporting C# I can be everywhere: On PCs, on Consoles, on Mobile Phones and on Browsers. With languages I know, am experienced with and that appeal to me.
So, do I still have to put all my power in re-learning what I already know in other languages? Where I have intensive practical knowledge? Where I can craft my dreams?

Ignorance is bliss

Even with my underwhelming C skills I get along very well. Tiobe proves me right and until now I always solved the problems given to me or achieved and created what I wanted. I am working in the games industry, worked on large and international projects for big companies, wrote some publications and most results were accepted just fine. I even remember some projects and programs created by me that I am still proud of and this does not happen very often as every developer I know normally wants to change the code he wrote the second he/she finished the last line ^^.
I am aware that for the last performance tweak, for the most awesome graphics engine I would have to use C (or Assembler) and I am aware that the foundation for all that I use such as the Java or the .net VM an explicit knowledge is required. Nevertheless, I do not state that nobody should use C or C++. It is just that I want to raise awareness for people that complain about people not knowing C, labelling these as non-programmers. These guys are able, too. And if they want to Write Games, not Engines they might even be better for game logic and not “just” tools. These guys are also able to know what really happens underneath as that is a mandatory pre-requisite and not the knowledge of a syntax.
Therefore, besides all my years trying to get into “the game” of learning C and C++ I turned out pretty well, with experience in large projects, systems and now games. I call myself a game developer. And if many decline my languages I decide for myself that (C+)Ignorance Is Bliss…

Part of the Challenge: Show your ignorance! for #AltDevBlogADay

No matter what we do, if we are Agile or fall down the water… if we are senior or junior… if it is big or small… for nearly everything we do we have to define tasks and estimations to plan the days, weeks and months to come. Again, no matter what, this (especially first) planning is in most cases (and from personal experience most means 90%) pretty far from what is really required in the end. The other 10% split up into 1) the ones that planned good but not 100% correct, maybe used “proven” methodologies such as PERT or just estimated +30% and 2) the ones where the planning perfectly fit the development (again in my experience normally 1%-3%).
So, what you could say is to just “do it” like the 1%-3% did. This would normally be the way to go if theirs worked out. The thing is, from everything I have seen in project planning over the years: It just worked because of luck!

I think it is fair to say that I learned project planning pretty much from the practical side, always failing what I learned theoretically. No mater how much time I spend planning big projects, setting up tasks, goals, milestones, reviews, reworks, … it never got into this 1-3 frame.
Even with a more agile-driven approach, small sprints, good daily tasks, weekly reviews and time consuming remodelling of the plan: If I sum up what had to be reworked every single week I was as far away as with the initial waterfall plan. All goals got achieved and “somehow” it worked out but it is disappointing for the one who planned to see his estimations being more a guideline than a workplan.
Based on that experience I started thinking: What are the reasons for such divergence? What am I planning wrong? What do I have to change to fit the developers needs? And that is what strucked me: The Developer!

…to be busy!

With all IT projects I had to work on, the main time is consumed by the developers, the engineers, the architects of the (mostly) software projects. Of course Game Design, Art, etc. have to be taken into account but are often more parallel to what goes wrong more often: The actual development or implementation! (no question, thinking lean everybody should care about downtimes because of unfinished output/input)
As a developer myself that has to plan for others, estimate work, thinking about the production, milestones etc. none of the “theoretical” methodologies really worked out for me but just took my time. And in most cases this time is very limited. Estimations have to be given instantly to evaluate feasibility, plans have to be set-up initially to have a higher model to work and further estimate on. So, time is of the essence not only in the plan itself but also for the time to create it. And if I have to rework it all the time (real-life) I do not want to spend too much time in that phase (no time for building up charts with optimistic, pessimistic and realistic plans…).

…should be enough!

In a coincidence Jake Simpson gave a pretty good impression of this wonderful land, where everything works out. It is known as Should Be Land. This is normally the land where the estimations come from, too. From developers that should estimate their tasks, should give away an idea how long each of it could take to make a plan that also has to tie in with other departments (lean everywhere). If such an estimation fails because “36 hours should be enough!” more often others that depend on you are delayed, too.
Especially inexperienced developers, juniors and fresh “hackers” from the backyard tend to underestimate especially the requirements in correlation with others, to plan interfaces, to build adapters to dock onto others and so on. Nevertheless, seniors aren’t better in general. All people that “program” stuff normally just plan the programming time… and they do not want to plan too much time as the developer is often assessed based on his Cph (Code per hour) output and not based on his quality of code, re-usability, extendibility or tests. The results are in many cases optimistic estimations with no or little time to even plan what you are going to develop.

…am no developer!

Another often misleading planning element is that (many) project managers, scrum masters, gantt-junkies, … do not have the best development background. Therefore, the estimations given are taken as fixed. Experienced managers add an amount of 30% and plan it in. This is unfortunate as even the best estimation cannot just be coped by some time-addition if essential points that are requirements for good development are missing.

One of Two of Three

Besides complicated methodologies or the adding of just 30%-50% of time to an initial estimation given, I split it up into the three tasks I want to see as an output from a developer: The implementation (or coding, hacking, programming, refactoring, …), the planning and the tests!

• The development is the actual implementation of the task. It may be the creation of a user-system, achievements, tool, crafting, … whatever comes to mind
• The planning is the structuring of work, the evaluation of patterns, architecture and interfaces to follow during development and precedes it accordingly
• The testing is no QA process but the personal testing of code, writing of (unit-)tests, maybe even playing the created and succeeds the development

Now, instead of adding a specific amount to a given estimation I add tasks to the estimation. My input is the implementation estimation from a developer. Based on that I add two thirds as planning and one third of that as testing resulting in the three tasks of implementation, planning and testing with a weight of 1/3 of 2/3 of 3/3. For example, if an estimation is 9 hours, I add a task for planning with 6 hours and a task for testing with 2 hours.

Yes, the result is a very keen estimation but the important part for me is that it covers mandatory tasks that are often forgotten and is also able to compensate for possible misjudgement, unforeseen circumstances, … as the package is given as one. The creation of these tasks remind the developer what he “should” do, and the derived estimations compensate for possible problems as well as they fit the real necessity for the other tasks (at least in my experience).
The tasks are important as normally you do not start hacking instantly. To evaluate existing code, interfaces and elaborate what architecture or pattern to use is often more practical and a necessity in general before starting to implement (to think something through before starting programming). To already know what the result should be helps the implementation. And the testing part may be the coders worst nightmare but again a requirement.

The most important point for me is: It’s easy! I can easily derive it in my mind, do have a most-likely accurate estimation (future may prove me wrong ^^) and won’t forget the importance of planning and testing.
If you follow up different approaches the weighting can also be adapted either by mixing tasks or changing the base weight. For example, if you are following a Test-first approach you can either switch the planning and testing tasks, as the testing in TDD also compensates planning partly. Or you can change the base to 4 and plan 1/4 of 3/4 of 4/4 meaning for our example implement 8 hours, test-first for 6 hours and plan for 2 hours (bare with me as I selected easy to calculate estimations).
What base to use depends on personal experience, the project and just the most important gut feeling. For me myself a third for general estimations and a fifth (1/5 of 2/5 of 5/5) for more specific tasks paid out. But all in general split up into my three main tasks I instantly have an estimation ready that fits at least my real-world.

…should work!

Please keep in mind this has no theoretically proven background but my experience over the years experimenting with different approaches and using the methodologies given in literature. Everything depends on your environment and personal likes and dislikes. It “should” work for other instances, too. I used it in several personal standalone and living project estimations and at least for now it was fitting best.
In my environment, with the time given and the amount of work to do this approach works. It is never really off the track, it reminds people about planning and testing besides the actual hacking and helps me to easily keep track about developments without spending too much time in overblown concepts that do not fit my personal habits or the “real” developer.
Of course, there are also drawbacks, such as too little/too much planning. If you split up e.g. User Stories to have tasks such as: Build divideByZero() function; Create class object; Write SQL Statement for querying all users; … you will end up in unnecessary tasks because of the simplicity. In such cases, the User Story “should be” the one to estimate and divide onto the tasks or you reduce the base and introduce a zero/x task.
Therefore, this may not be the 100% 1-3 approach but it fits me best and therefore leads me into that frame more often as the important thing is the variance that fuels this approach… and that can make it work for you, too!

Written for #AltDevBlogADay

…a Triangle! In the previous part I presented WebGL, a new competitor in the graphics programming market. You got to know some history and parallel branches in the history of 3D graphics in the browser environment. Now, in this part you will see how to get a WebGL application into your browser.

The beginning

Last time was historical, this time we will get practical. In this part we will write one HTML page with embedded JavaScript code to draw a simple triangle through WebGL into an HTML5 Canvas. For that we will see how to set up a canvas, create a WebGL context, embed shaders and create a draw loop to present our triangle. Especially the shaders are an important topic regarding WebGL as WebGL is based on OpenGL ES 2.0 and OpenGL ES 2.0 does not support the fixed function transformation and fragment pipeline of OpenGL ES 1.x. Therefore, everything has to be done through shaders.

Note: What I present is an overview and user guide of WebGL, not OpenGL (nor OpenGL ES Shading Language)! WebGL could be seen as a wrapper for OpenGL ES 2.0 in your browser (and in the current state programmable by JavaScript). Therefore, I will not explain every OpenGL command or speciality. What is pointed out is just how to get your OpenGL knowledge into your browser. General programming knowledge and some HTML/JavaScript expertise may help. If you need help with OpenGL please refer to the masses of great tutorials in the net, especially NeHe and the OpenGL ES 2.0 Programming Guide (the main inspiration for this).

The Page

First of all we will set up our frame, our basic HTML file which we will use throughout this post. To write and develop HTML, JavaScript and therefore WebGL yourself you are pretty open to what to use. You can use a normal text editor or rely on a WebDevelopment environment but there are no distinct WebGL IDEs.
For WebDevelopment you can use Aptana or the direct Eclipse JavaScript Development Branch IDE. Both are fully fledged IDEs with great support, refactoring, auto-completion etc. Always a good simple helper is also Notepad++.
Everything shown here has been developed in Eclipse, Notepad++ and tested in Chrome 9. Chrome 9 is currently the only release browser download with enabled WebGL and has very good Developer Tools. Both is recommended for JavaScript development as debugging is kind of a pain in the a** (we will come to this in later parts).

If you have everything ready, have a look at the initial HTML scaffold:

This is the scaffold we will use throughout this part to show how to embed WebGL in a HTML file. You can copy it and save it as e.g. an webgl-part2.html file to open it with your WebGL enabled browser. At the moment, there is nothing to see or do. We will consequently fill it up and start using WebGL to draw our triangle.

One thing you might notice immediately if you have seen or written HTML pages before is the first line: <!DOCTYPE html>! This is the reduced Doctype used to init a HTML 5 page. You no longer have to write these long Doctype XHTML 1.0 transitional etc. Just that! Afterwards comes pretty general HTML stuff and nothing very special for our test.
Between lines 11 and 14 we define the width and height of our canvas we want to draw in through CSS. For now and the following we will stick with a classic 640×480. There are several ways to define the width and height of the canvas. As it is an HTML entity you can use everything that HTML allows. Regarding the WebGL drawing viewport we can refer to this size later on, increase or decrease the glViewport.
At line 17 you can see how to embed external JavaScript files into the page. We already embed one .js file in this case: webgl-utils.js! These utils provide some common methods for creating a WebGL context on a canvas. These are cross-browser compatible and actively maintained at Khronos, therefore it is unnecessary to rewrite these by yourself. You can download the original file from the Khronos CVS. Download and save the file at the same location where you put your HTML file. I will rely on these in this and the following parts.
The lines 25 and 26 define the initial canvas which we will use to draw in. It is just a simple HTML entity. We identify it by the id attribute as “canvas” but the naming is up to you (but you would have change other occurrences).

Now, the interesting things will happen in between line 19 and 21. This is where the magic will occur. In this showcase we will fill it part by part to get our triangle in the browser. Every code shown in the following should be copied in between here (or download the full file at the end).

Global Definition

At first, we will add some global variables that we will use in the following WebGL application. In addition, we define our triangle vertices and the mandatory fragment and vertex shader (add this where the dots … are).

We define handles for the created GL context we want to re-use throughout this page as well as the width and height of the canvas into which we want to draw. Do not forget the canvas itself, of course. Afterwards we set up the three vertices of our triangle in vertsTriangle.
You may have noticed that we do not type the width/height or gl handle. All variables are just noted as (mutable) var‘s. As JavaScript is a dynamically typed language this is fine. The definition happens as soon as it assigned. But it is never strongly typed for dynamic variables and therefore can rely on different sets of types. Nevertheless, you can also type your variables.
As JavaScript is required to be more and more with high performance inside your browser an initiative started to define some specific arrays to speed up the applications. These Typed Arrays such as the used Float32Array are still in a draft state as well as WebGL but will be released and supported probably in parallel to it.

After the vertices array you can see the fragment and the vertex shader code. Here, it is assigned as String to a JavaScript variable. If you would copy these and remove the special symbols you will get a normal shader as you might know. Here, we explicitly define the end of each line through \n\. This looks odd but is required to compile it later on as the shader source is required to be an array. Therefore, you could also write:

Both things would work. It may seem pretty odd to write everything directly into these arrays/variables but for now it’s enough as we only need one shader each. In a ladder part we will see how to load/reload specific shaders into your application.
The last thing we already pre-define is a variable for our later assigned shader program.

Entry point

JavaScript itself and in its browser environment have no specific entry point such as a classic main method. Therefore, we have to create an entry point ourself based on the principles of the DOM loading of the WebPage. As we want to start our WebGL application as soon as the actual body of the page (with our canvas) has been loaded, we add a trigger to the body itself. The trigger is docked onto the onLoad delegate of the body:

By that we listen for the body to be loaded (the canvas has to be created in the DOM up to that) and fire our main() method where we start with our part of the application:

In the first 8 lines we init our canvas and the WebGL context for it. First, we retrieve the canvas element from the DOM through its id “canvas”. Then we call a method from the downloaded WebGL Utils to create and enable the WebGL context of that canvas. Please have a look at part 1 to see what is done in that method. Basically, we utilize the generalized setupWebGL(canvas) method to be cross-browser compatible as there is still no distinct method to init a WebGL context.
Afterwards we retrieve the width and height from the canvas (as defined in the CSS) to reuse these in our glViewport later on. Then we fire a general init() method to setup everything WebGL we need:

In general, the init method follows three steps:

• Init our shaders
• Init our buffers (our triangle buffer)
• Set up the clear color, depth and our viewport

Step 3 should be self-explanatory, therefore we will continue with loading and setting up our shaders.

Load the Shaders

You already saw our two shader variables. Now, we want to compile, attach and link these. For that we require two methods: initShaders() and createShader().

At the beginning of initShaders we call our createShader method with the type of the shader and the according shader source variable. The called method createShader does exactly what the name suggests: It creates a shader based on the given type, compiles the given source and returns the created glShader.
Actually nothing special here as it is just a helper method. If we would hand over the shaderSource in a different format we will probably extend this method to convert the given shader source to a common format. But for now this is fine.
One speciality you can find is the error handling: Throughout the page you can find alerts and empty returns. As we have no specific exit() call in JavaScript or HTML (there is a possibility, but we will not use it later on) we alert the user, firing a MessageBox and empty return. As catched in higher instances this will result in a jump out of the application which leads to a manually “stopped” application. As we entered by ourself through the main() method, we can jump out any time we want. An alert() may not be the nicest way to show errors and exit the application but it at least gives feedback. Later we will see how to combine HTML entities, CSS and WebGL and will use the normal HTML functionality to fire error messages and according to the error lead the user to a solution or mail these errors to the developer.

After we loaded and created our shader we start creating our program at line 10. Again we check for an error that may have occurred. If no error happened we attach both shader objects, link the program and if nothing happened, use it.
If you know OpenGL you might say: Still nothing that special here!… and this is intended. WebGL was intended as a low-level programming opportunity without too many specialities away from the original uses of OpenGL. This was done with VRML and many other special plug-ins but never lead to what was expected as commonly used 3D in the browser.

Nevertheless, one speciality about JavaScript is being used now: The dynamic prototyping. You can see at the end that we return “the index of the generic vertex attribute that is bound to that attribute variable” and we assign it to the shaderProgram as position.

This is possible even if we haven’t predefined that variable in the shaderProgram object. We dynamically extend and create a new prototype by assigning the position without prior definition.
This should never be used as best practice as there is no contract we can rely on, e.g. through a specifically defined class, structure or interface. In this simple case as we do not need reusable and generic objects we just assign the handle for later reuse in our own “knowledge space”. Regarding classes and interfaces for contracts, these are all possible in JavaScript and we will come to that in a later part.

But now our shaders are (hopefully) all loaded and assigned so that we can continue setting up our triangle vertices buffer.

Setup the Buffer

To set up the buffer based on our vertices we go straight forward:

Absolutely nothing special here! We create the buffer and assign it to our global variable, bind and set the according data. This will become more complicated in later parts, when we define structures, load models etc. But as we just want to draw one triangle this is enough.

Let’s draw

What we really want to do after all this work now is to draw. Therefore, we define our draw() method:

As you can see no immediate drawing here for this very simple example. This again relates to WebGL and its origin OpenGL ES 2.0: Besides no fixed-function pipeline there is no immediate drawing. We just clear, bind our buffer and draw!
But wait, how do we draw? I said we have no specific entry point and created one ourself. If we have no specific entry point we probably also have no specific draw() loop we can rely on. Again, we have to create on our own. Here again we will rely on a method from the WebGL Utils and the according best practice from Khronos.

In the end of our main method, after all initiations we call our draw() method once:

After the initial call, in the first line of the draw method we call up a utils method: requestAnimFrame(draw, canvas)! This cross-browser compatible method takes the canvas in which to draw and the according method as callback. Inside is a timeout that will recall and keep the loop running. Currently this is the recommended way to do a loop. But it has to be noted that this not final. You can see the drawbacks immediately in the timeout and in the call directly in the draw method. For now until we see a final call and the draft has been approved we will stick to that as it is nevertheless cross-browser compatible and works fine.

Now, if you copied and setup everything correctly you should see the following:

You can download the full source here. If you downloaded the webgl-utils.js put it at the same location as the HTML file.

This is it… at least for now. There are still some “not so ideal” things here as this is neither best practice nor the only way to program JavaScript and therefore WebGL. Everything is embedded directly into the HTML page, everything is handled as one. The shaders are odd string variables and the process is very focussed around “just work”. But this was intended for now. Now, you have a page you can use as an initial foundation for further experiments. For example, try fooling around with the shaders and see what happens.

Next time we will get into User Input and show how to make the triangle move to the rhythm of our key strokes (and build up our own matrix). In the following parts afterwards I will present how to load textures, load models and operate with several shader files, dynamic loading and obfuscated JavaScript.

Written for #AltDevBlogADay

As I did not want to be as somewhat polemic as last time I checked several different pragmatic ideas I could post about. I weighted each against the other but with the news that the final draft of WebGL was released I decided to go this route and present some information, basics and a furthermore small tutorial in the following parts about WebGL!

A new challenger appears

Twelve years after HTML4 and eleven years after XHTML1.0 the WorldWideWeb Consortium “finally” dropped all efforts to standardize another, a different and more XML-based standard for the Web and continued where they left off to extend HTML4 to built it up to the requirements of our current time. As we are easily able to define that our current web-browsing habits are influenced by multimedia-based content with YouTube, Facebook, Farmville, Podcasts, … the new standard would have to be more multimedia flexible. And W3C listened!

The consequent successor HTML5 was finally started in 2008. Now, only three years later the standard is seeing the finishing line and most released drafts have already been implemented in common browsers such as Firefox, Chrome or Safari through WebKit. It provides special video, audio and canvas elements, support for codecs such as OGG Theora/Vorbis and MP4 (still a little dependent on decisions and implementation as it is still not final, possibly WebM), semantic support based on RDFa, sectioning etc. and a native 3D API named WebGL!

WebGL is a specification, independent from HTML5 but depending on the Canvas element of the standard. It is implemented as a context of the canvas and can be programmed (for now, actually more will be possible) through JavaScript and shaders. Speed and some specifics are dependent on the actual implementation i.e. the Browser but in general interchangeable in-between different Webengines.

Therefore, WebGL offers native in-browser support for 3D development. But actually the idea of 3D in your Browser is not a new challenge for our beloved internet…

3D on the Web

Already in the early days of the WorldWideWeb several different developers, companies and initiatives tried to establish 3D in the browser to provide a more persuasive environment for the user, correlating what was currently being established in games, that became more and more 3D focused during these years.
Already released in 1995 the Virtual Reality Modeling Language (VRML) tried to bring 3D to the Web. VRML 1.0 allowed to define the geometry, textures, materials etc. and especially scripts to visualize a 3D scene in a common textfile format. This scene was additionally able to retrieve additional data from different URLs as well as to react to events and triggers through special Java/JavaScript programs in its script nodes. Later it was extended to allow animations, sounds and other multimedia assets in 1997 with the VRML 2.0 standard.
The problem with VRML was mainly that it required a plugin to be installed in your browser as well as much processing power. Most plugins weren’t optimized and the scenes described in a very high-level style required too much load. There were some initiatives but besides some world viewers and websites of authorities no one really jumped onto VRML.

In 2001 the Web3D Consortium built a new high-level abstraction for 3D in the Browser: X3D. X3D extended VRML with more standards and especially profiles, shaders, gis and networking. It still requires a plugin or player and was therefore not as perceived as wished for.

As WebGL is more established and well-supported already by nearly every big browser on the market the Web3D initiative now jumps onto that train without giving up VRML and X3D. With X3DOM the initial specification and implementation is now being made available on your browser without the need of plugin a but with the power of WebGL and Canvas.

Nevertheless, in this multi-part series I will only focus on WebGL directly. If you want to know more about these “historic” approaches just follow the given links.

OpenGL in the Browser

In contrast to VRML or X3DOM WebGL follows a more direct (“low-level” in comparison) approach to 3D in the Browser. As the name suggests WebGL is based on OpenGL and specified by The Khronos Group. It is based on OpenGL ES 2.0 (nowadays good known from iOS and Android) and supports GLSL in version ES1.0. It docks onto the HTML5 canvas as a drawing context and with that it is fully integrated in the Document Object Model (DOM) and therefore allows full interaction with the general HTML Layout and Objects (e.g. overlaying, CSS styles, …).

As mentioned, as well as OpenGL WebGL is low-level and fully based around shaders. Therefore, things like defining simple geometry and scenes in an easy XML format as it is possible with X3D is not part of the WebGL standard itself. Possible implementations and APIs on top are nevertheless feasible (and already developed to some degree).

You can nearly cope everything you know about OpenGL ES 2.0 into WebGL. But there are some limitations (besides what is currently still different in-between the different Browser implementations). One important difference is that WebGL has no support for non-power-of-two textures (you could disable mipmapping). You have to resize dynamically. But in general you can feel with WebGL as you do with ES2.0 in other programming languages. It even looks similar. Let’s have a look at an exemplary draw() method (taken from the OpenGL ES 2.0 Programming Guide):

Looks pretty familiar, doesn’t it? A description of what this all means and how to really program it in JavaScript and embed it into a WebSite will follow in the coming parts.

Browser support

For the User
First of all you have to be able to see and test WebGL developments. Currently the easiest way to use WebGL is to install the current Chrome Browser. Since version 9 it has enabled WebGL support in its stable release. If you want to use other Browsers such as Mozilla or Safari you would have to get the according nightly builds. In each case you might need to configure the according download. For a small “manual” have a look here or be lazy and use Chrome.

For the Developer
If you want to develop WebGL in a supporting Browser, you check for and enable WebGL through JavaScript by actually just trying and checking for success. There are two things you have to do:

• Check if the browser supports WebGL in general
• Find/Get a canvas and enable the WebGL context for it

To check if your browser or more specifically the current window you are in allows WebGL you check for a specific window flag:

If this context returns true at least the Browser does support WebGL. Now, you need to check a canvas and enable the WebGL context in that canvas. Normally, you would specify a <canvas> element and hand this to a check and enabling function:

If no context can be received but the WebGLRenderingContext says it may do WebGL, some other problems occurred. If the browser supports, you have enabled and retrieved the WebGL context and can start developing applications in your browser with fancy JavaScript.

The “new” power of JavaScript

Actually, nothing is “new” about JavaScript. The JavaScript used to first make a clock tick down on a Website, later to “do AJAX” or now to develop WebGL is pretty much all the same and based around the ECMAScript standard. Even if it contains Java in its name it has nothing to do with it. The former LiveScript is supposedly just named JavaScript to establish it with the already established Java… and probably because of a somehow Netscape/Sun partnership. But do not hesitate: The interpretation of JavaScript during runtime has been incredibly speeded up especially over the last years as more and more client programming is now part of normal websites and administrative interfaces reload and rebuild many things on-the-fly.

For JavaScript itself, it is first and foremost a prototyping programming language. This means that instead of developing a class-based architecture structure that is instanciated and dependent to the initial implementation and used throughout your development, in JavaScript you “re-use” the same classes for all instances with all given methods (called behaviours) that are added at first or also during runtime. These can be extended by the developer. Further the instances made from the structure are the states. In general you could say that prototyping is based on copying: It copies the “prototype” over and over again! Now, the most important thing about the prototype implementation of JavaScript is that it also holds a link to its “prototype” and therefore derives recursively through the prototyping hierarchy to find what we request.

A very simple example: We define a Blog!

Now we define a second blog:

and assign our personalBlog as prototype:

Now we query

and will get the following result: Savas Ziplies@AltDev Blog! As you can see, even if I have not defined “author” in altDevBlog I may still access it as I specifically set the prototype of altDevBlog to personalBlog, therefore the “author” not available is resolved at the prototype personalBlog and printed. This hierarchy can go on and on forever and can be a performance issue if not consciously developed against. But in general prototyping and JavaScript itself offers many patterns that go well with WebGL and designs in general.

Therefore, JavaScript depends on a little different “thinking” approach. But besides that JavaScript also provides “somehow” object-oriented principles, delegation, dynamic typing, closures, run-time evaluation (very helpful indeed) and much more. Actually, JavaScript is a very powerful and somewhat interesting programming language but just seems awkward to most people because of its syntax, the name and because it is an interpreted language. Nevertheless, you can do practically everything with it, also relying on nearly every design pattern described.

To be concluded…

As I do not want to write a book as I did last time (yeah, hard to believe ^^’), this is it for today. You now know some history, the basic standard and how to “use” WebGL applications. The next parts will feature of course further explanations of WebGL, an additional introduction to JavaScript (and some of the creepy stuff you can do with it), presenting already existing WebGL libraries and an exemplary tutorial game developed fully in WebGL (as well as some twists and tweaks around networking and dynamic loading). In addition we will try to clarify how WebGL stands against other 3D in the Browser such as Flash3D, Unity3D and Shiva3D.

To already give you a taste of what to come and what is possible with WebGL, have a look at these publicly available WebGL Samples over at Googlecode, the astonishing Google Body example or the nice presentation of GLGE in the video.

Written for #AltDevBlogADay