Rumours...
Well, well, well. The rumours are getting stronger. To Be or not to Be (sorry).
I've been following the Apple news quite closely of late (pcs-191 on Compu$erve) and Be is figuring prominently in a lot of media speculation. My personal volition is that quite frankly I just don't care anymore - whatever happens is fine. The Mac is here to stay - period. The O.S. will get better, one way or another. The PowerPC's abilities will be harnessed. 8086 will die, and not a moment too soon either. This time next year we'll all be running OpenOS (Go guys!) :-)
Who knows? I'm not sure if anybody does at the moment, not even Apple (Bless you!)
"I would be most surprised if Apple (Bless you!)
we're to abandon MacOS 8 in favour of Be's OS...".
That was quoted from StuChat#12, now I am not so sure.
We've been told Copland is dead, so what do we get now? Personally I fail to see what the problem is (controversial I know). If I were Apple, I'd just introduce the microkernal with a new Finder - and then modify the API's as time permits. I'd say "It's there if you want to use it", if not the old code is there too. You can use AppleEvents if you want, or you can use the kernal messaging services - your choice. You want to protect a memory range - just pass the range to the kernal and ask. It is a God given right of any O.S. to provide memory protection, and it's not as if Apple doesn't know how - SADE (a high level Apple debugger) was doing it ages ago.
Development-wise loads is happening. It looks as if we'll be doing a 4.2 release before V5. The compiler has actually compiled six lines, although the last four lines were "complete boll*cks :-)", Eddie has gone to 1.6, we've nearly finished defining the plug in spec. for front end tools (Rob came up with "I want a plug in to read the text so I can tape it and listen in the car...hmmm) and preproc #4 looks like it may work this time.
Some people have moaned about not knowing 415 was released. We are deeply sorry about this, but we will get round to publicising the fact - it just takes time. The simple case is that we publish first and foremost on our www pages and to the list server - we rely strongly on word of mouth and believe it is better we spend our time developing and supporting rather than marketing - daft thing for a business to state, but that's how it currently is.
Mondays...
Monday. I used to hate Mondays.
Had a lie in, didn't get up till 9:30. Normally I either work through the night, or get up at 4:30 a.m. The great thing about working for yourself is you can work whenever you like, so I do. This isn't to say I don't work much - I do. On average it's between 12 and 16 hours a day, but sometimes I get over tired, and the only thing to do then is drink some of the Shamrock and get some shuteye.
I lead a strange life (as Cath, my wife, will tell anyone!). Having tried to work "normal" hours, I find it does not work - I simply can't think whilst the sun is up. I can wang out more code between midnight and 6a.m. than I could in five days of "normal" hours. It must be magnetism or something? The other really weird thing is the louder the music, the better I work - something my neighbours just do not appreciate - period.
Anyway, back to Monday.
Got the mail. Normally in a twelve hour period I'll get between 10 and 20 emails. First thing I do is answer it. This generally takes about an hour and is a nice way of easing into the day. Today it's easier as I've just upgraded The Beasts speakers to 300W jobs (so the manufacturer claims! No Way, p=iv and all that...) and Meatloaf sounds a lot meatier than he used to. They must be quite pokey thou, if I go make coffee and leave the CD playing, when I return, the keyboard is on the floor - but that's OK, cause it's a heap anyway!. Today is also easier as for the last two days all I've been doing is sorting out some Eddie foibles, and this version (1.6) is a lot neater, although not ready yet.
In this mornings mail was a demo (Fire) from Allan Jensen (maccoder@geocities.com). Allan is ex-Amiga and writes very neat code complete with readable (and entertaining) notes. The demo, in 68k assembler, runs in 800*600*256 (source mods required for other resolutions) and will trot along on anything with an 040 upwards (i.e. LC475 upwards) although he states it needs a PPC box. Interestingly it will run faster on a 475 than it does on a PM7200/90, mainly because of the emulator speed I guess. I'm sure Allan will find it necessary to write a native version :-) I'd estimate a x3 to x8 speedup depending on style (i.e.FPU usage).
I've placed his demo in the downloads area - it is extremely well written and commented and I would suggest everyone takes a look - it's a 14k download.
Allan mentions not quite cracking PPC assembler yet, what with the "backwards" operand placement. All I can really say about it, is after coding PPC, it makes 68k feel very old fashioned - give me PPC any day - it's very flexible.
He also states he used the plot routines out of Fantasm's library and then went on to optimise further. This is good, as that's why we supply the source code :-). The library routines are always a good starting point, but because they are generalised, really aren't fast enough for real use - Allan optimises his plotting by moving longs (i.e. four pixels at a time). In PPC one could plot 8 pixels at a time with lfd / stfd instructions.
In his notes, Allan inquires about Mac tiled scrolling. As some of you may be aware, we have a game, Eclipse, and it just so happens that some stages of the game are scrolling sections (I can see I'm going to have to "put my money where my mouth is" before long!). I can state that it's not easy, indeed it took longer to write the scrolling sections than it did everything else put together. Basically, for scrolling, 'specially multiplane scrolling, you need to design everything first, specifically with regard to the printing and unprinting stages. Print all in one go, display, then unprint backwards. If you get this wrong, your overlaid sprites will either get dragged by the scrolling background, or else you'll get artifacts when moving sprites are overlaid.
The other thing Allan asks about is sprites - icl8's are too limited. Ok, in this case we use BMP strips (yes, that's the Windows (spit) graphics format). For example if a sprite has 8 frames of animation, we draw all 8 frames on one long strip (in Colour It!, Painter, Clarisworks, ShareDraw or whatever you have), then save it as a BMP. You obviously need custom written programs to take these BMP's and insert them into the right resources in your game/demo. Previously we've published BMP expander code (StuChat#11). Using such code you simply expand the BMP's into memory and use these. Using strips rather than other shapes means one does not have to "cut" the shapes out - as the width of the strip is the width of the graphic.
For Eclipse, we currently have two custom written programs - the first takes a graphic and inserts it into the resource fork (although the shareware Graphic Convertor also does this) and also designs and produces resources for game level control. The second is a map designer for scrolling sections. If you are designing a game, it is well worth taking a few days out and writing your own miscellaneous tools. The Mac will be around for a while, so you should get good life out of these.
A typical tool will handle sound, graphics and other bits and bobs. It is folly to think you can design every level in hex - you can't :-) (Although we have seen some wicked Fantasm macros for this!).
Most games are either event or time driven, or a mixture of both - for example in a scroller, you want to be able to say, when we get to scroll frame 1000, I want a wave of nasties to come in out of the north east. The wave formation has already been defined (possibly in another tool), so you just state "formation 17" or whatever and you're tool does the right thing.
In-betweening means the tool generates necessary graphics for you, rather than having to define every single graphic - for example I want a slope but to be more realistic, it has to have a certain randomness to it. Again in a scroller map designer, I click at the start position and end positions, and the tool generates the necessary graphics shapes to create a slope between the start and end click points.
I should point out, that any PPC chip is more than powerful enough to do this sort of thing on the fly, and some programmers maintain that it is quicker to decompress data on the fly, rather than have decompressed data to start with (from a cache point of view).
You can write your tools in anything you like - for Eclipse I started with a standard shell written in ECL, then added bits in hand coded PPC. High level languages are fine, but the mechanical nature of the type checking can get in the way some times. What do I mean? Well, assume I have just got 16 handles from the memory manager and I want to check they're all valid - AND them together and if not zero, they're all ok (saves a lot of compares and code) Well,in C you have to cast a handle to a long before you can "and" it, so the type checking gets in the way (for me anyway). No problem in assembler - I know the handles are 32 bit, so I just AND away. Even better, between the last AND and the conditional branch, I get some free instructions :-)
Whilst we're here, a few notes about sound creation. If there's one thing the Mac has no shortage of, it's sound generation programs and sound hardware. Almost any Mac is suitable for sound design. Obviously an AV or PowerMac is better, but for games, 8 bit is fine. We do ours in 16bit. Some are stereo, some are not and are made stereo during the gameplay (by playing on two channels, with a bit of delay or whatever). The best news is that it need not cost you much - the shareware programs are excellent and are quite capable of producing any kind of sound.
Now, there's two ways you can produce your sounds - either
pre-sampled or created from scratch.
Pre-sampled sounds can come from anywhere - for example your Yamaha,
Technics or Casio keyboards are always old faves. You can also
record "live" sounds through the Mac's microphone or
you can sample off CD. Of course, copyright is a problem, but
as Ice-T found out, anything less than 8 seconds is fine (but
don't quote me on that! )
For the ultimate in control however, you should create from scratch. This requires more skill and understanding of sound, but is well worth the effort. An average sound generally takes me about an afternoon to create.
Grab yourself a load of shareware programs off the net (or a magazine CD or floppy) - a few good examples are "SndSampler", "SoundEffects" and "SoundBuilder".
To create a sound, you should start with a basic wave form - sine, triangle, sawtooth, squarewave. Use any of these programs to create say a two second burst at you're required base frequency. It is surprising how low in frequency sounds are - for example 440hz is middle C on a piano keyboard and actually sounds quite high in pitch. It is important to get your base sound correct - I generally record three each of sine, triangle and square at a range of frequencies round about the area I'm interested in. Be aware, that the greater the rate of change of the amplitude, the more harmonics (or complexities) will be produced. Thus a square wave is very rich in harmonic content.
After you have your base sample, try to draw your sound on a piece of paper. It helps visualise how you want the sound to vary. Don't forget you have control over the amplitude, the frequency and if stereo, the position of the sound at every single point of the digitised form. A big tip here is do NOT wear headphones whilst working with sounds. Whilst you may need them to check dynamic range and signal to noise ratios (SNR) etc, you're listener will be using either the Mac's in built speaker (not hi-fi!) or at best hi-fi speakers and amplifier. Headphones will give you the wrong sense of position - actually thats wrong, position with speakers is more vague than with headphones, so you need your position correct with speakers, and not cans.
Another big tip, is to save your sound after every modification - this gives you the chance to "go back" should you really blow it after four hours work! Do experiment with down sampling, and then up sampling again (followed by smoothing) - this can introduce some very weird phasing effects with stereo sounds. Ring modulation (if you need it) is best applied early in the processing, then followed by heavy filtering if it isn't to sound pathetic and old fashioned.
Finally, try to maintain the SNR - this is sometimes difficult. 16 bit sounds should have an SNR at least better than 80dB, and preferable closer to 90. Any hiss must be filtered out. You can do this by first expanding the amplitude (do not "clip" the sound, that is over expand so the top of the waves are clipped flat), then low pass filtering (only allow frequencies lower than the hiss frequency), then compressing the amplitude again. This may cause you to loose harmonic content - if this is the case then you simply have to go back to a previous copy and try again :-(
There is something very satisfying about creating a sound out
of nothing. Artificial sounds are easy to create. Natural sounds
are much harder. In Eclipse we needed a "whale" type
sound - from a basic sine wave to a lovely whaley sound in about
3 hours - just a load of numbers, but it sounds great.
Some hard code (PPC)
Initialising sound channels (no callbacks - you may need them to let you know when a sound has finished):
la r3,left_chan(`bss) li r4,5 *sampled sound li r5,2 *left channel li r6,0 *no callback Xcall SndNewChannel la r3,right_chan(`bss) li r4,5 *sampled sound li r5,3 *right channel li r6,0 *no callback Xcall SndNewChannel la r3,middle_chan(`bss) li r4,5 *sampled sound li r5,3+2 *center channel li r6,0 *no callback Xcall SndNewChannel la r3,middle_chan2(`bss) li r4,5 *sampled sound li r5,3+2 *center channel li r6,0 *no callback Xcall SndNewChannel la r3,stereo_chan1(`bss) li r4,5 *sampled sound li r5,0xc0 *stereo li r6,0 *no callback Xcall SndNewChannel
Playing a sound (handle to sound in r3):
lbz r4,sound_on(`bss) *Global sound on variable cmpwi r4,0 beq no_sound *Sound is off, so no play sub_in *Save r3 mr r28,r3 **Flush channel lwz r3,stereo_chan1(`bss) lwz r4,flush_now(rtoc) Xcall SndDoImmediate **Make it quiet lwz r3,stereo_chan1(`bss) lwz r4,quiet_now(rtoc) Xcall SndDoImmediate *extern pascal OSErr SndPlay(SndChannelPtr chan, SndListHandle sndHdl, Boolean async) mr r4,r28 *takes handle to sound in r3 lwz r3,stereo_chan1(`bss) li r5,-1 *play async Xcall SndPlay sub_out no_sound: blr Setting a channels volume: lwz r3,amp_command(rtoc) lhz r4,sound_volume(`bss) *volume runs 0-7 slwi r4,r4,5 *So multiply up sth r4,2(r3) *new volume in amp_command lwz r3,left_chan(`bss) lwz r4,amp_command(rtoc) Xcall SndDoImmediate
**Various sound commands
flush_now: dc.h flushCmddc.h 0dc.w 0quiet_now: dc.h quietCmddc.h 0dc.w 0amp_command: datadc.h ampCmddc.h 0 *Amplitude 0-255dc.w 0 *Not used
415I did promise the dirt on 415 here didn't I. Well it was very frustrating. It had been testing for a couple of weeks, and whilst the odd bug popped up, nothing serious. Then just a day before it was to be published the most weird bug came to light. A tester sent me a project that simply kept crashing the PPC linker. NO!
Turns out the project had no imports whatsoever, and CXF went into a mega sulk. This is why it's nice to have testers at all different stages in their projects. We test with standard test files (for example F32Val.s), auto test software and test projects, both 68k and PPC. However, this does not necessarily find all bugs, so we have nice testers who write some weird code (no offence guys). By "weird" I mean in a different "style" as there are an unlimited number of permutations of laying out source files, projects, bcf switches etc.
And don't get me wrong, I don't know everything about Fantasm - sometimes we get mail from people saying they've found this out and I say "I didn't know it did that!". This is a result of Fantasm being made up of lots of smaller tools, some of which are old, and some new. For example, whilst I actually coded the macro processor, it was Rob that did most of the designing - I personally use very few macros, whereas others use macros extensively. I don't use register equates, indeed I very rarely use equates at all (although I am getting better now, honest). The piece of code I am most intimately aware of (and proud of) is the PPC linker and CXF. This is amongst the newest pieces of code and most complex, but it works magic on your fragment.
It was just the other day, Rob was saying to me he didn't know how we did it on an ST with just a floppy and one single huge source file. I guess it's because you just don't realise it at the time?
Writing tools is not like writing any other piece of software because development is always on going. There are very few rules set for what constitutes "a release". It's a case of saying, well it's much better than the version it's replacing, so let's delay no longer. The software is primarily released because it will make users lives better than with the previous version. As it is, we're getting good reports on 415, so it looks as if we did the right thing. I have to admit it, getting a release together is extremely hard work and takes a lot of time.
It was about this time last year that we started designing PowerFantasm and I think the way it's turned out is pretty cool. It dramatically simplifies PPC assembly language, runs fast and is well on it's way to producing some cool apps. It has been shown that hand assembler can whip the life out of compiled PPC code. This was the design aim, so overall it's turned out pretty much on track. It is extremely difficult predicting what it will look like a year from now - it could be pretty much as it is now, or it could look different. I can predict that it will be lots faster, probably have a high level sibling, may be available on another platform, probably cost more and be bigger than it's current form. We are committed to supporting PowerPC. More than that, I cannot say.
1996
Well, what happened to 1996? It's nearly all gone already. That has to have been the fastest year of my life. Next month I'll be doing a review of 96 and looking towards 1997, and am looking for any interesting snippets you may have. We'll be wrapping up all the articles from this site and publishing them as the "Lightsoft 1996 annual" or something similar.
Also next month, right on the cutting edge of technology, we (hopefully) have the Lightsoft "Virtually a Christmas Party" held on-line on a private server (courtesy of Kev). The date is tentatively set at Saturday 21st December. This is purely a social event at the end of a hard year and should not be viewed as a forum, although of course we'll do our best to answer any questions you may have.
You'll be able to chat to Rob and I, other Fantasm users, developers, testers - you may even find a long lost friend (Rob won't cause he hasn't got any. Oooh, right in the back :-)). The party is open to customers, developers, testers, in fact, anyone with any interest in Lightsoft. The only rule is "No Apple slagging" (Oh really Stu...).
As this is a worldwide event, it may mean that for some, the actual time of the party will not be optimal - if we could sort it so it was 11pm everywhere we would, but unfortunately...
You will need to bring a sense of humour with you and naturally, you have to supply your own drink and music, but in a way that's better 'cause you get to listen to what you want and there's no chance of being hit by anybody elses puke. Err, sorry, hard facts of life and all that.
More details will be published as finalised, but you need to get your names in now, as space is limited (literally by the servers memory!). If you wish to attend, please let us know as soon as possible via email - either lightsoft@zedworld.demon.co.uk or 100625.720@compuserve.com - bottles of Southern Comfort and cans of Guiness also gladly accepted!
You will need a First Class client.
Till next time,
Code on!
Stu.