So, what actually causes slowdown?

[psycopathicteen]

"Game Maker" was brought up in a few threads, so I looked up a few tutorials. Under the platform game tutorial it said that tiles are just part of the background, and invisible solid objects are placed over the background tiles. Now I understand that this is just a quirk in the "Game Maker" program, but it does make me want to ask if this was common practice in the NES/SNES days, because it is much faster to use a collision map than to map every solid block into an object.

[tepples]

The invisible solid objects in such a game form a collision map.

But the common practice as I understand it, at least in the NES era, was to build the nametables and the collision map from the same underlying data set in real time. For example, Super Mario Bros. decodes a column of 13 metatiles (totaling 16x208 pixels) at a time, writes it to the nametable, and then caches it for collision in a 32x13-metatile sliding window. Each metatile then has its own collision properties.

[tokumaru]

Nowadays it appears to be common practice to draw the scenery entirely with objects, but old consoles would definitely have a lot of trouble keeping track of many active objects. Games like SMB and SMW did use objects to create the backgrounds, but those were converted into tile maps before being used by the engine.

[MottZilla]

I think generally only something moving would be platformed on as an object and not part of a tile array. Or maybe some large flat surface or something like in Castlevania IV where there is rotation or SMW boss on the tilting land in lava. It is more efficient to have a tile array generally. Not collision related, but the NeoGeo makes all its major backgrounds and objects from what we call sprites. It only has a non scrolling simple background layer that's usually just for status bars and the credit display.

[tepples]

And since the PlayStation and the stripped down SGI Indy that is the N64, everything has been made from textured triangles or quadrilaterals.

Neo Geo sprites are sort of hybrids. They're actually maps made of 16x16-pixel tiles that are 1 tile wide and up to a screen tall. This makes it practical to have block puzzles like Magical Drop (16x16 pixel square grid), Puzzle Bobble/Bust-A-Move (16x16 pixel hex grid), and Joy Joy Kid/Puzzled (8x8 pixel square grid). A platformer like Super Mario Bros. might be done on a Neo Geo using about 20 such tile columns for the playfield.

[psycopathicteen]

Is there anyway of telling if a game is programmed in C, by looking at it's ASM code?

[tepples]

I know of no foolproof way to detect whether an unknown C compiler was used. Some techniques may help:

• Someone familiar with each of the major C compilers might be able to identify instruction sequences or memory model assumptions that a particular compiler makes. For example, ca65 has a separate native stack from the C stack in order to allow use of more than 256 bytes of automatic variables.
• Some games are written in a hosted mode, which means they use parts of the C standard library. One way to tell whether you're dealing with an implementation of the C standard library is by looking for data formats used by the C standard library. This is how NovaSquirrel and I detected Koei's use of C, by running strings on some Koei game and finding printf format strings.

[psycopathicteen]

I attempted to fix SGnG again, and I found another thing wrong with it. Many large objects are composed entirely from 8x8 sprites.

EDIT: Hey, if you remove support for 16x16 sprites, almost all slowdown goes away.

[rainwarrior]

I expect that C code on the NES would have a few recognizable earmarks, regardless of which compiler was used.

Probably you would find a lot of poorly optimized code, especially with calls to common subroutines that would be part of its CRT.

Perhaps there would be a recognizable software stack, like the one CC65 has (this generates tons of calls to the CRT subroutines for the software stack), or alternatively you may find a lot of passing of variables on the hardware stack, which will involve TSX/TXS and frequent use of X indexed addressing with ranges probably around $00F0-00FD (e.g. if you saw something like LDA $00FA, X frequently enough, I would definitely start to suspect C). An assembly programmer is not likely to use the stack like this, since they will probably know which functions may call each other, and can manage parameters through ZP variables. A C compiler won't likely know this and has to use the stack, unless you explicitly avoid the stack by using global variables.

The number of original NES games using C is probably extremely small. It's been mentioned before that some of the KOEI games that were ports from PC systems to NES probably used some C code. That may be a hint for where to look (e.g. PC->NES ports, games that may have complex behaviour but don't need high performance). In recent homebrew there's probably several examples, but usually in this case the author will just tell you if you ask, which is much easier than trying to guess from disassembly.

[psycopathicteen]

Super Ghosts and Ghouls DOES have a software stack, and there is an awful lot of pushing and pulling.

[koitsu]

Use of the stack on a 65xxx CPU is not considered grounds or justification for "it was probably written in C". While what rainwarrior and tepples both said is completely valid/true, but it isn't a definitive indicator that something was written in C.

The short version is that no, there is no definitive way by disassembling a game to accurately conclude "yes that code was generated by a compiler thus originally in C".

Also, food for thought: Super Ghouls and Ghosts (not Ghosts and Ghouls) was one of Capcom's first SNES/SFC titles. It's very likely that given what games they were working on at the time (circa late 80s/early 90s), much of the code was probably intended for a general-purpose engine that was used in other titles, or very possibly a hacked-up version of a previous engine.

I'm really not surprised about large mobs consisting of mainly 8x8 sprites, nor do I believe that is the direct source of the slowdown -- do you know why they did it that way? Almost certainly because if there's animation or changes that occur on a fairly granular level within the mob (e.g. an eye blinking, a hand opening/closing, etc.) then all that's required is that the engine refer to a different 8x8 tile in the nametable. You don't have to keep tons of 16x16 objdata laying around (wasting ROM space), nor do you have to resort to worse things like taking 16x16 objdata, shoving it into RAM, then splitting it up into 8x8 pieces yourself, modifying the part relevant, then recombining it all and updating VRAM.

If you really want a game that has slowdown that is intentional yet there have been a couple people that have looked at it (myself and Neill Corlett) and never figured out the root cause, try Gradius III for the SNES/SFC. Neill and I are both of the opinion the slowdown is intentional (to make the game easier for players given the huge number of objs on-screen), but neither of us were ever able to determine where/how this is done. Further efforts were needed but neither of us wanted to put in the extra time.

[tomaitheous]

Super Ghosts and Ghouls DOES have a software stack, and there is an awful lot of pushing and pulling.

Could be macros. I wrote a macro system for huc6280 that looks more like 68k code. It creates shorter and cleaner looking code, but expanded it tends to look like compiled code a bit. It's great for prototyping my code, and if I need a speed increase - I'll rewrite that routine.

[rainwarrior]

I'm only talking about clues, not rules. There are reasons/ways to do the opposite of what I've suggested in either assembly or C based programming. I'm only suggesting cases where a closer look may be warranted. You'll have to make an educated guess based on what you see, I couldn't say much based on what you've said so far.

[tomaitheous]

I attempted to fix SGnG again, and I found another thing wrong with it. Many large objects are composed entirely from 8x8 sprites.

EDIT: Hey, if you remove support for 16x16 sprites, almost all slowdown goes away.

All that 8x8 meta-cell sprite decoding can take up quite a bit of cpu resource per frame.

[psycopathicteen]

Sprite handling almost takes 1/3 of the frame, due to all those 8x8 sprites, and the thing with the size bit being encoded where the priority bit is supposed to be.