soledad penadés
repeat 4[fd 100 rt 90]

Archive for the ‘opengl’ Category

20080516 Escena.org invtro v2

This demo was released at Inspire, a new demoscene gathering held in a small town north of Spain, with the aim of promoting escena.org, the spanish demoscene website. There was already another promotional demo done by elerium core in 2001, but I thought it would be interesting to have a newer one to kick things off.

Scene 1

It is very, very calmed. I had thought at the beginning about doing something very demoscene-ish, just as the previous promo demo was, but then I found myself not wanting to redo yet again the same old school effects, and headed towards something a bit more abstract. Then I remembered about eb7m's 3400 miles below and suddenly lots of ideas came to mind!

The tech stuff

The biggest change compared to previous demos which I've coded is that I used a scripting engine instead of writing everything in C++, and recompiling every time I wanted to change a parameter. For this I've finally used Lua, after considering Ruby and Python. The nicest thing about Lua is that it is really easy to embed. If you want to embed Ruby or Python, it's a completely different (and long) story, but with Lua you just build the library (with a nice makefile which they provide already and just works™) and link to that library in your project, and that's it. You can then create as many instances of Luas as you want, and they won't interfere with each other. In my case I just use one, which loads and executes the demo script (demo.lua).

The second nicest thing with Lua is the way in which you pass parameters between C and Lua. It is very simple, with functions such as lua_tonumber, or lua_tostring; if you compare with Python for example, it is way more verbose.

In the demo script you can access several functions which I created in C and exposed (registered) to Lua. So for example, there's a function for loading a song in C and once I say to Lua: hey, there's this function in C that you can use!, you can write loadSong("filename") in the script and it will end up calling fmod through the C function.

The syntax and function naming is highly inspired by Processing's syntax, although I still want to change a few details and remove some functions which end up doing the same, so that there's only one way of doing things and it's minimalist, as Lua is.

This was also a bit of a benchmark for Lua, so instead of using the typical Vector3D, Face and Mesh C++ classes I decided to implement a reduced subset using Lua's metatables. Even normals are calculated using Lua's math library! Considering the insane amount of stuff which is going on there (I basically increased the number of things such as particles, terrain segments, etc, until the frame rate began to be a little bit jerky), I think it performs very decently. Next step would be to optimise what is sent to opengl, since currently not only everything is drawn in immediate mode but also nothing is culled at all.

Scene 2

Why does it look like that?

Some weeks ago, trace was joking about the lack of texturing of any kind in my demos. I said I would try to use some texturing next time, but as it happens, I thought it would be more funny to play with lights. Yes, I think it's the first time I use lights in a demo. Well, a light. Since the song's title is 3400 miles below, I thought of building something like an underwater world. A very deep one indeed, since sun rays do not even reach that depth, and so any ship which wanted to explore that area would need to use their own light - hence the light is needed for illuminating where we are looking at ;-)

I first built the ground. Initially I thought about calculating an evenly distributed matrix of points and then randomize the heights so that they formed something such as a terrain, but it looked too usual - so I broke some things here and there and that's why it looks as if the tiles are misplaced.

Then I wanted some kind of life in there. But life in very deep waters doesn't resemble the usually depicted fishes. It's more about strange entities, and so I thought of those strange spiders which are in the scene. They are simply there, waiting for something while their legs oscillate.

But it was still too plain. I went too creative and added some plankton, which actually is quite wrong (plankton isn't present at that depth). The plankton is abstracted with those little triangles which go up. In fact they shouldn't go up but down, since they are created and fall from above, but in this case they contribute towards the how odd, things are moving upwards feeling.

In the quest for making it a bit more sinister and mysterious I also added fog. I think it's the first time I use fog too! It was a black fog so that colours got even darker with the distance.

And then I began with the particles-text effect. I didn't want to load and analyze a bitmap to find out where the points were, so I remembered about those naive drawings we did with PRINT in Basic, and did this:

escena = {
        "XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX    XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX",
        "XX      XX XX         XX         XX      XX XX      XX         XX    XX      XX XX         XX        ",
        "XXXXXXXXXX XXXXXXXXXX XX         XXXXXXXXXX XX      XX XXXXXXXXXX    XX      XX XX         XX     XXX",
        "XX                 XX XX         XX         XX      XX XX      XX    XX      XX XX         XX      XX",
        "XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XXXXXXXXXX XX      XX XXXXXXXXXX XX XXXXXXXXXX XX         XXXXXXXXXX",
        "                                                                                                     "
        }

which is a table with strings. When loading the demo and preparing the effects, I go through each string and if there's an 'X' I store a new point in the list of particles to draw. Actually, I created several particles for each point so that the fountain of particles was a tad denser. Then in each frame they move a little bit towards their final destination. To make it more subtle too, I made the alpha dependent of the height, so that transparency decreased with height.

The problem was that everything was still too evident. Something else was needed in order to hide stuff and avoid showing everything from the beginning. So that's why I added several randomly sized but circularly distributed meshes around the center of the scene. They even look sort of kryptonitic to me!

And why is everything green? Because our ship has only got a very old green phosphorus monitor, so it can only display things in green shades. Apparently ;-)

Scene 3

Source release and other builds

I intend on releasing the source code soon, once I decide which functions go away and which ones do stay. It is only a few source files and it's built with C and some bits of STL so it hopefully should be quite easy to understand and follow, even if you just want to see how to connect Lua and C.

I also need to fix a couple of details, such as the universal libraries issue that I found at last minute, and changing to the data directory in non mac builds (in mac, it automatically changes to the data dir inside the Resources folder), etc. At that point new builds should be available for something else than Leopard.

I was also thinking of replacing fmod with a free alternative, but I have several problems: it seems there isn't a decent, open and easy to integrate module player library (other than fmod and bass, which doesn't work in linux), and libvorbis is quite heavy for what I want. Suggestions welcome :-)

Thanks

Of course big thanks to Pplux for his awesome explanation about how the stack in Lua works. That was all I needed to take off!

I'd also like to thank Corsario for offering his computer as compo machine, and trace for the hard work in his inspire demo - it encouraged me to finish this one on time :-)

And finally thanks to Inspire organizers for all the enthusiasm they have put into this new event. Let's hope we can release lots more of demos in subsequent Inspire editions!

20080226 Xcode3 oddities

It's been a couple of interesting days already, got ideas for something fun and I'm using XCode quite furiously. Everything began since I got SDL working with OpenGl (what derived into a Linux version of the famously rotating triangle with pink background), then a couple of weeks later I made some additions which I'm further developing now.

But… what's going on with XCode3? It's just me the only one which has to close it and reopen it again every X debugging attempts? or maybe that's what the X in XCode stands for…

The symptoms are: you Build and Go (Compile and debug in ye olde jargon) and then one would expect the debugger to pop up. But nothing happens because a) it didn't rebuild at all or b) it couldn't attach the debugger to the process. So it runs as normal.

There's another weird thing, sometimes I add a new method in a class header (I'm working with C++) and when I write the method body in the .cpp file and try to compile, I get a message saying that there aren't matches with the definitions of the class, blabla. I solved this one cleaning all targets and rebuilding again, but if you know a better way of fixing it, I'm all ears.

Maybe there are hidden options which can be configured with

defaults write com.apple.Xcode AppleAnnoyances off

or something like that!

Event though, I must say that I like XCode2 way more than the previous version. If I had to choose a single reason it would be the removal of ZeroLink, then I would say the new finder, code folding, etc. (I never use its SCM features or design features so I can't tell)

20080112 My first opengl program in Linux!

SDL and OpenGL playing nicely under linux

I had my first look at SDL some years ago, when Wing Extrem from Wildbits told me about a library which could work either in Windows or Linux and was very nice for making games. I remember that I managed to compile the .lib for visual studio but didn't manage to go much further.

Since then, I have been finding lots of projects which use SDL as their base, which makes them really portable across platforms, and I decided to have a more in-depth look at it this time, since there's no point in fighting the masses :-)

So I was toying with some tutorials, specially Sol's Graphics for beginners tutorials and the Me and Mark Publishing SDL and OpenGL tutorial and wondered if it would be possible to get the same main.cpp compiled and working on our ubuntu computer…

I had absolutely no idea of how to get something compiled with SDL and OpenGL in linux; the last time I tried to compile a demo for linux it ended up being a frustrating experience which almost caused me a trauma, so I was slightly scared of trying it again. But I decided to go ahead since it was just a plain .cpp file!

Googled a bit and found an straightforward way of compiling:

gcc main.cpp -o main.o `sdl-config –cflags –libs` -lGL -lGLU

If that's not ridiculously simple you tell me what it is. In Mac, for being able to get a [Cocoa] window, you need to prepare a tedious series of files and Objective C wrappers, just for being able to open a window and having decent event processing. Thanks god the nice people from SDL provide some XCode templates for getting started!

Immediate conclusion: apparently it's easier to develop OpenGL stuff in Linux than in Mac, unless there's some hidden automagic going on without my knowledge.

Of course there are a couple of minor details; because this is a computer which acts primarily as a file server, we have never bothered to make OpenGL work and all that, and as a consequence, it doesn't have hardware acceleration. This forced me to comment out the multisampling part, or I would get a Couldn't find matching GLX visual error message each time I tried to execute the program. It's also reporting that polygon stipple is being done by software rendering, but at least it does it.

This has left me wondering why there's not more people making demos for linux. I still need to find out how it would work with more complicated code bases and things like cmake, but it looks as truly doable now that I managed to get my first program working. Hmmm…

Sources

Should you want to fully experience the 0xFF00FF background plus a randomly noise-texturized rotating triangle, simply compile this little file and let yourself carried away :-)

20060911 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", trace and blackpawn were working on the demosystem, 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!

20060503 The making of "tube"/xplsv

tube screenshot

Getting the right music, and the right inspiration

Some years ago, in the almost already forgotten summer of 2003, trace sent me a test of a song he was making. If I remember properly, it was called B04.IT, and featured the characteristic samples one can get using fuzzion's 4k synth. Actually, it reminded me a lot to the music of "insert coin", by fuzzion & threepixels. I think trace did the song for using it in another intro, but it was forgotten.

And some months later he passed me again the song but it was B05.IT then and it had more stuff - almost finished! It had passed through sml's and wizard's ears too. This time I really liked the song and thought that I wanted to do something with it, although I didn't know yet what exactly. So I just converted it to mp3, copied it to the ipod and let it appear whenever the random mode decided. One day while I was in a Circle Line train, entering Moorgate station, the song was playing and I had something like a vision, when I saw the platforms along with the signs, the sensation of movement that fitted with the song and its somehow agressive feeling… and I decided that I would do something related with the tube!

Then almost a whole year was spent developing something to be able to do the demo, as I switched to mac, and also wanted to do demos in a more decent/cleaner way that I was doing until that moment. And finally as I got the tickets for Breakpoint06, I decided that I definitely would do the tube demo for BP06, as I knew that it would rock big time to see it on the bigscreen.

At the beginning I thought of alternating 3d scenes with the 2d animations that I was going to put in there, but since I didn't manage to get a decent port to opengl of neonv2's graphics engine, I just set apart that idea and concentrated on getting the best animations I could get.

How to record in the tube (without looking suspicious)

That part was really funny. I borrowed trace's camera, which is way more discreet than mine, and the 1GB memory stick he got for his PSP, and just headed towards the tube on a nice sunday evening.

Why I chose sunday and not any other day of the week as it would have been more representative of the real stress of the daily commuting it's relatively simple: when there's so many people you would have seen only the first row of people and maybe think that I was taking pictures in a protest march. So that's why it just shows half empty trains and stations.

With that camera it was relatively easy to take pictures as it is quite small and doesn't do any noise when switching it on (in contrast to mine!). So most of the time I just walked as if I was going to take a train, with the camera in my hand - and recording it all!

I also wanted to be discreet not because of the passengers, but because of some news I had heard about people being arrested and their camera confiscated just when they were shooting pictures in tube stations. Just in case they were evil terrorists and were getting information of how the station was. For destroying it according to the plans. You know!

The worst of all was when recording the final part, which is actually how the Central Line trains enter Bank from Liverpool Street. I had to redo that one like three times because it didn't got recorded properly. Either bad angle, not looking good enough (the train stopping at the entering and somehow destroying the speed sensation, etc). So I had to change to the opposite direction and turn back to Liverpool Street again, and cross the fingers so nobody in the control room could notice a girl dressed with a blue electric jacket entering three times the station, and taking the train of the opposite platform three times too.

Imagine if they had asked me:

- What are you doing?
- oh just recording some movies for breakpoint 06 demo compo
- a compo!! it doesn't sound right! it sounds violent
- errrrr….

I also arrived until the ultramodern Canary Wharf station (where some movie was shot, if I'm not wrong) and took lots of pictures there, but they didn't fit at all in the demo. Apart from the "severe delays" pictures, everything else got discarded as it wasn't dynamic enough. It was so empty on a Sunday!! One can't appreciate any movement sensation if there's no reference point, like people, etc. Oh and it was so damn cold in Canary Wharf! I had to put my hat on while taking pictures of the outside…

Most of the moving images are from Victoria and Westminster stations. I missed lots of footage video as I thought that I was recording but actually I hadn't pressed properly the button. So novice!

Locations - for the map/tube addicts

Tube locations
So finally my travel consisted in:

  • Victoria - Westminster (with the District line)
  • Westminster - Canary Wharf (Jubilee Line)
  • Canary Wharf - London Bridge (Jubilee Line)
  • London Bridge - Bank (Northern Line)
  • Bank - Liverpool Street, and Liverpool Street - Bank, three times (Central Line)
  • Bank - Oxford Circus (Central Line)
  • Oxford Circus - Victoria (Victoria Line)

and not it didn't cost me much money since I just went out the tube itself in Canary Wharf for taking pictures of the skyscrappers :)

Coding horror

Then we have the nightmare the day before the party. I had let until the last moment the step of doing a final test in my pc. (I developed it in mac as I said). Horror happens and it happens more specifically the night before, when tired and almost aslept you get to test your demo in trace's laptop and then discover that everything turns white. ARGH!!!!!!!!! It wasn't even a black screen, it was all completely white. I just said ok … I'm going to release it in the wild compo, I don't care if they don't accept mac entries in the demo compo, I want to sleep. And I absolutely did.

I suppose a real coder would have stayed all night trying to find out which was the bug but as I'm not a real coder I just let the pillow give me some advice. Of course, the next morning I hadn't thought of any solution for the bug yet. I even didn't find anything until for some reason I ran the demo in fullscreen in my mac and WTF!!! it was WHITE!! What was happening there?

Well it was actually quite stupid. I did some very basic filters, reading from the current framebuffer and manipulating the data. But just some filters used one code I saw in one page which said: glRead(GL_FRONT);

I simply had sticked it in my code without noticing any performance difference, so I just let it be there. Buuuuuut that was a very bad and irresponsible idea! Depending on the graphic drivers, the FRONT buffer had something - or not. In my old pc it didn't make a difference, but in trace's it made everything go white. And I don't know why, I hadn't tested the faulty filters in full screen in my mac. Maybe in fullscreen the opengl gets like a different context or something like that (I don't have any clue, I must recognize), and that's why it showed different results when running in a window or in fullscreen.

I proceeded to remove that code from every place where it appeared and voila! it was working perfectly fullscreen on mac! Then Corsario/tlotb offered to help me to compile a win32 version - and hence release the demo in the demo compo.

Forget libc

I used visual studio 6 in my old pc. It worked pretty well - apart from thousands of warnings from the STL, of course. But Corsario had Visual Studio 2003 and Visual Studio 2005. He said it should be ok. Of course, it wasn't. There was some kind of funky incompatibility with the headers that my project included and what MSVS2003 decided that was ok. Basicly they had deprecated (and removed) libc!

But Corsario managed to identify which of the libraries introduced the libc dependency and replaced it with a compatible and appropiate (for VS) header. And oh it worked quite well! :)

The remaining was simply a question of putting the nice layers that trace gave me in a more or less meaningful order, and syncronize things a bit. Also, trace convinced wizard to do another pattern for the song so it could get a bit more polished. So we had another star in our team!! :D
As you see, it's very easy to do a demo! You should do one too!