MintyTheCat wrote:
GEMS was used in a number of MD Games and to my understanding it was used a great deal with early MD Games. However, I had heard that GEMS as a driver and system had a few issues but it was used widely as it was released by SEGA themselves and it was fairly easy for musicians to use.
I know this isn't a question, but the widespread use of GEMS was likely because it was a "turn-key" system. A completely developed, ready to use, officially supported solution that Sega of America stood behind. Its shortcomings, I feel, are overstated in light of its benefits. I think a lot of people don't appreciate it in perspective of the time it came to exist and what MD development was like at the time.
MintyTheCat wrote:
1. Does anyone have any understanding of GEMS and indeed sound drivers that were used on the MD and be able to explain a little further as to what the problems (if any) were when using it to create music for Games?
I don't know much about other MD sound drivers (other than what is generally known by say, the Sonic hacking community) but here is the way I see GEMS, and indeed Sega, relative to the time.
I'll be referring to the MD as the Genesis from here on out to emphasize its position in the USA, and I feel that the GEMS "phenomenon" is definitely American. This is going to be a long meandering post so stick with me.
From about 1989 to 1991, the Genesis had a marketing problem in the form of games that would appeal to the American market. Sega's early brand strategy is well known--celebrity endorsements (Michael Jackson) and major sports figures (Joe Montana etc). Lots of these early games were developed by Sega of Japan, for Sega of America, or were rebranded games that existed prior (Tommy Lasorda Baseball was Super League, Buster Douglas Knockout Boxing was Taito's Final Blow, the first Joe Montana game was rushed and bought by Sega from EA and quickly rebranded, Arnold Palmer Tournament Golf was some other golf game and so on).
Anyway, the point of this is that Sega needed more games, particularly in light of the success of Sonic the Hedgehog and the sales spike that caused. They needed games that would sell to an American market. This leads to 1992.
If you look at all the games for Genesis released in 1992, you'll notice something straight away compared to years prior--there was something of a renaissance of American developers that year. Look more closely and you'll notice something else--basically all of those games use GEMS for music and sound. Why this is, I can only postulate, but I wouldn't doubt that it had something to do with wanting to get those games out as soon as possible, and the less time those developers spent developing tools and the more time they spent on games, that would have been a benefit to Sega of America. It's well known that Sega of America commissioned GEMS from Technopop, so they obviously saw a need and wanted to fill it. From there on out I imagine it was momentum. Many of those initial American developers went on to develop more Genesis games in a 2nd party capacity and by that point their composers and programmers understood GEMS--and GEMS was constantly being improved, too.
Other factors that I believe led to high adoption of GEMS:
- As far as I can tell the software was royalty free beyond the initial purchase--if these developers even had to purchase it, most of them were contracted to Sega--so using it saved both time and money
- FM is "hard." Your average musician/keyboardist of the time, the closest they got to FM was the DX7 and it was infamous for not being the type of keyboard you wanted to make your own patches on. Example: GEMS itself doesn't come with patches beyond the Ship demo, yet many GEMS games use the same patches. I'm sure good sounding patches got swapped around back then.
- MIDI. This was the standard, at least in America, of the type of composer that had familiarity with computer music well enough to get a job as a video game composer. Sure, we had people who used things like trackers, and we had a demoscene, but most musicians familiar with computer music knew and understood MIDI.
- Genesis audio is sort of weird to the uninitiated. Keep in mind video game audio up to this point was square waves and a handful of 8 bit port writes, from one main CPU. The Genesis added layers of complexity to this in the form of FM synthesis, a separate CPU running its own program with its own RAM and its own bus, having to code around that--and this is just the stuff that was intentional by design, not even considering the hardware bugs and quirks that were later discovered.
- Technical reasons. Dynamic channel allocation means musician doesn't have to worry about individual channels, only not exceeding total channel budget, and sound effects are handled automatically. On the software end, it integrated well with C compilers.
- Prior use in games. If a developer used GEMS to develop a game, it makes sense to use it in the sequel, or in another game that reuses the same code base.
As far as problems with GEMS goes? It's not perfect as lots of armchair critics have observed. It doesn't have the best sample quality (but IMO it is comparable to other engines), it has some shaky tempo issues, and there's reports of it not working 100% identically on all MD hardware. I have a Genesis that doesn't like certain GEMS games and has tempo issues, and I have others that don't have any problems. That said I honestly feel its biggest downside is its ease of use. I think that GEMS got a bad reputation for exactly two reasons.
1. Lazy musicians not utilizing features of GEMS that would make their music sound better (pitchbends, modulation), or simply just not writing very good music. Not really the fault of the driver.
2. Bad emulator sound. This has really tarnished the reputation MD sound in general and has made every "gamer" out there who thinks they know a thing or two about retro games utter this statement in some form in their lives: "The GEMS sound engine sounds bad." This isn't really true. I can cite one example: going back to what I said earlier about GEMS games sharing patches, there was one really prevalent patch, a hi-hat type sound, that got shared a lot. It's a patch that sounds fine on hardware, and on modern emulators. Older emulators though, like Gens, emitted a horrible bleeping/ringing sound when it played back. You would not believe how many people think this is how GEMS actually sounds,
as if any developer would let a game out of the door sounding like this.
MintyTheCat wrote: At this point in time there have been a few attempts at making sound drivers such as Echo. however, there is no definitive sound driver that could be used as yet. My thoughts are that one of the goals for the MD Dev Community would be to have a decent sound driver implementation and indeed a set of tools to facilitate music development on the MD. Reading of CountSymphonic's progress in developing a native MD Tracker is again promising and good news. My only hope is that he makes it Open-Source.
2. What are the shortcomings of GEMS for Musicians and could an improved version of GEMS be developed as a community
Certainly, I can think of a few features that might help improve it as a driver, but the most desirable development would be a replacement for the 20+ year old GEMS.EXE. A MIDI converter, I think, would be the most feasible, but there would still need to be some sort of opcode-editor. r57shell's GEMS split and merge tools are interesting as well and you should check into them if you haven't. They basically de-compile GEMS data into its constituent patches, modulators and even decompiles sequence data into text form. The merge tool recompiles it. It would be nice to have a modern GUI app that mimics the old GEMS.EXE in functionality, with built in sound emulation cores to remove the need for a Genesis.
MintyTheCat wrote:Given that these days some of the Assemblers that are kept up to date now have backwards compatibility with older and more established Assemblers it makes one think about applying this approach to sound drivers and indeed music development systems on the MD.
I would be interested in your thoughts.
In order to get GEMS.A to assemble with vasm I had to change one opcode (it used a backward notation for indexed addressing that was nonstandard), change the syntax of local and global labels, and do a find-and-replace on some other minor things. It worked perfectly in conjunction with the VBCC C compiler with no other changes. I also made some other minor changes to the code like automatically loading the bank pointers instead of doing so through an external function, but that's hardly a huge change.
I feel that GEMS would make a great community sound engine for many of the same reasons it was popular back in the MD's day. Ease of use, the source is there, we know it's been well-tested. With the knowledge we have now, we might even be able to fix its few remaining issues. The only drawback is we do not really know its copyright status.
If the community was to work together to create a new sound engine--I would strongly push for it to be like GEMS. If that is not a ringing endorsement, I don't know what is.