It is currently Fri Nov 16, 2018 1:21 pm

All times are UTC - 7 hours



Forum rules





Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12, 13 ... 30  Next
Author Message
PostPosted: Mon Jan 25, 2016 8:37 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2764
I think I should try to investigate the BG collision routines in other games and compare it with my own game to find out if this is where the "horror code" lives.

I've already investigated how the BG collision in Super Castlevania 4 works, but I didn't measure exactly how much time is spent.

Edit: Looked at the traced code again. SCV4 spends 20 scanlines just to do BG collision with the player character. Now I need to check other games to see if the have anything similar.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 12:24 am 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2827
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?


It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 2:19 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tepples wrote:
I know the walking characters in Haunted: Halloween '85 (the player and the zombies) are the most algorithmically complex because they have to read the collision map four times (bottom center, left, and right, and head-height at leading edge), compared to everything else that reads it once (bottom center) or not at all.

Normally you can get away with just checking once per axis (usually the problems from that tend to be minor and self-correcting).

Players are notoriously more complex in general though. For starters, unless you're using the same routine for everything, they're the only ones to have full blown physics (collision all ways, acceleration, slopes, checks against background and platforms, etc.), while most objects usually just have the bare minimum for what they do. Also, players are the only ones to have many actions (idle, running, jumping, swimming, crouching, hurt animation, etc.) and potentially could switch between them at any moment, while most objects just have a couple of simple actions and maybe a collision check and not much else to worry about.

psycopathicteen wrote:
I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.

The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 2:47 pm 
Offline

Joined: Fri Jul 04, 2014 9:31 pm
Posts: 968
MottZilla wrote:
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?

It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

That's without factoring in the gain from 16-bit operations, which is substantial but can be a bit slippery as it is application-dependent. Movement code is an example - adding a 16-bit number to a 24-bit number is far quicker on the SNES than on the NES.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 2:57 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2764
MottZilla wrote:
Espozo wrote:
Isn't the SNES's CPU supposed to be something like 4x faster than the one in the NES?


It's not quite twice as fast. The NES CPU runs at 1.78mhz where as the SNES CPU runs between 2.68mhz and 3.58mhz. If it were to run always at the top frequency of 3.58mhz and didn't have DRAM refresh periods frequently then it would run twice as fast.

However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.


The 65816 is more cycle efficient than the 6502 as long as the programmer knows what their doing.

Sik wrote:
psycopathicteen wrote:
I wonder if slopes have anything to do with it, because a lot of NES games didn't use slopes.

The problem with slopes is not so much that they're slower (it's not that bad) but the fact that they're notoriously hard to get right, and by "right" I mean "things don't suddenly jump when going downhill or suddenly stop when going uphill" (especially the jump part). That usually requires a lot of hacks to get working within your limited physics engine. No wonder they were usually avoided (and even into the 16-bit era, usually only players would handle slopes, since it was easier to have everything else just treating tiles as "solid or empty")


I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms. Maybe I just never noticed it before because nobody ever pointed it out to me.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 4:14 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10972
Location: Rio de Janeiro - Brazil
psycopathicteen wrote:
I don't remember seeing any game that doesn't allow enemies to walk on sloped platforms.

I wouldn't be surprised if they at least used a simplified form of slope handling for objects other than the player. I know that the Sonic games did this... Enemies are placed at the correct height on slopes, but the angle doesn't affect them at all, it's like they're always walking on straight ground. You can easily notice this if you use the debug mode to place enemies near loops or quarter pipes. They ascend insanely fast, because their horizontal movement isn't attenuated by the angle, and their Y coordinate is adjusted to match the height of the slope.

Quote:
Maybe I just never noticed it before because nobody ever pointed it out to me.

There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 5:09 pm 
Online
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 2332
Location: DIGDUG
Other ways SNES is more efficient...
-Separate processor to handle music, don't have to waste CPU cycles running a music engine
-tons more RAM, don't have to do things twice if you can store it in RAM for later
-much more efficient moving large chunks of data around
(DMA)
-larger sprites, don't have to waste cycles contructing metasprites.


Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.

_________________
nesdoug.com -- blog/tutorial on programming for the NES


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 8:48 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20774
Location: NE Indiana, USA (NTSC)
dougeff wrote:
Downside of SNES dev...the expectations are much higher, it's assumed that an SNES game should look as nice as SMW.

This is the essence of what I was trying to say in points c (color use) and d (parallax layer use) of my first post. But most of this topic has been about the 65816 CPU, with only a few posts addressing the expectation of production values:
Bregalad wrote:
However you can always come up with cheaper graphics that don't push the system to it's limit.

tepples wrote:
And open yourself to "Why didn't you just make it for the NES?"

psycopathicteen wrote:
It shouldn't be that difficult to develop an SNES game that looks like an NES game.

MottZilla wrote:
The harder part is getting all of the artwork, sound, music, etc designed.


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 10:11 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3381
Location: Richmond, Virginia
MottZilla wrote:
However the PC-Engine/TurboGrafx 16 CPU runs 4x faster than the NES CPU running over 7mhz, and thus basically a bit more than twice as fast as the SNES CPU.

And thus almost twice as fast as the 68000? :lol: (I mean, the way you just calculated it there anyway.)

It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram. I'm not sure how anyone was able to manage with that given the general complexity of games on the system.

tokumaru wrote:
There are a lot of limitations games managed to hide from us pretty well. I'm pretty sure there are many cases where level design and object placement are carefully planned to avoid tricky situations.

The DKC games are carefully designed around the 8 sprite palette limit. There are situations like climbing a rope that stop you from doing things like carrying barrels too far, or ditches that stop enemies from traveling to far if you follow them. The tiles often get messed up because there's not enough vram for how they're managing it.

Actually, you know what I just thought of? If you're using 8x8 and 16x16 sized sprites, you don't even need to search every 8x8 block for a vram engine, because all 128 16x16 sized sprites just fit it. I mean, that's if you're using that much. You could even assign sprite a spot in vram.

Yeah, if each sprite is using individual tiles, then 32x32 sprites are actually kind of pointless.

dougeff wrote:
it's assumed that an SNES game should look as nice as SMW.

So not very? :lol:


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 10:54 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10972
Location: Rio de Janeiro - Brazil
Espozo wrote:
dougeff wrote:
it's assumed that an SNES game should look as nice as SMW.

So not very? :lol:

My thoughts exactly. As I see it, SMW is to the SNES what SMB is to the NES. The graphical potential of the console is severely underused.

Maybe dougeff meant "at least as nice as SMW", which is like, a little bit better than some late NES titles?


Top
 Profile  
 
PostPosted: Wed Jan 27, 2016 11:54 pm 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3381
Location: Richmond, Virginia
I'd actually argue that it's even worse in terms of effort put in. There isn't that much shading, and the shading that exists isn't too spectacular, and the sprites aren't any larger than what you'd find on the NES (and the animation isn't any smoother because of the limited vram system), so the amount of effort it takes to do all this is less than trying to fit everything within the NES's constraints. I think SMB 3 actually looks better overall. The sprites are cleaner and the artwork is more consistent. Then again, I like SMB3 a whole lot better anyway.

I never understood, did Nintendo forget to outline this or something? It sticks out from the rest of the sprites like a sore thumb:

Attachment:
Lava Monster.png
Lava Monster.png [ 735 Bytes | Viewed 2077 times ]

You want to know another thing that always looked weird to me in SMW? A lot of the color gradients are kind of poorly done. You'll see something like the green on the pipe have some red, then not have red, then have red again even if the green is increasing. Just an observation.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 12:04 am 
Offline

Joined: Sat Apr 25, 2015 1:47 pm
Posts: 424
Location: FL
SMW uses lots and lots of 4-color and 8-color graphics, which is the reason it looks so simple compared to a lot of other contemporary/later SNES titles. Given the amount of time it was in development (supposedly ~3 years, probably close to the release of SMB3), I think a lot of the graphics were made before the technical details of the SNES had even come close to being finalized, so they just played it safe.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 12:26 am 
Offline
Formerly Espozo
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3381
Location: Richmond, Virginia
I was under the impression that the SNES was originally supposed to be more powerful, not the other way around. I really have no clue how that game took 3 years to make. I'm pretty sure DKC was made in about a year.

Not just technical though, a lot of the artwork, simple or not, just doesn't look that good. Maybe Irem just has me spoiled. :lol:

Aren't the BG tiles actually only 3bpp in order to save space on the cartridge? I mean, this doesn't justify the sprites though, which are the main problem.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 4:00 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 275
Quote:
It seems the TurboGrafx is a bit unbalanced in design, like having a 7+mhz 6502 variant but with only 8KB of ram.

This is because the PCE has no restricted acces to VRAM, you can decompress or modify SAT/BAT directly in vram, without any RAM buffer .
In fact is less problematic than it seems,but it is if you are coding like a system with allowed VRAM acces only in vblank .

Quote:
Other ways SNES is more efficient...
-Separate processor to handle music, don't have to waste CPU cycles running a music engine
-tons more RAM, don't have to do things twice if you can store it in RAM for later
-much more efficient moving large chunks of data around
(DMA)
-larger sprites, don't have to waste cycles contructing metasprites.

Fast shortcuts here ..

Quote:
-Separate processor to handle music, don't have to waste CPU cycles running a music engine

Yes but without any mechanism for accessing ROM/WRAM to refresh his limited amount of RAM for a sample based sound processor, it's not really an advantage.
PCE can do better samples without any dedicated sound processor .

Quote:
tons more RAM, don't have to do things twice if you can store it in RAM for later

Yes but too slow for 65xxx, better to have 32ko of fast ram than this shity DRAM imo ..

Quote:
-larger sprites, don't have to waste cycles contructing metasprites.

Yes but it's relevant with a descent SAT/OAM organisation and not with only two size allowed at the same time. In the snes's case,it'is a little bit useless .


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 7:55 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 20774
Location: NE Indiana, USA (NTSC)
tokumaru wrote:
Maybe dougeff meant "at least as nice as SMW", which is like, a little bit better than some late NES titles?

That's what I guessed too. SMW has 7-color shading (even if not 15-color) and parallax.

Espozo wrote:
I never understood, did Nintendo forget to outline this or something? It sticks out from the rest of the sprites like a sore thumb:

Attachment:
Lava Monster.png

Blargg appears only in skull-raft levels, and all these levels are on black backgrounds. It isn't outlined for the same reason sprites in Donkey Kong and Metroid aren't outlined.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 436 posts ]  Go to page Previous  1 ... 7, 8, 9, 10, 11, 12, 13 ... 30  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: creaothceann and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group