Yuji Naka explanation about NIGHTS engine and Sonic X-treme accusations

derrickchase said:
People were lamenting a bygone era of warrior-poet programmers that never actually existed. I'm just trying to remind everyone that programmers are actually BETTER today than they were back then.
Click to expand...
Seriously. Yuji Naka remarking that he coded his engine in assembly is a nothingburger and only matters to him through assuming that everyone else around him is just too stupid to figure things out. It perfectly speaks to Yuji Naka's arrogance and that for some reason, everyone else always seems to be the problem and he is always the victim.

But then, Sega enabled his shitty behavior the moment they gave him a ferrari to appease and rehire him after he quit in the 90s. No wonder he is so self-important.
 
derrickchase said:
People were lamenting a bygone era of warrior-poet programmers that never actually existed. I'm just trying to remind everyone that programmers are actually BETTER today than they were back then.
Click to expand...
Read: Dying on the hill and noising up an otherwise relatively enjoyable thread by tilting at windmills.
 
thicc_girls_are_teh_best said:
This guy's got some brass balls.



Wasn't uncommon for Sega's top programmers back in the day; Yu Suzuki also programmed the original Virtua Fighter engine in assembly language for the Model 1 arcade hardware. Back then if you wanted the best performance from gaming consoles and most types of hardware, you needed to code at least the most critical parts in assembly.

Very small steps away from that and moving certain parts to C started with some games on MegaDrive/SNES, but the PS1 liberated a big chunk of programming dependence from assembly and moved it towards C language with their SDKs and APIs. Still though, the best-performing games still needed to optimize critical parts of their engines in assembly, but that gradually lessened with each successive console generation, and assembly pretty much became completely niche once we got to PS4/XBO.



For outsiders enthralled reading about exotic console architectures and the programming feats to get impressive results from them, yes the move away from assembly and handling most game logic "coded to the metal" sucks, but for actual programmers in the field today who have extensive assembly experience or were in the industry back in the 16-bit/32-bit/6th-gen etc. days, they probably do a little dance every morning in celebration.
Click to expand...
Yeah well I would have expected game development to have moved to C like you said about PS1 game development with only critical parts being done in assembly.. Not all of the game code!

It must have been a big enough pain in the ass to write Genesis games or even NES games in assembly, but whole Saturn games with the dual CPUs and what not. Yikes!
 
Shifty said:
Read: Dying on the hill and noising up an otherwise relatively enjoyable thread by tilting at windmills.
Click to expand...

Yeah I'm dying on that hill so much that other people are agreeing with me (Including actual game devs like John Carmack. Go ask him. He'll tell you that game devs are better than they were in the 90s, too).
 
derrickchase said:
People were lamenting a bygone era of warrior-poet programmers that never actually existed. I'm just trying to remind everyone that programmers are actually BETTER today than they were back then.
Click to expand...
But that's not true. today there is so much built in error handling to hardware level functions and easy to use libs. It's not the same.
Back then you had nothing. You started with zero. You could Destroy the hardware if you didn't know what you were doing.

And also it wasn't until the 32bit era that doing simple multiplication and division didn't completely tank your cpu. Programmers had to use tricks like bit shifting to quickly times numbers by a factor of 2. The nes cpu for example had only two instructions ROL And ROR to shift bits left or right for x 2 multiplication and division

A lot of what seemed like impressive trigonometry were just static tables of pixel positions played out like a tape. This was possible because of the low resolution of old consoles but took a lot of storage space.

But then you had programmers like cerny, yuji naka , mark betteridge ( battle toads) , and Jon button ( toy story on 16 bit consoles) that were doing crazy math and pushing limits on 8bit and 16bit systems.

Todays game programmers have no such limitations of basic functionality. They don't even think twice about such things because they don't have to.
You want to times a number by 3 just write x * 3.

On the nes to times something by three you needed 2 bytes for the final value. 2 bytes for temp values. You could ror the lower byte to save cycles then carry the remainder to the upper byte while finally just adding the initial value one more time while again checking for the carry.

Or you could do it the slow way and use the x register to loop and add the values 3 times while checking the carry each time.

Oh and if you went over 512 using the two byte method your calculation would flip to 0 and be useless. Do you want decimals? Then you need another byte or two.

Now take that little bit of knowledge and do rudimentary physics and collision on those consoles.
 
RoboFu said:
But that's not true. today there is so much built in error handling to hardware level functions and easy to use libs. It's not the same.
Back then you had nothing. You started with zero. You could Destroy the hardware if you didn't know what you were doing.

And also it wasn't until the 32bit era that doing simple multiplication and division didn't completely tank your cpu. Programmers had to use tricks like bit shifting to quickly times numbers by a factor of 2. The nes cpu for example had only two instructions ROL And ROR to shift bits left or right for x 2 multiplication and division

A lot of what seemed like impressive trigonometry were just static tables of pixel positions played out like a tape. This was possible because of the low resolution of old consoles but took a lot of storage space.

But then you had programmers like cerny, yuji naka , mark betteridge ( battle toads) , and Jon button ( toy story on 16 bit consoles) that were doing crazy math and pushing limits on 8bit and 16bit systems.

Todays game programmers have no such limitations of basic functionality. They don't even think twice about such things because they don't have to.
You want to times a number by 3 just write x * 3.

On the nes to times something by three you needed 2 bytes for the final value. 2 bytes for temp values. You could ror the lower byte to save cycles then carry the remainder to the upper byte while finally just adding the initial value one more time while again checking for the carry.

Or you could do it the slow way and use the x register to loop and add the values 3 times while checking the carry each time.

Oh and if you went over 512 using the two byte method your calculation would flip to 0 and be useless. Do you want decimals? Then you need another byte or two.

Now take that little bit of knowledge and do rudimentary physics and collision on those consoles.
Click to expand...
Good comment. I am currently developing a game on Game Gear in C (having started with some assembly at first), the compiler doing some pretty good things for me, but I am not even thinking of doing an elaborated action game with per pixel precise collisions and scrolling. It requires a tremendous amount of work to achieve this and working directly in assembly, which can be extremely abstract. I made a proof of concept for a Phantasy Star II game and managed to have scrolling, collision and smooth movement on a 16 by 16 pixels basis. As well as dynamically merging monsters over the background. This was already a pretty great achievement for me.

The Z80 does not support multiplication or division, and of course you don't have anything such as a modulo operation. And this is something you need to use a lot actually. When managing VRAM you have to modulo by 256 and 228. The first one is pretty easy : you simple use the natural overlap of a byte. However the second one requires coding. To keep good performance I actually had to use ifs and add/substract 228 manually. This avoids any division. Then you have to modulo the scroll screen position, which will relate to the resolution of 160 x 144. Optimizing is very important and even though I work in C for simplicity, it is still important to understand the specifics of the hardware and avoid costly operations and useless whiles/fors.

This is only one topic among a ton of others, such as ROM organization (with almost mandatory banking on 8 bits consoles) and very tight VRAM management. Most people don't even realize that the virtual screen in the VRAM barely contains anything more than what is displayed on screen, and that everything has to be streamed real-time.
 
existensmaximum said:
What.. Wait. He codes the whole game NIGHTS in fucking Assembly!? 😳😳😳😵‍💫

The skill of that guy
Click to expand...
That's why the Saturn was "A Coder's Machine", to get the most out of all that silicon you were best off using Assembly. I think it's fair to say that Sega of that time had some of the best "to the metal" coding staff around.
 
AREYOUOKAY? said:
Bfj8SqT.png
Click to expand...
What are these screenshots ?
 
RoboFu said:
But that's not true. today there is so much built in error handling to hardware level functions and easy to use libs. It's not the same.
Back then you had nothing. You started with zero. You could Destroy the hardware if you didn't know what you were doing.

And also it wasn't until the 32bit era that doing simple multiplication and division didn't completely tank your cpu. Programmers had to use tricks like bit shifting to quickly times numbers by a factor of 2. The nes cpu for example had only two instructions ROL And ROR to shift bits left or right for x 2 multiplication and division

A lot of what seemed like impressive trigonometry were just static tables of pixel positions played out like a tape. This was possible because of the low resolution of old consoles but took a lot of storage space.

But then you had programmers like cerny, yuji naka , mark betteridge ( battle toads) , and Jon button ( toy story on 16 bit consoles) that were doing crazy math and pushing limits on 8bit and 16bit systems.

Todays game programmers have no such limitations of basic functionality. They don't even think twice about such things because they don't have to.
You want to times a number by 3 just write x * 3.

On the nes to times something by three you needed 2 bytes for the final value. 2 bytes for temp values. You could ror the lower byte to save cycles then carry the remainder to the upper byte while finally just adding the initial value one more time while again checking for the carry.

Or you could do it the slow way and use the x register to loop and add the values 3 times while checking the carry each time.

Oh and if you went over 512 using the two byte method your calculation would flip to 0 and be useless. Do you want decimals? Then you need another byte or two.

Now take that little bit of knowledge and do rudimentary physics and collision on those consoles.
Click to expand...

Nope. Everything you said tells me that you don't even have a glimmer of an understanding. Writing programs in assembly just isn't that big of a deal on those old, simple CPUs. And that's also ignoring the fact that a lot of the boiler plate for games was "write once, copy and paste 18 trillion times." Capcom used the basic code for Final Fight and Street Fighter 2 like 27 times.

You guys are vastly overestimating how hard it was to make those simple games and vastly underestimating how complex it is to make a modern game that has exponentially more going on--where games actually have internet multiplayer, have to actually worry about security issues, etc. Code is more complicated and code quality is generally much higher.

Anyone who actually understands computer science will tell you that programming isn't hard. It's actually really simple, and the simpler you get (ie. assembly), the more straightforward it actually is. Complicated languages like C++ are actually HARDER than assembly. NO, the actual "hard" part is understanding more advanced math and physics to make more complex modern games.
 
Last edited:
SirTerry-T said:
That's why the Saturn was "A Coder's Machine", to get the most out of all that silicon you were best off using Assembly. I think it's fair to say that Sega of that time had some of the best "to the metal" coding staff around.
Click to expand...

The other comments on this thread demonstrate how challenging it was to write Assembly code for classic consoles and home computers. Programmers always needed to think outside the box and come up with inventive solutions to problems.

As always, I highly recommend the book Racing the Beam, which discusses how programmers made the Atari 2600 work well beyond its "official" limits.

As for Sega Saturn, it is well known to be a hardcore coder's machine, made for Assembly and best exploited by demoscene coders & programmers used to working with parallel processors. It was far less suited to C programming, although the Sega Graphics Libraries helped this somewhat.
 
DT MEDIA said:
The other comments on this thread demonstrate how challenging it was to write Assembly code for classic consoles and home computers. Programmers always needed to think outside the box and come up with inventive solutions to problems.

As always, I highly recommend the book Racing the Beam, which discusses how programmers made the Atari 2600 work well beyond its "official" limits.

As for Sega Saturn, it is well known to be a hardcore coder's machine, made for Assembly and best exploited by demoscene coders & programmers used to working with parallel processors. It was far less suited to C programming, although the Sega Graphics Libraries helped this somewhat.
Click to expand...

It's funny because books like "Racing the Beam" are literally the contemporary version of "I walked 20 miles to school every day in the snow."

It isn't a big deal. Mike Abrash has commented on it several times because he's not an ego case who tries to pretend he's wearing a bigger pair of pants than he is.
 
cireza said:
Awesome. Send me a port of Bayonetta for the MegaDrive. You are allowed to lower the resolution. With how awesome you are, it should take a couple days at most ?

Looking forward to the ROM.


About this... I just gave a call to John. He told me derick who ?
Click to expand...

It'll be about as good as the terrible version of VF2 for the Genesis. Huh. It's almost like they weren't any better in the 90s.
 
cireza said:
This was actually a very impressive port for the console. But how about you stop derailing the thread and bring your hate boner somewhere else ?
Click to expand...

Nah, it wasn't impressive at all. It was exactly the only way you could have ported it to the Genesis. Funny, isn't it, how games are most often whatever the obvious solution would have been.

This thread is basically dead anyway. Yuji Naka is Yuji Naka, so he has to say something stupid every so often. This thread could have started and ended with:

maxresdefault.jpg


I'm not derailing the thread. I'm not the one who started erroneously fawning over what a programming genius Yuji Naka was--I just responded to it.
 
derrickchase said:
Nah, it wasn't impressive at all. It was exactly the only way you could have ported it to the Genesis. Funny, isn't it, how games are most often whatever the obvious solution would have been.

This thread is basically dead anyway. Yuji Naka is Yuji Naka, so he has to say something stupid every so often. This thread could have started and ended with:

maxresdefault.jpg


I'm not derailing the thread. I'm not the one who started erroneously fawning over what a programming genius Yuji Naka was--I just responded to it.
Click to expand...
At least, he did not need a Memory Expansion Pack to make Nights runs.
 
derrickchase said:
Nah, it wasn't impressive at all. It was exactly the only way you could have ported it to the Genesis. Funny, isn't it, how games are most often whatever the obvious solution would have been.

This thread is basically dead anyway. Yuji Naka is Yuji Naka, so he has to say something stupid every so often. This thread could have started and ended with:

maxresdefault.jpg


I'm not derailing the thread. I'm not the one who started erroneously fawning over what a programming genius Yuji Naka was--I just responded to it.
Click to expand...
Let me guess....it was Naka who was sitting in on that interview you had for that coding vacancy at Sega.
Right?!?
 
derrickchase said:
Nah, it wasn't impressive at all. It was exactly the only way you could have ported it to the Genesis. Funny, isn't it, how games are most often whatever the obvious solution would have been.
Click to expand...
You have no clue what you are talking about, but it was pretty obvious from the beginning anyway.

We all understand that Yuji Naka touched you somewhere, but keep in mind that he did it with the mastery of an expert in assembly coding. That's without a doubt why it left such a lasting impression.
 
I'm so glad to see some of the old Japanese staff hit back at some of the crap thrown at them by a few ex-Sega America staff and lying bastards like Tom Kalinske, it's a refreshing change.
I do think mind, that Naka-san may be telling white lies, in some of his answers.

Naka-san was part of the DC committee sector inside SEGA Japan, who would have a say on what games would get the green light or be cancelled, the world over. Naka wouldn't have any say of what staff SEGA America could hire or fire, so we know it's total bull crap over Giest Force and how Naka-san wanted staff.

I'm sure almost anything Sonic, had to go through Naka-san in the 90's; Yu Suzuki/AM2 had to ask Naka-san for permission to use Sonic, in Sonic Fighters, I would guess Sonic X would have needed to go through Naka/Sonic Team to be approved, so he would have been aware of the project. I thought Ofer Alon's Boss engine was 100% Assemble, because it was the one part of the project that was 100% built for the Saturn?. There's been a few times over the years that a game needed to make a complete switch to a totally different engine (Daikatana) so I guess it would have been possible and I seem to remember, the late Bernie Stolar also confirming, that he made a request to use the NiGHTS tools and had to tell the team they couldn't use them

Whatever the case, no way should a (so-called) elite In-House team need to look to use an outside engine after 2 years of development and it wasn't like SEGA Japan In-House teams, ever shared their tech with each other, never mind an outside western division. Sonic X was a mess of all SOA making and it's far too easy to blame Naka and SOJ. Sonic X was a project that spanned 2 years, 4 different systems and where at one point you had 2 different lines of the same team, working on different parts with 2 completely different engines, A complete mess from start to finish and despite all that and after 2 years. I don't think not a single stage, was ever playable from start to finish with all correct enemy placements Ect.


Like almost anything SEGA America, in the 32-bit era, It was badly planned and totally mismanaged. Soinc X was cancelled because the game was going to be crap at the end of the day and all the blame should be laid on SEGA America. Sonic should never have been given to them to cock up. Overlooking SEGA Japan should have demanded and made sure the Sonic Team itself, made one of the most important Sonic games (to sell its 32-bit system) SOJ would have been better off giving Sonic X to Realtime Associates (given Bug had a nice engine and was delivered on time) or Travellers Tails, rather than STI to totally cock up given they just simply weren't up to 32-bit production. Their 32X version looks like something thrown together by an Amiga bedroom coder.

SEGA America was beyond hopless in the 32-bit era
 
Last edited:
derrickchase said:
It's funny because books like "Racing the Beam" are literally the contemporary version of "I walked 20 miles to school every day in the snow."

It isn't a big deal. Mike Abrash has commented on it several times because he's not an ego case who tries to pretend he's wearing a bigger pair of pants than he is.
Click to expand...

Do you actually program? Do you have any assembly programming knowledge? Care to share an example of game code you've done in a modern language vs. similar in assembly?

I mean you are talking a lot about how assembly isn't difficult, but forgetting that assembly is specific to the actual chips and architecture you code it on, so the complexity scales depending on the architectural design of the chips themselves. Doing assembly on a Z80 is going to be much easier than assembly on a R3000 or SH2 or the Saturn DSP.

Not to belittle your expertise but if I'm just going off what I've read it would sound like cireza cireza and RoboFu RoboFu have actual assembly and modern programming experience, but I don't get that same impression from you (at least in terms of having actual assembly programming experience). They've also provided some great examples of the complications in assembly programming, while the examples you've provided for modern programming have more to do with sheer amount of code (there is such a thing as spaghetti code and code bloat, especially with modern AAA development) and amount of manpower/labor hours needed to type up the code. But those examples of yours don't actually speak to any particular difficulty in needing to write the code, which is especially true considering the amount of free libraries, algorithms etc. that exist.

Your examples would probably work better if you focused on the actual game engines that are created for modern games; I can see a case for that being more involving and complex than coding games in assembly on older consoles, especially since almost all game engines have to have some parts written in assembly for optimization purposes anyway. The actual games are just leveraging the hard work put into the engines, though, and a lot of the complexity in the software code comes from the sheer amount of code that has to be written, not any particular logic constraints or challenges (though it depends on the game; a lot of Sony's 1P games have some hand-written assembly involved in their programming, probably in adjusting parts of the underlying engine for further optimizations, for example).
 
Last edited:
Did an NDA expire that he was tied to recently? Because some of this has been part of the Sonic Extreme story for what seems to be forever (nights engine stuff)
 
True if one listens to Wallis, but who knows. All one can say that STI should never have needed to go running to SOJ/ST for a engine after 2 years of development and who were meant to be the Elite In-House team at SEGA.
 
Last edited:
Yuji Naka is basically inafune at this point, right down to blaming the fans, throwing developers under the bus, and taking credit for the creation of each companies mascots when they didn't.

Only difference is Inafune doesn't aggressively use social media, at least outside of Japan.
 
Naka was one of the reason why Mark Cerny left STI.
Or that time Peter Moore said to the translator to tell him "fuck off".
And other stories...
 
IbizaPocholo said:
Click to expand...

"The NiGHTS I programmed was coded in full scratch assembly, so there is no way I could share that engine with people who are making it in C because they don't understand it and the documentation doesn't exist. All these people who tell these stories are liars."

"NiGHTS program was so special that it's impossible to use it for anything, and I have never even heard of anyone wanting to use it."

Eh, I don't know about that. It's pretty much confirmed that at first the american dudes making Sonic X-Treme were using the NiGHTS engine when the game looked like this:

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

Then it's said that after Yuji Naka learned they were using his engine without permission, he made a fuss and they were forced to start from zero and thus they created that engine with the fish eye lens:


 
Togh said:
Then it's said that after Yuji Naka learned they were using his engine without permission
Click to expand...
Thing is it wasn't "his engine". He didn't personally hold the IP for it. It was Sega's engine, and there was no official regulation on what game could use it.

Naka's delusions of auteurship (enabled and amplified by the extremely silo-ed way in which Japanese corps generally used to operate) caused a fair bit of damage to Sega.
 
also about that part:

"NiGHTS program was so special that it's impossible to use it for anything, and I have never even heard of anyone wanting to use it."

It's a lie because Burning Rangers was made with the NiGHTS engine, but maybe it's not a intentional lie, he said his english is not very good so sometimes he has trouble to express himself
 
Togh said:
It's a lie because Burning Rangers was made with the NiGHTS engine
Click to expand...
The guy was the lead developer of both engines, but yeah, he is lying lol.

He probably used part of what was created for Nights, but obviously, it was heavily modified to go from a game like Nights to Burning Rangers.
And the graphics pipeline is different, and very specific, for Burning Rangers.
 
RoboFu said:
No they don't … not beyond hardware drivers and even then it has to be a very specialized piece of hardware as most things are layered on top of generic usb drivers.

It's definitely not used in game development anymore. There is no
upside but there is a thousand downsides to doing so. ( devs really like their apps to be compatible with the most computers and operating systems ) ms and Sony want their consoles to be backward compatible and be on multiple devices. Everything uses abstract layers these days on consoles and PCs.

Not to mention just the sheer amount of bytes there are in 1 gig of ram let alone 16. Then you have the sheer number of registers to deal with in modern cpus.



The majority time machine code is still used today is in direct hardware specific tasks such as small sensors or motors for something like assembly line equipment. Or any type of small embedded system like that. A toy that makes sounds, routers, switches .. etc
Click to expand...
Most of these kids barely know what a cash register is, much less a CPU register.
 
You must log in or register to reply here.

Similar threads

Yuji Naka returns to X by accusing Dragon Quest producer of ‘lying to court’
Business Cringe 
20
2K
Pidull replied
Sonic x Shadow: Generations - coming to Switch 2
2
333
Mownoc replied
Best game recommender engine?
2
145
Dacvak replied
Metaphor: ReFantazio and Sonic X Shadow Generations Are “Performing Better Than Expected” – Sega
News Sales-Age 
26
1K
Gambit2483 replied
Switch 'Welcome' will cost $10, explanation why not free
2 3 4 5
239
11K
Super Lemon Drop replied
Top Bottom