Linked by Thom Holwerda on Wed 6th Jan 2016 12:20 UTC
General Development

So, Castlevania: Symphony of the Night is one of my favourite games of all time, and it's also generally considered to be one of the best games ever made. And, as with all games, people 'speedrun' this game, which means trying to beat the game as fast as is humanly possible. There are several categories, each with certain rules and things that are and are not allowed.

This particular speedrun of Symphony Of The Night by Cosmo takes this concept to a whole new level. The end time of 7 minutes and 52 seconds is mind-blowing enough, but how he actually gets there is just utterly insane. Basically, he procures a very specific set of items in his inventory, and then proceeds to manipulate the items in his inventory in a extremely specific way, within very specific fractions of seconds of game-time, to use the sorting mechanism of the inventory to manipulate the assembly code in memory to make the game finish itself. All this, on the actual console itself, without tools, without additional software, without emulators, without anything.

The actual science or coding behind this technique was discovered and developed by a person named Sockfolder, and he put up a 40-minute stream to explain in detail what's going on, with the contents of memory on the side of the screen so you can see exactly what's happening. It's mesmerising (even though I don't fully understand what's going on).

While the actual coding part of it can be discovered and explored in relative comfort of an emulator and other tools, actually pulling this off 'live', with just the tools at the disposal of any regular player, is absolutely amazing. This kind of stuff sits at the very fringes of programming, and I find it incredibly impressive.

Order by: Score:
Comment by Kroc
by Kroc on Wed 6th Jan 2016 12:42 UTC
Kroc
Member since:
2005-11-10

In speedrunning this is known as Arbitrary Code Execution. It's somewhat common on 8-bit titles because of the easy mapping of game variables to 8-bit assembly opcodes (only 0-255 to deal with), but doing arbitrary code execution on a 32-bit machine? That's bonkers!

Here's a video of Super Mario Bros. being created within Super Mario World! https://youtu.be/YHyaTCuZRzM?t=3m53s

Reply Score: 5

RE: Comment by Kroc
by Drumhellar on Wed 6th Jan 2016 19:40 UTC in reply to "Comment by Kroc"
Drumhellar Member since:
2005-07-12

In speedrunning this is known as Arbitrary Code Execution. It's somewhat common on 8-bit titles because of the easy mapping of game variables to 8-bit assembly opcodes (only 0-255 to deal with), but doing arbitrary code execution on a 32-bit machine? That's bonkers!

Here's a video of Super Mario Bros. being created within Super Mario World! https://youtu.be/YHyaTCuZRzM?t=3m53s


Wow. That is supremely cool.

Reply Score: 3

Pretty Hard Core
by FortranMan on Wed 6th Jan 2016 13:53 UTC
FortranMan
Member since:
2011-12-21

That's some pretty crazy manipulation of commercial software. I'm struck by how fragile some of the game code seems to be. Maybe this is a result of very careful optimization for limited hardware?

Reply Score: 4

RE: Pretty Hard Core
by Kroc on Wed 6th Jan 2016 14:52 UTC in reply to "Pretty Hard Core"
Kroc Member since:
2005-11-10

I would say it was more of a reflection of the C programming language and development processes in 1997. The code is written to do exactly as intended with not a bounds-check in sight! There was no concept of 'error handling' on a console; either the code works, or it doesn't. ;)

Reply Score: 2

RE[2]: Pretty Hard Core
by teco.sb on Wed 6th Jan 2016 15:35 UTC in reply to "RE: Pretty Hard Core"
teco.sb Member since:
2014-05-08

Is it a reflection of the C language or of the practices? Error handling and bounds checking is an expensive proposition, but today the benefits outweight the performance hit. Back then, I'm not so sure. Error handling required additional code and RAM. And bounds checking require a compare/branch instruction, which used to be even slower than it is today.

All that said, I agree with the original statement that this is a result of the limited hardware of the time and the optimizations that needed to be done.

Reply Score: 2

RE[3]: Pretty Hard Core
by JLF65 on Wed 6th Jan 2016 18:19 UTC in reply to "RE[2]: Pretty Hard Core"
JLF65 Member since:
2005-07-06

If you look at the source code for Doom, there are range and bound checks in the code with conditional compilation defines. The code slows the game, so you only use it in the testing phase. For the final release, you disable the checking code for best speed, also leaving more ram for game data. This was needed on computers that ran at much less than 100 MHz and maybe had 4 MBytes of ram. Today's computers have infinite speed and memory compared to those old systems. The kinds of errors you get on modern games are of a completely different sort.

Reply Score: 3

RE[4]: Pretty Hard Core
by Kochise on Wed 6th Jan 2016 19:54 UTC in reply to "RE[3]: Pretty Hard Core"
Kochise Member since:
2006-03-03

Yeah, something like "Explorer (or Firefox) is not responding, wait until the application responds, close the program, get lost"

Reply Score: 2

RE[3]: Pretty Hard Core
by Alfman on Wed 6th Jan 2016 21:46 UTC in reply to "RE[2]: Pretty Hard Core"
Alfman Member since:
2011-01-28

teco.sb,

Is it a reflection of the C language or of the practices? Error handling and bounds checking is an expensive proposition, but today the benefits outweight the performance hit. Back then, I'm not so sure.


The existence of these exploits on consoles is not really surprising to me. Unsafe languages like C have always been dangerous and more often than not programmers will make some bad assumptions like an off by one error or overflow somewhere and boom, there's an exploit.

I find it unfortunate we didn't have something like rustlang in place of C as a defacto platform programming language. If rustlang had been around back in the 70s/80s, all languages after it would have undoubtedly had zero cost semantics for guarantying no overflows or segfaults. Today virtually all our low level code (and alot of fairly high level stuff too) is based on C, and virtually all of it has to worry about being exploited.

Reply Score: 2

RE[4]: Pretty Hard Core
by teco.sb on Wed 6th Jan 2016 23:08 UTC in reply to "RE[3]: Pretty Hard Core"
teco.sb Member since:
2014-05-08

I think you're putting too much stock on the language itself. Any program can have exploits, regardless of the language it was written in.

I've read multiple articles comparing C with "portable assembly". It just let's you do whatever and doesn't judge you for doing it. I'm pretty sure that's why people use and/or like C.

I remember, a while back, reading an article here about some recently open sourced code from a 70s system. Anyway, in order to optimize the code, the programmer had taken advantage of the spinning disk's latency to do some additional work while disk was seeking to the correct memory location. The programmer knew exactly how nanny cycles it would take for each disk operation and fill those dead cycles with instructions. It was all done in assembly, of course. I don't remember the article in detail, but that was the reality back then. You did what you had to.

Edited 2016-01-06 23:08 UTC

Reply Score: 3

RE[5]: Pretty Hard Core
by Earl Colby pottinger on Thu 7th Jan 2016 00:49 UTC in reply to "RE[4]: Pretty Hard Core"
Earl Colby pottinger Member since:
2005-07-06

Had to do that for a condo management program I wrote in BASIC, as sectors were read the following sector was on the opposite side of the disk (ie read sector 1 and you had half a rotation of the disk to process then read sector 2).

Thus to do things like the month-end accounting or print out a list of delinquent payments you have to get a 1 MHz 8 Bit machine to do the calculations before that half rotation took place, or take THREE times as long to do the same work.

I almost sweated blood finding methods to speed up some functions to stay in the time limits.

At the time I had 32K of RAM (Commodore 8032) while working with 1 Meg (8250) floppies, there was no way to buffer the reads to RAM.

Reply Score: 4

RE[5]: Pretty Hard Core
by Alfman on Thu 7th Jan 2016 02:09 UTC in reply to "RE[4]: Pretty Hard Core"
Alfman Member since:
2011-01-28

teco.sb,

I think you're putting too much stock on the language itself. Any program can have exploits, regardless of the language it was written in.

I've read multiple articles comparing C with "portable assembly". It just let's you do whatever and doesn't judge you for doing it. I'm pretty sure that's why people use and/or like C.


C took shape in the 70s when building unix. Back then they were only thinking of building C to replace assembly. It's not perfect mind you; Consider that it's more difficult to test for overflow in C than it is in assembly, which is ironic. The lack of access to overflow flags still leaves a lot to be desired with some numeric algorithms. But all in all C does a pretty good job and had obvious advantages. But over time C would be used more and more due to it's role in legacy software than the actual merits of the language.

This has left us in a state of encountering the same infuriating C/C++ safety problems over, and over (and over...) again. Experienced C programmers are all too familiar with these, but we continue to use C anyways because that's what one uses for systems development, and that's just the way it goes. I'm a long time C/C++ user as well, and even I'm using C++ over Rust in a recent project. It's not really because C/C++ is better, quite the contrary, but there are billions of man hours are vested in C, replacing it is formidable, it may not be economically viable at all...

Rust is a good example of what an alternative could look like. Unlike most contemporary languages, it was specifically designed for systems development. It can correct many of C's mistakes because it has the benefit of hindsight. Like C, it lets you do whatever you want, but unlike C it's safe by default. This means that all dangerous code is tagged with unsafe markup, which makes it easy to grep for and makes it much easier to find code responsible for faults. If only C could have had these features, software would be much more robust today!

Beyond safety, other aspects of C/C++ development like header files are downright lousy. But once again they were developed for a time when software was much simpler. There will be differing opinions on whether C has aged well, but one thing is very clear: the lack of safety semantics in C has been one of the main culprits of software instability over the many decades of it's use.

Rest in peace, C. Long live C.

Reply Score: 2

RE[6]: Pretty Hard Core
by moondevil on Thu 7th Jan 2016 07:22 UTC in reply to "RE[5]: Pretty Hard Core"
moondevil Member since:
2005-07-08

took shape in the 70s when building unix. Back then they were only thinking of building C to replace assembly.


While ignoring safer systems programming languages like Burroughs' Algol variant (1961), CPL (1963), PL/I (1966), Mesa (1976), Modula-2 (1978), ...

Just like now Go ignores current modern language features. Everything old is new again.

Reply Score: 2

RE[7]: Pretty Hard Core
by Bill Shooter of Bul on Thu 7th Jan 2016 14:33 UTC in reply to "RE[6]: Pretty Hard Core"
Bill Shooter of Bul Member since:
2006-07-14

Well, Go & C share an author, so it isn't really that surprising.

Reply Score: 2

RE[5]: Pretty Hard Core
by Vanders on Thu 7th Jan 2016 13:20 UTC in reply to "RE[4]: Pretty Hard Core"
Vanders Member since:
2005-07-06

I remember, a while back, reading an article here about some recently open sourced code from a 70s system. Anyway, in order to optimize the code, the programmer had taken advantage of the spinning disk's latency to do some additional work while disk was seeking to the correct memory location.

The Story Of Mel? http://www.catb.org/jargon/html/story-of-mel.html

Reply Score: 3

RE: Pretty Hard Core
by CaptainN- on Thu 7th Jan 2016 16:24 UTC in reply to "Pretty Hard Core"
CaptainN- Member since:
2005-07-07

They aren't doing 100 exploits here. They are using the game state to set up memory so that it looks like a program (all memory is just bitmaps, even executable memory), then they are using 1 exploit to execute that program. It's the same trick so many hacks on the internet use, which is why security holes in Flash or Java, or whatever else on the net are so catastrophic.

Reply Score: 3

RE[2]: Pretty Hard Core
by Alfman on Thu 7th Jan 2016 17:09 UTC in reply to "RE: Pretty Hard Core"
Alfman Member since:
2011-01-28

CaptainN-,

They aren't doing 100 exploits here. They are using the game state to set up memory so that it looks like a program (all memory is just bitmaps, even executable memory), then they are using 1 exploit to execute that program.


Perhaps this would have been a good reason to favor a Harvard Architecture CPU design, to eliminate the possibility of code getting stepped on by leaky data structures.

https://en.wikipedia.org/wiki/Harvard_architecture

x86 can support something similar with read only code segments since the introduction of 386 protected mode, but I'm not aware of any operating systems that have taken advantage of it. Operating systems only started to support this at the page level when amd introduced x86-64.

https://en.wikipedia.org/wiki/NX_bit

Reply Score: 3

I love it..
by uridium on Wed 6th Jan 2016 16:32 UTC
uridium
Member since:
2009-08-20

I really enjoy these sorts of things and tear-downs.

Moar plz!! ;)

Reply Score: 2

Comment by IgnitusBoyone
by IgnitusBoyone on Wed 6th Jan 2016 17:00 UTC
IgnitusBoyone
Member since:
2007-02-07

Very impressive. A unique looking version of this type of program stack manipulation can be scene for the Super Mario World.


https://www.youtube.com/watch?v=gECESOoU8Es

It takes an amazing amount of analytical work just to find these bugs, but to practice an implement them on the original hardware is equally non trivial.

Thanks for the video.

Reply Score: 2

Comment by jonnyvice
by jonnyvice on Wed 6th Jan 2016 18:11 UTC
jonnyvice
Member since:
2013-06-20

"and it's also generally considered to be one of the best games ever mad"

*cough* horseshit! *cough*

Super Metroid puts Castlevania to shame in every way possible. Castlevania will play second fiddle to Super Metroid throughout eternity.

Reply Score: 1

RE: Comment by jonnyvice
by Thom_Holwerda on Wed 6th Jan 2016 18:24 UTC in reply to "Comment by jonnyvice"
Thom_Holwerda Member since:
2005-06-29

"and it's also generally considered to be one of the best games ever mad"

*cough* horseshit! *cough*

Super Metroid puts Castlevania to shame in every way possible. Castlevania will play second fiddle to Super Metroid throughout eternity.


You do realise two games can both be "one of the best", right?

Super Metroid is the other half of the 'Metroidvania' genre of games, with a different focus. Some people will prefer SOTN, others will prefer Super Metroid. The idea that one is better than the other is kind of idiotic.

Reply Score: 3

RE[2]: Comment by jonnyvice
by jonnyvice on Wed 6th Jan 2016 18:28 UTC in reply to "RE: Comment by jonnyvice"
jonnyvice Member since:
2013-06-20

I guess it didn't come out in the text, I was attempting to be facetious a la High Fidelity https://www.youtube.com/watch?v=pc3TYIIpOZM

But Metroid is still better... ;)

Reply Score: 1

RE[3]: Comment by jonnyvice
by Thom_Holwerda on Wed 6th Jan 2016 18:33 UTC in reply to "RE[2]: Comment by jonnyvice"
Thom_Holwerda Member since:
2005-06-29

Haha alright, sorry! Both are awesome games ;) .

Reply Score: 1

RE: Comment by jonnyvice
by IgnitusBoyone on Wed 6th Jan 2016 21:06 UTC in reply to "Comment by jonnyvice"
IgnitusBoyone Member since:
2007-02-07

Funny,

Super Metroid is one of my fav games, but in just terms of scale I think the game has maybe 9 bosses. SoTN has at least 30 and around 130 enemies. The scale of the game is just mind boggling. Not to mention I believe the native resolution of the tiles is far beyond any of its sequels.

I saw a mod of SM yesterday that rotates the entire world by 90 degrees. I am planning on picking it up to see it changes the game.

Reply Score: 1

RE[2]: Comment by jonnyvice
by jonnyvice on Wed 6th Jan 2016 21:57 UTC in reply to "RE: Comment by jonnyvice"
jonnyvice Member since:
2013-06-20

I'd say quantity doesn't equal to quality, but it was badly based on a joke.

I'm definitely in the Metroid>Castlevania camp however and while SotN definitely won in terms of scale, most of that scale was utterly forgettable as a player. I'm sure this comes down to taste and the weight of the nostalgia.

The craftsmanship of Super Metroid is where I feel it excels above and beyond anything SotN has to offer.

Native resolution isn't surprising considering the hardware targeted.

That mod sounds pretty interesting, I'll definitely check it out. Be sure to check out AM2R if you haven't already: https://www.youtube.com/watch?v=sUIfPKdf39I

Reply Score: 1

RE[3]: Comment by jonnyvice
by Morgan on Wed 6th Jan 2016 23:44 UTC in reply to "RE[2]: Comment by jonnyvice"
Morgan Member since:
2005-06-29

Speaking strictly of my own tastes and preferences, what makes Castlevania: SOTN (and most of the Castlevania series) more enjoyable is the music and atmosphere. I'm a Metroid fan too, but Castlevania and especially SOTN just comes together as a more enjoyable experience for me. It doesn't hurt that, just as with playing Final Fantasy III (VI outside the US) with my brother, playing SOTN with my best friend made for some of the dearest memories of my teens and early 20s. She and I still talk about the game to this day.

As Thom said above, both are great game series and one isn't inherently "better" than the other. I'm hoping that Bloodstained: Ritual of the Night[1] lives up to the hype and becomes another great Metroidvania game.

[1] https://www.kickstarter.com/projects/iga/bloodstained-ritual-of-the-...

Reply Score: 2

RE[4]: Comment by jonnyvice
by Kochise on Thu 7th Jan 2016 06:03 UTC in reply to "RE[3]: Comment by jonnyvice"
Kochise Member since:
2006-03-03
RE: Comment by jonnyvice
by matthekc on Sat 9th Jan 2016 09:56 UTC in reply to "Comment by jonnyvice"
matthekc Member since:
2006-10-28

I don't know about best but I like Super Mario Allstars (Mario 3 is my fave), Zombies ate my neighbors, and Killer instinct (graphics aged poorly). Super Metroid was good but a bit of a grind to find most of the stuff.

Reply Score: 2

Comment by ilovebeer
by ilovebeer on Wed 6th Jan 2016 22:22 UTC
ilovebeer
Member since:
2011-08-08

That video, while about an interesting topic, was painful to watch. Someone else should narrate next time.

Reply Score: 2