• Please review our updated Terms and Rules here

8088 Domination: A new FMV method for 8088 PCs

Trixter, have you any idea how far this (presumably new compression) technique could be pushed? For instance, might "TV quality" be possible with say a 12MHz 286?

Yes, with limitations. The basic techniques (which I'm still writing up, sorry it's taking so long) can be easily applied to any chunky mode (Tandy 320x200x16, MCGA 320x200x256) and datarate, but you run into disk bandwidth issues if you're trying to do too much. Once you hit a certain CPU power threshold, it makes more sense to switch to something else (such as Cinepak, or a custom algorithm based on vector quantization). For example, a 386-25 can play back 160x120 Cinepak @ 30fps while not exceeding a datarate of 150KB/s, so that's definitely the point at which you switch to something like that.

My technique can easily be ported to Tandy 320x200x16 and have it still perform nearly as well as it does in Domination, but until I get a Tandy DAC system, I have no real hardware to test on, sorry. I'll be releasing source and instructions after I finish the write-up, so if someone else wants to take up the charge, I'd be tickled.

I imagine this applies to PWM techniques, but what about LPC or CVSD playback using the PCjr Speech Adapter?

If the sidecar can play audio independently of the CPU, it should be possible. And I think it can, looking at the tech ref quickly. But I won't be tackling that any time soon, sorry :) And besides, it would only sound decent for voice.
 
Exact setup code:

For some reason I was thinking that the default palette for BIOS mode 6 is light grey, but it is in fact white so it's not necessary to set the palette explicitly and this code is fine. I was also thinking that the colours in DOSBox are too dark, but the real problem is that they're hue shifted so that red things look purple. This can be corrected by setting DOSBox's hue to ~40 (for 0.74) or ~20 (for current SVN). We improved it a bit a while back but perhaps we didn't go far enough!
 
This can be corrected by setting DOSBox's hue to ~40 (for 0.74) or ~20 (for current SVN). We improved it a bit a while back but perhaps we didn't go far enough!
In current SVN, are you setting "late CGA" mode (ctrl-alt-F11)? when I do that, the colors look close enough to Trixter's capture without further hue shifts - at least to me. (Late CGA emulation could still use some improvements though, as we discovered a while back.)
 
In current SVN, are you setting "late CGA" mode (ctrl-alt-F11)? when I do that, the colors look close enough to Trixter's capture without further hue shifts - at least to me. (Late CGA emulation could still use some improvements though, as we discovered a while back.)

Oh yeah, you're exactly right. I was thinking that old and new CGA were the same in 640x200 mode with a white palette, but the phase of the color burst relative to the pixel clock is different. In that case, it's good to know that Trixter's capture agrees with DOSBox!
 
Oh yeah, you're exactly right. I was thinking that old and new CGA were the same in 640x200 mode with a white palette, but the phase of the color burst relative to the pixel clock is different. In that case, it's good to know that Trixter's capture agrees with DOSBox!

Running with an old CGA card will produce some "interesting" results in the second part, see blog for more details.
 
Last edited:
Very interesting stuff! I like the change size ordering bit to solve lack of CPU time.

One question though. As delta blocks are dropped, so it becomes steadily more out-of-line - does the encoder cope with that, by redrawing some small percentage each frame for example?
 
Last edited:
Amazing work! Not just technically, but the video mix itself was very entertaining and built well on the original material.

Very cool to see Bad Apple in a new format. Goes next to the Megadrive/genesis version in my youtube playlist ;)

Seriously though, congrats on accomplishing this! Eagerly waiting for part two of your post-mortem. :)
 
Really fantastic!

Really fantastic!

Awesome Jim. Love it. This player is much more advanced than corruption and the encoder is much more advanced. It is cool to me how the encoder really evolved to a hand-in-glove kind of fit with the processor instead of a more traditional data-stream / execution stream arrangement. Nice hardware/software harmonic symphony. Sweet.
 
Jim, you are psycho. Can't believe this! Just ran it on my 5150, sure enough it works perfectly! :)

I read on your blog that the encoder is actually a compiler and the player loads the code for each frame and has the CPU execute it directly. I'll say it again. You are a freakin' psychopath dude. Brilliant. I wouldn't have ever thought to do it that way.
 
As delta blocks are dropped, so it becomes steadily more out-of-line - does the encoder cope with that, by redrawing some small percentage each frame for example?

Yes, as each time a new frame is loaded, the deltas are recalculated against whatever is currently displaying out of screen memory. This is adjustable via a threshold parameter though; you can have it always ignore screen, always consult screen, or any percentage inbetween. This was done to favor picture integrity at one extreme and framerate at the other extreme.

I tried the demo on my Tandy TX, and it does work except for the wrong colors in the first half of the demo.

Now that's dedication! I want it clear that I did not ask you to do that :)

It is cool to me how the encoder really evolved to a hand-in-glove kind of fit with the processor instead of a more traditional data-stream / execution stream arrangement. Nice hardware/software harmonic symphony. Sweet.

Now you know why I love the demoscene so much. Oldskool productions adhere to that kind of harmony and there is always some clever bit in every production.

You are a freakin' psychopath dude.

My "favorite" comment so far :)
 
I read on your blog that the encoder is actually a compiler and the player loads the code for each frame and has the CPU execute it directly. I'll say it again. You are a freakin' psychopath dude. Brilliant. I wouldn't have ever thought to do it that way.

About 1/3rd (overall) of all GM light vehicles produced in model years 12, 13, 14, 15, and probably 16 have the welcome animations and power flow animations drawn using compiled bitmap deltas created off-line. A custom compiler does something similar to Domination. It analyzes complexity of the delta from one frame to the next - actually to the second frame from current because of double buffering. If under a threshold, it emits C code to draw the delta to a passed-in frame buffer pointer argument with light optimization of the generated code. It then runs the generated code for each frame through GCC with heavy optimizations and thumb2 output enabled. I found GCC actually does a better job optimizing for ARMv7 than I could do by hand at a first pass. For larger complexity frames, a straight gzip of the raw frame data is performed and stored. Everything gets linked to a binary blob with a table of contents at the front. There wasn't a video decoder on the SoC. :)

Compiled sprites were nothing new in the 80s. Quite a few parallax scrollers used them including a game I wrote in 1989!
 
Thoroughly impressive effort Jim! :D


PCjr/Tandy can't play digitized audio without consuming 90% of the entire machine, so that's out of the question, sorry :)

You realise the irony of that statement, given how you managed to pull off the seemingly-impossible-leap over your corruption work.. :)

One 'quick and dirty' method that I would've envisaged to help reduce the CPU workload, would be (for example) to initialize one (or more) channels of the SN76496 to output the maximum possible tone frequency (125KHz) and then modulate the corresoponding 4-bit attenuation register? It would probably sound terrible but anyway.. :)
 
Last edited:
One 'quick and dirty' method that I would've envisaged to help reduce the CPU workload, would be (for example) to initialize one (or more) channels of the SN76496 to output the maximum possible tone frequency (125KHz) and then modulate the corresoponding 4-bit attenuation register? It would probably sound terrible but anyway.. :)

That's not the tough part -- the CPU-consuming part is modulating it 8000 times a second. Interrupt overhead is not free :)
 
That's not the tough part -- the CPU-consuming part is modulating it 8000 times a second. Interrupt overhead is not free :)

Thinking about it more, you're right that is a major issue. :) I wonder if it could be done via some form of software polling of Timer0/2 in the 8253 instead of using interrupts?
 
You made it onto OSNews too... one of my usual hangouts since I'm an OS whore.
 
Last edited:
Tried it on my CDP 1600. Colors look nice on the CGA composite out, but the cheap 8-bit RLL hard drive controller I threw at it couldn't keep up.

What hard drive controller did you use with this? I guess I just need to get a XT-CF-Lite or XT-IDE anyway :)
 
I used a high-performance one (ADP50) but I tested it with an XT-CFv3 board in PIO mode and it was able to keep up.

There is a bug in the buffering code -- when the buffer gets exhausted, it doesn't properly rebuffer. I will fix that before I release all the source and tools.

An RLL controller + drive with an optimal interleave should be able to sustain 90KB/s which should do a respectable job of playing the demo back; if you are using the default 6:1, it might be worth re-testing with spinrite or equivalent.
 
Back
Top