8088 MPH: We Break All Your Emulators • Hacker News Board

Re: 8088 MPH: We Break All Your Emulators

#11

Post by ajenner » Wed, Apr 08, 2015, 7:19 AM UTC

ekianjo wrote: post #8

corysama wrote: 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?

It certainly can be (and has been) used for games where a limited set of sprites are drawn - each frame of animation is just a separate compiled sprite routine. Compiled sprite routines write at video memory addresses relative to a specified position, so they can be moved around at will.

Re: 8088 MPH: We Break All Your Emulators

#12

Post by corysama » Wed, Apr 08, 2015, 7:19 AM UTC

ekianjo wrote: post #8

corysama wrote: 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?

IIRC, because of relative-address store instructions, the destination address does not have to be hard-coded. So, the sprites can still move around dynamically.

What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall back on a more complicated blitter.

The Allegro game framework had a compiled sprite jitter as a feature early on. So, that would be existence proof of them being used in games :) http://alleg.sourceforge.net/stabledocs/en/alleg016.html

Re: 8088 MPH: We Break All Your Emulators

#13

Post by Drakim » Wed, Apr 08, 2015, 7:19 AM UTC

ekianjo wrote: post #8

corysama wrote: 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?

It could probably be used for games as long as you keep within the bounds of your pixel data.

However, modern games use GPU acceleration instead of plotting the pixels with the CPU, and most higher languages don't expose the sort of functionality you need to use this trick in the first place.

Re: 8088 MPH: We Break All Your Emulators

#14

Post by enqk » Wed, Apr 08, 2015, 7:20 AM UTC

ekianjo wrote: post #8

corysama wrote: 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?

If you create code for each sprite and only change the base address to write to, you can use it for games alright. Jazz Jackrabbit is one that I've seen mentioned using compiled sprites. Lots of DOS games basically had to.

Re: 8088 MPH: We Break All Your Emulators

#15

Post by ekianjo » Wed, Apr 08, 2015, 7:21 AM UTC

geocar wrote: post #10

ekianjo wrote: post #8

Earlier quoted context omitted.

> 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?

Your game could dynamically modify the instructions.

Sure, but wouldn't that incur a loss of performance ?

Re: 8088 MPH: We Break All Your Emulators

#16

Post by ekianjo » Wed, Apr 08, 2015, 7:24 AM UTC

skrebbel wrote: post #9

ekianjo wrote: post #7

Earlier quoted context omitted.

> I wonder if youngsters who didn't grow up thinking 1 MHz is a perfectly acceptable CPU speed and that 640 KB is a whole lot of RAM will understand what the fuss is about here... They won't, and thus they don't understand the value of demos in the first place. But don't blame them, even back in the days I knew many people who could not appreciate demos either.

Stop generalizing. Plenty will.

> Stop generalizing. Plenty will.

Look at modern forum discussions on Smartphones, it's full of youngsters comparing specs of their respective phones without grasping at all what they mean. Or maybe you are referring to a highly educated subset of youngsters, but that's very few of them.

Re: 8088 MPH: We Break All Your Emulators

#17

Post by ekianjo » Wed, Apr 08, 2015, 7:26 AM UTC

blackhaz wrote: post #3

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

The Amiga had such tricks as well to display 4096 colors at the same time on screen while it could only display up to 32 specs wise. Not sure how they do it on PC, but there's probably a way to achieve it as well.

Re: 8088 MPH: We Break All Your Emulators

#18

Post by donkeyd » Wed, Apr 08, 2015, 7:28 AM UTC

jpatokal wrote: post #2

I found the raw video awesome enough to submit a few days ago, but the super-detailed explanation in this blog raises this to a whole new level of epic. I wonder if youngsters who didn't grow up thinking 1 MHz is a perfectly acceptable CPU speed and that 640 KB is a whole lot of RAM will understand what the fuss is about here...

As a guy who grew up coding Basic on a 4mhz MSX I have no idea what's going on here...

Re: 8088 MPH: We Break All Your Emulators

#19

Post by frooxie » Wed, Apr 08, 2015, 7:31 AM UTC

ekianjo wrote: post #17

blackhaz wrote: post #3

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

The Amiga had such tricks as well to display 4096 colors at the same time on screen while it could only display up to 32 specs wise. Not sure how they do it on PC, but there's probably a way to achieve it as well.

The 4096 color HAM mode was always part of the spec.

Re: 8088 MPH: We Break All Your Emulators

#20

Post by nitrogen » Wed, Apr 08, 2015, 7:34 AM UTC

corysama wrote: post #12

ekianjo wrote: post #8

Earlier quoted context omitted.

> 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?

IIRC, because of relative-address store instructions, the destination address does not have to be hard-coded. So, the sprites can still move around dynamically. What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall bac…

What's harder is clipping against the sides of the screen. With no branching, there's no way to prevent the sprite from writing past the end of a line/screen (wrapping/mem-stomping). So, there does need to be a test per sprite to detect that case and fall back on a more complicated blitter.

In fullscreen modes, you could also just make your screen buffer bigger than the actual screen by the width and height of your largest sprite.