I recorded a video if somebody cares - https://youtu.be/0Fn1ka3CbYM.
A little disappointed with video quality (holy macroblocking!) and low-res flickery backgrounds (also fmvs now), but its better than nothing!
As i presume there is no CD-audio music in ReelMagic version of RTZ anymore? And you can't change FM synth to MT-32 emulation for example (update - actually, you can!)?

jrdennisoss wrote on 2022-03-01, 03:07:

The code repo can be found here: https://github.com/jrdennisoss/dosboxrm

Well done fork! And I really like how cleanly you document everything!

KainXVIII wrote on 2022-03-02, 13:12:

As i presume there is no CD-audio music in ReelMagic version of RTZ anymore?

No, of course not. The video files now occupy 633 MB on the disk instead of 90 MB in the regular CD version - there is no space for CD audio any more.

Uka wrote on 2022-03-02, 14:45:

KainXVIII wrote on 2022-03-02, 13:12:

As i presume there is no CD-audio music in ReelMagic version of RTZ anymore?

No, of course not. The video files now occupy 633 MB on the disk instead of 90 MB in the regular CD version - there is no space for CD audio any more.

Yeah, i thought about that..

Uka wrote on 2022-03-02, 06:17:

Sorry, my mistake. I must have confused "Man Enough" with "Flash Traffic" - there are no subtitles in the first scenes of "Man Enough" for some reason, even on the real hardware (must be an original bug). They do appear later 😀
And there are no actual subtitles for the videos in "Return to Zork" either.
So everything seems to be fine!

Cool cool... One less thing to fix then 😀

Is it the original ReelMagic / ReelMagic Lite?

Here's a pic of the card. I'm pretty sure it's the Maxima model, but embarrassed to say I am not 100% positive about that. To be honest, I only learned about the ReelMagic technology about a month or so ago and was completely blown away by how friggin cool this thing is and how it would have been totally awesome to have a ReelMagic setup back in the day. (Also a bit surprised that no one has already created an emulator for this)

It has glitches on later cards with 8-pin pass-through outer cable (REALmagic Maxima, REALmagic Maxima Pro, REALmagic Ultra), and the latest ISA card (REALmagic Ultra II / NetStream 1, with 9-pin pass-through outer cable) has some problems with other games as well (while PCI cards do not work with any of them at all, of course).

Bummer 🙁 I guess we'll have to see what happens. If there are too many issues, I may have to try to scrounge up an older card that uses the feature connector. (oh no, anything but that 😀 ) Though we may also have to scrounge up a VGA card with the feature connector on it too... Any recommendations on VGA card to use with the original or Lite model?

KainXVIII wrote on 2022-03-02, 07:27:

Step-by-step instruction how to run ReelMagic games would be helpful!

Duly noted. We probably should include something in the README like the example Bobbytoz posted above.

PS - its actually Dos Navigator, if i quit it - game loads, never had this issue before in dosbox *shrugs*

I haven't heard of DOS Nagivator. I'll have to give that a shot one of these days to see if it's something I broke with the ReelMagic stuff.

I recorded a video if somebody cares - https://youtu.be/0Fn1ka3CbYM.

This is great thanks for posting! Good choice of ending 😀

A little disappointed with video quality (holy macroblocking!) and low-res flickery backgrounds (also fmvs now), but its better than nothing!

Yeah there is definitely some improvement to be done here; a few known issues right now with regards to this:

• The "just make it work f_code hack" I put it to get 90+% of the MPEG video working is certainly not complete and causes some video artifacts; most noticeable in the RTZ cliffs of depression.
  • https://github.com/jrdennisoss/dosboxrm/issues/2
• The PL_MPEG decoder library itself may have some bugs in it causing some of the macroblock "color flashes" most notably at slice ends. (like the garbage you sometimes see on the right edge of the screen when the wizard is talking)
  • https://github.com/jrdennisoss/dosboxrm/issues/11
• The roughness of the macroblocks and blocks can sure be observed as well; especially on modern high-resolution digital PC displays. I think that on the old CRTs this was less noticable. People weren't yet use to the HD glory we have nowadays and take for granted. SIF quality back then was (supposed to be anyways) the same quality one would have for their OTA analog television signal. It might be possible to get in an OpenGL shader which helps smooth these out yielding in a better overall picture quality.

I spent some time over lunch today grooming the open issues to help track this stuff: https://github.com/jrdennisoss/dosboxrm/issues
Its good to track all this properly as there sure are a lot of things currently in motion with this project... 😀

jrdennisoss wrote on 2022-03-03, 00:25:

Here's a pic of the card. I'm pretty sure it's the Maxima model, but embarrassed to say I am not 100% positive about that.

Oh, yes, it is a 1995 Maxima card. I have it as well, but it is not the ideal choice, you know. "Return to Zork" won't work with it the correct way.

Some time ago I have collected and uploaded to Archive.org all the drivers I have: https://archive.org/details/sigma-design-drivers
Maxima has only a version 2.30 driver available.

jrdennisoss wrote on 2022-03-03, 00:25:

Any recommendations on VGA card to use with the original or Lite model?

That's an interesting question 😀
There are many cards with feature connector, but some of them have issues with it (that feature connector was not something that had to be tested). I had to try maybe five different cards before I have found a nice working one (Trident TVGA8900C with 1 MB).
Luckily they are all not rare and very cheap (especially when compared to the original ReelMagic/ReelMagic Lite card)!

There is an official list of recommended VGA cards (the one that came with my boxed card as well): https://ia803401.us.archive.org/1/items/fullv … lity_manual.pdf
But it is not complete of course - there are just a few examples, which were popular in the USA back in the days.

jrdennisoss wrote on 2022-03-03, 00:37:

I haven't heard of DOS Nagivator. I'll have to give that a shot one of these days to see if it's something I broke with the ReelMagic stuff.

I think that it is not something you have done with DOSBox, just this game does not like DOS Nagivator. It is not the only one that does not work when launched from there!
DOS Nagivator is a file manager, which was quite popular here in the (former) USSR countries.

Update: I have created a new release for this: https://github.com/jrdennisoss/dosboxrm/relea … /tag/2021-03-02

Lord of the Rings should be stable now with a couple known issues:

• Hitting spacebar then ESC during a video will lock up the game
• Loading the demo on the title screen gives a "FMPOpen Error Code: 0" error message

Note: The demo error message can be worked around by copying "C:\LORD-CD\GAME\LORD.CFG" to "C:\LORD.CFG"... Not currently sure if this is something introduced by DOSBox ReelMagic or if this is a bug in the game itself. (probably the former 😀 )

Uka wrote on 2022-03-03, 04:12:

Oh, yes, it is a 1995 Maxima card. I have it as well, but it is not the ideal choice, you know. "Return to Zork" won't work with it the correct way.

Good to know.

Some time ago I have collected and uploaded to Archive.org all the drivers I have: https://archive.org/details/sigma-design-drivers
Maxima has only a version 2.30 driver available.

This is a great collection and will certainly be helpful.

...before I have found a nice working one (Trident TVGA8900C with 1 MB).
Luckily they are all not rare and very cheap (especially when compared to the original ReelMagic/ReelMagic Lite card)!
There is an official list of recommended VGA cards (the one that came with my boxed card as well): https://ia803401.us.archive.org/1/items/fullv … lity_manual.pdf

Thank you this is exactly what we need! 😀

I knew about RealMagic for a long time...
But I also began to deal with this problem closely about a month ago.

Uka is probably one of the most knowledgeable people on the planet at the moment on this technology.
He gave me some consultations earlier.

I bought a RealMagic XCard for experiments ($2 price).
Here 's what I managed to find out in the course of my research.

- XCard plays standard MPEG1 (Non-standard formats - artifacts)
- XCard playback on an LCD monitor (mediocre quality)
- XCARD playback on CRT TV via S-Video cable (good video quality)

Huge problems with drivers and video playback software (terrible compatibility, unavailability on the Internet).

About the launch of games on the original RM:
There is a DOS program (http://mpegone.de/) that is capable of reproducing RM MPEG without hardware. (Compatibility is about 60% according to my tests)

The real RM hardware also experienced huge problems with running games that were specially made for it...
Special patches and specific hardware are needed otherwise there will be failures.

Here 's what the developer himself writes :

Palette Problems
================

If you are experiencing color palette problems with some of your
software programs, such as wrong colors or posterized images, it is
most likely that you have a local bus VGA adapter. Some software
does not pass the palette information to the feature connector as the
palette changes. Since RealMagic gets the palette information from
the feature connector, wrong colors will result.

One solution is to connect your VGA display directly to your VGA
board, in effect bypassing the RealMagic board, when you are using
this software. Another solution is to connect the two VGA outputs,
one from RealMagic and the other from your VGA board, to a VGA signal
switch box. This type of device allows you to switch between the
RealMagic VGA output and your VGA board output with a flick of a
switch.

Playing DRAGON'S LAIR
=====================

The RealMagic DOS driver must be loaded before playing Dragon's Lair.
A batch file is created in the RealMAGC directory called DRAGON.BAT
which handles all this for you. To play Dragon's Lair, place the CD
in your CD-ROM drive and type:

CD \RealMAGC and press <Enter>
DRAGON and press <Enter>

Note: the batch file assumes your CD-ROM drive letter is "D". If this is
not the case, you will need to use a text editor to modify the batch
file. The line which reads:

D:

should be changed to reflect your CD-ROM's drive letter (e.g. "E:").

Playing THE HORDE
=================

You must have RealMagic Software Version 1.10 or later to run the
MPEG version of The Horde. If you have the RealMagic Lite, make
sure your sound card is 100% SoundBlaster(TM) compatible. Some
sound cards, such as the Media Vision ProAudio Spectrum 16(TM) and
boards that use the Media Vision PAS 16(TM) chip set, will not work
with The Horde (no sound). Crystal Dynamics has provided a fix for
this in the form of a new HORDE.EXE. It is available on the Sigma
Designs BBS for download.

Another sound card, the Sound Galaxy Pro(TM) from Aztech, requires
a special command when starting The Horde. Modify the PLAY.BAT file
in the \HORDE directory (created by the INSTALL program) to start
The Horde with the command line "HORDE /S:SBLASTER" (between FMPLOAD
and FMPLOAD /U). Without this command line option, the volume
controls of the Sound Galaxy Pro will be set to zero each time you
start The Horde.

If you use disk caching programs, such as Microsoft SMARTDRV, you
MAY experience hanging problems. If you do, try turning off the
"write-caching" to the hard drive where The Horde has been installed.
For example, if you use SMARTDRV and The Horde is installed on drive
C:, use the command SMARTDRV C to turn off "write-caching" on drive C:.

Playing RETURN TO ZORK
======================

You must have RealMagic Software Version 1.11 or later to run the
MPEG version of Return To Zork. The Return To Zork installation
program will check the version of your RealMagic driver to make sure
you have a compatible version. You can also find Version 1.11 of
the RealMagic software on the MPEG version of the Return To Zork CD.

Playing MAN ENOUGH
==================

You must have RealMagic Software Version 2.00 or later to run the
MPEG version of Man Enough. Be sure to read the README.TXT file on
the Man Enough CD for installation instructions.

I conducted an experiment.

The Horde RealMagic CD

Replaced the original intro.mpg (12 fps) file with a file from the RealMagic Demo disk (29.97 fps).
The game still didn't play the video...

Apparently the problem is not in the MPEG standard in which the file is written.
There is a more serious problem here.

jrdennisoss wrote on 2022-03-03, 04:59:

Update: I have created a new release for this: https://github.com/jrdennisoss/dosboxrm/relea … /tag/2021-03-02

Lord of the Rings should be stable now with a couple known issues

Great!
So, for now we have two games being 'officially' supported - although someone could still play them all till the end to ensure everything is all right.
1. "Return to Zork" - I did not complete it in the DOSBox RM fork, but I tried my old saves from different parts of the game, everything is fine!
2. "The Lord of the Rings" - I have not played it too far either.

Now, there are 8 more ReelMagic DOS games currently available. I have tried them with the new release, but the results are the same:
3. "Man Enough" - I have now played a bit further: unfortunately if the first videos are fine, the later ones either show artifacts or do not appear at all. And sadly only disks 1 and 3 are available for now.
4. "Crime Patrol" - aborts itself just after the launch not recognizing the driver.
5. "Dragon's Lair" - the game launches, but the game videos do not show up (only the end-game videos are present).
6. "Drug Wars" - the same as with "Crime Patrol".
7. "Entity" - now, that's a special case as this is the only game I can't run on the real hardware (and it is the only one I have not on original disks or images but on some suspicious custom-made image). Still, it seems it launches fine and recognizes the DOSBox RM drivers! The videos are shown incorrectly though (just artifacts).
8. "Flash Traffic" - the game launches, but there is no picture at all.
9. "Space Ace" - the game launches fine, but the videos are shown incorrectly (with artifacts).
10. "The Horde" - the game launches and plays fine, but the videos are missing.

Then, there are Windows 3.11 ReelMagic games!
I have not tried them as I am not sure DOSBox 0.73 could run Windows 3.1 (that would better to be done with DOSBox SVN or SVN Daum).
But of all games and multumedia programs for Windows, as far as I know, only "The Psychotron" requires the RM driver to run, and "Prince Interactive" requires it for some of its videos.

jrdennisoss wrote on 2022-03-03, 04:59:

Note: The demo error message can be worked around by copying "C:\LORD-CD\GAME\LORD.CFG" to "C:\LORD.CFG"... Not currently sure if this is something introduced by DOSBox ReelMagic or if this is a bug in the game itself. (probably the former 😀 )

Indeed, you are right! Yes, that's the original bug - it is all the same with the real hardware.

jrdennisoss wrote on 2022-03-03, 04:59:

Update: I have created a new release for this: https://github.com/jrdennisoss/dosboxrm/relea … /tag/2021-03-02

Thanks for you work!
PS - call me crazy, but shouldn't there be another date, like 2022-03-02?

@uka: Windows 3.11 should work fine in DOSBox 0.73. Only problem (that persists in SVN as well) is that share is not working. If a game needs, you can fake it though with fakeshare (in my Wibdows 3.1x guide).

Update: I have created a new release for this: https://github.com/jrdennisoss/dosboxrm/relea … /tag/2022-03-03

• "The Horde" now plays video, but looks like total crap due to non-compliant MPEG-1 formatted ReelMagic video files.
• The date / version number has been corrected moving forward. Thank you KainXVIII for catching this... "What year is it? Oh yeah the great diffusion was..." 😀

Note: This is the ticket I am using to track the issue with the proprietary ReelMagic video files: https://github.com/jrdennisoss/dosboxrm/issues/2
In a nutshell, these video files are not MPEG-1 compliant and my workaround to just make them work does not fair so well on The Horde. More details below.

Thank you Uka for that clean succinct list of game compatibility as this helps keep this project organized.

Dominus wrote on 2022-03-02, 13:41:

Well done fork! And I really like how cleanly you document everything!

Thank you for the feedback Dominus! Something this complex sure needs a lot of documentation, otherwise it's just not humanly possible to grasp. 😀

Uka wrote on 2022-03-03, 07:26:

Then, there are Windows 3.11 ReelMagic games!
I have not tried them as I am not sure DOSBox 0.73 could run Windows 3.1 (that would better to be done with DOSBox SVN or SVN Daum).
But of all games and multumedia programs for Windows, as far as I know, only "The Psychotron" requires the RM driver to run, and "Prince Interactive" requires it for some of its videos.

For now, Windows 3.1x support is something further out in the future, but definitely something I have given thought to. Especially as "The Psychotron" looks pretty cool. I do have a working Windows 3.11 install which runs great on DOSBox 0.74-3 (thanks Dominus for your excellent guide on that! 😀 ), however rebasing this project on the SVN trunk just seems like the sensible thing to do before hand. I don't think it will be too hard to rebase, but I'll probably get to it once I hammer out most the major game compatibility and major MPEG decode issues. Hindsight 20-20, it really was pretty stupid of me not to base this off of the SVN trunk, especially as those builds seem pretty stable. I guess I'm so used to working in an enterprise software development environment where running anything off the trunk or master branch is just asking for trouble as something major is usually broken. 🙁

Uka wrote on 2022-03-03, 07:26:

Indeed, you are right! Yes, that's the original bug - it is all the same with the real hardware.

Awesome thanks for confirming!

Bobbytoz wrote on 2022-03-03, 07:07:

I conducted an experiment. […]
Show full quote

I conducted an experiment.

The Horde RealMagic CD

Replaced the original intro.mpg (12 fps) file with a file from the RealMagic Demo disk (29.97 fps).
The game still didn't play the video...

Apparently the problem is not in the MPEG standard in which the file is written.
There is a more serious problem here.

Great experiment! This certainly inspired me to dig further on this specific issue as I missed your earlier "The game does not play video(((" comment post.
There is indeed an MPEG standard/encoding problem with "The Horde" game assets, however this is only one of many the problems at play here. 🙁 I explain in more detail below. The more serious problem that you observed was the emulator being too strict with one of the video play calls. Thanks to your help, I found this issue, and on this new release, I relaxed the parameter validation on that and now it looks like "The Horde" plays video. There are probably other bugs too as I have not thoroughly tested things yet and the video quality is complete garbage, but at least it now plays and there is sound. So in theory, if you retry your experiment, things should be MUCH more successful now. 😀

Note: Both files are 29.97fps; more details below.

Bobbytoz wrote on 2022-03-01, 18:54:

DOWNLOAD VIDEO SAMPLES: https://www38.zippyshare.com/v/fzwlt40W/file.html

This turned out to be very helpful thanks! I started doing an in-depth analysis of your #1 and #2 sample files. Sample file #1 (DEMO CD) is pretty much the good old-fashioned MPEG-1 PS format that we all know and love. Sample file #2 (Horde CD RM_MPEG) is a "magical" (a term I used to describe these) MPEG-1 PS format file.

#1 DEMO CD Sequence Header:

- Picture Size: 352x240
- Aspect Radio Code: 0x0C
- Frame Rate Code: 0x04 <--- 0x04 = 29.97 fps
- Constrained Parameters: Yes
- Bitrate: 2875 (1150 kbps)
- VBV Buffer Size: 20

#2 Horde CD RM_MPEG Sequence Header:

- Picture Size: 352x240
- Aspect Radio Code: 0x0C
- Frame Rate Code: 0x0C <--- This is NOT a valid MPEG-1 frame rate code!
- Constrained Parameters: No
- Bitrate: 2538 (1015 kbps)
- VBV Buffer Size: 20

The invalid/reserved frame rate code of 0x0C is what makes sample file #2 "magical"... I have only currently seen 0xC and 0xD on these "magical" files, but it's safe to assume that when anything 0x9 or above is present in this field, it signals that this file needs special handling to recover the proper picture f_code values. If one strips off the most significant bit (0xC & 0x7), then the correct frame rate code of 0x4 (29.97fps) is revealed. This has held true for all "magical" videos I have ran across so far. I know that the correct frame rate is indeed 29.97fps, not 12fps because the 90kHz PTS clock for the video ES has elapsed 17795798 ticks for a total of 5925 pictures. Doing the math (5925 / (17795798 / 90000)) yields ~29.9649fps.

I suspect that these two files were produced by two completely different MPEG encoders. The picture f_code values in the sample file #1 don't change but they do seem to change often in sample file #2, even taking into account the detection algorithm I wrote for this. I have tried statically patching in picture f_code values 1 through 7 and playing the sample file #2 in VLC and the video is always garbage. Also, The GOP size of sample file #1 is double that of the sample file #2 and the B and P picture ordering is a completely different pattern. This is a bummer because having a "magical" and "non-magical" version of the same MPEG file would be incredibly useful as I could compare bit-for-bit to see EXACTLY what is different. I already have nailed down what makes a "magical" file non-compliant with standard MPEG-1, but having this would certainly accelerate development efforts of getting the video to decode correctly.

Bobbytoz wrote on 2022-03-01, 19:06:

On real hardware RealMagic XCard PCI Similarly... […]
Show full quote

On real hardware RealMagic XCard PCI
Similarly...

MPEG1 Video 29.97fps 1150kbps (works!)
MPEG1 Video 12fps 1015kbps (Frame failures)

Not surprised at all that this does not play on a later model card as they are doing things that are COMPLETELY insane / out of spec for standard MPEG-1 (ISO/IEC 11172-2) video. I'm speculating that they may have actually done this on purpose to prevent a competitor from making a compatible card. According to the datasheet, it looks like the CL450 decoder chip supported doing manipulation of some fields in the picture header on a per-picture basis on-the-fly; but I can't imagine why this would be a feature available in many MPEG decoders chips. No wonder they had so many problems with backwards compatibility with these cards.

Side comment: I think something is off with the MPEG analyzer you are using because 12fps is not a "legal" MPEG-1 frame rate. This page (http://stnsoft.com/DVD/mpeghdrs.html#seq) lists the handful of valid MPEG-1 frame rates which range from 23.976 to 60 fps. I have confirmed this against the actual ISO spec which unfortunately I can't share because it is licensed. I'm guess the reason it is telling you 12fps is because the value in the sequence header frame rate code field is literally a value of 12 (0xc in hex) and it does not know what to do with that. I ended up writing my own MPEG analysis tools for this project because there is just too much junk out there that is out-of-spec or simply gets too many of these critical details wrong. These can be found in the "tools/" folder in the repo... If you are feeling adventurous just hit "make" (Linux only) to build all tools in the directory. Usage instructions are in the "NOTES_MPEG.md" file. I haven't committed the tools I used to decompress and validate the slice/macroblock/block bitstream data, but the tools that are there will validate and walk an entire MPEG-1 PS structure. The "superanalyze_mpeg_ps" tool will essentially convert an MPEG file to a very big text file. This has helped me tremendously see what is actually going on inside of these files.

Bobbytoz wrote on 2022-03-03, 05:51:

I knew about RealMagic for a long time...
But I also began to deal with this problem closely about a month ago.

I wish I would of known about this back in the day... Then again, I may have given up on it seeing the frustration many people go through just to get a working setup. Plus it seems like the made more board models than games!

Uka is probably one of the most knowledgeable people on the planet at the moment on this technology.

Yeah seems like it! I'm sure glad I found him on this forum as I have learned a ton this week. 😀

- XCard plays standard MPEG1 (Non-standard formats - artifacts)
- XCard playback on an LCD monitor (mediocre quality)
- XCARD playback on CRT TV via S-Video cable (good video quality)

Good to know thanks! The s-video thing adds to my thought on an OpenGL shader being able to help smooth out the video a bit.

Huge problems with drivers and video playback software (terrible compatibility, unavailability on the Internet). ... The real RM […]
Show full quote

Huge problems with drivers and video playback software (terrible compatibility, unavailability on the Internet).
...
The real RM hardware also experienced huge problems with running games that were specially made for it...
Special patches and specific hardware are needed otherwise there will be failures.

Yeah that really is a shame 🙁

About the launch of games on the original RM:
There is a DOS program (http://mpegone.de/) that is capable of reproducing RM MPEG without hardware. (Compatibility is about 60% according to my tests)

Thank you for bringing this up! I'm definitely gonna check it out as having another MPEG decoder/player in my toolbox is incredibly helpful for debugging this stuff.

Here 's what the developer himself writes :

This information is gold... Especially what he writes about the VGA pallet stuff as I have an open issue to properly implement and fix issues with that too.

jrdennisoss wrote on 2022-03-04, 02:47:

Good to know thanks! The s-video thing adds to my thought on an OpenGL shader being able to help smooth out the video a bit.

While using a shader is an option (especially with SVN trunk, which already supports rendering via shaders - the main reason I suggested looking into it), have you attempted to use the SDL YUV overlay functions? Scaling may still be an issue but at least you wouldn't have to worry about RGB/palette problems.

jrdennisoss

Thank you for the work done and detailed stories about the progress of development.

The update works with a modified The Horde disk!

But I noticed that the image is divided into large transparent squares. Which are noticeable in the dynamics.

jrdennisoss wrote on 2022-03-04, 02:37:

According to the datasheet, it looks like the CL450 decoder chip supported...

In case it helps you, about 9 years ago I scanned and uploaded the C-Cube CL450 User's Manual for Toni Wilen/WinUAE (and for the MAME project). It should be quite a bit larger than the datasheet! I believe that DatasheetArchive and such did make their own copies of my upload, so you may in fact be talking about this document, but it is not a datasheet, it is the user's manual.

You can find it here: http://mess.redump.net/_media/datasheets/c-cube/cl450um.pdf
and errata here: http://mess.redump.net/_media/datasheets/c-cube/cl450mpg.pdf

jmarsh wrote on 2022-03-04, 04:04:

While using a shader is an option

My thoughts on the shader was to use it more as a "final video filter" kinda like the ones that give it a CRT look to help smoothen out the MPEG video block/macroblock boundaries; like the phosphor physically would in an old CRT.

especially with SVN trunk, which already supports rendering via shaders

Funny you mention that because a couple months ago I was actually playing around with these shader files in an attempt to correct a pixel aspect ratio problem I was having with a game...

have you attempted to use the SDL YUV overlay functions?

No I didn't know about this... This is a very good starting point this especially as I don't (yet 😉 ) really have any experience with SDL. The "SDL_CreateYUVOverlay()" function looks pretty handy, especially for what I'm doing here! The YUV -> RGB conversion is a large part of the software compute resources required for this implementation so being able to hand it off to something else which has the potential to further offload it to dedicated hardware when applicable would certainly be the "right way" to do this. I'm thinking that the rebase to trunk and researching this should be done as part of the same task.

Scaling may still be an issue but at least you wouldn't have to worry about RGB/palette problems.

Aside from efficiency, the current MPEG RGB data is OK as MPEG video is always 24bpp regardless of VGA mode. Although, matching VGA RGB colors to closer match MPEG video RGB colors but would be a nice-to-have if possible to improve. It is especially noticable in games like Return to Zork in the gift shop where the ceiling fan colors are slightly off from the MPEG video colors...

But yeah things like scaling, offset, surface z-order, transparency, MPEG clock, and probably something else all need to be accounted for when deciding on which is the right way to hook this in. I first need to get my ducks in a row with a full understanding of the capabilities of what the ReelMagic hardware and drivers truly can do. Especially as I mentioned in an earlier post, I only heard about this technology about a month ago. 😀 My current approach on this is continually improving the emulator 0.74-3 fork and getting it mostly functional with most games out there. In parallel, we just received a real ReelMagic card this week and are working on getting it setup in a real 486 PC. We will bust out the old Watcom compiler, synthesize some MPEG video files, and see how this thing actually ticks, bugs and all. Once we have reached a reasonably solid understanding of this thing and have reasonable support of a diverse set of games, that should give us a fairly comprehensive list of high-level features that the emulator needs to cover in order to start researching a better approach. In the best case scenario, most of the github fork code will be reusable for rebasing this fork on to DOSBox SVN trunk with minimal change/adaptation. In the worst case scenario, the ReelMagic emulation code is completely re-written, however, we would at least have gained a "spec" which defines how all the ReelMagic stuff works. With the way things are going currently, I suspect that this will fall towards the middle with a slight lean towards the best case scenario 😀

For the palette stuff I was mentioning earlier, I was referring to the way the ReelMagic driver has a dependency on the VGA palette. While fiddling around faking some of the port I/O, I once caught the real FMPDRV.EXE making an INT 21h/AH=25h call to install itself into the INT 10h slot. While I do not currently understand why it would need to do this, my running theory is that this is done so that it can intercept any video mode or palette updates, and notify the physical hardware accordingly; especially for the models that do not use the VGA feature connector.

With the current fork's implementation, I am also intercepting the VGA pallet in the fork, but for a slightly different reason. This way I can always keep the video output in 32bpp mode so that I do not constrain the MPEG decoders to just 256 colors when VGA is in 8bpp mode or cause unnecessary flashing during switching of MPEG video plays. Thus I am currently re-implementing the VGA 8bpp -> 32bpp (technically 24bpp) color map in the "reelmagic_videomixer.cpp" file. Probably not ideal for the long-term or something that I would present as "mergable" quality, but allows me to focus on the ReelMagic interface game compatibility and MPEG video decode problems. Having an alternate path where I can just provide the 24bpp/32bpp raw RGB (or even better YUV) pictures would be much better!

I am only "underlaying" (I know, technically "overlay" but this word seems to fit better here 😀 ) beneath the VGA picture and using VGA palette index 0 as the alpha/transparent color when in 8bpp mode, and "pure black" when VGA is 32bpp mode. I initially started this project with just using pure black as the transparent color, however, this was noticeable in Return to Zork on some of the menus. Surprisingly, this seems to work pretty reliably across the games people have mentioned here. Aside from the issues with TESTFMP.EXE, I haven't yet ran into a game where this approach fails. However, I'm pretty sure this is not the right way to do this and I need to further research how the real deal actually makes the decision of what is transparent. So far, I have only seen this card "underlay" video beneath the VGA output, but I suspect there is also a flag in the driver which allows the caller to actually "overlay" the video as well.

The current fork has a couple dependencies on VGA:
. Emulated VSYNC signal ("RENDER_StartUpdate()") drives the MPEG system clock reference.
. Palette colors to determine where to "underlay" the MPEG video.

I should be able to refine that list and the final features list once the current "research phase" is more complete and I might hit you up (if you don't mind that is 😀 ) on sensible software architectural approaches that would be able to accommodate the ReelMagic emulation better into DOSBox (+SDL).

Bobbytoz wrote on 2022-03-04, 05:51:

The update works with a modified The Horde disk!

But I noticed that the image is divided into large transparent squares. Which are noticeable in the dynamics.

Nice... Thanks for running that test again... Much appreciated!

The transparent squares you are seeing are indeed expected and part of the original video. They are the MPEG block (8x8 pixels) and macroblock (16x16) boundaries. The MPEG picture quality is slightly improved when turning on "VGA DUP5" mode, but you will still see theses in that mode too unfortunately. I attached a screenshot of roughly the same scene playing in VLC media player. You will notice that the block boundaries are harder to see in the places that have a lot of motion, but still visible in parts of the picture that remain fairly still. VLC media player applies some post decode digital filtering on the images which essentially "blur" the boundaries. The ReelMagic DOSBox emulator currently does not have this functionality. In the old days, when outputting MPEG-1 video through an analog format such as S-Video, these boundaries get naturally blended together as there is no such concept as a "pixel" with analog video, but rather things are separated per line, and the line boundaries are often blurred together by the phosphor in the CRT. Not now, but at a later phase I am thinking of implementing similar digital filtering like VLC does, but possibly in an OpenGL shader. Currently I am waste deep in figuring out the key to making the "magical" videos convert and play as normal MPEG-1 videos as well as game compatibility, but once I get past these major issues, I will definitely be looking at optimizations like this. 😀