 Am I on? Good. Thank you very much for coming. Nice to see that there. Thank you, Descar. That's on. Thank you, Descar. Ah, so go in there. So, I'm happy to see that Commodore 64 is still a topic or still raises some interest. It definitely does for me. A few words about me in daily work. I'm a Linux kernel hacker specialized on embedded systems and doing lots of low level stuff. And I still prefer limited machines. If people come to me and saying, hey, have you heard about this new arm quad core with super duper GPU graphics powers? That's not what amazes me. Yeah, well. But with limited machines getting something done, that's what raises my interest. And this is because I grew up like this. I'm hacking the Commodore 64 since 1988. I just realized that's 23 years. 23 is always a nice number. And I've been mainly interested in the demo scene, which was back then very, very high. And laid the foundations to the demo scene we know today, even if it's PC or whatever. And yeah, it is a passion. I don't know if Zen is the right word, so I put a question mark behind it. But searching enlightenment via excessive practice is not an understatement. I really did this a lot. And I learned a lot. It is part of my history. So it made me who I am today. And I'm not so active like I used to be, but I have still a lot of interest and I have still a lot of ideas left. What I'm going to show the demo is, of course, not my personal work. That would be too much. It is a group effort. I mainly work with some close friends of mine, also located in Germany, and a group of people which are in Hungary. And I really have to thank them because it's always a great collaboration. I think we collaborate now for more than seven years. And it's always great fun working together. And I really have to thank them a lot. Also, I want to mention that I want this talk to be seen as a case study. This is one example, I think an interesting example. But it doesn't mean that this demo is the best C64 demo of all times. I think it's a good one, though. We're not the absolute gods of C64 coding. And there are other people doing great stuff at the moment. This is one case study. And it's not even meant to be a glorification of the C64, although it is a very cool machine. But there are other platforms. And I'm usually easily bored by platform walls. So if you have another 8-bit machine and have a great demo, I'd be the first one to appreciate that. I also understand if people get bored by C64 demos, because I get bored with PC demos. So that's kind of fair, then, I guess. Some short facts about the Commodore 64. I don't want to talk too much about it. I think Michael has doing the last time great overviews of the Commodore 64 just for those to freshen up. We have a 6-fave i2-based CPU, which has less than 1 MHz, 3 registers, 556 opcodes, although we used some extra ones. I'll be talking about that. Few addressing modes. We have no multiplication on assembly level. Of course, no sine, cosine. So it's more like adding, shifting, stuff like that. 64 kilobytes of RAM. People are always amazed how less that is. I still think it's quite a lot. Forget about the ROM. First thing you usually do is switch it off to get all the RAM. The machine has various graphics modes. The one which is used in this demo is mostly 160 by 200 by 16, with a limitation you see there. But we have movable object called sprites. We can C64 is very famous for it. We can place it and we will use it. Yeah, sound, the famous sit. This is quite a mighty synthesizer, I think, because of the modulation filter options. We have to do load and data, so we have to take care of the disk drive. 170 kilobytes per site. Yes, you can turn the disk. Remember that part? Turn the disk. Sadly, it's connected by a serial interface which requires even handshaking. So it's very, very slow, especially if you use what is supplied from the beginning. And one other gimmick which is used in demos usually are the internal timers, which can be changed to each other. They are a bit underestimated, but they are powerful and I like them a lot. The design choices about this specific demo, it's a bit special in that case that we had the music in the beginning. Usually you have a concept and then you have a musician who follows, tries to follow the concept with some music. But this time it was around. There was a music already present and a few effects were already done. And Oswald, who's really, really, really good at designing demos, had the idea of so much potential for a demo and came up with a script. And given by this music, we wanted high-pace, really. Effect, effect, effect. Not showing too long. Yeah, what's the last point here is really meant right in your face. Here you have it. With other demos you notice, okay, there's some filling material, either to build up some tension or to have load in new data or for whatever reasons, and we wanted to avoid this or empty screens as much as possible, which was quite a lot of work. The next demo we did, we decided on a slow pace and that was so relaxed to do, but it's missing the kick, I think. So, with that bit of talk, I want to show the demo now, so everybody has seen it at least once. You see the current work state, because when we released it, it was a 90% version, then we put out 91%, what you now see is like maybe 93, although it's five years ago. But actually, we tried to finish it for this talk, but we couldn't make it. Although we have some, internally makes some good steps to finish it really somewhere. No promises, though. So, let's see. Let's hope everything works now. It's an emulator, though. Forgive me about that, but the C64 has such a strange pulse signal, it usually confuses beamers and if you want to go, say, if you use emulators. So please turn me down and the volume up. Thank you very much, glad you liked it. So, before we talk some further, I need to define some terminology, which happened to, which is established in the C64 community. These names are there for ages, although they're sometimes weird. I will probably talk, or mention the term speed code a lot, which is basically unrolled loops. Maybe you have heard that before. You just skip loops, because iterating over loops costs some extra cycles and you want to save that. I took some very primitive, simple example, load a value from a sine table indexed with an index register, add another value of that table with another register, and store that as a pixel to whatever graphics mode you just have. And instead of doing this in a loop, you just put the offset here again, sine table, sine table, and then the pixel again. Do this 1,000 times, and you have a simple plasma. Okay, you can do a bit more nifty things to make that plasma look better, but it's as simple as that, and that's why I generally don't like these plasma wavy thingies, because they are just too boring, I think. Speed code, unrolled loops. Sometimes I might mention illegal op codes. Those are in fact just undocumented op codes. Back in the days, that sounded perhaps not cool enough, so they were illegal. This is just from the fact that not all op codes were, yeah, wired to some useful or planned features, so they had some open, and didn't bother to knob that out. So they do strange things, and people have learned to understand those strange things and make use of it. So we have actually more op codes and if you really go for the ultimate thing, you should use those which are useful. In fact, I own one world record, which is only possible because of these illegal op codes. There's no way you could have done that without them, but that's too much detail, just believe me. Sometimes I might talk or slip through the term rustle time, just interpret this as cycles. It's based on that because, you know, the ruster is building up the screen and if you take some time or burn some cycles, the ruster moves, so sometimes it's called ruster time. To get a glimpse on what happens, things we do, I call it self-modifying code is a central way of doing demos. I don't think there's any decent demo about self-modifying code. It doesn't matter if you modify the arguments of an op code or the op code itself, it's all the same. Code is data, data is code. You do what is what you want. Sometimes tables are mixed patterns of code and data and whatnot, so we make extensive use of that. One other example is we abuse a stack. What you see in the first line is I want to get a lot of information from a table, so I could just get the first value here index, increase the index, so that will cost me six cycles. If I just get a value from the stack pool accumulator, I get it from the stack. It just costs four cycles and the stack counter will automatically move, so I can just do the next pull and I will get the same value for four cycles without taking care of incrementing something and it leaves the... We just have three registers, it leaves one free. So there are routines which completely use the stack as a table of whatever. The problem is when you have interrupts, the processor will use the stack to store data on it. So you have to copy that somewhere else and later put it back and in the end this is some kind of sliding window technique. So you have the stack as you wanted. Tell that to your computer science professor he will be very happy about that. He would also like this one. Okay. On the C64 it's pretty important sometimes that you do really certain things at a certain time. One cycle off and it won't work. So you first you have to eliminate some jitters so you know when you get something stable so you know when you are where. And this is usually done by timers, using timers. And let's now just assume DC06 I like talking in hex values. I would never do this when doing kernel code but when I do C64 I just I would never give that a define. That's DC06, that's a timer and let's assume if you read that timer you know how much jitter you have. And one thing you could do you read the timer, feed that value into a delay loop and once you run through the delay loop you have your set everything stable you know where we are. There's one thing I don't like about this approach there's a delay loop. I mean we have just 20,000 cycles per frame and I hate delaying very much. And there's one way to get rid of it. DC04 is another timer which you can imagine is rightly in front of that one and we write some values to it. You could now think okay it's counting for C what's that that's 76, okay it's probably counting 76 cycles for whatever reason. But later we see this this is setting up the interrupt vector. Low byte 04, high byte DC. Hey we've seen that, that's DC04. It's directly jumping into the IO register space it's accessing code here in the first timer register. And now I can tell you 4C is the opcode for jump. I don't care about 76 the timer is not running it's constant memory so this is the opcode for jump this is the low byte of the opcode it's zero it could be anything wherever I place the routines it's DC06. That's the timer who gives us the jitter. So it changes with every cycle it changes the jump instruction changes and when we jump to it at exactly defined times we will jump to a very very specific jitter routine so we can optimize it for that special occasion. That will terribly fragment memory but it's really fast. And this is used for doing one graphics mode where we have 100 extra interrupts per frame and it wouldn't be possible without such techniques. I love such things. Okay there are such as two sets of effects on the Commodore 64. I call them the first one table based effect and those have lots of tables and lots of speed code and the magic is in the tables and the speed code generators. If you look at the speed code itself you probably will not figure out anything because it's just shuffling data around and you see no pattern. These are more mathematically based effects for example if you saw the tunnel there or stuff like that and those are for people who like 3D effects or whatever mathematically based they are easy in that part that if they are too slow well they just look slow and you can try to make them faster. You can use some chunky molds to get them farther then you have resolutions like 80 by 50 or whatever if you use dithering you can hide that and most people also call them new school effects where new school means like 1995 and ongoing. Remember next year the Commodore 64 will turn out 30 this is quite a lot and those effects are usually in frames per second 50 would be good that would be the maximum or one frame 25 depends on the effect you can do that but some people do 10 that's not very enjoyable for the audience I think but some people are very brave in that regard. The other type of effects are Vig this is the graphics chip or register based effects they might use speed code not so much and pretty simple tables and the magic is the actual code so if you look at the code you see a lot of registers written and if you know the registers you can really get the idea of what is going on there. They mostly run in interim context to make this stable thing more easy must be cycle exact like I mentioned and this is different from the others if your code is too slow the effect is impossible because you get up a certain amount of registers in a certain time and if you fail to do that you won't create the program the chips as you want and you will just get a black screen or whatever so this is what the old school effect were famous for cycle counting okay I have to do this at that time and I have to do that at that time okay I could do this no no no I need to do that as well but it won't fit and then you start doing some magic and if you're good it fits totally different style of effects and the nice thing about the combination from the Hungarian guys and me or our group is we can do both and we can combine that we're not the only ones who can do that but that has a lot of potential if you maybe remember at the beginning there was a bump mapper it looks like a torch was shining onto something the bump mapper itself is a new school effect it needs a lot of tables not lots of speed code but it moves and the moving is an old school effect because the main all the CPU time is done to do the actual bump mapping we need a fast way to scroll and then you can use old school effects because then you can start poking in registers and confuse the poor wick chip so much that it gets totally confused and shifts the picture around and this combination between new and old school there's lots of potential still left I think I don't want to spend too much time with this one just to give you an idea what's used in these days it's mainly really only cross development I started in 1996 with cross development back then I was laughed at killing the true feeling and stuff like that but it's status quo today especially when it comes to coding but you should always pay attention to test everything you do on the real machine especially if you do graphics if you do sound otherwise you might have strange surprises with code it's a bit easier yeah of course we're using the internet they being in Hungary or one is in England and me being here interesting thing is that the whole demo was compiled using my old Pentium laptop running DOS but it was working fine since 1996 and I never had a reason to change and I think it still did a pretty good job but other than that every developer has a freedom to use what he wants so there's visual basic Java and what not involved that's the basic memory layout I tried to impose on the other people because I could impose because I was responsible for the linking so I could say I'm aiming for that and the lowest things are given by the hardware architecture the zero page is special because you can access this memory very fast this is the stack and then I decided okay we need a loader to get data from the disk it needs some buffers and we have a deep packer which is relocatable so I can move it around if I want some temporary stuff the music which needs to be memory present all the time this is here you can do what you want with the parts and now let's take the recursive mapper which is also in the beginning as an example so far so good it uses the zero page a bit of a stack for variables here are some temporary tables and here's the init code table speed codes new school effects lots of speed code 500 byte left that can be quite a lot so you think it's all fine but then oh no there's this special table which without which the effect can't work sadly that is terribly fragmented but I'm tempted to show you why it won't work okay I I'll be brave and UV2 the nice thing with the way I do it is that I compile the demo as a whole but also part separately which makes testing a lot easier no no music off is okay we don't need that okay this is the part can you read that in the back good just show some code speed code it shuffles memory around gets it from some table, puts it somewhere this is in direction so it's more or less a pointer some 9.9 I don't know so try to make a pattern out of that let's look at the pointers oh okay that was not good yeah the font is too large but if I make it smaller you won't see much okay will you believe me it points to roughly the same memory if we go to that memory we see another speed code which shuffles memory around again this is in fact the screen memory so here the screen gets updated and you see here it gets again values from some tables and the tables always the high byte and the low byte are always in the range 0 to 0f and this is one of the key tricks of that effect because it's recursive it's important that the index to the table can be used as an immediate value or as an address here so this value can be just again it's the speed code with lots of self-modification we modify the speed code so we need that we have to directly put this value here or let's say here and here or we need it in a register to work with it further scary huh and all I wanted if you're happy that way this is what I wanted to mention why those tables have to be exactly there and you can't move them so you have to work around it so the key thing to remember is you can make plans but demo part coders will always come across and think of something else you have to deal with it there's no way around it so there is a table destroying my loader code so I have to back it up somewhere before so I have to do a lot of relocation and this is really really ugly dirty work but there's no way around it talking about loading I don't want to meet the Commodore engineers who designed that or actually for that and it was mainly management who spoiled that because they wanted some backward compatibility so the engineers couldn't use all the hardware features which could have made loading fast it is really awfully slow and you cannot use the routines Commodore delivered at all so demos have their own way to improve the situation and one way to do this is well usually you have a clock and a data line so you have one bit transfer and we use the clock line as a data line too so we have a two bit transfer that means we have to use the attention line which is just for basic signaling more or less like clock or handshaking line which is a bit dirty but works reasonably well the drawback is that you can have only one drive attached to your Commodore 64 if you have two drive attached they will be totally confused but with one drive it works fine but you have to design it all for yourself you need custom code in the drive because Commodore drives are intelligent they have their own CPU they have their own memory and so you write code for that too to make a proper loading system there are advanced demos who use the co-processor so while the Commodore 64 is cleaning the bitmap or whatever doing some drawing the floppy drive is actually rotating some points and the rotated points are sent back or stuff like that back in the days it was very cool to do everything on your own so people did their own loaders but as you can imagine it's pretty hard so a lot of them crashed and did not work reliably but as a result we have just a few these days and these are commonly commonly used one of them is our Dreamload which has special feature you can run it from a hard disk which is available or even from the MMC cartridge that used to be a feature which was cool but it got a bit outdated people have other hardware and you don't really need to have to support the hard disk anymore so that's a bit of a pity because we could put quite some effort into it but you have as a result you have to take care of loading all yourself to design the protocol get it stable and keep in mind that your drive is not the only drive in the world it's involves mechanics so if you tune your loader for your drive it will perfectly crash on the next one because the mechanic is a bit worse it won't come up with what you programmed a rule of thumb you want good compression to minimize loading if you can avoid loading do so so what can you do to do packing, crunching, compressing whatever how you name it there are millions of compresses out there everyone has his favorite and people like to do their own most are LZ based I used the best packer around which is called ExoMizer which is really good and it's astounding how long you can a gigahertz or two gigahertz PC can take to pack 40 kilobytes it's not like minutes or hours but a few seconds and it was really designed to achieve the best packing results which is nice in many ways but the drawback is that sometimes the de-packing is too slow so we pimped it a little bit with some parameters and that worked out pretty well and I rewrote the de-packer so it's larger of course there has to be a trade-off but it's faster but if you want to have decent packing system I don't think you will you can take something off the shelf and invest a bit of time to that one as well but that worked quite good the other rule of thumb is you know your data best use your a priori knowledge you know the symmetries of your tables you know where delta packing might be sufficient and try to not rely on a generic compression algorithm if you know something which could be helpful use that this is a lot of work but if you want to save loading and want to keep a high pace do that and then we need to put it all together because you can imagine if you work on a demo on a part you work only on that part you want to get it going and once it's done it does roughly what you want you consider yourself done and then you want to throw seven or eight of them together that won't work that way yeah well I won't read it all this is really really the dirt work everybody I know hates it it's usually not regarded in the scene it's got given and still it's the number one reason why demos fail come not into existence stop at 64 or 90% versions doing this right, removing all the glitches doing some transitions but there's no way around it you have to go through it to get the proper flow and here's where also where you have the trickiest part to keep all in 64 kilobytes of memory I have this part running I want the next part loading oh I can shut off maybe half of the part sometimes and then load that already and this is tricky and totally different from demo to demo I don't think you can use a generic framework on that not with C64 demo effects as I tried to show you with the memory layout before this is too special there will always be one special case where all your framework won't work so it's mostly hand work there's only in this demo there's three global things more to say load from this and call the music and everything else has to be handled individually and even after being done at 90% I don't see more to generalize synchronization it's usually a good idea to do that with music people like that me included if things are timed to music if music switches and you have an effect something switches on the screen as well because music is played once per frame once the raster beam runs through you just use a simple counter that there's no magic you have to keep in mind with syncing that loading drives drives are mechanics loading times can be different from the system you use yourself so always use some tolerance most coders have a really really bad floppy drive they call it killer drive or bad drive or whatever the worst drive they could find and they test their demos on them and once it passes on that bad drive you can consider yourself done and another nice thing music players do use instruments internally you have a little bit of noise and you have a drum, something like this and they have numbers and you can peek into the music player find out which memory location contains the instrument number and okay then you find out instrument 6 is a drum and then you can check in your code is currently a drum used then I don't know light up the effect or change the color scheme or whatever this is also a nice way to spice up your demo okay now I'd like to show the demo again with some minor comments I think we can leave the music off so because I will be interrupting anyway just to point out some more specials now I gladly killed my terminal let's see if I get some one thing I don't know if you've not heard that before here this is the so called border and this is the visible area I mention this because soon there will be an old school effect which is crossing the borders it used to be a main effect back in the days but these days you can just add it somewhere to give a bit of oh that was nice feeling oh they took care nice detail here we went through the border with the graph it's nothing breathtaking anymore but it's some extra effort which is nice to put once in a while okay here as I mentioned the main effect is a new school effect but we are able now the old school effect to get this moving and I don't think this has been copied so far one thing I'd like to mention here is that we also decided to entertain the audience a bit with additional graphics that used to be I had to change my way of thinking because I always wanted to put all the energy into the effect itself but Oswald rightfully convinced me that we need to add some elements onto it because displaying this graphics because it takes 10 to 12 percent of CPU time we need to use sprites for that and those need to be multiplexed so here are three or four we just have eight sprites so usually they would be ending here so we have to reuse them which requires additional code displaying sprites not all that 10 percent might not be too noticeable it gives a little extra feeling to the demo part this one is special because it's what we call a loader part I think 20 percent of the time is used to load the next part into memory actually it was just meant we need something to do or let's do a plasma Oswald tried hard to make a high resolution one and he succeeded in that we made a very good move with moving the girl into the middle because you have a full screen like impression although just one third roughly one third of the screen are used calculated by the plasma so what was intended to be a loader part I think if everyone most people on the net if they want to put up a screenshot of our demo they use that it started to be a loader part pretty amazing but the sad thing is we know how fast it actually could run if you don't have the loading in the background so that makes us a little bit sad luckily you don't know so you can enjoy it as you see it here the rubber cube originally you think cubes are easy you just draw lines but now the lines try to shape hey that needs to be a lot of mathematics involved the key thing here is you draw the cube into buffers so you have a set of buffers and pick from older buffers what you actually display is a mix of current and older buffers so I wouldn't call that cheating but I don't know if some people on PC would do but it gives a very good rubber cube yeah well the Hungarian guys are really good at math and although this is Oswald's part and he is very good at this speedcode table thingy and I know there are some lookup tables involved using shadow and I rewrote the part the speedcode generator was taking 3.5 seconds and that was too long so I optimized the generator I'm quite sure he wouldn't recognize it anymore so it just took 1.5 seconds but what the part actually does I still haven't figured out ok this is the 7-color tristor this is so to say an old school effect because on every line here I set up the amount of registers to display the line itself and I do this 192 times and then I'm done which is pretty nice because it leaves all the upper and lower bottle again for loading and while this part is displayed we load the next two parts and keep them in memory for later it's also technically not quite interesting because I don't think any internal counter of the graphics ship is the way as it was intended so it's totally confused there's just one problem with the part have you noticed it's fucking ugly we ran out of time to add a proper object meanwhile thanks Joe I have a proper object which is this is generated from some I don't know and now we got a hand drawn object and the movement is very very bad I mean it looks like it should be like twisting it should be a twister but the final version will definitely improve on that because this was one of the main blockers for the final version this is what we call coder colors every graphician would run away crying we're seeing that colors but well I'm a coder for a reason the graphics are all hand pixel by the way I think they had a photograph as a reference but it was not not wired as we say it was really hand pixel and I think they given the constraints they did a really really good job yeah and this I don't know it's a free directional tunnel the final version will be able you will be able to control it with your joystick to see it's real time the creator boobies has a PhD in math I think you need that no idea I fell off my chair when I saw this was a first one think about it we have still 985 kilohertz and we do a free rotating tunnel there well beats me also this is this is a filler we have to get rid of that in the final version that's just too boring I don't like the graphics too much either yeah and then we have the tunnel we have to admit that the calculation of the movement that's all pre-calculated but the filling the filling is done in real time and this is another part which will be greatly improved in the final version that was that oh one thing I changed it now reloads itself so once you started it you either stop it or we'll run endlessly yeah I think this was it from my side I hope you could find something interesting in that for you I hope it wasn't boring or could give you an idea and of course if you have still questions I'm eager to hear them we have 10 minutes for questions so if there are any questions please raise your hand so that an audio engineer can come to you yeah okay alright 80s we needed you now actually why wasn't this possible in the 80s I mean I've seen a lot of counter 64 and nothing goes I mean just the last scene was a bit like the game way out but everything else was just totally amazing and beyond what was being done in the 80s so what makes the difference evolution I can't probably say more than that because of course with those new school effects they were influenced by PC demos sometimes they had more computing power so they could try free directional tunnels once they had this done C64 coders tried okay let's try that on our machine so this would be one one answer to that and it takes time to really understand the machine this is what troubles me in real life I work for linux for new CPUs and once we have the basic set of drivers and everything in the mainline the processor is discontinued and you start working on the next one that's somehow stupid and a lot of things which are abused here are more or less flaws in the chips to find out that there are flaws and then it takes time to find out what you can do with these flaws and we're still it got rare but there are still once in a while somebody comes and shows something on the Commodore 64 which has not seen before after 30 years it takes time any more questions yes maybe I want to connect to this question is it possible that emulators got an impact on developing demos on the 64 because of using the development cycles is it possible I would extend this to cross development in general my first system I had was a cross development system where the assembler address was on the PC and I transferred the object code to the C64 via cables that was already a big help using emulators is another help because you can stop the machine at any point in time without any side effects there are very good freezer cartridges so you can stop the real machine but they tend to have side effects so it makes it a bit easier yes I have another question I really understand that you have to use self modifying code to show such demos is it possible to reuse code or do you write every demo from scratch can self modifying code be reused to generate every code even the self modified code has an initial state and you can reuse that but reusing in this term at least from my point of view it means if you want to use something from older demos it's copy paste and hack until it fits to the current demo I don't have any kind of library that tends to not work for my case I'm not sure about all the others but I would think it's rare okay thank you there's one question on the EISC there are actually two Finkel is asking what your favorite C64 demo is that changes over time at the moment I like very much Andrapolis from Boost Design which has a very astonishing 3D part which is real time and I like Insomnia from 64 ever pretty much and there was one Fairlight demo I just forgot doesn't matter Delroth did you find or fix any bug in the emulator while working on this demo I didn't fix any bugs but the emulators had to be fixed for that demo that happened because I'm the guy who really likes to do the register based effects and try out new things I think there are quite some but a few improvements that's always fun gives you good feeling okay one more question I have two questions do you have a macro assembler on C64 don't you use macros for speed coding for example the problem, yeah you can do that but the problem is that with speed code it has a pattern but for example the addresses to use change very much so a generic packer will have lots of problems with that code speed code so that results in large binary blobs you have to load as I said you have a priori knowledge you know how the pattern is and using these generators you save a lot of code it's really like these generators are I don't know 500 bytes, 1 kilobyte or whatever and the packets code could be 12 kilobytes or 20 so you usually don't do that and on Commodore you can have a scene manager because I am from the PC scene and we use scene managers but I don't think that I don't know actually if Commodore have enough power for that for what? scene managers I don't think so that's yeah so how do you manage the scenes like yeah we have a script written down more or less and then we work according to that script sync to the music and then it's more or less done manually there's one more question in the back so how does the demo team organize itself do you use version control or do you use IAC and how do you communicate and does everyone work on its own part in the end someone has to put it together or is it yeah is there cooperation involved it depends a bit usually we use a lot of email and IRC so far we did not use a version control system but for our next demo we will start using one it's a bit of Oswald is really a great coder he lacks a bit in terms of software development methods so for this demo the next one we introduced him to the magic of make files sorry Oswald but that was necessary so we will next introduce version control systems to him what else working on the parts sometimes you have an idea and work on that individually and then in the end show it to people and then they have comments or not you already have a script and then you have an empty spot there and then you collect ideas together and one starts and others add to it so that depends a bit on the situation it can be that really one coder is responsible for a part but it can also be a team effort or like with the bump wrapper Oswald comes to me and says okay I want to do this and I will do the bump wrapper and I need a routine from you so we start with the scrolling and then we define some interface and we throw it together and which version control system are you intending to use once again which version control system are you intending to use in the future um subversion because what do you want to explain gits to someone who just learned make files but but he's got a phd right so no no that's it no I think it's see we have windows mac linux systems and I think it's okay to use subversion as the least common denominator I will use git as for n for sure and I'm happy with it they will we have I don't want to force something on people I just want to work with them as they want and as they are used to and most people in that regard are used to subversion okay okay there's one last question here in the audience I'd like to ask another question connected to the previous one how do you organize in the sense not what tools do you use but how do you interoperate personally do you explain stuff to each other do you educate each other or is it more like a splitting task and work individually and put it all together afterwards no we're teaching and we're explaining stuff to the degree the other person wants so I am more the specialist for these register based effects and the other guys are more specialist for the table based effects but that does not mean that we don't know shit about the other part so we do know something and we do want to improve our knowledge so we really we discuss to a certain degree I did not want to know all the mathematics behind the free direction I'm just happy that it's possible to do in the 64 and but to a certain degree yeah we work as a team and explain stuff to each other we also discuss ideas do you think this is possible what would it need and how could it be done do some brainstorming together also yeah okay I'm sorry but we are running out of time so thank you Ninja for this wonderful talk