soledad penadés

“Seen, gone.” is my first (serious) incursion in Android development. Yeah!

As the description says:

Take a picture, watch it morph into something different – yet related to its true origin. And before you can blink twice, it’s gone, destroyed by the very same hands that created it.

To escape from the usual demoscene non-interactive demonstrations, I decided to do something interactive but that still used a bit of processor power, so that I could see what could the platform do. I had already tried to do some audio stuff, but the results were a bit disastrous. I might come back to that field again; maybe I will be more inspired or I will know how to do things ‘the proper way’ and it will end up being a more satisfying experience.

For this, I began using Canvas and only integer math to speed things up but the results were horrible; using Canvas for this was just too much and there weren’t available cycles for anything else. It was unacceptably jerky. I even showed the app to my favourite betatester and he told me that he would uninstall the application immediately.

Since I was determined to improve things, I watched the mighty session by Chris Pruett at past year’s Google IO and understood why things weren’t quite working the way I expected them to do. After much cursing myself for not having watched the presentation before, I replaced Canvas with OpenGL ES –in which I still miss good old immediate mode, but hey… it’s way faster!– and float calculations (to my surprise, you can even afford a few float operations!), plus reorganized pretty much everything, and rewrote the rest. Core calculations could probably be optimized with native C code but I didn’t want to limit myself to non-portable code yet. Although… are there any Android devices which are not ARM based? Heh!

It’s been a very instructive experience; I’ve learnt a lot doing this –the Garbage Collector and I have become almost close friends, so to say– and obviously it will help me to create more Android applications in the future.

But in the meantime, there’s another demo waiting to be finished!

And yes, this app is what I wanted to finish a couple of days ago, just in case you missed that post.

Today I decided to do something different. And I thought: Okay, I’ll try and sort out this compiling for windows issue, so that I can focus on the rest of more important things without having to worry about it any more.

And guess what…? I think I managed to do it :-)

Roughly, these are the steps I followed, just in case someone else wants to compile for windows with opengl and sdl support, using [ubuntu] linux:

• install mingw (I did it with Synaptic Package Manager so that I didn’t have to go through the ./configure and ./make hell)
• get the dev libraries from sdl for windows/mingw –this file– or check their downloads page
• uncompress the file and locate the bin, include and lib folders within, and…
  • copy bin/SDL.dll to the folder where your win32 .exe will go — so that the exe can pick and load the dll when executing
  • copy the include and lib folders to a folder in your project’s src folder — or anywhere you’ve got access to! For example: project/src/libs/sdl/
• now in your main.cpp, include SDL’s header files like this:
  #include <SDL/SDL.h>
#include <SDL/SDL_opengl.h>
• And the makefile could be something like this too:
  WINDOWS_SDL = ./libs/sdl/windows

windows:
        i586-mingw32msvc-g++ -I$(WINDOWS_SDL)/include -L$(WINDOWS_SDL) \
main.cpp $(WINDOWS_SDL)/libSDL.dll.a -o ../test.exe\
 -lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R.

(ugly hard line returns added by me so that you can see all parameters in one go).

This assumes you are invoking make from the src folder. The output will go to the parent folder. But well, the most important things that need to be highlighted are the bunch of switches you need to include in order to get the program to link:

-I$(WINDOWS_SDL)/include — this tells the compiler where to look for additional header files. This way it can find <SDL/SDL.h> and you do not need to modify the file or add #define’s when building for linux.

-L$(WINDOWS_SDL) — pretty much the same but tells the compiler to look for static libraries in the WINDOWS_SDL folder too

$(WINDOWS_SDL)/libSDL.dll.a — links the library into our binary!

-lmingw32 -lSDLmain -lSDL -mwindows -lopengl32 -Wl,-R. — these are magic – remove any of them and the linker will complain about missing symbols ;)

I still have to test this in a real windows machine; so far I have just tried with Wine. The output is a little jerky and a bit slower than the native (64 bit) counterpart, but I guess this will do much better than compiling in Virtual Box and testing with Wine :D

I’ll try to upload a test .exe when I test it on a real windows box myself, so that you can test it and see if it works in your computer (if you want, of course!). It’s ages since I compiled anything for win, and I truly wonder whether it will work with Vista/7… my last demo for Windows was done in 2005 and XP was in full glory back then :P

So the quest is set, the aim is clear: create something for Breakpoint 2010. There won’t be another opportunity; not at least under the Breakpoint umbrella.

The organizers have expressed publicly they don’t wish to organize yet another edition of nowadays biggest demoscene event, so it’s now or never! (At least until a new event this good takes off).

I already have had stuff of mine shown in their big screen. But that was before the true Big Screen, with capital letters. The 70 square meters one. I must release something, I said to myself.

Of course, this means that in a way, I’m going to break my own self-imposed rule (I will release things when they are done), but I’m working in a slightly pressurised scenario in order to finish the demo before setting off for the airport.

I have decided to keep a somewhat sporadic short demolog to keep people informed of what I’m doing, trace’s style. Hopefully it will help/force me to do things, daily, so that I don’t slack or procrastinate, and maybe you may help me too when/if I get stuck somewhere ;)

I’ll keep things short –this is probably going to be the longest post in the series– so that writing here doesn’t starve me of time to code.

This is the current status of the project:

• the theme is approximately set, but I won’t disclose it here
• I’m working on converting my on-its-own rudimentary OO-C synth (sorollet) to a bit less rudimentary C++ synth that can be embedded and interfaced, VSTi style, so that I can sequence everything from Renoise and play with parameters and settings in real time…
• … and convert Renoise’s Song.xml (inside the .xrns file) to my own data file — kind of means recreating a simple tracker which follows Renoise conventions (Lines Per Beat for example). I have taken a look at the Song.xml file, extracting and using the relevant data seems easy, specially since Sorollet was already using a tracker style format.
• So far I have managed to compile a VST plug-in in Linux. I had to solve several issues like having to compile for 32 bit while using a 64 bit OS, because Renoise is 32 bit too, gdb not willing to cooperate most of the times, the VST SDK docs being scarce and incomplete and not ready for Linux and etc, but I’m slowly progressing. Now I have a basic synth that can play sines or triangles, and transpose octaves. Awesomeness!
• This means I’m not using an mp3 this time. Could this fit into an intro? Maybe, but I don’t want to sacrifice code readability in order to make it fit into an intro… I’ll be more than content with making a demo!
• I need to find a way of producing a working Windows executable. Sadly, party organisers won’t allow a non-Windows .exe to enter the demo compo. Big BOOOOOOH for them. I have thought of different solutions, the easier is to install mingw in a VirtualBoxed Windows I’ve got, recompile my sources there and run the exe in my main machine, using wine. But I still have to try that, and I hope it works in Windows Vista :-S
• I still haven’t thought about the visual part, I fear I’ll have to script it as in ye olde times –no time for writing a visual timeline manager–, but I will probably use Lua to alleviate the pain.

Complimentary screenshot:

More later.

So here’s the last installment of my demoscene sources: escena.org dentro version 2. It was done for past year’s Inspire democompo and it won (incidentally, there weren’t any other entries in the compo but hey, it’s not my fault! :P).

This demo used a different approach; instead of building a whole scaffolding of C++ classes I just wrote some glue code with C++ in order to be able to draw something with OpenGL, and scripted everything else using Lua. It was also a bit of a benchmark. The result isn’t bad, given my lack of experience with Lua :)

Here’s the HD video (and here’s on vimeo, if you prefer it to youtube), and finally, here are the sources.

PS: The count down goes on to 1, and…

Since the code for re:fritos is pretty much the same than the one from tube, porting it to Linux has been pretty much easy. So here’s another batch of demoscene sources! This demo is totally different from tube. While tube is highly aggressive and reflects perfectly the daily fight to get to your final destination on time, re:fritos is a cheeky, for-fun only, demo.

While porting this demo to Linux, I found something strange. Once I finally got everything compiled again, and executed the demo, I got a super segfault when initializing one of the resources in the demo. The SEGFAULT more exactly happened when calling std_vector::push_back. The fun begins when I tell you that this very source had also been compiled in mac and in windows, always using gcc, and never got any problem when executing it, and the machine was way less powerful than this one (just compare a Quad Core vs a humble Powerbook G4 or Mac Mini).

Trying to find out why was that happening, I suspected it could be something to do with the heap size or the stack size, although I didn’t quite know why should I have that problem. I did a test in which the effect used less interpolation points (and therefore used less memory), and the SEGFAULT didn’t happen, so that confirmed my suspicions in some way. But why? Some forums suggested to have a look at ulimits and see if that would shed any light but it didn’t really help me (or I don’t quite know how to read those results). Looking somewhere else, they suggested to add the #include <new> line. I tried it, quite skeptically to be honest, and to my surprise, the demo worked! I’m still puzzled by this. I guess that maybe Xcode included that header or linked to it when building, but I still don’t now what’s the purpose of that header. Must investigate.

Anyway, enjoy the demo, have a peek at the code, or if you know anything about this mysterious new and segfault issue, do let me know!

PS: And the count down goes on! 2…