• Please review our updated Terms and Rules here

8088 corruption encoder... a new one

Not sure what's going on, but I highly doubt it's a scaling bug. I'm using the same scaler I have been, a function from the SDL_bilinear library. (Unless they did a bad job writing it) Some sort of comparison issue I am guessing. Nothing's changed from the 40x25 mode though, I'm simply scaling the source frames to 320x100 instead of 160x100 and doubling the amount of characters in the width that I compare pixels for.
 
It has a few of the three-line characters, but not many. I really don't know what to do about it, I think this is the best I'm going to get for now. :/

If I can figure it out later, I'll definitely post an update. I'm sure I'll work on it sometime.
 
Since I feel the 80-col conversion is not much better than the 40, I'll refrain from changing the 8088flex player for now.

Upside: I'm going to release my encoder, and I'll ask sandor if he still has the source for it. It's nowhere near as friendly as yours (it doesn't accept video files) so there is "room" for both.
 
Trixter said:
Since I feel the 80-col conversion is not much better than the 40, I'll refrain from changing the 8088flex player for now.

Upside: I'm going to release my encoder, and I'll ask sandor if he still has the source for it. It's nowhere near as friendly as yours (it doesn't accept video files) so there is "room" for both.
Click to expand...

If he does have the source, you should look into multithreading it. It would be pretty fast on these modern multicore systems. It shouldn't take much effort really. What language is the source? C? I know you never really got into C, so if that's the case I can have a look at adding that if you get it.

As far as the 80-col conversion, it's definitely noticeable during smooth horizontal movement of things on the screen. It also is noticeable on the close shot of the faces where the guys are talking, as well as adding detail of the neon stuff on their "Tron suits" - whatever they call those, I never saw the movie sadly. Maybe you are onto something with the 80x50 idea though. ;)
 
Mike Chambers said:
If he does have the source, you should look into multithreading it. It would be pretty fast on these modern multicore systems. It shouldn't take much effort really. What language is the source? C? I know you never really got into C, so if that's the case I can have a look at adding that if you get it.
Click to expand...

It's Delphi with MMX assembly, which I can hack, but if I get a reply from Sandor with the source I'll likely release it as-is.

Maybe you are onto something with the 80x50 idea though. ;)
Click to expand...

Maybe, but maximum framerate at optimal conditions would be 15fps on 8088+clone_CGA so the practicality is debatable.
 
For fun, I added an 80x50 mode encode option. True 80x50 that is, not the tweaked CGA mode that cuts off half of each character. I know this isn't possible to play back on most 8088s, you'd need VGA and an IDE drive (or an amazing MFM drive) but I think this looks really awesome...

Trixter don't you think it would be cool to support this for higher-end 8088s? :)

The TNG intro: (again, make sure you switch it to 480 when you play)


It looks sharper before YT's encoding mauls it. This looks good enough to where you could probably watch a whole TNG episode and end up with only a very minor headache.

Fun fact: My 6-core core i7-4930k overclocked to 4.2 GHz and making full use of hyperthreading only pulls off 1.1 FPS encoding this!
 
Last edited:
Mike Chambers said:
Trixter don't you think it would be cool to support this for higher-end 8088s? :)
Click to expand...

Yes, but like I said at the end of the presentation: If I had a true VGA in an 8088, I would probably have designed a completely different method. :)

If I really had a VGA in an 8088: VGA supports redefinable character fonts, and any color index can be one of 262,144 colors. So, I would likely stay at 40x25 but use a custom character set and change the 16-color palette every frame in addition to the screen data itself (and use a second video page to synchronize the display start of both the new data and new palette). For simplicity in the encoder, the custom character set would likely be many sets of hand-drawn "generics" (different shade patterns, hard and rounded "edges", lines, diagonally-split solid+shaded, etc.)... although it might be possible to generate an "optimal" character set by treating the entire video as grayscale and using vector quantization techniques to come up with a codebook. And if you really want to get fancy, send a new character set with every frame, although each set is 2K by itself, and I also don't know how long it takes to load a new character set.

The above would be much better than a "stock" 80x50 encode :)
 
Trixter said:
Yes, but like I said at the end of the presentation: If I had a true VGA in an 8088, I would probably have designed a completely different method. :)

If I really had a VGA in an 8088: VGA supports redefinable character fonts, and any color index can be one of 262,144 colors. So, I would likely stay at 40x25 but use a custom character set and change the 16-color palette every frame in addition to the screen data itself (and use a second video page to synchronize the display start of both the new data and new palette). For simplicity in the encoder, the custom character set would likely be many sets of hand-drawn "generics" (different shade patterns, hard and rounded "edges", lines, diagonally-split solid+shaded, etc.)... although it might be possible to generate an "optimal" character set by treating the entire video as grayscale and using vector quantization techniques to come up with a codebook. And if you really want to get fancy, send a new character set with every frame, although each set is 2K by itself, and I also don't know how long it takes to load a new character set.

The above would be much better than a "stock" 80x50 encode :)
Click to expand...

Yeah, as cool as that would be I think it may be going a little too far. Especially having one charset per frame! Hmm, how about EGA 80x43 text mode? ;)
 
vwestlife said:
Any possibility of getting 8088 Corruption to work with Tandy DAC audio?
Click to expand...

That would be awesome, and iirc the T-DAC has DMA and IRQ. I suspect it would involve a lot of work to mod the player for that, though. If Trixter isn't interested, maybe I can write a special Tandy player... I'll have to look up DAC programming info but that would be fun to try.
 
Mike Chambers said:
Yeah, as cool as that would be I think it may be going a little too far. Especially having one charset per frame! Hmm, how about EGA 80x43 text mode? ;)
Click to expand...

The irony is that my idea (2K charset + 2K frame data) is less data than an 80x43 frame (6.7K) while also looking a lot better. It's not all that crazy...
 
Mike Chambers said:
That would be awesome, and iirc the T-DAC has DMA and IRQ. I suspect it would involve a lot of work to mod the player for that, though. If Trixter isn't interested, maybe I can write a special Tandy player... I'll have to look up DAC programming info but that would be fun to try.
Click to expand...

I donated my last Tandy DAC system two years ago, so I don't have a Tandy TL/RL/SL to test with, sorry. But Mike is right, it has IRQ and DMA and so it's probably fairly easy to do.
 
Trixter said:
The irony is that my idea (2K charset + 2K frame data) is less data than an 80x43 frame (6.7K) while also looking a lot better. It's not all that crazy...
Click to expand...

It's not the frame size I was talking about, I meant writing an encoder that creates a best-match charset. Ouch!

A single generic charset would still look great though. With 256 characters to play with, that gives us a ton of choices. It would look amazing.
 
nestor said:
Played with it, and it works very well!

Click to expand...

I'm late, but very cool! That one came out pretty good! Just checked this thread after a long while... glad somebody got some use out of it. :)

Also, I'm curious... how long did it take to encode for you, and what are your hardware specs?
 
Last edited:
Mike Chambers said:
Something I've been working on recently. I did that really terrible VB6 encoder that I posted here years ago, but this new one is in C and is light years beyond it. I actually based it off Trixter's lecture this time. ;) The quality is really close to his original encoder, which was unfortunately never released.

I used the ffmpeg libs for source input, so it can accept practically any video file format and turn it into a TMV file. It can use up to 12 processing threads to speed things up on a multicore system. It's not that fast, I get about 5 FPS on my overclocked core i7-4930k but it does a pretty good quality encode. Two screenshots of it's encode of the Tron disc scene, and one of the Enterprise from the Star Trek TNG intro:

tmvenc.png


ST:TNG intro... Youtube kind of hurts the quality a bit.

Or download it to play on your XT: http://rubbermallet.org/tngintro-tmv.zip :D

Download the encoder here if you want to play with it: http://rubbermallet.org/tmvenc-0.14.2.14.zip

It's a command line app. Run tmvenc.exe -h to print out usage info. Have fun!
Click to expand...

Hi. Awesome encoder - wish I had the skills. I would love to speak with you about the encoding algorithm I am using for a TMV encoder. I will have two demo files to view shortly. I am struggling with getting the video stream data correct (trivial error, some colors inverted) but it is a horrible bug to find.

Anyway - your encoder is awesome since it has multi-thread support. Since I use temporal effects to create the effect of additional colors the computational complexity is an order of magnitude greater. Right now it is likely 3 full days to encode the discs sequence. I could use some help. Let me send you some stills via PM.
 
Are the stock CGA card characters all stored in a ROM on the card? Conceivably at least, could we replace that?
 
pearce_jj said:
Are the stock CGA card characters all stored in a ROM on the card? Conceivably at least, could we replace that?
Click to expand...

Absolutely. The ROM is even socketed and contains the two CGA fonts (selectable by a jumper), and the MDA font as well. Cards might have localized font ROMs from IBM, for example a font including the Nordic letters Ø and ø.

The type of ROM is however not of the typical 2764 kind, but rather the uncommon MK36000 kind.
 
chjmartin2 said:
Hi. Awesome encoder - wish I had the skills. I would love to speak with you about the encoding algorithm I am using for a TMV encoder. I will have two demo files to view shortly. I am struggling with getting the video stream data correct (trivial error, some colors inverted) but it is a horrible bug to find.

Anyway - your encoder is awesome since it has multi-thread support. Since I use temporal effects to create the effect of additional colors the computational complexity is an order of magnitude greater. Right now it is likely 3 full days to encode the discs sequence. I could use some help. Let me send you some stills via PM.
Click to expand...

Thanks. You're writing one too? Yeah, I'd love to see some stills. What language are you using, and what exactly are you doing with the temporal effects? Sounds interesting.
 
You must log in or register to reply here.
Back
Top