Loki Software to Open Source SDL Motion JPEG Library

Loki Games has announced that they will be undertaking their 3rd Open Source project, the SDL Motion JPEG Library. SMJPEG creates and displays full motion video with a non-proprietary format created by Loki. It was developed while porting Railroad Tycoon II: Gold Edition. Check out their website for more details. Suffice to say that "among its many benefits, SMJPEG allows for arbitrary video sizes and frame-rates, user-tuneable compression levels, and facilities for frame-skipping and time synchronization," according to Loki.

Comments

Great stuff

[jregel]

This is good news. I've been hoping that better multimedia support would come for Linux, and the proprietry "standards" in use don't help. Maybe this will help us join the multimedia world in style...

Similar to motion jpeg codec?

[Jon Peterson]

Is this similar to the motion jpeg codec (NOT the same as MPEG) used widely as a high quality high bitrate format for captured digital video?

If so, it's quite useful for local playback and editing, and provides very high quality, since each frame is basically just a jpeg. But without any attempt at delta compression, it results in stonking bitrates.

Very useful for editing though.

On further reading this looks more like an MPEG format, since it is based on MPEG 1 code. That would be a pity, since MPEG 1 fills its niche badly, while motion JPEG filss its niche well. However, I can see why a games company would want an MPEG (low bitrate/low quality) format more than a high bit rate high quality format.

Re:Similar to motion jpeg codec?

[Simes]

It's not based on MPEG. The press release mentions the MPEG decoder as being their first open source release - it doesn't say that the new library is for anything other than Motion JPEG. After all, if you already have an MPEG player library in the open source domain, where's the benefit from releasing another one?

--

Motion JPEG?

[hta]

Last time I encountered motion JPEG (a few years back), it consisted of stringing JPEG pictures after each other (plus a soundtrack).
Makes skipping to random points MUCH easier than with MPEG, but makes the files 10 times bigger, because you don't do inter-frame compression the way MPEG does.
I couldn't tell from the press release whether it was the same thing or something entirely different.
Nice move!

Re:Motion JPEG?

[Paul Johnson]

but makes the files 10 times bigger, because you don't do inter-frame compression...

Bigger yes, but not ten times bigger. I've done some experiments. A 600x400 image compresses down to 15k with some minor artifacts, and 24k with some almost-invisible artifacts. Reduce that to 300x200 and you are looking at 8 or 9k. My experience of watching compressed video is that the motion reduces the visual impact of the artifacts because they keep changing randomly, while the eye tends to track the image. So you should be able to get away with some 15k per frame. Maybe slightly less because these figures include picture headers that would be factored out of MJPEG.

At 15k per frame and 25 fps that is 375k/sec, or 1.35Gb/hour, which is about twice MPEG-1. Plus sound of course. But radio quality sound only needs about 8k/sec, so we can ignore that for now.

Has anyone tried doing this in real-time? It strikes me that we might have a DIY version of the TiVO here.

Paul.

Cool!

[RealUlli]

This news is simply cool! It seems Loki is evolving into a (sort of) Red Hat of games! Ok, they don't open source the games, but they open source the libraries they had to develop to port those games! :-)

Source already available

[- BlueSky -]

According to Linuxgames the source code has already been released.

SMJPEG documentation

SMJPEG source code

BlueSky

way to go loki

[pilot]

wow...with all the proprietary codecs out there, this is the kind of think we need. and does loki ever get a shitload of my goodwill :-)

now, if only we could get a gpl'd quicktime implementation...

ajit

Another Linux success story.

[CocaCola]

I've recently tried out Loki's latest Myth II demo , and it's one of the best games ever written for Linux. I was amazed and shocked, but the best thing about this game is not the game itself, but the fact how smooth and playable it is under Linux/XFree86. I never thought that such level of control and performance was possible in X. Myth II grabs the whole screen intelligently and goes into full screen mode without any flicker. Mouse movement cannot not move you out of focus, only exit brings you back to 'normal X'. Still the game has the performance of native SVGALib apps. I wish Loki good luck - both in their Open Source, and game-porting projects. They really have proved that Linux can be an excellent gaming platform.

Smacker

[Wax-On]

Anybody in-the-know technically out there that can give us a blow-by-blow of how SMJPEG compares to Smacker, the current "standard" for video in games?

I'm curious as to why they decided to develop their own codec (which has got to be more than a couple of nights' coca cola-frenzied hacking) instead of going with the tried-and-true. Smacker licenses only cost around $1K last I knew ...

Re:Smacker

[Anonymous Coward]

I'm curious as to why they decided to develop their own codec (which has got to be more than a couple of nights' coca cola-frenzied hacking)

Well technically doing MotionJPEG should be: cat video_as_image_*.jpg > myVideo.motion-jpg
ls -l video_as_image_*.jpg > myVideo.indexing-info

This isn't true if they reimplented part/all of the JPEG decoding etc..., but if they didn't, it isn't so complicated.

Re:Smacker

[shadrack]

Smacker creates smaller video files, but is restricted to 256 optimized colors. It's main claim to speed is to pre-optimize the video, instead of trying to dither down during playback. The same company has a newer and very impressive codec called Bink. I downloaded a demo video from a site that specializes in 3D animation. It was better than DVD quality. Currently the beta version of Bink is free and installs under DirectShow.

Re:Smacker

[Wax-On]

Thanks for the headsup on Bink. It's interesting that I didn't get a spam from Smacker announcing their new goods since, as a licensee, they've got all my info ... or maybe they're waiting to complete Beta ...

I'll definitely check it out.

Re:Smacker

[Anonymous Coward]

Mostly because when we approached RAD Game Tools, they basically said: Sure, you can port smacker to Linux, and then you have to pay us to use it. The SMJPEG versions of the video files were about 60% of the size of the Smacker ones. There are obvious quality artifacts since we compressed the video down to 320x240 and then re-expand it to 640x480, but for the types of movies in RT2, it works just fine. SMJPEG is definitely not a replacement for MPEG or Smacker, but it is a good alternative. -- Sam Lantinga, Lead Programmer, Loki Entertainment Software

Linux development for businesses

[RichardW]

Perhaps this kind of development is the way forward for businesses wishing to start developing on Linux. Obviously many of them wish to protect their source code, but they could release libraries they've developed (or extended) that aren't directly related to their main product.
Nice one Loki.

QuickTime Player for Linux

[Sleepy]

This falls squarely in the "rumor" catagory, but at NAB99 about a truly "crossplatform" version of QuickTime, and he very carefully worded it as "we would NOT see a Linux version of QuickTime before the OS X Consumer version was out".

I forget when OS X Consumer is out... Spring maybe?? That *doesn't* mean a Linux version will be out then, what I heard implied was we might get a clearer picture..

Basically the issue for those that don't know is, OS X Consumer is a UNIX BSD-based ("the other Linux" as someone put it, although it's technically innaccurate) implementation, and since OS X is commercial that will be "competing" for mindshare. Releasing a QuickTime for Linux before OS X would kind of steal Apple's thunder... QuickTime is one of the few world-class technologies they have left that can be sold, and great QT support IS still a basis for buying a Mac for some people.

I see both sides of this, and it is frustrating not to have a robust and well-supported video system in Linux. It's not *entirely* Apple's fault as some would state.. I don't see Red Hat and SuSE funding some GPL'd alternative (which without compatible codecs is moot anyhow). Apple doesn't "owe" the any platform a player - they owe their stockowners results. Anyways, It's fantastic to see some free good work out there.... thanks LOKI! I don't think a company should "own" a video delivery system any more than a phone (or cable...) company should have a monopoly .

The FIRST person I talked to at Apple's booth said "if I wanted QuickTime on UNIX I'd have to buy OS X". Great.. does OS X run Linux binaries? Oh, wait, they quietly smothered OS X for Intel (remember?). "Der...":-/

Re:QuickTime Player for Linux

[phutureboy]

OS X Consumer, a.k.a. Mac OS X a.k.a. OS X Client is very much MacOS to the core, not BSD. It will offer pre-emptive multitasking, protected memory, and lots of overdue simplification of the MacOS API. It should very much rock, and promises to be very stable. Last I heard it was due Q4 1999 or Q1 2000. Apple has been really tight-lipped since Jobs came back, so we probably won't know until right before it ships. MacOS X Server is the one that's BSD-based.

Re:QuickTime Player for Linux

[IntlHarvester]

My understanding of OS X is that it's neither BSD nor MacOS at the 'core'. It's a mach kernel that runs several different user space modules, including NextStep/OpenStep/Yellow Box/Whatchmacallit, a BSD user space for traditional Unix compatiblity, the entire legacy MacOS running in some sort of VM (blue box), and a new MacOS-influenced API called Carbon (that allows pre multitasking and protected memory) so that existing Mac apps can be ported easily.

The question is: Which API does QuickTimeX run on? My guess is that it's not the BSD API (too bad for Linux), and instead either OpenStep or Carbon. If Apple is going to support QuickTime for Linux, they will probably have to create a seperate Unix/X Window application.

Re:QuickTime Player for Linux

[Pudding]

This falls squarely in the "rumor" catagory, but at NAB99 about a truly "crossplatform" version of QuickTime, and he very carefully worded it as "we would NOT see a Linux version of QuickTime before the OS X Consumer version was out".

I made a shitload of noise on the Quicktime-talk mailing lists about a truly cross-platform version of QuickTime (the player and codec modules). I don't care too much about a Linux version, but I want the QuickTime format (which is wonderful) to get a wider spread than it has, particularly on un*x machines.

The first comments were basically "Have your vendor licence it from Apple." and "Won't it be great for that vendor to be the one offering QT?" Comments about the Windows client (not licenced by Microsoft) petered out to market share talk, which makes sense, although it's ever so unfair. Apple would not make the big money from a vendor licence, but rather from owning the major format for digital media. They don't seem to understand this.

OK, this costs a lot of money, and ofcourse was not the kind of answer I was hoping for -- in my eyes Apple would be the one to benefit from spreading their technology. This was from Charles Wiltgen, who is the QT Technology manager at Apple. Feel free to write him, but don't expect much understanding.

I don't see Red Hat and SuSE funding some GPL'd alternative (which without compatible codecs is moot anyhow)

This is exactly what Wiltgen meant by a vendor licencing it, and he hinted that RedHat had just completed a very successfull IPO. Should we leave it up to one of them to do this?

Wiltgen has, however, promised me that they will revisit the case of a true cross-platform QT player. We can only wait, I guess.

Hhm..

[Talence]

What I like most about libs such as SDL is that they are *cross platform* -- I can develop my things from the comfort of my linux environment and cross compile to win32 if I need to. I'm afraid that for the time being, developing things for both platforms (i.e. not only linux) is the way to go, even for huge linux fans such as myself :-)

- Talence

Re:Hhm..

[Anonymous Coward]

Well, since Loki's stuff is open sourced, it shouldn't be too much trouble to port it to Win32. (Unless they've done horrible nasty nonportable things to their code of course)

It is Motion JPEG, not MPEG1

[Anonymous Coward]

Glancing over the documentation, it would appear this is a sequence of JPEG pictures rather than the MPEG1 compression. Nifty. Simpler, too.

Giving back to the community.

[Black Parrot]

It looks like we're seeing a minor trend for companies that make their profits off OSS code and/or OSS users to "give a little back" in terms of open-sourcing some of their own creations. Let's hope these smallish companies can establish a new ethos for the profession, in opposition to the "can't let go" mentality of the established vendors.

What was the problem with Quicktime

[heroine]

Quicktime supports arbitrary video sizes, arbitrary frame rate, compression levels, synchronization, seeking, and presumably is only patented at the codec level. It costs a lot less that writing your own library from scratch. It's the standard for DV and it's been open sourced for 9 months, just not by a slashdot sponsor.

>The audio chunks should be encoded one frame >ahead of the video chunks

Don't do this. Instead encode one second of audio data ahead of the first second of video data.

Re:What was the problem with Quicktime

[substrate]

QuickTime server was open sourced and possibly enough information to understand the file format. What hasn't been open sourced are CODECS (compressor/decompressors) such as Sorensen. So while you've got a system for net distributing already compressed image data you don't have an open sourced system for producing it.

As far as I know there are no open source initiatives to actually produce a CODEC for high quality and low bitrate image data.

Rumor has it that Sorensen has stated that Apple prohibits them from open sourcing their CODEC. I'm not sure how true it is. It may be closer to reality that Apple wouldn't be happy about it after paying large fees to make use of it. The other half of the equation might be that even if Apple didn't care one way or the other Sorensen still wouldn't. CODECs are expensive pieces of intellectual property to create, it may well be that Sorensen uses Apple as a convenient scape goat.

Re:What was the problem with Quicktime

[dirty]

I don't know anything about quicktime being open source, but I know the codecs are not. What good is quicktime without the codecs? Developing the file format is quite simple, it's developing the codec that takes time. The description of the file format for SDMJPEG is maybe 50 lines. IMHO Loki did a good thing by creating their own format. I wouldn't trust Apple for a second when it comes to open source. IIRC Apple can still revoke the license on whatever parts of OS X that they released as "open source".

Re:What was the problem with Quicktime

[shadrack]

You are right. Quicktime, like the Windows media player/Direct Show, is simply an interface. Apple includes a codec to make it useful. They do have a published API so a developer can create a codec that plugs into the QuickTime.(Same for Direct show under Windows). Macromedia has done this with Flash for Quicktime(included with Quicktime 4).

For those interested, MainConcepts has a low cost MJPEG codec that is compatible with many of the popular video capture cards. They are also developing a DV codec that will enable you to output DV compatible video without requiring acess to a 1394 device. Not open source, but low cost and will be available for both Windows and Linux this fall.

http://www.MainConcepts.com.

Mildly off topic? One never knows..

[Kitsune Sushi]

Of course, Loki would be less than worthless as a company if they open sourced their games (well, unless they used something similar to the NPL rather than the GPL.. and they wonder why its mainly Netscape that does the development work for Mozilla..?), although they are already a step ahead of id Software (even though I do so love Wolfenstein/Doom/Quake).

I've been thinking a lot about the pros and cons of commercial vs. free software.. and I believe that games (excepting rather simple ones) should probably remain the domain of commercial programming. Of course, I believe that games should remain reasonably low cost, but then again, I might be sort of biased since I'm designing the layout and other nifty things that will form the foundation for a 3D fully interactive RPG using anime-style graphics (am I nuts or what?).. Well, ones hopes, at least.

And, back to the point, perhaps? Since games of all sorts use stylized characters that the designers and/or companies would like to keep a hold of, GPLing such programs would not be the most productive thing in the world toward this end. Not to mention the fact that these things are strictly entertainment, not any kind of means to an end, besides killing boredom. Reusable tools (like the libraries Loki develops in the course of producting their games) and simple games should remain the focus of this arena.

Re:Mildly off topic? One never knows..

[Rational]

What exactly do you mean by "one step ahead of Id Software"? Id games come to Linux fast, look good, and eventually we get source code...

Time to market

[hobbit]

From a purely cynical point of view... do Loki specialise in bringing 'Myth'-type games from the Windows platform in particular?

If the boot were on my foot, I would concentrate my efforts on code to convert games written for Windows to this SMJPEG or SMPEG-based platform... then let the developer community perfect the rendering code. If they are doing this for a number of different games, they minimise their time-to-market, and I feel that the market for linux games is going to be a large one (my HDD gets shot of Windows as soon as there are a decent number available).

Having said this, I heartily applaud what Loki have done, and I wish them every success, if only for making the leap of faith.

Great Idea

[shadrack]

I just want applaud those commited to creating open source multimedia stuff for Linux.

Other stuff coming....
Though it won't be open source as far as I know, a company in Germany called Main Concepts is currently developing a low cost Video Editing system for both Windows and Linux. They are also developing(or already developed) a software only DV codec that should have generally higher quality than MJPEG with lower bit rate requirements (basically about 25Mb or 3MB per second throughput). DV, unlike MJPEG is lossless. The great thing will be the ability to encode/decode DV video without the requirement to be attached to a 1394 device. The company is very commited to the Linux platform.

Please no Flames, just putting out some info.


http://www.mainconcepts.com

Film Archiving?

[Ronin Developer]

This is wonderful news!

I have inherited a box full of 8mm, Super8mm, 35mm slides and photographs dating back as far as the 1940's. My aim is to scan and encode each film and store them on CD or DVD before they deteriorate. Part of the process is designing and building an 8mm/Super8 film scanner (which I can do). The other aspect is figuring out how to store them efficiently.

I am assuming that since these are JPEGS, I should be able to manipulate them (i.e. color enhance, etc.) and save an important aspect of family history.

Been using Quicktime for almost a year

[heroine]

I've been using Quicktime 4 Linux for almost a year without any problems. It supports motion JPEG, PNG, RAW, YUV, and audio just fine. It's output is compatible with all the Linux video software. If you want a list of files to edit just run 'dechunk' and it creates the individual JPEG files. Why should I switch to SML?

Re:Been using Quicktime for almost a year

[Anonymous Coward]

There's no reason to use SMJPEG over Quicktime at all. We just wanted a format that was very simple, low overhead, had good compression, was easily manipulatable, and could be played a frame at a time.

-- Sam Lantinga, Lead Programmer, Loki Entertainment Software

More efficient storage than M-JPEG possible

[harmonica]

As M-JPEG makes each frame accessible independent from the others, try something like MPEG-I or MPEG-II, otherwise file sizes will be huge. Make sure that you get a standard video file format (I'm not sure about Lokis code) or you will have problems viewing the films in the future. Having to convert them every ten years or so using lossy video codecs also will result in quality becoming poorer and poorer, so MPEG xy may be the way to go. I'd avoid proprietary stuff like QuickTime / Sorenson - although the codecs are great, compatible players might not be available in the future. The exact format will depend on how much disk space you're willing to provide for the storage of a minute of film.

Re:More efficient storage than M-JPEG possible

[Ronin Developer]

Thanks for the input. Natually, I want to do this project right and you make some really good points.

Where can I get good, low-cost MPEG encoders?

Loki deserve to succeed

[Matthew Vernon]

OK, so Loki's games are non-free (but that's to be expected), but not only do they enable us to play top games (CivCTP is wonderful) ported professionally to Linux (the games feel like the "real thing"), but they keep on giving code to the Free Software Community. IMHO they are a good thing, and I'm happy to support them by bying games.

Re:Loki deserve to succeed

[vixiejvc]

CivCTP wasn't _all_ that wonderful...

Me and a friend of mine tried it under Linux, and again under Windows. The Windows version could run circles around the Linux version, stop to take a breath, have lunch, then leisurely walk to a finish line, and STILL leave the Linux version in the dust. It was that bad.

CivCTP, IMHO, is a neat way of saying "Yes, it is very possible right now to make games for Linux, but ultimately Linux still sucks as a gaming platform."

(Disclaimer: This is from the endluser perspective, please don't flame me for being technicially innacurate because I don't know the technical details :) )



"I don't believe that there is one, single, perfect spiritual way and, in realizing that, obviously you become a lot more open."

Re:Loki deserve to succeed

[warmi]

What do you mean "run circles" around ?
Speedwise ? Unresponsive ?

Re:Loki deserve to succeed

[Andy Dodd]

I wholeheartedly agree. The only reason I haven't bought Myth II is because it's too dangerous - Having CivCTP around is going to be bad enough for my attempts to do my schoolwork. :)

Re:Loki deserve to succeed

[jedidiah]

This is the first we've heard about it, especially strange considering that just this sort of thing was discussed heavily by those of us who were anxiously awaiting it (CivCTP).

Re:Loki deserve to succeed

[vixiejvc]

Both, actually. Tho response time wasn't _that_ bad, just the overall speed. Graphics slooooowwww....


"I don't believe that there is one, single, perfect spiritual way and, in realizing that, obviously you become a lot more open."

Not too fast, pard'ner.

[Trixter]

I think some clarification is needed: Loki has shown that Linux can be a viable gaming platform, but I wouldn't call it an excellent one. Performance under X on a continuously multitasking system simply doesn't leave as much CPU time as going into windoze and hogging the entire system.

Note: I am not saying Linux is bad. I'm just saying that Linux is not as suited for gaming as other platforms. Of course, this should be common knowledge around here... and if it is, then heck, why the hell am I typing this anyway?

Re:Not too fast, pard'ner.

[Patrik Nordebo]

You don't have to run lots of stuff in the background if you don't want to, you know. If you want maximum game performance, shut down everything else and things will be quick and nice.

Re:Not too fast, pard'ner.

[On Lawn]

would single user mode help here?
^~~^~^^~~^~^~^~^^~^^~^~^~~^^^~^^~~^~~~^~~^~

Ask and you shall receive

[Anonymous Coward]

I got your QuickTime for Linux right here

Re:Ask and you shall receive

[Pudding]

I got your QuickTime for Linux right here

No you haven't.

The QT4Linux libraries are development libraries, and do not posess hardly any of the features of the QT player as developed by Apple. And certainly, the most interesting codecs (Sorenson, Qdesign) are not included.

Although the libraries are great, and we're using them for a M-JPEG project right now, they're not to be confused by the player proper, so please don't pretend that they are.

init 1, or optimized gaming runlevel

[FreeUser]

Perhaps. Your best bet would probably be to configure and run a customized runlevel, optimized for gaming. This would probably shut down most services, excess VCs and the like, but possibly keep network and multi-user facilities in tact (in case the game clobbers the IO interface and you have to ssh in to reset the box. Unusual, but possible with both svgalib and X.

Myself, I find games run excellently under Linux in its normal configuration, but them I'm spoiled with a fast CPU and lots of memory -- it takes something like Windows 98 or NT to really slow it down. :-)

MJPEG vs MPEG

[vleo]

Linux Media Labs offers MJPEG hardware for Linux and I want to comment on some widespread misconceptions about MJPEG vs. MPEG performance.

Full rate, broadcast quality signal (D1) at 720x480@30frames/sec with 4:2:2 color (2 bytes/pixel) has a data rate of 20 MByte/sec. Now, with 1:10 compression the image quality is very good, especially since there is 60 fields per second with noise caused by lossy compression averaged out. So, D1 quality requires 2 Mbyte/sec bandwidth. That is about 7 Gbyte/hour. DVD disks have 4.7 Mbyte of capacity and hold about 2 hours of video. Therefore with all hoops and patents MPEG-2 has 3 times better performance. I would argue though that D1 encoded with MJPEG at 1:10 compression is much better quality then DVD, and don't forget that it's a 4:2:2 color, not 4:2:0 one as in DVD.

Let up now go to VHS (MPEG1) qualiity and also reduce frame rate to 15 frames/sec. There would be no flicker since our video frame buffer still allows our CRT to be refreshed at 60 fields per second. 320x240@15frames/sec at 4:2:2 (2 bytes/pixel) gives us 2.2Gbyte/sec uncompressed and with 1:15 JPEG compression (certainly better then VHS) gives 150 Kbyte/sec. MPEG1 data rate is about 180Kbyte/sec - i.e. MPEG1 is no better then simular quality MJPEG.

Advantages of MJPEG:

• Patent clean
• Less complex algorithms
• Frame accurate editing/positioning
• Better video quality

Therefore maybe Linux should use MJPEG as a standard for handling video.

Speaking of codecs - nothing prevents Open Source community from creating a first class MJPEG codec. As a matter of fact we're working right now on a MJPEG viewing application, simular to xanim from the user prospective but optimized for MJPEG with the requirement to playback 720x480@30fps on resonable hardware and it's under GNU GPL of course. If anybody has some top performing (assembly language?) JPEG code (DCT/Huffman) or desire to work on such (under GNU GPL) I would like to talk very much.

Vassili Leonov vleo@linuxmedialabs.com

Re:MJPEG vs MPEG

[shadrack]

Full rate, broadcast quality signal (D1) at 720x480@30frames/sec with 4:2:2 color (2 bytes/pixel) has a data rate of 20 MByte/sec.

Full rate, broadcast quality signal D1 at 720x480@29.97frames/sec with 4:1:1 (DV, MiniDV, DVCam) only needs 3MB per second. And its lossless. All Consumer/Prosumer based DV Camcorders support this format. Not quite as good as 4:2:2, but excellent quality none the less.

OOPS!

[FreeUser]

Ouch! I forgot I had moderated a couple of comments in this discussion earlier today! ARGH! Apologies to those who just lost their +1 points ...

no windowmanager

[copito]

The biggest single thing you can to to improve performance is to make the game your window manager. Just make your .Xclients file a link to the game binary.

If you want even better performance, customize a runlevel with fewer things playing, but before you do that, renice the game to a higher priority, that should help out to minimize the effect or anything except memory intensive background programs.
--

Re:no windowmanager

[DThought]

The biggest single thing you can to to improve performance is to make the game your window manager. Just make your .Xclients file a link to the game binary.
Or, even simpler:
start X with
xinit /full/path/to/game/binary
- initializes X11, and starts the client you specified. (a window manager in general...)

minimize the effect or anything except memory intensive background programs.
Or I/O intensive background...
it SO bloats a (E)IDE System - UDMA doesn't help that much :-(

smothered?

[onjay]

I have it on good authority that parallel development of Intel versions continues. It is just too large a potential market to ignore, esp having done all of the preceding work...I am NOT saying they have any plans to spring it on us anytime soon. Not at all. Nope. Sorry.

..?

[Kitsune Sushi]

Really? I thought I saw something about some id guy saying that the games would never be open source because that's their bread and butter or whatever. I'm not about to fire up my Web browser to search it out, though.