nesdev.org

Many games actually may be coded in C, I heard japanese devs mostly used C and that even SuperFX-2 title Doom coded in C with no assembly involved what so ever. Makes sense for me, if some game's slowdowns too much.

Nitroman wrote: even SuperFX-2 title Doom coded in C with no assembly involved what so ever.

So that's why it looks the way it does. I can understand the SNES part pulling a port down (video bandwidth) but there are definitely plenty of things that are the actual SuperFX's problem. Not having texture mapped floors is definitely not the SNES's problem, and I would have thought that a 20Mhz processor would be able to handle a seemingly perfect port of Doom, but apparently not. What kind of specs would your computer need to run Doom back in the day, because they must have had to be pretty good...

Espozo wrote:What kind of specs would your computer need to run Doom back in the day, because they must have had to be pretty good...

I remember running Doom on my 386DX-40 with 4MB of RAM. It was playable, but it was definitely not running at full speed.

EDIT: Found a video of it running on a 386DX-40. It's pretty slow in big rooms with lots of enemies.

Doom would (barely) run on a 25 MHz i386 PC with 4 MB of RAM. A 33 MHz i486 PC with 8 MB was recommended. (Source, via Google doom system requirements)

I think I ran the demo ... for hilarity ... on my 386sx/16 with 2MB of RAM. I believe it worked, although I think had to drop the resolution to zoomed in all the way? I forget.
Of course, the thread that tepples linked implies that it tested for and refused to run with less than 4MB of RAM, so maybe my memory is wrong.

Well, dang... The GBA can run a seemingly perfect port of Doom 2, (censorship doesn't affect processor speed ) and it definitely doesn't have anything like 4 MB of ram. I guess the GBA's small resolution helps cuts back on CPU power. (Which I know isn't directly related to ram, but still.) Do you know what resolution Doom was running in in the video? I know the GBA technically has a 32 bit processor, but from what I've heard, it takes quite a performance hit when accessing rom when in 32 bit mode, (If I remember correctly) so it's better to just use Thumb which is 16 bit. Of course, CPU speed isn't everything as some processors are more efficient than othersI'm looking at you, Stef.

Three things going for the GBA are IWRAM (32K of zero wait state memory, almost like a software-defined cache), execute-in-place ROM (less need to swap textures and things in and out of RAM), and advances in compiler technology for the ARM and Thumb ISAs.

Okay, as customary, I'm not doing anything to really improve the conversation, but I got a couple of good laughs after reading the NOW ONLY prices: (And I'm sure these would be twice as expensive in today's money.) https://books.google.com/books?id=v9TVJ ... MB&f=false
(I didn't know it was that costly to play a game of Doom. )

Random comment in passing for @Espozo: if you're ever willing to try learning C, I'd be happy to buy you C Programming: A Modern Approach, 2nd Edition by K.N. King, which is worth every cent. It's probably the best C book I've ever read; extremely good visual diagrams, layouts, clear explanations, and great real-world examples. Having some assembly background (meaning conceptually) really helps when it comes to understanding C, especially pointers (the #1 thing people have trouble grasping -- but assembly programmers tend to say "oh it's just indirect addressing, got it" and that's the end of it), and some of the syntax (no argument, it get a little hairy at times). Just let me know + get an Amazon wishlist + add it and it'll appear.

And as for those PC prices: I'm the one laughing. Those really aren't very expensive. Shall I scan or photograph the sales receipt for my Apple IIGS, circa late 80s? Or maybe point you to something like this?

Know your roots. And in knowing your roots, realise how ridiculously affordable computers/technology is today. What you get now, for how much you pay now, is pocket change compared to then.

Espozo wrote:Well, dang... The GBA can run a seemingly perfect port of Doom 2, (censorship doesn't affect processor speed ) and it definitely doesn't have anything like 4 MB of ram.

But it has ROM it can access directly (what's the size of GBA Doom's ROM?). Remember the RAM requirement deals with the fact that PCs have to load everything into RAM to be able to do anything at all =P

Back on the question of the thread title: does anybody know if the Mortal Kombat ports look like they're made in C? (I know the Mega Drive ports are, in fact I wouldn't be surprised if they just used the arcade code which is also in C)

Nitroman wrote:Many games actually may be coded in C, I heard japanese devs mostly used C and that even SuperFX-2 title Doom coded in C with no assembly involved what so ever. Makes sense for me, if some game's slowdowns too much.

I'd love to see that GSU C compiler (ie. what you've heard isn't worth jack without sources or critical thought).

the #1 thing people have trouble grasping -- but assembly programmers tend to say "oh it's just indirect addressing, got it" and that's the end of it

Wrong - I had a strong assembly background when I learnt C, but I still had major trouble with pointers. It's a fact the syntax of C becomes awful as soon as you start using pointers (and you HAVE to be using pointers to do anything in a meaningful way in C), the language discourage the use of pointers when in fact it's a key element of the language.

That being said I never had any problem to the concept of a pointer thanks to my assembly background, but using them in C is at first a nightmare until you figure how everything works out.

If you don't see what I mean and want me to provide concrete arguments I'll be happy to provide them but I doubt it's here the place to do so.

Optiroc wrote:

Nitroman wrote:Many games actually may be coded in C, I heard japanese devs mostly used C and that even SuperFX-2 title Doom coded in C with no assembly involved what so ever. Makes sense for me, if some game's slowdowns too much.

I'd love to see that GSU C compiler (ie. what you've heard isn't worth jack without sources or critical thought).

I'd love to see any survived GSU assembler, not mentioning C compiler.

Nitroman wrote:Many games actually may be coded in C, I heard japanese devs mostly used C and that even SuperFX-2 title Doom coded in C with no assembly involved what so ever. Makes sense for me, if some game's slowdowns too much.

Can you cite something about this? Just saying "I heard this" doesn't really help. Finding clues to a game being compiled is more useful than just guessing or going off what some unknown person may have said. Unless they actually cited some evidence to support their claims.

I'm really septic about the fact that Doom on SNES was coded in C, is there any C compiler for the SuperFX in first place ? I don't think so...