Daily Update 12

Today I completed the module functionality, both for loading libraries into the environment and exporting existing code as a GIFScript module. I tested my code for a few examples, which went well on both sides. As I mentioned earlier, modules are implemented as ZIP archives containing code and resources. The code contents get interpreted by Nashorn in order specified by a initialisation file when a module is loaded.

Tomorrow I plan to start working on more complex modules to further test the implementation.

Daily Update 11

Today, I started working on modules. I decided to implement modules simply as ZIP archives containing both code and resource files along with a descriptor file showing how GIFScript should handle each. Once a module is created, users will be able to dynamically load these packages in their animation scripts, enabling their functions. A packager tool available through the command line will be used to bundle JavaScript code and possibly images into module files for reuse.

I implemented the basics of the "packager", reading through the documentation for Java's ZIP utilities. Java's interface for compressing and decompressing ZIPs is pretty straightforward, but the code for loading these to the environment is not done yet, so I couldn't actually test the concept yet.

Daily Update 10

I couldn't work much on GIFScript the last few days, I had an exam that I had to study for. But now that it is over, I can once again focus on my programming tasks.

This week I'm supposed to implement "modules", or packed animation libraries that provide access to reused functionality. These could both involve JavaScript code and also resources like images, icons or fonts. Some example modules I thought of earlier are a 2D plotting library, a library for drawing probability distributions and one just animating chess moves. Thinking it will be useful, I spent some time today on a GIF demonstrating a genetic TSP algorithm work on the problem of travelling around Turkey.

Of course, the JS code is pretty lengthy, about 400 lines, due to the genetic algorithm. Completing this weeks work, I'll make it possible to separate the algorithm into a TSP solver module, leaving only 10-20 lines of GIF related code in the script as it should be. I think it'll be easy to implement modules with most of the scripting functions ready, I hope to finish early and focus on other details later in the week.

As a side note, GIFScript is now available under the MIT license, GitHub.

Daily Update 9

As I mentioned earlier, the past week went by mostly working on GIFScript's internals. I implemented some performance improvements, changed how tweens are stored and computed, and most importantly, I started working on my own GIF exporter. One thing I'm working on is a way to generate color tables before actually rasterizing a frame, which will save a lot of memory when generating large GIFs. The exporter is not done yet, but I'll probably make it usable by this week.

Thinking I've been working too much on the technical side lately, today I decided to make a detour and produce something more concrete. I parsed a long list of default color names for use in scripts. I implemented basic relative positioning on the scene, which I might develop even further later. Finally, I attempted to reproduce the quantum tunneling animation in GIFScript as an example by writing a more general numerical solver in Javascript, but it turned out to be more time-consuming than I anticipated, so I'll complete it later.

Daily Update 8

I spent the first day of the week with some modifications to the GIF writer, I completed some details left from last week. I rewrote parts of my text rendering code, fixing a few bugs relating to how Java graphics handle text. I started planning how I can replace Java's standard image exporter with my own code, to improve performance and GIF quality and for better integration. I laid the groundwork for the replacement, tested some prototype code. I'll probably spend this week with improvements.

Daily Update 7

The last two days were spent on animation functionality and general modifications to the code. I improved the tween engine, earlier the intermediate values of a property were precomputed and stored in a vector to be loaded as a frame passes. However, thinking that the cost of computing values is much lower than storing them in memory, I worked on a more flexible "pipelining" system.

I decided to start working on my list of to-dos which I accumulated in past weeks with details I didn't want to spend time on earlier. I cleared up nearly half of the tasks, with changes relating to functionality, better code quality and performance.

Daily Update 6

I haven't been blogging much the last few days, but I kept working on an animation system for the engine. I've been spending most of my time on a flexible tweening mechanism for scripting complex behaviour with minimal code. I exploited JavaScript's functional programming capabilities, and since Nashorn handles most of the interfacing, the implementation was pretty straightforward. However, I still need some time to make things feel more natural for the user.

This week and the next I'm supposed to develop the internal representation of animations in GIFScript, meaning I'll improve the translation process in the background. With this in mind, I set up cleaner error handling for scripts. I also worked on the rendering code, the previous naive implementation would occasionally fill up the Java heap space for GIFs with large dimensions and 500+ frames. Now using up all heap space is much more difficult, and probably a heap error won't be a problem for mainstream GIFs.

Finally, I did some profiling to help me decide where to head later. I'm actually happy with the performance, but as the frame count increases to more than 500, the run time can jump to a noticeable few seconds. It turns out that roughly 95% of the program time is spent on writing frames to a GIF file, the cost of interpretation is very small even with complex mathematics involved. While Nashorn is working pretty efficiently, Java's standard image exporting functionality seems to be slow. I'll optimize this later next week, for the time being I'll focus on more urgent tasks in my schedule.