It is currently Tue Dec 12, 2017 6:50 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next
Author Message
PostPosted: Mon Jan 18, 2016 8:03 am 
Offline
User avatar

Joined: Fri Nov 19, 2004 7:35 pm
Posts: 3968
The most tiles updated per frame in any NTSC NES game is the Snake Pit level in Battletoads. 16 tiles for Rash, 16 tiles for Zitz, and 24 tiles for the snake animations, diagonal scrolling, and a top status bar that begins 31 scanlines into the screen. The patterns for the snakes are simple, so multiple consecutive values can be stored without reloading anything.

_________________
Here come the fortune cookies! Here come the fortune cookies! They're wearing paper hats!


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 6:32 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
I still think the tile update portion of that idea is possible but as Bregalad mentioned, the palette aspects make it more graphically limiting than other options. Every character and background would have to share the same palette, per level.

Also, I don't think it would take both CHR-ROM and CHR-RAM. I believe I mistakenly said something about drawing to CHR-RAM from CHR-ROM but I meant PRG-ROM. I'm sure the program itself wouldn't have to be too big. Graphics on the other hand, think of how many KB of tiles per character you want. BG characters will have to be stored both ways, unless you reverse in CHR-RAM. I was thinking like a bank-swappable MMC3 with CHR-ROM replaced with large CHR-RAM.

Anyway, you're right though that the idea I had would be too limiting to work. What do you need help with, just graphics? I've done some work with scanline splits but I'm sure it's not as good as what you'd program.

Edit: Just a couple typos


Last edited by darryl.revok on Mon Jan 18, 2016 8:10 pm, edited 1 time in total.

Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 7:29 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
For fighting games on the NES, I'm a fan of the idea of having one character use the background and the other use sprites. If they're always facing each other, like is common in fighting games, you don't even have to store flipped versions of the graphics, you can simply switch which character uses sprites and which uses the background as necessary.

The biggest drawback of this method is that the background has to be blank anywhere the fighters can go. You could maybe decorate that flat area a bit with sprites so it doesn't look so dull, being careful to never use more than 1 or 2 sprites per scanline, as any more than that would cancel the advantages of having one of the fighters use the background.


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 8:08 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
One thing I was thinking about is that all projectile attacks will have to be sprites, since they can't move horizontally at a different speed than the BG character. That might make it tough to have sprites left over to decorate the backgrounds.

Multiple projectile attacks on the screen will have to flicker a little, but i don't think that's bad for projectiles, and we can leave the ones that define the hitbox so that a player never loses track of that with their eyes.

I would personally treat the background character as an object, so collision testing would be the same with the sprite object. Then offset the scroll of his background strip based on his object's X/Y position.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 12:05 am 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
tokumaru wrote:
If they're always facing each other, like is common in fighting games, you don't even have to store flipped versions of the graphics, you can simply switch which character uses sprites and which uses the background as necessary.

Actually there's an awfully common situation in fighting games where both players can be facing the same way: when one player jumps above the other, and the latter is still performing a move when the first one lands (players don't turn around until they're done performing their moves). Until the second player is done with that move, both players will end up facing the same way.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 1:44 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7314
Location: Chexbres, VD, Switzerland
darryl.revok wrote:
Also, I don't think it would take both CHR-ROM and CHR-RAM. I believe I mistakenly said something about drawing to CHR-RAM from CHR-ROM but I meant PRG-ROM.

No, it's not about your typo. You'll admit that your idea required CHR-RAM to scroll a (or both) fighter(s) while having a background there. However it also might need CHR-ROM in order to get new animations in fastly for the sprite part of the fighters. Anyways this is overly complicated and a bad idea in general.


Quote:
For fighting games on the NES, I'm a fan of the idea of having one character use the background and the other use sprites.

Yes, the problem is that since this technical feature is the only reason we're interested in the project at all, we'll loose interest as soon as the game "engine" is done, and will never get a fully functional game. Once again. That's why I was more aiming at a tech-demo anyway, leaving the possibility to get a full game open.

Quote:
I would personally treat the background character as an object, so collision testing would be the same with the sprite object. Then offset the scroll of his background strip based on his object's X/Y position.

That seemed obvious from the very start to me.

Quote:
What do you need help with, just graphics?

Well yeah, *just* graphics. I am not a very skilled artist, and designing/animating 4x8 or 5x10 tiles sprites is harder than the usual 4x2 we're more used to. I mentionned that project because it's the only project where I needed animation done. I'm sorry for completely highjacking your thread.

Quote:
Actually there's an awfully common situation in fighting games where both players can be facing the same way: when one player jumps above the other, and the latter is still performing a move when the first one lands (players don't turn around until they're done performing their moves). Until the second player is done with that move, both players will end up facing the same way.

Oh no! I guess you're right. We'd have to somehow get around this.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 8:42 am 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
Hum... I hadn't considered this case when both characters are briefly facing the same way. If this is an original game you have the freedom to cut any ongoing moves short and have the character immediately turn if the other one jumps over their head.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 2:41 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
Wouldn't that feel odd when playing, though?

Maybe just duplicate all of CHR-ROM, with the second half having every tile flipped. Then when somebody complains that it'd have been unfeasible, just say that back in the day it wouldn't have been duplicated and the MSB of the address was used to flip the tiles instead ;)


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 6:43 pm 
Offline
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10164
Location: Rio de Janeiro - Brazil
I don't think it'd feel odd... Odd would be someone in real life continuing to perform an attack on nothing after realizing the opponent jumped over their head.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 7:26 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19335
Location: NE Indiana, USA (NTSC)
Once you're in the follow-through of an attack, though, it's hard to pull out of it.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 8:50 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5892
Location: Canada
You're doing all this to avoid doubling the needed CHR-ROM space for flipped background version. As an alternative you could: half the number of characters, half the required frames of animation, or half the character size (or any partial combination of these things).

If you used bankswitched CHR-RAM big enough to hold all needed tiles for a fight, you could at least save on ROM space by flipping in software on load.

You could also build a mapper that knows how to swizzle CHR data lines. Punch Out got a custom mapper for its specific large-character needs; how about your game?

It's really a question of which of these options seems best for your situation. There's no actual situation being discussed here AFAIK, so I'm tempted to use one of these ¯\_(ツ)_/¯ but maybe you enjoy the debate, so don't mind me.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 10:42 pm 
Offline

Joined: Thu Aug 12, 2010 3:43 am
Posts: 1589
rainwarrior wrote:
You're doing all this to avoid doubling the needed CHR-ROM space for flipped background version. As an alternative you could: half the number of characters, half the required frames of animation, or half the character size (or any partial combination of these things).

But then it's doubled again in comparison to the new requirements, so we're back at complaining about the same thing. Unless there's some reference CHR-ROM size to compare against, that kind of suggestions don't really work.

rainwarrior wrote:
You could also build a mapper that knows how to swizzle CHR data lines.
Yeah, this is what I suggested (doubling all graphics was just a way to fake it without custom homebrew chips)...
rainwarrior wrote:
Punch Out got a custom mapper for its specific large-character needs; how about your game?

...and screw that turns out that you could just argue Nintendo did it.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 11:04 pm 
Offline
User avatar

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
Who even cares about if it's what they would have done then? If I ever get around to really making an SNES game, memory is going to be my last concern, because memory is cheap now. If many developers just added more memory to their cartridges, we would have seen much more accurate ports on these older systems, and I thought that it's cool to show off what these systems are capable of without the unnecessary constraints like that.


Top
 Profile  
 
PostPosted: Tue Jan 19, 2016 11:55 pm 
Offline
User avatar

Joined: Sun Jan 22, 2012 12:03 pm
Posts: 5892
Location: Canada
Sik wrote:
Unless there's some reference CHR-ROM size to compare against, that kind of suggestions don't really work.

The entire situation is hypothetical, so if you want to argue what "really" works I'm just going to...
rainwarrior wrote:
¯\_(ツ)_/¯


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

Joined: Mon Sep 15, 2014 4:35 pm
Posts: 3153
Location: Nacogdoches, Texas
¯\_(tsu)_/¯


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 60 posts ]  Go to page Previous  1, 2, 3, 4  Next

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google Adsense [Bot] and 3 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