8088 MPH: We Break All Your Emulators
trixter.oldskool.org
8088 MPH: We Break All Your Emulators
1–10 of 102 posts
Re: 8088 MPH: We Break All Your Emulators
#2I 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...
Re: 8088 MPH: We Break All Your Emulators
#3I can't believe my eyes. 256 colors on CGA?! HOW?!
Re: 8088 MPH: We Break All Your Emulators
#4I 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...
You know you've seen something special when the only thing you can think to say afterwards is "But it isn't supposed to do that...".
Re: 8088 MPH: We Break All Your Emulators
#5Quick 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 better, but it's still a complicated loop and still a lot of reading pixels.
So, many crazy democoders have decided to write "sprite compilers" that read the 2D color array of a sprite and spits out the assembly for the exact instructions needed to write each visible pixel one at a time as a linear instruction sequence with no branching. The sprites are then assembled and linked into the program code as individual functions. I believe they can even exclusively use immediate values encoded inside the instructions rather than reading the colors from a separate memory address. So, rather than read instruction, read data, write data; it becomes a read instruction, write data in two straight lines in memory.
Re: 8088 MPH: We Break All Your Emulators
#6This is the coolest thing I've seen all year, way to go to everyone involved!
Re: 8088 MPH: We Break All Your Emulators
#7I 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...
> 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.
Re: 8088 MPH: We Break All Your Emulators
#8Quick 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?
Re: 8088 MPH: We Break All Your Emulators
#9I 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...
> 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.
Re: 8088 MPH: We Break All Your Emulators
#10Quick 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?
Your game could dynamically modify the instructions.