Going forward with thisisnotanengine

After some months dedicated to little and unimportant businesses, such as getting a fantastic tan which left as soon as it arrived, and finding a new job, I finally half-made my mind about the future of thisisnotanengine. For whoever which do not know what is it, it was our answer to the supercomplicated demosystems around there which are more focused in 3d stuff than in sequencing. It started simple, with a flash sequencer, but with the addition of blackpawn to the team it has grown big and powerful into a binary mega sequencer - but still simple and easy!

The main idea is very erm... simple... we have something similar to MIDI files but for sequencing a demo. The sequencer (the demo studio) helps you build the sequence, but you can also build it yourself, since it is an XML file. In fact, I did it like that for tube demo, but it's not something you would recommend to everybody. That XML contains a list of resources and a list of when the resources are used, along with usual things as modifiers, parameters, etc. And it can be read by any "engine", which does not neccessarily have to implement everything defined by the XML - it simply ignores what it does not understand. This allows you to sequence with a platform and produce a result for another platform. For example, Holy guadalupe! is a flash demo but it was sequenced with the demo editor which runs in windows.

While I was making "tube", the demosystem was being worked on, and they had to make certain changes to the definition of the XML file. I just decided to left the implementation of these changes in my version of the code "for later", since I knew they would take me quite a lot of time to implement.

Although the current version of my player is more decent than the first one (used for vslpx), it is still far from being clean. I just didn't feel like modifying the parser/loader in C++ again, so I decided it was a good moment to start experimenting with (tadaaaaa) python! (I don't know much python yet, though, but seems that its learning curve behaves quite well, one day you're writing 1+1 programs and next day you are writing the next big Web 3.0 project).

The main idea is to build a library in C++ which will implement the graphics and sound code, and leave the remaining to python, connecting everything with some kind of bindings like the ones provided by Boost.Python or SWIG. But keeping things simple. Even if I started using STL, some things still get horribly complicated in C++ but would be much easier with Python, and the inverse. And I tend to get paralysed when I see code which is excessively complicated (specially if it could be simpler), so that's not good.

Another goal of this is to stop depending on any IDE for compiling. That is, even if I'll use XCode for writing the code and all of that, I am trying to avoid using it for managing the project settings. My aim is to use Make for these tasks, since configuring a project with XCode's interface does not provide as much visibility as a makefile does. It could also help me with other goal, which is to get rid of Visual Studio in Windows. I want to investigate which free and modern compiler can be used, specially if it does not annoy me with false STL warnings. Also I presume that using the same or similar compiler (barring platform differences) would help me with the crossplatform development.

By the way, now that we have a fully working computer with decent graphic cards and ubuntu installed, I will probably try to get a linux version as well. From my experience it is relatively easy to get my code working in different systems, now that I have learnt not to use proprietary functions, so it shouldn't take too much time.

I am still in the research phase. I first started with Edwin Jakobs homepage (who is a very famous dutch scener), where he related his experiencies with C++ and Python in order to build pom pom, their scriptable engine. From there I began testing SWIG in order to get a simple test library which could be able to open a window with a certain background color (specified from python) and play a sound file (also specified from python). But I haven't managed to get to that yet... I'm running into lots of problems mainly because of my horrible ignorance of building anything else apart from a simple console application and the funky differences between usual GCC conventions and Apple's implementation of GCC - but I'll find out the solutions somehow!

More to follow... but meanwhile if you have any experience in building dynamic libraries for mac or in doing exactly what I am trying to achieve, I'll love to know about it!