It is currently Wed May 23, 2018 5:47 pm

All times are UTC - 7 hours



Forum rules


Related:



Post new topic Reply to topic  [ 377 posts ]  Go to page Previous  1 ... 8, 9, 10, 11, 12, 13, 14 ... 26  Next
Author Message
PostPosted: Thu Jan 28, 2016 8:44 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10481
Location: Rio de Janeiro - Brazil
tepples wrote:
SMW has 7-color shading (even if not 15-color)

And they wasted it on dumb gradients and unbalanced contrast... :? A good NES artist could do wonders with that.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 10:23 am 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2648
Mario's dull pink hat always bugged me. They used pure red for everything else in the game, why didn't they just use pure red for Mario's hat as well?


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 3:45 pm 
Offline
User avatar

Joined: Wed Dec 06, 2006 8:18 pm
Posts: 2824
Espozo wrote:
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.


I'm not sure what you mean. The 68000 I assume you mean in the Genesis is clocked slightly faster than the PC-Engine's CPU but they are completely different designs and a simple clock speed comparison isn't as valid as it is when comparing NES, SNES, and PCE which all share the same basic cpu design.

The TurboGrafx 16 having only 8KB of RAM clearly wasn't unmanageable. Most of the types of games that were being made at the time didn't need a whole lot of RAM. And when the CD-ROM system came along, you had more RAM than either SNES or Genesis if you wanted it for game variables or buffers. I don't think many SNES games or Genesis games are really going to need a large percentage of the RAM available. That's not to say they don't use it, because if it's there a programmer will probably use it. But you could certainly optimize or do things in a different way to get by with less. SNES and Genesis games are probably more likely to have large buffers or arrays of data to be readily accessed.

I know that one or more of the SNES Mega Man titles uses a large chunk of WRAM to store and restore the background map when you pause the game. That certainly isn't necessary but they had the memory to do it, so they did it. Probably made the programmer's job a lot less complicated.

And once you get into "why did they do this" or "they should have done this" you can say that about every console and talk about it forever. For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does. In my mind it would have been a bit improvement for what I can only suspect would have been a manageable cost. Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster. Or why Sony never came out with a RAM cartridge for the Playstation 1 as Sega did for the Saturn.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 4:30 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2648
Quote:
Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster.


Nintendo didn't expect anybody to write such inefficient code.


Top
 Profile  
 
PostPosted: Thu Jan 28, 2016 7:14 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3315
Location: Nacogdoches, Texas
TOUKO wrote:
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 .

I'd say the organization of it cancels out its usefulness. I never quite understood the hate on the sprite system though. The only real legitimate complain I have is that there's only a fourth of vram available for it. They should have made tiles for sprites 16x16 like the Turbografx so sprites could occupy all of vram. You could even keep 8x8 sprites, but the only advantage you'd get is sprite pixels per scanline, but I guess you could actually also store BG tile data. Just saying, 16x16 and 32x32 is easily the best sprite size configuration. 64x64 with anything is completely useless. I would actually prefer a color math enable bit over an extra size bit.

SNES and Turbografx sprite capabilities really are about the same aside for vram. I think you can make every sprite configuration on the Turbografx with 64 sprites that you can on the SNES with 128 16x16 and 32x32 sprites, aside from one where there are 64x16 sized sprites on the Turbografx? One thing that people are forgetting is that the SNES has more sprites, so it's actually more flexible in that regard, although it's also more to process if you're pushing a bunch of sprites. (I've never seen a game use past 80...)

psycopathicteen wrote:
Mario's dull pink hat always bugged me. They used pure red for everything else in the game, why didn't they just use pure red for Mario's hat as well?

I never liked the color of the overalls either. It's like the brightness was turned up.

psycopathicteen wrote:
Quote:
Or we could go on to why Nintendo didn't do something to clock the SNES CPU faster.


Nintendo didn't expect anybody to write such inefficient code.

I actually kind of feel the same way. I mean, if developers (excluding Micronics among others) didn't have a problem making games on the 1.78mhz 6502, then they shouldn't have a problem making slightly more advanced games on a 16 bit processor clocked 2x as fast, right? The one thing were this breaks down though is that Nintendo wasn't necessarily the best themselves, but still better than many others.


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 4:06 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 254
Quote:
They should have made tiles for sprites 16x16 like the Turbografx so sprites could occupy all of vram.

The PCE have more size than 16x16, you can have 16x32,16x64,32x16,32x32,32x64 and you can have all that sprites size in your frame at same time,but unfortunately no tiles under 16 pixels . :?

Quote:
SNES and Turbografx sprite capabilities really are about the same aside for vram.

Not really, PCe can use all his VRAM space for sprites .

Quote:
One thing that people are forgetting is that the SNES has more sprites, so it's actually more flexible in that regard, although it's also more to process if you're pushing a bunch of sprites. (I've never seen a game use past 80...)

yes but don't forget more sprites to manage, more CPU to spend for .


Last edited by TOUKO on Fri Jan 29, 2016 4:20 am, edited 2 times in total.

Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 4:15 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tokumaru wrote:
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...

That's because everything in that engine is a slope (walls are just very steep slopes), so it's actually kind of required for enemies to handle slopes in that game. But yeah, even then it's limited: they can handle a height difference of 1 pixel (without any momentum adjustment), but that's it. Becomes obvious with motobugs, where they'll stop immediately the moment they try to go through a 45º slope (i.e. the bottom of a loop). The enemies launching drills in Hydrocity maybe are a better example, since there a few actually placed next to a loop.

Espozo wrote:
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.

The SNES was also being publicly promoted quite early too. It's likely SMW took that long as the hardware was being developed (and also why it looks to take so little advantage of it, it was a constantly moving target).

MottZilla wrote:
For example I've thought that Sega should have outfitted the Genesis VDP with enough Color RAM for 128 Colors instead of 64 and made the Background and Sprites use different section like the NES or SNES does.

That was their original intention, but they ran out of die space ¯\(º_o)/¯ (instead we got less-used features like S/H that took up less room) There's a good reason why the VDP can use an external color DAC, but again that'd have made the console more expensive (ugh).

Espozo wrote:
I never quite understood the hate on the sprite system though. The only real legitimate complain I have is that there's only a fourth of vram available for it.

The hate comes from the fact the MSB of the X coordinate and sprite size are stored separately. Alright, but the real problem is that this area decides to pack four entries into a single byte, making things way more complex than needed and resulting in slower code. Ugh!

For the record, since OAM is in on-die memory, they could have easily just made it look like 768 bytes (i.e. one address per entry) but not store the redundant bits (resulting in about the same amount of die space). Would have made things much easier for developers, even if that most likely took a hit in DMA bandwidth.


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 6:04 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3315
Location: Nacogdoches, Texas
TOUKO wrote:
The PCE have more size than 16x16, you can have 16x32,16x64,32x16,32x32,32x64 and you can have all that sprites size in your frame at same time,but unfortunately no tiles under 16 pixels .

Yeah, I meant, like how the minimum sprite size is 16x16, so I said 16x16 tiles. I'm pretty sure the Turbografx 16 has 9 bits for selecting tiles, it's just that it's going by 16x16 instead of 8x8? I mean, I don't think not having 8x8 sprites is that big of a loss. (referring to not having them on the Turbografx 16 or the SNES with 16x16 and 32x32 sprites selected.) Most arcade machines that I've seen didn't even support tiles that small, although they had plenty more sprite pixels per scanline.

TOUKO wrote:
Not really, PCe can use all his VRAM space for sprites .

I said aside for vram, although that is a big factor. I didn't know the PCE was a male. :lol:

TOUKO wrote:
yes but don't forget more sprites to manage, more CPU to spend for.

True. The one advantage you have to the SNES sprite system has though is that although the total sprite area is the same as the Turbografx 16, it's more flexible in that it can be divided up (instead of a 16x32, you can have two 16x16s) which is nice for shoot em ups, but with how many developers were programing, they couldn't take advantage of that because of limited CPU power.

Sik wrote:
The hate comes from the fact the MSB of the X coordinate and sprite size are stored separately. Alright, but the real problem is that this area decides to pack four entries into a single byte, making things way more complex than needed and resulting in slower code. Ugh!

I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again, although the processing part is still a problem. Like I said though, if you have limited vram for sprites, you'll try to do fancy things to try to make the most out of the space, and if you're doing that, you're taking up more CPU time then you are for the 9th x bit and size bit.


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 6:56 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again

I could say that about most stuff, the problem is getting it to work at all (and performing well) in the first place. For many people that must be a headache. Just because you do it once doesn't mean it won't make you hate it =P


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 7:13 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3315
Location: Nacogdoches, Texas
Sik wrote:
Espozo wrote:
I mean, you deal with it once when you make your metasprite code and you don't have to deal with it again

I could say that about most stuff, the problem is getting it to work at all (and performing well) in the first place. For many people that must be a headache. Just because you do it once doesn't mean it won't make you hate it =P

Well, I just hijacked psychopathicteen's code. :lol: Really though, making a good vram engine is much, much worse. I really feel like Nintendo should have released code to people for handling hioam, like how they did with initialization.


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 7:28 pm 
Offline

Joined: Wed May 19, 2010 6:12 pm
Posts: 2648
This is how it was like back in the day for a developer.

Programmer 1: We need a hi-oam code fast!
Programmer 2: Why don't you just hijack psycopathicteen's code?
Programmer 1: Psycopathicteen isn't even potty trained yet!
Programmer 2: Oh NOOOOOOOOO!!!!


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 7:42 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3315
Location: Nacogdoches, Texas
What the hell?


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 7:53 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Espozo wrote:
Really though, making a good vram engine is much, much worse.

Because you all insist on it. Nearly every game out there just hardcoded the VRAM addresses.

Espozo wrote:
I really feel like Nintendo should have released code to people for handling hioam, like how they did with initialization.

To be fair, do we know if they really didn't? E.g. I know Sega did release some sample code (mainly to show that their devkits worked), but I don't think many developers used it... at least on the Japanese side of things.


Top
 Profile  
 
PostPosted: Fri Jan 29, 2016 8:32 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3315
Location: Nacogdoches, Texas
Sik wrote:
Espozo wrote:
Really though, making a good vram engine is much, much worse.

Because you all insist on it. Nearly every game out there just hardcoded the VRAM addresses.

It isn't nearly as efficient with saving tile space though, which is important on the SNES. The problem with this kind of approach though is that you're not 100 percent sure everything will fit in vram at a given time, but this isn't any different then sprite dropout, and just about every NES game after 1987 has that. Just thinking, 3D systems are kind of the same way. If you were planning everything for the worst, but unrealistic, scenario, then you couldn't get away with as much.


Top
 Profile  
 
PostPosted: Sat Jan 30, 2016 4:27 am 
Offline

Joined: Mon Mar 30, 2015 10:14 am
Posts: 254
Quote:
Yeah, I meant, like how the minimum sprite size is 16x16, so I said 16x16 tiles.

Ah ok sorry espozo :wink:

Quote:
I'm pretty sure the Turbografx 16 has 9 bits for selecting tiles

No, it has 11 bits :)

Quote:
it's just that it's going by 16x16 instead of 8x8

Yes :( ,and you lose some sprite bandwidth when only 8x8 sprites are needed .

Quote:
I didn't know the PCE was a male. :lol:

Of course, and with big balls :P

i'am curious to know how many cycles take to write an entire sprite attributes on MD .

@espozo: Bad coding exist on all systems, doing a good one (in any department) needs a big amount of time.Now we are coding for pleasure, with no deadlines, we have time, and it's easy to optimise our stuffs like hell,redoing code if it's not good enough,etc ..
You absolutely can not comparing nowadays stuff with 90's ones .


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 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