Another Gifntext Update initially started as a Geocities website when I was in 6th grade. Over the years, it has slowly evolved into a place where I can practice and become familiar with web development as it progresses. I started out coding with Microsoft Frontpage, then moved to Dreamweaver. Initially, there was very little coding, and it was all WYSIWYG. However, as I learned more, I could make it more interactive.

I incorporate drawings and blog posts to keep those that are interested updated. Through the evolution of the website, I was forced to learn HTML, PHP, CSS, XML, jQuery, javascript, and the handling of MySQL Databases. I've put online some code samples.
Another Gifntext Update
Following up on last post I thought I'd give another update on gifntext, as that's what I've been doing in my free time. There've been a bunch of updates in the last month:
The last one was the biggest one. It existed for a long time, and I couldn't figure out what was going on. You can see it in this soccer gif, right as the ball hits the post. Look for it glitching.

Background: The gifs that gifntext generates are very big files. In order to generate them, I take a frame, and do some magic on it to encode it so that it works in a gif. This encoding is process intensive. Because of this, I encode a gif frame by frame, rather than encoding the entire gif at once.

Once encoded, the frames are then saved to a file. I'd boiled down the issue to the fact that sometimes the frames saved out of order (for instance, it would save frame 5, then frame 7, then frame 6). However, the way that I was generating frames, this seemed impossible. This is because the next frame could only generate once the previous frame finished. On top of all of this, this bug never occurred when I was generating a gif. I could only see that on the "recently created" page, some gifs were skipping. This made it extremely difficult to debug. It also made debugging take a while, as I had to wait until I saw that a gif skipped before I could go examine the log to see what happened. I ended up creating a script that logged every single action that any user made in the order that they did it so that I could trace the code path that was taken. The log looked something like this:

        step: about to doStep while generating 10, Are we stepping?true
        Dostep: We are within doStep on frame 10(though it will change to 11) here
        DoStep: about to step frame 10
        DoStep: we just stepped to frame 11
        DoStep:  We are about to save frame 11
        SaveFrameToFile: about to save  frame  11 to file
        DoStep:  We just saved frame 11
        step: just did Step while generating 11 Are we stepping?true
        saveFrameToFile: Adding frame was a success - Previous: 10, Current: 11
        SaveFrameToFile: Now that we have succeeded in adding that frame, going to step
It allowed me to see which function I was in, and which frame was just added.

Using this log, I was able to find out that sometimes frame 1 ended it's process (without even saving the file) prior to frame 0 ending it's process. What this meant was that we actually had two concurrent processes trying to add the frames to the same file. I was able to add in a variable that allowed only one process of generation at a time, and the bug was fixed. This bug was the gifntext version of my water rendering problem from dangeraffe; both issues were challenging, but I logically went through the code and after much persistance, was able to solve the issue.

There are many new enhancements that I'm still hoping to implement, given that I have time:

Those are mostly just ideas that I've had for the website. Maybe I'll add a simple poll, so that people can fill in what they want to be on the site.

2015-12-02 12:20:38

Cool idea

Write a comment...
Want more? Check the blog archives
Untitled Document