|<< Newer||Article #160||Older >>|
What you may have deduced from the whatsnew in MAME 0.106u1 (assuming you read it) is that some work on the video system was under way. I've been claiming "video system rewrite!" for so long that I can barely remember when I first started discussing it. It was at least a year ago, if not longer.
Ever since I first mentioned it, it has been a monkey on my back -- a giant "everything's gonna break" rewrite that I've been both itching to do and dreading at the same time. It's been clear for years that MAME has needed far more fleixibility in handling things like multiple screens. It's also been clear that my original attempt at a system to incorporate artwork was only partly successful. And there has been way too much interference with game-drawn graphics by external entities like the user interface, which has created a lot of grossness about the way video is handled.
All this was to be fixed with the video rewrite. And if you know me, you know that fixing all those problems is something that I really, really wanted to do. But at the same time, I was dreading it. Why? Well, the biggest reason is probably the fact that it would mean delving back into DirectX programming once again, which is always fraught with pain. Ever since the original port to Windows a number of years back, I haven't had to deal with the DirectX side of things much.
Plus, it's a hard problem, and not the sort of problem that I can easily solve in one-hour sessions over the course of a number of weeks. It's really the sort of problem that requires me to sit down with several days' worth of completely dedicated time ahead of me so I can get "over the hump" of the initial programming work and then spend the more normal one-hour sessions debugging/fixing the remaining problems.
Well, this past weekend, I'm happy to say, it finally happened. Bye bye,
A number of factors came together to get most of the work done, but the most important one (and the one that I have been planning around) is that the missus was out of town from Thursday noon to Sunday evening. Couple that with some vacation time, a bunch of junk food, some musical inspiration, limited sleep, and you end up with a solid 78 hours of geekdom. I think I ended up programming for 55-60 of those. It's all a blur now anyway.
The practical upshot of this is that the core work for the new video system is now written. I had the software-only version up and running by the wee hours of Friday morning, and the Direct3D-based version running about the same time Saturday morning. Artwork of all forms -- bezels, overlays, backdrops -- is working, including more flexible state-based control over the pieces. Vector games use the hardware to render the vectors. Multiple screen support works in the core, and most of the code is written to allow it to actually render to multiple screens/windows on the Windows-specific side, though I'm still at a loss for how to expose the new gamut of options in the limited form of the command line.
In subsequent days, I hope to provide more information about the rewrite, including details on the new layout file format and some of the internals of the new system. For now, I'm just going to list out a few interesting tidbits/side effects that you should be aware of. Keep in mind that although the basic system works, there are still a lot of things left to do.
- There is now a new layout file format (.lay), which is XML-based, and which replaces the old .art files. Converting a .art file to a new .lay file is a little tricky, but not too difficult. I've done it for invaders and turbo.
- XML-based layouts are also now used internally to describe how screens are oriented and positioned. For example, dual-screen games have a layout that positions the two screens relative to each other.
- Multiple layouts can be loaded and ready, and can be switched between at runtime. This means you can have a layout which only has the first screen of a dual-screen game, as well as a layout with both screens visible, and can switch between them. Eventually I hope to save this information in the .cfg file. Rotation of the UI and game screens will also eventually be able to be dynamically changed.
- There are no plans to support DirectDraw with the new system. It will be Direct3D or GDI only. DirectDraw has been deprecated for several years now. The Direct3D support will require Direct3D 8 or later, since I based the code on the work I did for the Radikal Bikers emulator.
- Even if you use software rendering, you still get stretching to the correct aspect ratio now (no filtering, just point-sampled stretching). You can turn this off by selecting a "native" layout, which is based on the pixel resolution of the screen rather than on the aspect ratio of the screen.
- A number of existing Direct3D and DirectDraw options will be going away in the first incarnation. Some of the options don't really make sense in the new world, and I doubt they will make a reappearance. For example, "cleanstretch" would only stretch the screen by integer ratios, but now each element in a layout can be stretched by arbitrary amounts, so there is no single item to use as a gauge for cleanstretch. A lot of the other options need some serious thinking in order to make a reapperance.
- In general, it seems that the use of video in MAME falls into one of two categories: either you are running it with a regular VGA monitor and want all the bells and whistles; or you are running it with an arcade monitor and want just the screen with no adornments and just the raw bits. I am considering making this a command-line switch, because choices about how to handle different behaviors can be more sensibly made if your intentions are clear.
- The UI font is now configurable. In the short term, this is more just for fun, but now you can provide any .BDF font (including proportional fonts) and use it for the GUI. I took one of the FreeFont TTFs and imaged it at 40pt to produce a nice, crisp font at high resolutions. Since the new rendering system is unicode-aware, we can eventually support displaying proper Unicode names of Japanese titles.
That's it for now. I'll post some screenshots later, and discuss more details
over the next week or two. Again, remember this is all still very much
a WIP, but the remaining issues can all be tackled one at a time. The big
deal was getting the core work done, and thankfully, that's finished!
Warning: mktime(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/aaron8/public_html/index.php on line 34
Warning: date(): It is not safe to rely on the system's timezone settings. You are *required* to use the date.timezone setting or the date_default_timezone_set() function. In case you used any of those methods and you are still getting this warning, you most likely misspelled the timezone identifier. We selected the timezone 'UTC' for now, but please set date.timezone to select your timezone. in /home/aaron8/public_html/index-html.php on line 87