July 1999
| DirectX 6.0 and Windows Media Technologies Bring Multimedia to Windows CE |
| You've probably been working with DirectX, Win32, and Visual C++ for years. Why not use that experience for the new Windows CE-based high-volume platforms? You can still use your existing knowledge of the APIs, tools, and other resources that you employed to build desktop applications. |
| This article assumes you're familiar with DirectX and Windows CE |
|
Code for this article: WinCEDirectX.exe (1,608KB) Rod Deyo and Mike Jazayeri are Program Managers in the
Consumer Devices Group at Microsoft. Rod works in the DirectX for Windows CE team, and can be reached at roddeyo@microsoft.com. Mike works in the Windows CE for Dreamcast Toolkit team, and can be reached at mjaza@microsoft.com.
|
|
You've all heard the talk by now: the convergence of the television and personal computer made possible by new easy-to-use devices that will bring the Internet to the masses. So far, a lot of it has been more hype than anything else, but we have seen a few real products—like WebTV®—going after the massive market of consumers still not "riding the wave." Many companies that have been successful with consumers in the PC world are starting to enter this new market. From the other direction, large consumer electronics companies are developing new kinds of advanced digital audio and video systems.
Where does this put you as a developer? What opportunities are there for you to provide the next killer consumer appliance or application? More importantly, what tools do you need to make the move? Microsoft® Windows® CE may be the answer. It's been a solution for a wide variety of embedded devices, and now Microsoft is providing DirectX® and Windows Media™ Technologies for the Windows CE platform. (The first Windows CE-based product to support DirectX is the Sega Dreamcast game console, which shipped in Japan last fall and should be shipping in North America and Europe later this year.) In this article, we'll show you the developer side of the new real-time and multimedia capabilities provided by Windows CE. Along the way, we'll point out any differences between the desktop and Windows CE interfaces and semantics. Windows CE for Consumer Devices If you're an OEM, you can use Windows CE to develop flexible game consoles, digital TV, set-top boxes, DVD, and MSAudio players, as well as other consumer electronics providing the same consistency and high performance available with current hardware-based devices. You can develop a system employing low-cost, targeted hardware that accelerates selected DirectX components. These capabilities are then accessed through DirectX and Windows Media Technologies. You've probably been working with DirectX, Win32®, and Visual C++® for years. Why not use that experience for these new Windows CE-based platforms? Microsoft provides the tools that allow you to do this, greatly expanding the products you can target with your current expertise and code base. That doesn't mean that you can necessarily take your desktop PC application, move it over to, say, a set-top box, and expect it to work without problems. For starters, these consumer devices are targeted at users with different expectations and experience. But in building your Windows CE-based apps, you can still use your existing knowledge of the APIs, tools, and other resources that you employed to build desktop applications. In addition to new DirectX components, Windows CE supports a carefully selected subset of the desktop Win32 APIs, such as GDI, WinInet, TAPI, and Sockets, plus some new APIs specific to embedded devices. Not all the desktop APIs make sense in new non-PC platforms; for instance, the support that would be needed to handle legacy Win16 interfaces and other components is just too big to be usable in today's consumer devices. But Windows CE does provide support for in-process COM objects, structured storage, and automation. Regardless of whether you use the components provided by Windows CE or decide to write your own, you can take advantage of the standard Microsoft tools. Products like the Visual C++ Toolkit for Windows CE allow you to develop your platform or applications for a Windows CE-based platform with the same development environment used to build desktop applications. You can write a DirectX-based game that works on both a Windows 98 and a Windows CE-based platform using the same tools and much of the same code. All aspects of development—editing, compiling, debugging, code browsing, and so on—are available when developing for Windows CE. For example, Windows CE for Dreamcast includes all the tools needed to develop for this Sb Hitachi processor-based platform in Visual C++. OEMs create an embedded platform SDK with the Microsoft Windows CE Platform Builder (see http://www.microsoft.com/windowsce/embedded/resources/pb.asp). Platform Builder provides all the operating system modules, libraries, runtimes, compilers, and debugging tools you'll need to build a customized version of Windows CE. The current Platform Builder release supports processors from AMD, ARM, Hitachi, IBM, Intel, Motorola, NEC, Philips, and Toshiba. These range from low-cost processors for embedded systems to processors that can provide exceptional multimedia and 3D graphics performance. Windows CE provides DirectX for those processors that are useful for multimedia systems. The modularity of Windows CE gives you flexibility in choosing which components your platform uses. When building an operating system image for your hardware using Platform Builder, you can tell the make tool whether you want a particular DirectX or UI component (like comboboxes), communications protocol, or file system. This flexibility lets you ship only those technologies that you actually need on your platform, saving space and reducing complexity. This modular design philosophy has been incorporated into DirectX and Windows Media Technologies. Even on the desktop, DirectX is modular. If you only use DirectDraw®, there's no need to include DirectPlay®, DirectInput®, or any of the other components that aren't required. If you want to create a cable TV box that only displays 2D images and text on the television screen, you won't need Direct3D® and you don't have to include it. Another cool feature of Platform Builder is that it generates code for a Windows CE x86 reference platform called CEPC. By using this platform, you can develop your software even before the hardware for your platform is available. In addition, Platform Builder supports commercially available reference platforms for other CPUs. Depending on the configuration of your platform, you may also be able to start development of device drivers using a CEPC or one of the other reference platforms. For example, with the CEPC, you first build your operating system image with all the needed components, then you boot the image using the Platform Builder Visual C++ 6.0 cross-platform IDE. You either create the appropriate Windows CE image yourself using Platform Builder or get the image from an OEM-provided platform SDK. Once you've booted your image on the CEPC, you can write the application software for your device using the Platform Builder Visual C++ 6.0 IDE, prototype any user interfaces, and possibly develop custom device drivers from the samples provided in Platform Builder. There are limits to how much you can do without the actual hardware, but being able to start development before it's available can be a major advantage. Microsoft has used the CEPC and other reference platforms in the past to develop DirectX-based applications and browsers for set-top boxes and other consumer devices. Real-time Features for Consumer Devices The major difference between multimedia played on a PC and multimedia played on consumer devices such as CD players, VCRs, or TVs is the guaranteed, no-fail performance achieved by using fixed-operation hardware. The PC system must be able to do many things reasonably well and so it must make compromises to remain affordable. The consumer devices, on the other hand, need to only do a few things well. Bridging this gap and making flexible—and potentially more powerful—software systems that behave just as well is the goal. Designing your device to have real-time system characteristics is the key. Too often, real-time systems are confused with "interactive" systems having only fast average response times. For a consumer device, it is inadequate to only manage the average response time of a given set of tasks; instead you must look at worst-case performance, paying close attention to the overall hardware and software system. For example, to ensure the product's performance, Windows CE for Dreamcast was created as an optimized version of the Windows CE operating system designed for the Dreamcast hardware. Let's review several important ideas about systems. a real-time system has four major characteristics. First, the system must understand the application's time constraints and take time into consideration. a consumer device playing back digitally stored or streamed media requires a complex set of cooperating tasks that must be jointly scheduled for completion before some deadline. Communication and coordination between these tasks, as well as any external controls and devices, must be performed in a timely and consistent manner. While playing an audio stream, data buffers must be filled and emptied by worker threads in a coordinated way at exactly the right times to avoid glitches or lost data. Second, the system must be deterministic. The system must meet its time constraints and deadlines in a consistent manner and with bounded worst-case performance. a digital TV using MPEG-2 video compression must not momentarily halt or glitch, regardless of peak computation load. Third, the system must be reliable. a consumer device must work for days on end without needing a reboot. It must robustly handle all manner of external and internal data errors, as well as poor environmental conditions. An audio player must continue to function adequately even with reduced network bandwidth. Fourth, the system must interact in a consistent manner with itself and with other system resources, including CPU, memory, buses, clocks, streaming multimedia audio and video hardware, 3D graphics accelerators, files, and network components. Designing a deterministic consumer device requires an overall system approach to all aspects of the design, not just CPU or memory usage. Deterministic systems strive to optimize for the "best worst case" (a characteristic of real-time systems is that they will happily exclude lower-priority processes and events), as opposed to providing the "best average case" (a characteristic of interactive systems is that they want to share system resources equally among all requestors). Generally, deterministic systems are not open like desktop systems. Instead, they are tightly controlled because they must plan for and limit interference among tasks that are competing for scarce system resources. Windows CE provides many essential system building blocks that can be used to implement a real-time system. Windows CE is a preemptively scheduled, multithreaded OS providing flexible task scheduling, thread synchronization, virtual memory management, interprocess communications, fast, non-blocking I/O and file systems, external connectivity features, and good integrated development and debugging environments. Because consumer devices are cost-sensitive, Windows CE components can be built to minimize the overall memory footprint, allowing system memory to be used by applications and not taken away by the OS as part of its runtime overhead. With real-time systems, interrupt latency is an important consideration. Latency refers to the amount of time that elapses after an interrupt event occurs and before the software responds. Real-time systems are designed for speed and predictability, with a time response scaled by the characteristic time of the system. Multimedia and graphics systems generally use either the audio clock (22.67 microseconds at 44.1kHz), video vertical synch (16.66 milliseconds at 60Hz), or an MPEG-1/2 presentation/decode time (100 nanosecond tick system hardware clock gathered into an elementary stream packet clock reference) as their characteristic time scales. a multimedia system requires that its control be much faster than its characteristic time scale. System timer, interrupt service routine, and event handling (from synchronous and asynchronous interrupts) latencies must be less than 100 microseconds. Windows CE provides interrupt service routines with bounded response times of this order, and a closed consumer system can be optimized to ensure deterministic response times to internal and external events. DirectX and Windows Media Technologies DirectX gives you fast, low-level access to a system's sound and graphics hardware while continuing to operate through the high-level features of the Win32 interfaces for Windows CE. It lets you interact with video and audio hardware installed on your system in a device-independent manner. You can improve an existing device or implement a new system with its driver without having to rewrite your application code. In addition, by adding DirectShow™ and Windows Media Technologies, DirectX provides easy APIs to stream, parse, decode, and render compressed multimedia audio and video data streams. DirectX is built on COM and consists of a set of fast, low-level libraries that you can call to create and use objects such as surfaces, palettes, textures, lobbies, sound buffers, and musical instruments. Layered over these low-level interfaces are APIs for implementing consumer audio and video devices, as well as broadband and Internet multimedia streaming. The first DirectX components in Windows CE Platform Builder are scheduled for release this summer as part of Windows CE 2.12 DXPAK. It will likely contain the multimedia components described in Figure 1. Additional DirectX DXPAK components planned for future Windows CE releases are described in Figure 2. Selected components of DirectX 6.1 for Windows CE and Windows Media Technologies will be available as part of Windows CE 2.12 on x86, MIPS R4300 and compatibles, and Sb CPUs. Additional DirectX media components (especially those needed for DVD and home electronics devices) and enhanced support for Windows CE CPUs are planned for future DXPAK releases. Windows CE for Dreamcast already contains DirectDraw, DirectSound®, DirectMusic®, Direct3D Immediate Mode (IM), DirectInput, and DirectPlay® APIs. These highly optimized, driver-based implementations are particular to the Sega Dreamcast hardware and are available as a separate SDK, but they are not part of the general Windows CE DXPAK releases. We will have much more to say about Dreamcast later in this article. DirectDraw Support in Windows CE DirectDraw in Windows CE offers fast access to your display hardware while retaining compatibility with the Windows graphics device interface (GDI). Basically, it's a specialized memory manager for both system and display device memory, with hardware acceleration where available. This is important because before DirectX you couldn't access your display memory directly. With DirectDraw you can allocate and manipulate memory in both system and graphics hardware memory, including transfers between the two. This allows you to do bit block transfers (blts), page flips (synchronize to video display vertical refresh), overlays (place one image surface over another on the video display), and alpha destination blending (blend two surfaces using the source alpha image component). DirectDraw also serves as a building block for other DirectX components such as Direct3D IM and DirectShow. Windows CE 2.12 DXPAK furnishes the DirectDraw 6.1 interfaces shown in Figure 3. DirectX in Windows CE supports the Windows-based DirectX interfaces. Take a look at the DirectDraw Mosquito sample on the Platform SDK to get a good idea of what you need to do on Windows CE-based platforms. The major differences between the Windows CE Mosquito source code and the Windows version are Unicode strings, window issues, and using a YUV overlay surface and RGB primary surface. Windows CE uses Unicode for all string operations. For example, the Windows CE WinMain prototype is |
|
| where the data type for lpCmdLine is the Unicode LPWSTR when UNDER_CE is defined rather than the standard Windows LPSTR. The need to convert to Unicode strings also arises in window class names, resource names, and error messages.
The window issues arise from the simple fact that while all Windows CE-based devices have the concept of a window, not all are capable of actually displaying one. To that end, the developer creates a window to handle messages, but will not draw it. Error handling raises the same issue. All Windows CE-based devices are capable of doing something meaningful with messages passed to the OutputDebugString API. However, they might not be capable of handling the MessageBox API that the desktop code prefers for error handling. Finally, on Windows CE the Mosquito program has been changed to use the YUV color model for the overlay surfaces since many Windows CE-based applications involve streaming video and are best implemented using YUV mode surfaces. The Windows CE 2.12 DXPAK supports an AlphaBlt with an Src over Dest operation, which is the most generally useful operation for compositing a source image over a destination image. The operation can be repeated to composite a series of source images in back-to-front order into a single destination surface. One way to think about this blending operation is as follows. When viewing a background or destination pixel value (RGBdest, ALPHAdest) stored in the DirectDraw primary surface through a translucent intermediate pixel (RGBsrc, ALPHAsrc) stored in another source DirectDraw surface, the combined source over destination blended pixel value is |
|
| Alpha blending can be performed only if the destination surface has a non-palettized pixel format such as RGB or YUV. The source surface for the blt may have either a palettized or non-palettized format.
Windows CE-based DirectDraw interfaces are generally fully consistent with the Windows versions of the APIs, but sometimes they can differ slightly. For example, surfaces are never lost in Windows CE under normal circumstances, and interactions with GDI surfaces through non-GDI primaries can be different. Invalidation of Windows CE surfaces may occur when the display mode is changed or a surface in exclusive mode is created, loses or gains focus, or receives WM_SYSCOMMAND or SC_MONITORPOWER. All surfaces are invalidated on StartExclusiveMode. Because a special interface, IDirectDrawSurface5, has been added to support AlphaBlt, you will need to first create an IDirectDrawSurface4 and then QueryInterface for IDirectDrawSurface5. |
|
| DirectDraw 6.1 uniqueness values and multi-monitor capabilities are not supported because of the need to keep the system memory footprint as small as possible. DirectSound DirectSound allows you to play back audio data in a variety of formats, at various rates, and in either mono or stereo, as well as capture it. It stores individual sounds in separate buffers and can mix an arbitrary number of them together simultaneously to produce the desired output. Storage and mixing are accomplished using pulse code modulation (PCM) to optimize throughput. With DirectSound you get low-level, device-independent access to your sound device, enhanced automatically by hardware acceleration when it's available. Windows CE 2.12 DXPAK furnishes the DirectSound 6.1 interfaces shown in Figure 4. Generally, DirectSound interfaces in Windows CE are fully consistent with the Windows version of the APIs. Some minor differences can occur because the Windows and Windows CE driver models are not identical. For example, DirectSound buffers are never lost under normal conditions. DirectSound 6.1 sound hardware memory compaction, 3D sound capabilities, and IKsProperty sets are not yet supported under Windows CE. DirectShow Windows CE-based DirectShow gives you the ability to play back multimedia streams from either local files or (when combined with Windows Media Technologies) streamed over a network. Many important multimedia types are supported including MPEG, audio and video, AVI, WAV, MIDI, and Advanced Streaming Format (ASF). The fundamental DirectShow object is the filter, a modular component that can be classified generally as a source, transform, or renderer. Filters operate on data streams by reading, copying, modifying, or writing the data to a file or rendering it to an output device. They are arranged in a configuration called a filter graph, controlled by the Filter Graph Manager (FGM).
|
 |
| Figure 5 DirectShow Filter Graph |
|
A DirectShow graph (see Figure 5) consists of a directed sequence of filters connected by input and output filter pins. These filter pins negotiate which media types they will support. The FGM controls the multimedia data flow between the graph filters. Because DirectShow has a reconfigurable filter graph architecture, it can support playback of many media types using the same software components. Developers can extend DirectShow multimedia support by writing their own filters.
Using DirectShow, it's easy to play multimedia files. The code in Figure 6 shows how to write a trivial multimedia file player application. (Among other simplifications, we've suppressed QueryInterface return status.) Note that CoCreateInstance instantiates a filter graph object, but no filters (it doesn't yet know what media types it needs to play back), and returns an IMediaControl interface for running, pausing, and stopping the streaming of media through its filters. (It also provides simple methods for building graphs, but we'll use IGraphBuilder to do that.) Since Windows CE currently supports only in-process COM servers, CLSCTX_INPROC_SERVER is the only valid server context for CoCreateInstance. Trying anything else will return E_NOTIMPL. IGraphBuilder is used to create a filter graph, add filters to or remove filters from a filter graph, enumerate all the filters in a filter graph, and force connections when adding a filter. We used its RenderFile method to build the graph, where the final constructed graph depends upon the video and audio formats contained in the source file. Finally, we can play back the file using IMediaController::Run. Since we want the application to wait until the rendering is finished, we've added IMediaEvent::WaitForCompletion. Multimedia file formats supported in Windows CE 2.12 DXPAK version of DirectShow include WAVE, AIFF, AU, SND, MIDI, MPEG audio, and ASF audio formats; AVI, MPEG-1, MPEG-2, MPEG-4, and ASF video formats; ASF and ASX streaming formats; and MIDI. The multimedia codecs available with Windows CE 2.12 DXPAK DirectShow are described in Figure 7. MSAudio, ACELP.net, and Microsoft MPEG-4 are state-of-the-art codecs providing the best possible audio, speech, and video coding at a given bit rate. Microsoft MSAudio 4.0 is an advanced perceptual audio codec used for high-quality music at medium bit rates. It delivers near CD-quality stereo at 58 to 128Kbps. Sipro Labs Telecom ACELP.net is a sophisticated algebraic code-excited linear prediction (ACELP) speech codec designed for 8 to 16kHz mono sound. Microsoft MPEG-4 V3 is a high-quality video codec providing CIF (352X288) resolution at 28.8 to 300Kbps. The other codecs support existing ASF file content on the Internet. Other broadband and computation-intensive formats and codecs, such as MPEG-2 HDTV video, advanced audio coding (AAC), and Dolby AC-3 multichannel audio, are supported with DirectShow filters implemented using specific platform hardware features. DirectShow in the Windows CE DXPAK includes an FGM that has an aggregated plug-in distributor (PID) interface to manage correct distribution and collection of stream control directives and common stream properties to and from all filters in a graph. Common PID tasks include running, pausing, stopping, seeking, setting rate, and getting duration. Windows CE 2.12 DXPAK with DirectShow provides the DX 6.1 filters shown in Figure 8. Audio and video capture is not currently supported. Many DirectShow filter samples are provided, and you can write your own DirectShow filters as needed. You can add your own codecs to DirectShow by either writing a new decompression filter or using the Audio Compression Manager (ACM) for audio codecs and the Video Compression Manager (VCM) for video codecs. This allows you to easily add support for new media streams and codecs. Hardware-based DirectShow filters, such as AC-3 Audio Decoder, DVD, MPEG-2 Link-Layer, Transport Descriptor, TransportDemux, Line 21 Decoder, Stream Splitter, and Video Decoder can be implemented by an OEM for a particular platform configuration and subsequently used as any other DirectShow filter. By implementing DirectShow filters, an OEM can enable and control multimedia features such as MPEG-2 video and audio stream parsing, splitting, decoding, and playback using the same set of common interfaces and controls. Most Windows-based DirectShow sample code can be easily recompiled and used in Windows
CE. See the Microsoft DirectX Media Web site at http://www.microsoft.com/directx/dxm for detailed information on the DirectShow architecture, interfaces, and sample filter code. Windows Media Technologies Windows Media Technologies 4.0 includes client software components for Windows CE and server applications for Windows NT. On the server side, Windows Media Services delivers a superior multimedia experience for the user over low-bandwidth 28.8Kbps modem connections and supports MPEG-4 streaming up to 5Mbps on broadband networks. Windows Media Services client software for Windows CE makes it easy for a developer to write applications that can access content either from a local disk or over the Internet. Using ASF, Windows Media Services can supply whatever content is appropriate for your connections. The ASF content streams for Windows Media Services can be composed of different media types, which can come from different servers. Supported multimedia file types include WAV, AVI, MPEG, and QuickTime. Windows Media Services also provides seamless switching, which means you can play any number of clips without pausing between them. Windows Media Services provides special client DirectShow filters that support ASF streams using UDP, TCP, and HTTP protocols. It also provides event-driven stream switching and smart streaming that takes into account time-dependent and site-dependent connection bandwidth variations. Windows Media Services supports encoding for multiple data rates, where multiple streams with different bit rates are created in one ASF file and the client negotiates with the server for the appropriate stream. It automatically adjusts the stream depending on playback conditions, and can select from multiple video streams based on their bandwidth. The client can dynamically thin the stream based on the available bandwidth by using an algorithm that changes delivery from full frames to keyframes only. If necessary, the Windows Media Services client can ask the server to send only audio and no video. Audio is given top priority since it is considered critical to the user experience. As network bandwidth and conditions improve, Windows Media Services steps the video back up to restore the viewing to its optimal level. In addition, a UDP resend capability allows the client to request missing packets from the server (if there is time available). The Windows CE-based DirectShow codecs used with the Windows Media Services client software support a wide range of low and medium-bandwidth multimedia:
A key part of Windows Media Technologies 4.0 and DirectShow is the Windows Media Player control. This ActiveX® control lets you add multimedia playback capabilities to applications, including Web pages. It allows you to embed Windows Media-based content in software that supports ActiveX controls, like Microsoft Internet Explorer, and Visual C++. It provides a programming interface for rendering a variety of network streaming (as part of Windows Media Services) and non-streaming multimedia formats. Windows Media Player controls use an appropriate DirectShow filter graph to parse, decode, and render the media stream. The Windows Media Player controls are implemented through the DirectShow FGM. Windows Media Player controls in Windows CE incorporate many of the features of the older ActiveMovie™ control, as well as lots of other new features. Functionality exposed by the methods and properties includes:
Windows Media Player plays the media types and codecs listed earlier for DirectShow (see Figure 7). You can select different video images including full-screen, or resize the video to any size you want, depending on your preference and image quality. There are two ways of using Windows Media Player to play content. First, you can use it as a standalone player and decide how you want to access Windows Media Technologies-based content. If you play the content file locally, you are not streaming the file. Windows Media Player reads the content file from the hard drive and then plays it. If you play a content file from a remote location, you can start the standalone player from a link in a Web page, and the content streams to your computer. Second, you can embed the Windows Media Player control in a Web page, a JScript-based application, or another ActiveX container application. The script commands used to embed the player can identify the content to play as well as show how to play it. If you are designing Web pages to run on Internet Explorer using DirectX, you have possibilities that go beyond standard scripting. Smooth, tear-free animation, accompanied by high-quality mixed audio and immediate response to user actions can make your Web pages stand out among the crowd. As previously mentioned, Windows Media Player is scriptable with HTML and JScript, so it can be embedded in a Web page and readily customized. Since it supports all major formats, Windows Media Player gives you a wide range of possibilities for enhancing your Web page. One of the most powerful of these is presenting a multimedia stream while providing the user with associated links that can be viewed simultaneously. Web controls, or pages on Web sites that control playback of local media, are also easy to implement using this technology. Windows CE 2.12 DXPAK Windows Media Player controls include a carefully selected subset of Windows Media Player features and most ActiveMovie controls. Some excluded control properties are markers, optional flags, and the ability to toggle options. Windows CE for Dreamcast Toolkit As we already mentioned, the first product to ship with support for Windows CE and DirectX is the Sega Dreamcast game console. Microsoft recently released the Windows CE for Dreamcast Toolkit to licensed developers. Windows CE for Dreamcast is an optimized version of the Windows CE operating system designed for the Dreamcast hardware. It includes all the tools needed to develop for this Sb processor-based platform in Visual C++ and a highly optimized implementation of the DirectX APIs. It is a prime example of a platform where you can use your existing Win32 and DirectX expertise and code to develop content for new consumer devices. In the past, console developers were forced to learn and use proprietary APIs and tools for each new platform. Developing for a new console almost always meant dealing with all the hassles of first-generation development tools. By providing Win32 and DirectX on Dreamcast, Sega and Microsoft are for the first time allowing game developers to create titles for both the PC and console using virtually the same code base as well as providing the opportunity to use existing code for exclusive Dreamcast titles. Also, you get to do all the development with the same familiar tools that you use for developing desktop games.
Unlike other consoles that either use cartridges (like the Nintendo 64) or standard CD-ROMs (like the Sony PlayStation), Sega designed a proprietary storage format for the Dreamcast called GD-ROM (Gigabyte Disk ROM). These discs can store both standard CD-ROM data and game data in a high-density band. The GD-ROM format allows Dreamcast titles to store more data than standard CD-ROMs without having to employ the much more expensive DVD drives. There are currently several peripherals available for the Dreamcast including a standard controller, microphone, light gun, wheel, and arcade-style joystick. Many of the peripherals support the use of plug-in Visual Memory System devices. These small devices serve as both persistent memory storage units and as portable game players using their built-in LCD screen. One promising feature of the Dreamcast is its built-in modem, which allows you to provide the same kind of online game play features available in many PC titles today, as well as Internet connectivity previously unavailable on consoles. The Dreamcast console does not actually ship with Windows CE built in. The operating system, DirectX, and the game itself are built as one image and stored on the GD-ROM. When the GD-ROM is placed in the Dreamcast console, the boot ROM loads the bootstrap code, which then loads the Windows CE operating system. This way, there are no versioning issues. You ship the version of Windows CE your game was developed for with your game—so there's no need to worry whether the user has the correct version installed. There are, of course, differences between Win32 and DirectX on Dreamcast and the desktop. There is no Windows UI (Explorer, Start menu, and so on) for Dreamcast, so the game is in charge of providing the entire user interface. There is no support for multiple windows either; the game runs in full-screen exclusive mode with DirectDraw and Direct3D IM as the primary graphics APIs. Like other Windows CE platforms, you can choose which components you want to build with your game. For example, if your game does not make any use of the networking features of Dreamcast, you don't have to include DirectPlay or Winsock. Since Windows CE does not provide its own UI for the Dreamcast, much of the functionality of the Win32 User component has been removed. Only the APIs for accessing resources and some user input WM_* messages are supported. Specifically, those actually dealing with window elements like buttons or menus are removed. Similarly, much of GDI has been removed since DirectDraw and Direct3D are the main graphics APIs. What's left of GDI is support for loading fonts and bitmaps. a new Dreamcast-specific API has been introduced to allow read/write access to the Visual Memory System devices. The standard Win32 serial communications APIs and Winsock 1.1 are provided for using the Dreamcast communication features. Windows CE for Dreamcast supports the full set of DirectX foundation components: DirectDraw, Direct3D IM, DirectInput, DirectSound, DirectPlay, and DirectShow. An upcoming release will also add support for DirectMusic. All of these components have been optimized for Dreamcast to improve performance, reduce size, and take advantage of platform-specific features. This is done while still providing developers with the standard APIs available on the desktop for developing games. Figure 10 highlights some differences between the DirectX components for Dreamcast and the desktop versions. DirectDraw and Direct3D have been heavily optimized for the PowerVR graphics chip to support nearly all the features of the standard DirectX APIs. Since the Dreamcast hardware is fixed, much of the software emulation code in DirectDraw and Direct3D has been removed to reduce the memory footprint. Again, your game will be the only application running, so you use full-screen exclusive mode. |
|
| When using DirectDraw, your single game application loads the DirectDraw library ddraw.dll and DirectDraw HAL ddhal.dll, and DirectDraw calls are passed through these thin libraries to the hardware for execution. When using DirectSound, your application loads DSound.dll and SNDCORE.dll, and DirectSound calls are passed down through these thin layers to the ARM processor sound driver for execution.
Direct3D under Dreamcast is very similar to its PC equivalent. You create the Direct3D device, create and load textures, and then call BeginScene. Inside the loop you set render states for each mesh and then call one of the DrawPrimitive* functions. When finished, you call EndScene and Flip. One notable difference is that there is no Z buffer on the Dreamcast. However, it is still supported by Direct3D for code compatibility purposes. Some features of the PowerVR chip have no equivalent support in desktop Direct3D, like support for a modifier volume, which can be used by the hardware to alter various properties of other polygons that fall inside or outside of it. Direct3D exposes some of these in the current release, and many will be in future releases. Using these features does create situations where code is Dreamcast-specific, but allows you to make full use of the Dreamcast hardware while still benefiting from desktop-compatible code for the majority of your game. One DirectX component that is completely missing from Dreamcast is Direct3D Retained Mode, mainly due to its size and performance. Using DirectInput on the Dreamcast is virtually identical to the desktop version. You enumerate input devices using EnumDevices, and create device objects for each device. All the currently available devices for the Dreamcast, such as the game pad, wheel, and arcade stick, are supported. The main difference on Dreamcast is that buffered data is not supported, so you must use immediate data for all input. This should be done often, but cannot be done more than once per frame. Networking technologies like DirectPlay, WinInet, Winsock, and RAS are all available on the Dreamcast. DirectPlay for Dreamcast allows game developers to provide network-play functionality similar to that already available on the desktop. WinInet opens the door to various Internet services like WebTV that want to target Dreamcast users. As on the desktop, Winsock and RAS provide low-level access to the underlying protocol stack and support for dial-up connections, respectively. Dreamcast Development As with other platforms that support Windows CE,
Visual C++ can be used to develop for Dreamcast. This gives game developers the ability to use the same tools for both PC and console game development. The Windows CE for Dreamcast Toolkit includes the Windows CE Toolkit for Visual C++ 6.0, which provides an Sb compiler, linker, and debugger. All this is available using the standard Visual Studio® IDE.
|
 |
| Figure 11 Creating a Game for Dreamcast using Visual Studio |
|
Figure 11 shows how we've created a Visual Studio workspace that includes both the x86 Win32 and Sb Win32-based versions of our game, which use the same source files. The PC version is built using the include and library files from the DirectX 6.1 SDK, and the Dreamcast version uses the files provided in the Windows CE for Dreamcast Toolkit. And even though a large chunk of console game development is done in C and C++ these days, there is sometimes still the need to get down and dirty with assembly. This can be achieved using the inline assembly support of the compiler or using the standalone Sb assembler. The tools run under both Windows 98 and Windows NT.
Figure 12 shows some code from the D3DSTRM sample included in the Windows CE for Dreamcast Toolkit. This sample uses DirectShow to render a media stream onto a texture that is then mapped onto a waving flag using Direct3D. This sample will work under both Dreamcast and a PC running DirectX 5.0 or higher. Of course, you won't be able to run this under Windows CE unless you have Dreamcast development hardware from Sega, but you can still run it on a PC. (If you're interested in getting development hardware, visit http://msdn.microsoft.com/cetools/platform/factsheet.asp.) The full source code of this sample linked at the top of this page. Looking at the sample, it's easy to see where code can be shared across platforms and what things need customization. a major difference under the Dreamcast version of DirectX is that you can render the media stream directly into a DirectDraw surface that's in video memory. Desktop DirectX restrictions force the media stream to be rendered into system memory first, then copied over to video memory. The sample checks to see if RENDER_TO_ DEVICE_MEMORY is defined to determine whether it can render straight to video memory. When building a version of the project for Windows CE on Dreamcast hardware, this is set. Most code will compile without changes for both Dreamcast and the desktop, but there are situations where you'll have to make changes. For example, since there is no real concept of window attributes like the title bar, we don't specify any text for it: |
|
| The bottom line is that there will be differences between code that runs on the PC and code for the Dreamcast—particularly if your game makes heavy use of Windows UI components or you want to take advantage of Dreamcast features unavailable on the desktop. For the most part, however, most code will work across platforms. Conclusion The Sega Dreamcast console is just one example of a cutting edge consumer platform that takes advantage of industry standard APIs and tools. Microsoft is working with other OEMs to develop consumer devices like advanced set-top boxes and Internet terminals built around Windows CE technologies. With the latest release of Platform Builder, DirectX and Windows Media Technologies are now available to anyone interested in developing for the expanding consumer device market. For more information on developing for Windows CE-based devices or creating your own Windows CE-based platform, visit http://www.microsoft.com/windowsce/. Further details about DirectDraw, DirectSound, and DirectShow can be found on the DirectX Web site, at http://www.microsoft.com/directx/. Information on Windows Media
Technologies can be found at http://www.microsoft.com/ntserver/mediaserv/default.asp. If you are interested in how to use alpha channels for image compositing, take a look at Porter, T. and T. Duff, "Compositing Digital Images," Proceedings of SIGGRAPH '84, Computer Graphics 18 (3), July 1984.
|
|
From the July 1999 issue of Microsoft Systems Journal.
|
