| |
Slightly cold news on page 10! Phlamey breaks the server. |
| |
This is a long thread. Click here to view the threaded list. |
| |
|
Adrian Lees |
Message #106601, posted by adrianl at 14:07, 29/2/2008, in reply to message #106597 |
Member
Posts: 1637
|
5-second post to say that I did actually download and start perusing your source around 3.30am, ran the game and it's reporting 37fps on my IX; not tried A9home yet but can later this evening; do see the flicker on my GF5; will aim to have a proper look at the source tonight/over the weekend.... |
| |
 [ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106602, posted by Phlamethrower at 15:06, 29/2/2008, in reply to message #106601 |
 Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
5-second post to say that I did actually download and start perusing your source around 3.30am, That's why I stayed up late to get it uploaded, because I knew you'd be awake at that hour 
will aim to have a proper look at the source tonight/over the weekend.... Yay! |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106605, posted by Phlamethrower at 20:26, 1/3/2008, in reply to message #106602 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I've just uploaded a new version of DeathDawn, with about 20 load/save/new game-related bugs fixed. So savegames/etc. should now work properly.
A couple of bugs may have been causing crashes even if you weren't using savegames, and there were a couple of bugs in the tile caching which would result in corrupt tiles being drawn, so even if you (Adrian) aren't planning on using savegames it might be worth downloading new copies of the game + source. I've also fixed it so that you won't spawn underground if the playpen building doesn't spawn.
[Edited by Phlamethrower at 20:30, 1/3/2008] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106606, posted by Phlamethrower at 21:12, 1/3/2008, in reply to message #106539 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
I haven't plucked up the courage to finish the new map plotter yet, but ...
What about the FLAC player, with DiskSample?
http://users.skynet.be/Andre.Timmermans/digitalcd/modules/disksample.htm ... I've just downloaded the latest DiskSample module set so I can start adding support for DiskSample into the game. This will give you/me quite a few new options for music formats to use. I'll also add support for internet radio/files, since the sample that comes with DiskSample makes it look sufficiently easy to support.
Hurrah for André Timmermans! |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106607, posted by Phlamethrower at 02:03, 2/3/2008, in reply to message #106606 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Dissappointingly, FLAC playback seems to eat about the same amount of CPU time as MP3 playback (about 25% of CPU time). This was with a stereo 22khz track converted using encoder level '6'. Also the larger file size resulted in noticeable pauses as it was streamed from the slow IDE interface (Although I guess forcing it to use smaller buffer sizes could fix that). I haven't tried any other encoder settings yet, but I'd guess that the CPU time won't change all that much. Playback also seemed to cause my RiscPC to crash once or twice (although there's no guarantee it was the music doing it).
Ogg Vorbis is even worse than FLAC - eating about 50% of CPU time when playing the same sample encoded at quality '5'. I'm not sure, but I think the Vorbis module is just a port of the standard decoder, without any real ARM optimisations - so that might explain why it's so slow.
Since the new DiskSample module set came with a 32bit copy of PlayIt, I thought I might as well try that for ADPCM playback - which seems to take a much more comfortable 7% CPU time. The file sizes aren't too bad either, being only twice as big as the Ogg Vorbis file. The only problem with using ADPCM is that PlayIt doesn't support SharedSound, so there were no other sound effects playing. In fact, the game actually got faster, because PlayIt was preventing my own buffer filling code from running. After some more tests it looks like the buffer fill code I'm using for the sound effects is eating 15% of CPU time!
So (unless Adrian gets there before me) I suspect I'll soon be spending some time seeing if my buffer fill code can be optimised. I also need to change the code to properly manage the sound volume so that distortion/crackling doesn't occur where the volume overflows if too many samples are playing (most noticeable at the moment if music is playing).
And with regards to music, now that I've got a 32bit version of PlayIt, and also the documentation for the driver interface, there's a good chance I'll be able to write a SharedSound driver so that PlayIt can use that, allowing it to be used for music in the game. Assuming my code isn't as horrible as in DeathDawn  (And assuming I can work out why PlayIt/DeathDawn seems to think the test ADPCM file I was using is only 4 centiseconds long)
[Edited by Phlamethrower at 02:06, 2/3/2008] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106613, posted by Phlamethrower at 16:00, 2/3/2008, in reply to message #106607 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Another update, then:
After some more tests it looks like the buffer fill code I'm using for the sound effects is eating 15% of CPU time! Closer inspection suggests that the buffer fill only takes about 4.4% of CPU time. So I'm not entirely sure why I was reading 15% earlier.
However I have discovered that running the buffer fill from an interrupt handler (as opposed to a callback) was eating up 6.3% of frame time, so I've now changed it to use the callback system. This means that (without music) the RiscPC now runs at an average framerate of almost 26fps. Hurrah!
And I guess that 4.4%+6.3% = almost 11%, so the other 4% or so of perceived time spent filling buffers might actually be being spent inside SharedSound itself. Certainly finding that buffer filling is only taking 4.4% instead of 15% means that I'm not so worried about optimising it as I was before.
And with regards to music, now that I've got a 32bit version of PlayIt, and also the documentation for the driver interface, there's a good chance I'll be able to write a SharedSound driver so that PlayIt can use that, allowing it to be used for music in the game. Finished! It's still probably a bit dodgy (certainly there aren't any volume overflow checks when it mixes the PlayIt sound data into the SharedSound stream), but it seemed to work OK in DeathDawn.
DeathDawn on the RiscPC with ADPCM music runs at about 40.768msec/frame, i.e. almost the same speed as it was before I switched to using callbacks for the buffer fill code. So with the other optimisations to be done, it's now fairly clear that running at 25fps with music on a RiscPC is going to be possible.
The only problem I've now got with the music is that (on my Iyonix at least) SharedSound seems to be doing something sneaky with the volume when more than one sound handler is installed. If you have two handlers then it will halve the volume of each handler so that you don't get overflows. Which is quite nice for keeping buffer fill code simple, but it means that when the radio stops as you change channels/cars/etc. you'll get a sudden spike of volume from the sound effects. Which isn't so nice. And this volume scaling seems to be getting done even though I'm ignoring the volumes that SharedSound suggests that I should use - it must be part of some sneaky post-process somewhere. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106658, posted by Phlamethrower at 15:26, 8/3/2008, in reply to message #106601 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Update:
The dcache-optimised map plotter works, but only results in making the already fast bits faster while making the slower bits slower. So until I can find a way to get it to make the slow bits faster I'm leaving it disabled and sticking with the old code.
A few other small optimisations have resulted in some decent speed boosts though; without music the game now runs at a comfortable 36.755msec/frame (27FPS) on the RiscPC. With ADPCM music it runs at 39.881msec/frame - so just reaching the target. Also I decided to try the Iyonix at 800x600 instead of 640x480, and discovered that it does just manage to run at 25FPS. But it isn't really fast enough for me to consider increasing the default resolution.
Since the game is now (just about) running at its target frame rate on the RiscPC, and since I can't really be bothered hunting for further things to optimise, I think I'll start adding some new bits of code. This will also mean that the test run I've been using for the profiling will change significantly, so I wouldn't be surprised if the next time I do some profiling I find that it's somewhat slower (or faster!) than it is now.
5-second post to say that I did actually download and start perusing your source around 3.30am, ran the game and it's reporting 37fps on my IX; not tried A9home yet but can later this evening; do see the flicker on my GF5; will aim to have a proper look at the source tonight/over the weekend.... Have you had a chance to look at this yet, Adrian? I can upload the latest source if you want (you'll get my optimisations plus DiskSample/PlayIt support so you can try with AC3/Ogg/FLAC/ADPCM/etc.) |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #106660, posted by andrew at 02:14, 9/3/2008, in reply to message #106658 |
 Handbag Boi
Posts: 3439
|
Where's the music? I just get the CD playing.
Car driving is excellent. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106661, posted by Phlamethrower at 04:23, 9/3/2008, in reply to message #106660 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Where's the music? I just get the CD playing. I haven't released any of the music yet, so for the moment it will just be the CD. (Unless you put your own music in the radio file)
Car driving is excellent. Still not perfect though - there are some bugs in the movement code making it hard to steer while going up/down slopes, and I still need to work out why handbrake turns aren't working properly. |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #106662, posted by andrew at 11:47, 9/3/2008, in reply to message #106661 |
Handbag Boi
Posts: 3439
|
Are you going to make the map cycle around e.g. like SF3000? Or have boundaries on all sides| |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106672, posted by Phlamethrower at 13:40, 9/3/2008, in reply to message #106662 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
There will be boundaries on the sides. Probably big walls, since the cities are meant to be built fortress-like. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106850, posted by Phlamethrower at 22:29, 21/3/2008, in reply to message #106672 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Good news, Acorn abandoneers!
I've spent this afternoon working on an SDL port of the game, so you'll now be able to play it on your Windows/Linux/Mac/toilet. The game is now running with SDL (as seen below), although there are a few bugs (some of the maths code seems a bit screwy) and a few missing features (fonts, sounds, and radio). Fonts and sounds should be along shortly, radio will probably take a bit longer, probably just using SDL's CD audio & WAV support (which supports ADPCM!).
Of course, the screenshot below was taken on RISC OS, so I still need to do a bit of work to see if it runs on non-RISC OS. I've modified the code so it can build without any ARM assembler or SWI calls, so technically all that's left to do is produce a Unixy makefile and change a few filenames in the code to get rid of the Unix-meaningless <DeathDawn$Dir>. So sometime tomorrow expect to see screenshots of DeathDawn running on Windows and (most importantly) my Zaurus 
There's some news for the non-Acorn abandoneers as well. I've tweaked and fixed the train physics/AI, reworked the map generator a bit to try and increase the reliability of the mission building spawning code (hence all the compass arrows in the screenshot below - there's about 10 train stations in the test map now), and added the first version of the traffic light code (although the aren't any visible light objects yet). |
| |
[ Log in to reply ] |
| |
|
Andrew |
Message #106854, posted by andrew at 01:54, 22/3/2008, in reply to message #106850 |
Handbag Boi
Posts: 3439
|
|
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106855, posted by Phlamethrower at 02:01, 22/3/2008, in reply to message #106854 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
 |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106857, posted by Phlamethrower at 00:07, 23/3/2008, in reply to message #106850 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
So sometime tomorrow expect to see screenshots of DeathDawn running on Windows and (most importantly) my Zaurus Guess I'm running a bit late
The Windows/Cygwin version is working, and has already unearthed a few null pointer bugs that weren't getting caught on RISC OS. And at midnight I'd literally just linked the first Zaurus version, so I'll hopefully have that up and running in the next hour or two.
Fonts and sound have also been fixed for the SDL version (although fonts are a bit broken in the screenshot below, and sound causes a crash after a few seconds on RISC OS. And is completely silent on Windows.)
[edit]
main: DeathDawn build 2354 23:38:10 22-Mar-2008 (SDL) (Debug level 2)
Using gameconfig <DeathDawn$Dir>.gameconfig
QPaintDevice: Must construct a QApplication before a QPaintDevice Stupid SDL!
[edit #3]
Looks like there's a libSDLmain I need to compile. Luckily it's just one small file, so it shouldn't be too much hassle to get working.
[Edited by Phlamethrower at 01:06, 23/3/2008] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106860, posted by Phlamethrower at 13:24, 23/3/2008, in reply to message #106857 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Well, it kind of works on the Zaurus now. The engine seems to run fine, but SDL seems screwy. When you start the game the LCD will slowly white-out like the machine has crashed. Entering and exiting sleep mode will fix that, but you'll be left with a static image on screen (handily captured for your amusement below). After a few seconds my click into the terminal window worked, and the system was returned to normality - except that deathdawn was still running in the background, and not responding to kill signals Luckily it died with a segfault a few minutes later, otherwise I would have had to reset the machine again (like I did the first time I saw the whiteout, thinking it had crashed the machine).
I'm starting to think that I should just skip SDL for the Zaurus and write a proper Qt interface. This will probably be easier in the long run, since SDL is notoriously tricky to get working properly on the machine, and floating rectangles in the middle of the screen aren't exactly user-friendly.
[Edited by Phlamethrower at 13:25, 23/3/2008] |
| |
[ Log in to reply ] |
| |
|
James Lampard |
Message #106872, posted by Lampi at 15:23, 25/3/2008, in reply to message #106860 |
Posts: 190
|
Jeffrey did you know that
http://www.coderscauldron.com/darkmatter/
has lapsed?
It now shows lots of dodgy links. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106874, posted by Phlamethrower at 15:49, 25/3/2008, in reply to message #106872 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Jeffrey did you know that
http://www.coderscauldron.com/darkmatter/
has lapsed?
It now shows lots of dodgy links. Yes. Although Rich only managed to give me a few days warning
Since the site wasn't really getting used, it won't be making a return. So the useful stuff (SunEd and WOUM) is now located on my own site; and the un-useful or abandoned stuff is just sitting around on my hard disc. I'm currently counting Dark Matter as abandoned, although it may eventually make a return once DeathDawn is finished (or if someone pokes me enough for the source code). |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #106903, posted by Phlamethrower at 23:58, 26/3/2008, in reply to message #106874 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
After looking at the current status of the engine, I've come to the conclusion that I should now change from a top-down style "The engine will contain this!" approach to a bottom-up "In order to write this mission the engine needs to do this" approach. So basically I'll be finishing some designs, getting some appropriate art/sound assets, and then trying to implement the mission script for the first (and potentially only) city. So the next release (whenever it may be) may actually be the first properly playable version of the game.
The SDL port will be taking the backseat a bit; really the only thing I'll be commiting myself to for the next release is fixing the sound problems and tidying up the code a bit. I'm sure that any SDL users will be able to live without a UI for saving games or changing the game options |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #107095, posted by Phlamethrower at 16:58, 19/4/2008, in reply to message #106903 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
After spending a few days of just drawing sprites I became distracted by something far more interesting - the prospect of a working Nintendo DS port. If you run the game without sound and without using the map generator it'll fit in under 4MB of RAM, so the hard part was already done...
So needless to say I've now got a DS port to add to the portfolio. After getting the assembler code working the game was running at a steady 15-20fps using software rendering - which is somewhat better than I was expecting considering that it's running on a CPU about a tenth the speed of an Iyonix (or a quarter the speed of a StrongARM - which can only just manage 25fps @ 320x256). But when you take into account that the DS has a 33MHz memory bus instead of the RiscPC's measly 16MHz, and that the DS is writing about half as many pixels to screen, the relative performance does make sense.
Of course 15-20fps still isn't that great for playability, and as I keep adding more sprites to the game I'll eventually run out of memory to put things in - so I've now also got a version running which uses the DS's 3D hardware to do rendering, and streams data from disc/ROM whenever it's needed for rendering. There are still some bugs to iron out (some screen flickering during texture uploads and problems with memory fragmentation) but performance-wise the game is already running at 30fps most of the time.
At some point I'll be getting sound working (which will also use the file streaming code), and I'm hoping that the 2MB buffer that the file streaming/caching uses will be a suitable size for me to optimise the map generator into, so that the DS version will run and play identically to non-DS versions.
The work I've done to get the assembler bits running on the DS can also be re-used to get the assembler bits running on other ARM platforms (i.e. the Zaurus port, or the RISC OS SDL version). At some point I may also try re-using the VRAM manager and 3D rendering code to get an OpenGL renderer running on the (non-RISC OS) SDL version.
The only real problem with the DS version is that I've had to lower the camera a bit so that things are big enough to see. But I can probably add an option to the options menu (once I write it!) to control whether the game uses the normal or lower camera viewpoint. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #107175, posted by Phlamethrower at 13:55, 27/4/2008, in reply to message #107095 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Another cross-platform update:
* The DS version now has sound and music. Music is via a software ADPCM decoder on the ARM7, and seems to work fine. It may have been possible to use the hardware ADPCM playback for music, but I'm not sure whether it copes properly with streamed data. It would also have required manual de-multiplexing of stereo streams. Sound is currently controlled by the ARM9, which is the simplest solution, but does steal some valuable CPU time away from the main game. The buffer fill also seems to go out of sync with the hardware every so often, which is a bit of a problem. However it is using a slightly different timing method to the music player, so if I change the code around then it might work better.
* Sound for the SDL version has also been fixed, but there's no music support yet
* I've added some simple frontend menus to the non-RISC OS versions of the game, so you can now load/save games as well as change the configuration options
* Today I've also just started work on the new Zaurus version. Although the screen shot below suggests that the game is running at 30fps, the screen refresh is actually a lot slower, since the game engine and the Qt interface are in seperate threads. The screen refresh feels closer to 10fps, which is a bit worrying - but hopefully it won't be too bad once I've got the thread synchronised so that the game engine won't steal CPU time away from the frontend when the frontend is busy redrawing. I may also have to work out how to use the Zaurus's hardware overlay, because the redraw code in Qt is rather slow. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #107854, posted by Phlamethrower at 21:57, 13/7/2008, in reply to message #107175 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
The busy period at work has come and gone again, so now I have enough time/energy to work on DeathDawn once more. I'll be giving the cross-platform ports a bit of a rest (I've reached the limit of what I can easily do to them), and will instead be back to concentrating on what I should have been doing in the first place - creating the first city.
The only problem, as usual, is that there are so many things that need doing that I'm not sure what to work on next  |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #107961, posted by Phlamethrower at 01:19, 4/8/2008, in reply to message #107854 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Things seem to be going well at the moment. I've added a fair few new building textures and a few new cars, so the city is starting to feel a bit more real. I've also been focusing on improving the mission script parser, so that it's easier to create missions. In particular you can now spawn entities at suitable random points throughout the map instead of just at specific predetermined buildings. Sometime soon I'll be at the point where I can start writing some proper missions (Specifically, all I really need to add is one new car for the remaining megacorp to use).
However I've also discovered that the current map generator is fairly poor at placing small buildings - which I've defined most of the new buildings to be. So at some point I'll have to redo the building placement code to place multiple buildings within the same city block, either terraced or with pathways between, and to be more flexible in general. At some point in the future I'll be looking to add support for signs sticking out of walls, fire escapes leading to roofs, billboards on roofs, etc., so I'll be aiming to make it flexible enough to support all of that too.
I've also had a quick poke at the Zaurus version. The synchronisation code to make the game thread run in step with the screen redraw seems to be working, which is good. But it looks like clock() is either slow or isn't counting any of the time the game thread spends suspended - although the framerate counter says 30fps, the in-game clock is running at about a quarter the speed it should be. Apart from the strange behaviour of clock() it's also rather worrying because it suggests I'll have to find a completely different way of redrawing the screen if I want the game to be playable. Hopefully I can find some examples of how to use the hardware overlay, as that will provide the best performance instead of jumping through Qt's hoops all the time.
[Edited by Phlamethrower at 02:22, 4/8/2008] |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #107997, posted by Phlamethrower at 22:57, 10/8/2008, in reply to message #107961 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Sometime soon I'll be at the point where I can start writing some proper missions (Specifically, all I really need to add is one new car for the remaining megacorp to use). The missing car has now been added, so I've now started work on writing some proper missions. Unfortunately the multitude of bugs in the script parser and the game code are working against me, so things are going slower than I'd liked. I'm almost at the point where I'm annoyed enough with the script parser to get rid of it and replace it with something that works properly. However I'm also tempted to try adding ambitious new features to the new parser, to make mission scripting easier, e.g. modelling each mission around a finite state machine so that it's easier to keep control of which events are active on which entities.
Hopefully I can find some examples of how to use the hardware overlay, as that will provide the best performance instead of jumping through Qt's hoops all the time. I haven't found any documentation for the Zaurus hardware overlay yet, but I'm thinking I might just cheat and write directly to the framebuffer. But since that will involve a fair bit of new code it will probably have to wait until I've sorted the map generator/mission script issues out. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #108926, posted by Phlamethrower at 22:23, 1/12/2008, in reply to message #107997 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
DeathDawn setting + Dwarf Fortress engine/gameplay = WANT. Bah!
Oh well, maybe that can be the sequel. (Certainly it would be a lot easier than the Dwarf Fortress In SpaceTM idea that I've been kicking around in my head a bit)
Also I've been a bad boy and not done any work on DeathDawn for the past few months. |
| |
[ Log in to reply ] |
| |
|
Jeffrey Lee |
Message #109090, posted by Phlamethrower at 14:42, 4/1/2009, in reply to message #108926 |
Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot Hot stuff
Posts: 15100
|
Over Christmas I managed to write the new script parser. Hurrah!
The new parser is much better than the old one, since it won't get confused when faced with expressions such as "i-1" or "IF VLEN(emissions[0].org-emissions[1].org)>3.0 THEN .tribe_m1_gopark". It also attempts to perform type checking at load time, so the majority of syntax errors are now detected immediately instead of when you hit the affected code (although the type checks are often too restrictive, so some work may still be needed). |
| |
[ Log in to reply ] |
| |
|
VinceH |
Message #109531, posted by VincceH at 09:16, 12/3/2009, in reply to message #109090 |
 Lowering the tone since the dawn of time
Posts: 1600
|
I've found some more music for you - however, while the music is free to download, the site very usefully doesn't mention any licence terms. There is an email address, though, so it's only a matter of sending an email to ask if it can be used in a game. |
| |
[ Log in to reply ] |
| |
|
Jason Togneri |
Message #109532, posted by filecore at 09:34, 12/3/2009, in reply to message #109531 |
Posts: 3868
|
I think I'll pop back to page 10; I've forgotten what the h0t news was.
EDIT: it's cooled down slightly, you swines!
[Edited by filecore at 10:58, 12/3/2009] |
| |
[ Log in to reply ] |
| |
| Pages (22): |< <
22
|
