It is currently Fri Oct 20, 2017 10:03 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: Sat Jan 16, 2016 11:48 am 
Offline
User avatar

Joined: Fri May 08, 2015 7:17 pm
Posts: 1780
Location: DIGDUG
Quote:
256KB is even a little small for me


What about Membler's GTROM...

Quote:
GTROM (512kB, 32kB PRG pages, and banked
CHR-RAM)

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


Top
 Profile  
 
PostPosted: Sat Jan 16, 2016 1:24 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
darryl.revok wrote:
Making the character jump isn't going to be any trouble. The only real problem is that you've then got a solid color behind most of the playing field.

It's no major problem, but it increases the complexity of scroll split (needs to scroll bidirectionally instead of single-directionally), and removes the possibility of using horizontal lines background instead of plain colour. I was planing to go with plain colour anyway so it does not matter.

The second problem with jumping is that it greatly increase the height of the plain colour band, and as such, greatly reduce the heigth of arena graphics (no matter if they're top or bottom). Let's say if a fighter is 10 tiles heigh and don't jump, and the status bar is 4 tiles high, and that we can't use the top/bottom 2 tiles because of overscan.

Then the amount of tiles for arena is : 30 - 2 - 4 - 10 = 14 tiles

But now if we have the character jump it's own heigth, then 20 tiles should be reserved for the character alone.

The arena's heigth becomes : 30 - 2 - 4 - 20 = 4 tiles.

Obviously that's a major problem. Basically the screen will be a narrow status bar, a narrow arena, and a huge blank area. Not very good looking.

The only real solution is limit the height of the jump to much less than a character's own height. Or have smaller characters. Or a mix of both.

Quote:
I wouldn't sweat the extra scroll split at all. Once you get far enough to have one, making another isn't any trouble. Are you using MMC3?

I'm using NROM right now, but if this turns into a game it of course will use a more complex mapper capable of CHR-banking. I don't know if MMC3 will be necessary, if it is, then having a bottom area for arena graphics is doable, except for the screen space problem I mentioned above.

Since screen space will be so limited anyway, I thought I could just as well get rid of the bottom arena part, and have a few sprites doing the job of filling the very bottom of the screen. Especially considering the sprite fighter character will take only about 25 of the 64 available sprites (using 8x16 sprites).


Top
 Profile  
 
PostPosted: Sat Jan 16, 2016 6:10 pm 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
dougeff wrote:
What about Membler's GTROM...

If I remember correctly, the GTROM wouldn't work because it didn't have fine grain CHR banking for sprites.

Since my characters have around 16kb animation, they're pretty much restricted to needing their own CHR bank.

Although, I really like the direction that Memblers is taking with his boards.

Bregalad wrote:
The second problem with jumping is that it greatly increase the height of the plain colour band


You could scroll the screen vertically a little when people jump to get a bit more at the top and bottom but that's still not going to solve the issue of most of the visible screen being a solid color.

Have you given any thought to making a fighting game with sprites? I know it's going to limit the size of the character but I feel like the overall game might be limited less. Let's say you use all 64 sprites on the characters and somebody throws a haduken. Well, you could just render the haduken every other frame. Being that it's translucent, the flicker won't even look bad. Then you could set it up so that just the low priority sprites of the fighters flicker out, leaving the ones to define the shape. The characters would probably have to end up being smaller than a traditional fighter, but it's a trade-off.

Something else that I feel is worth considering is the two button limitation. This is just my opinion, but I don't think anybody's ever going to be able to, for example, recreate the experience of Street Fighter II on the NES. If nothing else, the lack of buttons is really going to hinder that. So, just to throw it out there, I feel like an NES fighter needs something unique in the gameplay department. I'm not saying something complex, quite the opposite. A unique gameplay mechanic that is simplified enough to be really fun on the NES. Something that makes playing this fighting game different from any other for reasons other than just being on a lower powered system.


Top
 Profile  
 
PostPosted: Sat Jan 16, 2016 7:32 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
In other words: clone Smash Bros. instead of Street Fighter.


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 1:58 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
darryl.revok wrote:
Have you given any thought to making a fighting game with sprites?

To be honest I haven't because I tought this was probably already done. It would limit the technical challenge, and such, loose my personal interest for such a project.

This would basically limit sprites to 4 tiles horizontally for the typical, not much smaller to what I have proposed.

However the worst case has to be considered, and that is the case where both fighters lie on the ground, so their whole body lies horizontally. We could design the game so that's impossible, so only one fighter can be knocked out simultaneously. Then, we can imagine that the standing fighter is 3 tiles wide and 6 tiles high, while the knocked-out fighter is 6 tiles wide and 3 tiles high. There would be a little flickering, and the characters would be only 6x3 tiles.

With my sprite/BG scheme, the lying character on the ground can take all 8 sprites for himself, and such the heigth limit is 8 tiles (so all what I said before about a heigth of 10 tiles is completely wrong, as I had forgotten that detail).

In order to keep the traditional 1:2 ratio, thet would make the characters 4x8 tiles when standing, and it's probably why I only used this size in the demo, even though it supports more.

Annother approach would be to store the tiles for the knocked out character twice in the ROM (for both directions), and alternate the BG/sprite character on the fly, so that whether a character is knocked out, he becomes rendered by BG, and the standing one is rendered by a sprite. This also forbid a situation where both fighters are knocked out simultaneously, unless flickering becomes acceptable in this rare case. Anyway, this is required only if larger characters are desirable, and because of the vertical screen space problem we don't know if they are.

Quote:
Let's say you use all 64 sprites on the characters and somebody throws a haduken.

As much as I love this move, it would be an obvious copyright infringement, so I wouldn't use anything like that in any game I'd ever program.

Quote:
Something else that I feel is worth considering is the two button limitation. This is just my opinion, but [...]. A unique gameplay mechanic that is simplified enough to be really fun on the NES. Something that makes playing this fighting game different from any other for reasons other than just being on a lower powered system.

I agree. I don't know how a game could be so unique though, fighter games are in general only interesting because of their characters, and still...

I guess having such large "sprites" on the NES would be unique by itself, but if you forget the "on the NES" part then you get a very bland, generic and uninteresting game that is less fun than Street Fighter, and that lacks hadokens as well as any interesting moves. If jumps aren't allowed then it becomes even flatter/blander.

EDIT : Yet another solution to the "knocked out" problem would be to completely change the approach: Instead of having the character knocked out lying horizontally like you'd traditionally except, we could make he lying vertically, so that he would be positioned along the Z axis. It would look strange, but maybe if the art is good this could work great, and get rid of all the issues I mentioned about rendering knocked out characters. Or, even simpler, make a fighting game where characters aren't knocked out during the fight, and are only "dizzy" no matter what happen.


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 6:43 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
You can bend the legs in various ways when the character's are lying down so that the sprites don't have to be as wide as they're tall when standing up.

I'm also not against the idea of rotating the fighters so that their feet are facing the camera when they're down, if this rotation is visible in the animation. It would actually look pretty cool if they spun in the air before falling to the ground.


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 7:00 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19113
Location: NE Indiana, USA (NTSC)
Bregalad wrote:
darryl.revok wrote:
Let's say you use all 64 sprites on the characters and somebody throws a haduken.

As much as I love this move, it would be an obvious copyright infringement, so I wouldn't use anything like that in any game I'd ever program.

In context, I read it as a generic projectile move. (Kaa... meeee... haaaaaa... meeeeeeee.... HADOKEN!) If that's protectable, then Capcom should sue Nintendo over Luigi's neutral B and Ness's forward B in Melee and Brawl. But Capcom won't waste lawyer money on that because it lost last time it tried that (Capcom v. Data East).

Make a "Heineken". (source 1 | source 2)


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 7:48 am 
Online
User avatar

Joined: Sat Feb 12, 2005 9:43 pm
Posts: 10065
Location: Rio de Janeiro - Brazil
The Hadouken is the most generic energy attack ever (at least in the game, where there's no characteristic build-up like in the Street Fighter II Victory anime series), so you definitely shouldn't worry about fighters shooting energy balls.


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 8:46 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
Bregalad wrote:
It would limit the technical challenge, and such, loose my personal interest for such a project.

Surely that's not the only way we can find to challenge ourselves. Granted, with a two player fighter not requiring map-based collision and limited scrolling, I bet it would be way under the amount of processing available.

What's the main goal? Is it a tech demo? A fun game? I'm all behind the idea of making a community project of it. Is there anyone who's particularly good with planning and coordination? Perhaps we should start with an outline of the idea.

This is a silly idea I had but one that could be fun. What if we let every active member who wants to be involved have a character? Some sort of nesdev community brawl. Just a thought.

Quote:
we could make he lying vertically, so that he would be positioned along the Z axis.

To me this seems like the best solution as the one that imposes the least restrictions on the overall design of the game.

I'd see doing things like moving sprites into BG more along the lines of "stretch goals" personally.

I'm most behind the idea that gets people excited about getting the game going. So if people here are more behind doing a system with BG character then I would be too. In any case I think it would be cool to see the basis of a game get formed. Even if it's on a rough engine. Maybe people will see the project coming and say, "Ahhh let me fix this part here!"

Quote:
I don't know how a game could be so unique though, fighter games are in general only interesting because of their characters, and still...

I don't really agree that that's the ONLY reason they're interesting. A huge part of it, sure, but bad play mechanics ruin a fighter completely. Mediocre mechanics with good characters get forgotten easily.
tepples wrote:
In other words: clone Smash Bros. instead of Street Fighter.

Honestly this was a little more what I was thinking. I think utilizing X-Y movement and some platforming might play to the strengths of the options we have available. It's just one way to consider it.
Quote:
In context, I read it as a generic projectile move.

That's exactly what I meant. Of course we shouldn't use any intellectual property that we don't own. I'm sure our characters will shoot some sort of projectiles though.


Top
 Profile  
 
PostPosted: Sun Jan 17, 2016 1:19 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
tepples wrote:
Make a "Heineken". (source 1 | source 2)

Great joke, I'll certainly want to wear a tshirt like this!

Quote:
I'm also not against the idea of rotating the fighters so that their feet are facing the camera when they're down, if this rotation is visible in the animation. It would actually look pretty cool if they spun in the air before falling to the ground.

Cool, it's good to know I can still have great ideas sometimes, even with my advanced age.


Quote:
The Hadouken is the most generic energy attack ever

This attack is what break the monopoly of punches and kick, and is why I'd sooner play Street Fighter rather than anything else. I do not manage to pull more advanced combos, other than by pure luck. However it seems it was heavily inspired by the Dragon Ball universe.

Quote:
What's the main goal? Is it a tech demo?

To be honnest my main goals were a tech demo about a figthing game, which could possibly be later turned into a game. I'm pretty sure fighting games with sprites only have already been done over and over, and such are as interesting as their content - doing a fighting game isn't interesting per se. But if one character is BG, then this is an interesting use of the NES hardware.

It goes completely oposite of the philosophy "make games - not engines" and definitely have low chances to end in a full sized game, I rekon.


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 12:37 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
I just had an idea, what do you think of this:

It kind of goes along with the thought of shifting some parts of the sprites into the background.

What if the characters were sprites, and then instead of flickering sprites when a scanline holds more than eight, actively combine the sprites with the background tiles and update to CHR-RAM.

If that engine could be devised, I think that might be the ultimate option. Then you could have as detailed of a background as you want and not have to store left and right facing tiles of your characters. CHR would end up becoming the limiting factor on making a game from this engine.

Just brainstorming, the idea may be a little challenging but I think it's doable. If we don't scroll and essentially do nothing else but play music in NMI, we could even blank out a little on the top and have plenty of time to upload tiles. Like I said before, I bet calculating the collisions and damage stats will leave enough headroom to potentially prepare the tile updates.

Drawing a tile, the program would need to analyze the sprite and replace any pixel which is color zero with the color of the BG tile underneath. The characters would most likely have to be stored in CHR to the shape of their animation, so they can be referenced and combined with a BG tile offset by X-Y position.

We'd also have to switch CHR banks in NMI. That's quick.

I'd say go with vertical mirroring so we can have a two screen width without having to write to nametables. Then we could slightly expand the vertical screen when characters jump by vertically spreading BG layers on scanline IRQs.

What do you think of any of these ideas?


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 1:53 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
That do not sound feasible, as it have the same problem I already mentionned with using CHR-RAM for animation : The CPU to VRAM bandwith is too low. It could be feasible only if the animations are seriously slowed down, and for a fighting game I belive this is unacceptable.

The Game Boy version of Street Fighter 2 does exactly what you describe, but I personally think this version suck.


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 2:45 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
But what if you only wrote the ones to CHR-RAM that needed to "flicker" out?

Also, if you needed more time, make the game in 16:9 to fit modern TVs and you'd have a ton of time outside of rendering.


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 4:05 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7232
Location: Chexbres, VD, Switzerland
Then it'd require a mapper that has both CHR-ROM and CHR-RAM, such as TQROM. And even then I'm not sure it'd be feasible, in the case of 5x10 tiles sized characters, we'd have to rewrite aprox. 3 columns and maybe 6 or 7 tiles height for both characters, so 48 tiles, definitely not doable at 60 FPS. Even if we limit to 2 colums (that would work, but not allow any other sprites, as each character would use 4 tiles) we'd have to rewrite at least 24 tiles, and that's still too much.

I didn't even approach the huge problem it's going to be with palettes, but it seem like a poor idea overall. Either using only sprites or using one character sprite + one character BG are the most sensible solutions.


Top
 Profile  
 
PostPosted: Mon Jan 18, 2016 4:48 am 
Offline
User avatar

Joined: Sat Jul 25, 2015 1:22 pm
Posts: 501
You're right. The palettes alone make that not possible.

Although my idea would have been to only write maybe around 20 tiles max, the excess ones. That much would be possible with some extra blanking time.


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: No registered users and 1 guest


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