Live data from Hacker News

8088 MPH: We Break All Your Emulators

trixter.oldskool.org

71–80 of 102 posts

Re: 8088 MPH: We Break All Your Emulators

#71
post #3

I can't believe my eyes. 256 colors on CGA?! HOW?!

the most impressive ascii art effect I ever saw was during movement. the minute it stops the motion blur goes away. in effect, I concluded I was looking at temporal antialiasing-like effects. (forget which demo it was, some 3d thing.) I wonder how much you could improve the effect (i.e. the woman after the 4:00 minute mark) by making it move. From the way it's drawn I'm not sure if you could get even 2 fps though.

I wanted to do some more impressive animation with the 1K color mode, but ran out of time unfortunately. One tricky part about doing animation with this mode is that it suffers from the "CGA snow" bug (visual glitching when writing to video memory). To avoid that by writing to video memory only during the vertical retrace/overscan period means that it would take about a quarter of a second to update the entire screen.

Re: 8088 MPH: We Break All Your Emulators

#72
post #60

The party this was released at had some absolutely mind-blowing stuff. The 8k and 64k competitions were amazing . The demoscene continues to be an astonishing force in computing. Some of the stuff would be completely at home as installation art in any top modern art museum. My favorite is https://www.youtube.com/watch?v=XF4SEVbxUdE done in 64kb! Here's the results with links to productions (most of them have youtube…

I think Chaos Theory still tops 64k.

https://www.youtube.com/watch?v=4DjBq2O0XXk

Re: 8088 MPH: We Break All Your Emulators

#73
post #68
post #51

Earlier quoted context omitted.

There are emulators (for other targets) which do emulate NTSC decoding properly, but until I did the research for this demo nobody understood how the CGA card generates composite signals well enough to be emulate it properly. I have some code which I hope to be adding to DOSBox (and any other emulators that want it) soon.

Do you know, how was the video uploaded to the YouTube made, if the emulators don't work? Was it really recorded with the plain camera?

We used a real PC obviously (my machine), and a capture device plugged into the NTSC composite output of the CGA card.

Re: 8088 MPH: We Break All Your Emulators

#74
post #57

Slight technical inaccuracy at the start: the Z80 also required a minimum of 4 clocks for a memory access, it wasn't better than the 8088 in that regard.

Not sure why you are referring to the Z80? We compare against C64, which uses a 6510 (6502-derivative), not a Z80.

Re: 8088 MPH: We Break All Your Emulators

#76
post #8
post #5

Quick explanation of compiled sprites: Most commonly a sprite is represented as a 2d array of pixels that you for X, for Y over and use math or branching to blend on to the screen. But, that's a lot of reading and writing, and a lot of the math ends up doing nothing because a lot of the pixels are intentionally invisible. So, you could do some sort of visible/invisible RLE to skip over the invisible pixels. That's be…

> it becomes a read instruction, write data in two straight lines in memory. So basically this kind of hack could not be used for a game, then, where interaction is needed?

Even the very first digital video game (Spacewar!) used something very much alike (Dan Edwards' outline compiler). Movable and rotatable – think of advancing by unit vectors –, compiled just in time from directional encodings. Read more at: http://www.masswerk.at/spacewar/inside/insidespacewar-pt4-oc...

Re: 8088 MPH: We Break All Your Emulators

#77
post #71

Earlier quoted context omitted.

the most impressive ascii art effect I ever saw was during movement. the minute it stops the motion blur goes away. in effect, I concluded I was looking at temporal antialiasing-like effects. (forget which demo it was, some 3d thing.) I wonder how much you could improve the effect (i.e. the woman after the 4:00 minute mark) by making it move. From the way it's drawn I'm not sure if you could get even 2 fps though.

I wanted to do some more impressive animation with the 1K color mode, but ran out of time unfortunately. One tricky part about doing animation with this mode is that it suffers from the "CGA snow" bug (visual glitching when writing to video memory). To avoid that by writing to video memory only during the vertical retrace/overscan period means that it would take about a quarter of a second to update the entire screen…

Is the CGA snow bug deterministic? Or at least model-able?

Re: 8088 MPH: We Break All Your Emulators

#78
post #54

Earlier quoted context omitted.

In my game engine I wrote for the Apple IIgs a long time ago, I used compiled sprites and maintained a 1-scanline-wide mask that I used to clip the compiled sprite to the screen edge. This only cost one extra AND instruction and allowed the sprites to be clipped to any size rectangular playfield while still maintaining almost all of the speed benefits.

That's actually cool, as it would also allow clipping against a "foreground" by varying the address of the scanline mask. E.g. imagine foreground trees in a jungle scene.

Exactly!

I did extend it to use a full-screen foreground mask that implemented this sort of clipping. I was able to make the mask scrollable which allowed the compiled sprites to appear "behind" fences and other complex shapes with per-pixel accuracy.

It could even be used to mask out individual pixel bits that allowed for fake "lighting" changes with a carefully chosen palette.

Re: 8088 MPH: We Break All Your Emulators

#79
post #71

Earlier quoted context omitted.

I wanted to do some more impressive animation with the 1K color mode, but ran out of time unfortunately. One tricky part about doing animation with this mode is that it suffers from the "CGA snow" bug (visual glitching when writing to video memory). To avoid that by writing to video memory only during the vertical retrace/overscan period means that it would take about a quarter of a second to update the entire screen…

Is the CGA snow bug deterministic? Or at least model-able?

Totally deterministic. I think there's even an emulator which models it (though without a cycle-exact emulation of the CPU the snow won't be in the same places as on real hardware).

Re: 8088 MPH: We Break All Your Emulators

#80
post #74
post #57

Slight technical inaccuracy at the start: the Z80 also required a minimum of 4 clocks for a memory access, it wasn't better than the 8088 in that regard.

Not sure why you are referring to the Z80? We compare against C64, which uses a 6510 (6502-derivative), not a Z80.

Oh nevermind, I thought you were referring to the intro screen of the demo... but there is something about Z80 in the article.
Post reply on HN