Well optimized snes games

/thread

>>3732159
I like you

That... that's not what optimized means.

>>3732159
I don't like you.

Also, gundam w endless duel, umihara kawase, shin megami tensei

>>3732308
What else could it possibly mean?

>>3732154
>running NES game on SNES hardware is "optimized"

No, its just faster hardware

>>3732154
>Completely fuck up the brick behavior while porting NES code

>>3732390
This.

NES == 6502
SNES == 65816 (Assembly and pin compatible with the 6502)
The SNES's PPU is literally the NES's taken to it's logical conclusion.
Besides porting the drawing commands, the game engine could have been ported without much tinkering.

>>3732308

What the fuck are you talking about?

>>3732413
>The SNES's PPU is literally the NES's taken to it's logical conclusion.
Why does it have a lower vertical resolution than the NES? 224 vs 256

>>3732431
Probably to fit a 4:3 aspect ratio better, NES game designers had to insert extra pixels horizontally to counteract the resizing that would occur on the TV.

File: 1482033412028.png (9KB, 464x496px) Image search: [Google]

9KB, 464x496px

>>3732463
>>3732431
Neither. This anon misread the specs.

The NES resolution outputs at 256x240

The SNES resolution can be altered between a handful of resolutions depending on mode and other PPU settings.
256x224 = Modes 0-4, 7
256x340 = Modes 0-4, 7 w/ overscan
512x224 = Mode 5,6
512x240 = Mode 5,6 w/ overscan
512x448 = Mode 5,6 w/ interlace
512x480 = Mode 5,6 w/ interlace and overscan

Disabling overscan allows more time to update VRAM during vblank, an extended period of time in TV technology when nothing is being drawn to the screen.

(curiously enough, the official documentation states the resolution is 224 and 239, but I actually don't know if this is right or not (or if they zero-indexed (or if they were talking about either bg or obj indexing (weee!!))))

> Probably to fit a 4:3 aspect ratio better, NES game designers had to insert extra pixels horizontally to counteract the resizing that would occur on the TV
I'm sorry, but the test results are in. You're retarded.

>>3732529
Professor NES?

File: Super Ghouls´n Ghosts.png (635KB, 650x475px) Image search: [Google]

635KB, 650x475px

:^)

>>3732529
Did you just make a post in MIT Scheme?

>>3732154
SMW was optimized for no slowdown. Have you ever tried to hit all the yellow and green ! blocks on star road 5 (I think it was, maybe it was 4)? Only the three or four last powerups will be displayed, the older ones are automatically removed from the screen, in order to prevent slowdown.

>>3732668
No, I've never used Scheme personally, but a senior project of mine from long ago was working with a team to build a compiler in Scheme on top of a 65816 assembler I wrote in C. I knew the technical details, so I designed the compiler while others programmed it.

>>3732675
That, and limiting the amount of statically allocated memory reserved for items. You almost never use something like malloc() on these old machines because of the overhead and the statistical sacrifice of ~1/3 of your RAM associated with dynamic memory allocation.

>>3732701
>That, and limiting the amount of statically allocated memory reserved for items. You almost never use something like malloc() on these old machines because of the overhead and the statistical sacrifice of ~1/3 of your RAM associated with dynamic memory allocation.

They didn't even need dynamic memory allocation for stuff like this, since they could just put stuff like items in a set position and then always load their graphics from there.

hell I don't even know when or where dynamic allocation would ever work, as far as video ram goes. Or do you mean something else, like the engine keeping track of where items are on the screen?

File: cactus-ever-been-so-mad.jpg (31KB, 450x301px) Image search: [Google]

31KB, 450x301px

>>3732661

File: 1480721247105.jpg (92KB, 578x632px) Image search: [Google]

92KB, 578x632px

>>3732979
>since they could just put stuff like items in a set position and then always load their graphics from there.
I'm talking about the state of instantiated items being stored somewhere in RAM (X/Y coords, animation frame, timers, physics, etc). If their is a 4 or so limit to the number of active items, that is a strong indication that a statically allocated array is used. If you wanted an arbitrary number of items able to be active at once (until you run out of memory), you'd need to dynamically allocate each instance and free it once it's destroyed.

>hell I don't even know when or where dynamic allocation would ever work, as far as video ram goes.
Dynamic allocation (malloc() and free()) is not hard to implement. But it fragments memory, which is unacceptable for a system that has precious little memory to start with.
However I can think of a few instances in games where some dynamic allocation must be going on in the background (even if it isn't full blown malloc()/free()). For instance, in Yoshi's Island, VRAM is dynamically allocated for on-screen sprites that use linear transformation functionality (scaling, sheering, rotation), such as Piranha Plants. I haven't disassembled YI, but this has to be the case because their is too little VRAM for a unique memory region to be allocated per plant in a level, and these types of sprites can't share graphics because they are all transformed in different ways, as when you see two on screen at once.

Another anon told me once that some strategy game he had been hacking also used dynamic allocation in the game's code, but I can't remember what game, nor can I verify.

Btw, static arrays are fast because their is no overhead, and developers can be sure of the performance of their system (can predict worse case how many clock ticks are needed to execute a program) which is critical in making highly responsive and reliable code.

NASA knows this, and has some very interesting guidelines for what can go into mission critical code (hint, no dynamic allocation, no recursion, etc):

http://spinroot.com/gerard/pdf/P10.pdf

>>3732397
>that one motherfucker that is still complaining about this 20 years later
still a good game