Hello,I used to make some little demos for the NES, but I'd quit quickly. The most original thing I've done is a music demo containing GGSound with my composition and some sound effects along with some button macros such as 4-state button presses (not pressed, just pressed, held, just released).

Outside of that, in Game Maker Studio, I have a game engine in which every game entity contains configurable bool values and integers regarding speed, jumping, gravity, bouncing, enabling collission, etc. and it works very well! I could apply that on the NES, but I'm not sure about how to render during V-Blank while the game executes during screen rendering. Should I have some kind of a queue or something? If yes, how do I avoid corruption when both the NMI and basic thread access the same variables used by the queue? There's so much to theorize about, but I need someone who's more experienced in this than me.

It's so easy for me to theorize about what an NES program should have, but I quickly lose inspiration when I realize that I'm still at the beginning. This is what I call a code block. But when I'm programming with someone, it's more easy because I feel like wanting to impress the person when they say "Hey, do this for me." and so I do it and also I can have someone who listens to my ideas and makes them work while I'm in theorizing mode.

I'm thinking about a fighting game with a character selection screen. It's about playing tag while avoiding TNT. Kinda like SMB3 battle, but imagine you're playing tag whie being chased by a TNT crate. The game should have many characters through bankswitching through their sprites.

I could do the game entity mechanics and the game logic while I'd like someone to collaborate with me to do the system part. It can be in NESASM3 or in cc65, but I prefer NESASM3. I've never tried cc65, but I know almost everything regarding C and its pointers and typedef structs. I used C in programming a microcontroller for my high school final project. Is someone interested in working with me?

If yes, how do I avoid corruption when both the NMI and basic thread access the same variables used by the queue?

The main thread sets a variable stating whether the data in the buffer is ready to transfer to VRAM. If it is false during NMI, the NMI handler doesn't perform the transfer. If it is true, the NMI performs the transfer and then sets it to false.

Quote:

The game should have many characters through bankswitching through their sprites.

There are two ways to do this: either load the into CHR RAM or use MMC3 to bankswitch a CHR ROM. It depends on what you want and how many frames of animation there are per character. That's a lot easier to see with a mock screenshot and a sprite sheet of one character.

There are two ways to do this: either load the into CHR RAM or use MMC3 to bankswitch a CHR ROM. It depends on what you want and how many frames of animation there are per character. That's a lot easier to see with a mock screenshot and a sprite sheet of one character.

I remember when I was studying MMC5. MMC5 has 8 CHR bank spaces. I'd do it like this: Two for each player's character, the other two for in-game objects such as powerups, TNT and explosions, and the other 4 which are the background for the level and ASCII characters.

But I still need someone to collaborate with me where we can both write code in real time.

I remember when I was studying MMC5. MMC5 has 8 CHR bank spaces. I'd do it like this: Two for each player's character, the other two for in-game objects such as powerups, TNT and explosions, and the other 4 which are the background for the level and ASCII characters.

But I still need someone to collaborate with me where we can both write code in real time.

Actually the MMC5 allows 8k CHR for sprites and 4k CHR for background.

I remember when I was studying MMC5. MMC5 has 8 CHR bank spaces. I'd do it like this: Two for each player's character, the other two for in-game objects such as powerups, TNT and explosions, and the other 4 which are the background for the level and ASCII characters.

But I still need someone to collaborate with me where we can both write code in real time.

Actually the MMC5 allows 8k CHR for sprites and 4k CHR for background.

Actually the MMC5 allows 8k CHR for sprites and 4k CHR for background.

Plus whatever other CHR for background you can switch in using a timer ISR, or you can splurge with ExGrafix. But practically, I have no idea what size of CPLD would fit even the subset of MMC5 functionality that doesn't use ExRAM.

Actually the MMC5 allows 8k CHR for sprites and 4k CHR for background.

Plus whatever other CHR for background you can switch in using a timer ISR, or you can splurge with ExGrafix. But practically, I have no idea what size of CPLD would fit even the subset of MMC5 functionality that doesn't use ExRAM.

Is there a problem with using MMC5? If it is, is there another mapper that has 8 banks for CHR?

MMC3 has 2 2K windows for background and 4 1K windows for sprites (or vice versa). VRC4, VRC6, VRC7, and FME-7 have 8 1K windows. All can be usefully subset to fit in the CPLD that Infinite NES Lives is using, so long as you don't try to include VRC6/7 audio.

But I still haven't got the answer to my question. Would someone want to collaborate with me? By collaborate, I mean talk on Skype and do some real-time coding together and such.

Oh, I apologize for not answering your question and being offtopic. It seems like you are not being very specific on what kind of collaboration you'd like. Personally I'd be happy to help someone make his game as long as I get help on my game back, for instance, I have been developping my game since 2005 and it's still unfinished... that should give you an idea how "efficient" I am. And I have plans for at least 4 other NES games as well, so if I ever finish this before I'm 80 years old it'd be a miracle (some of those "plans" are very vague though).

Many purely online collaborations are fragile for several reasons. The project that almost worked out for NESdev collaboration was the idea to have a NESdev collaboration fighting game. (note : The idea is apparently 9 years old, already ! Man times passes fast). A fighting game is relatively simple and by it's own nature it makes collaboration easy - each person simply submit characters to the game. The problem is that the NES is not really suited for fighting games because of it's weak sprite hardware.

Here are my ideas.In the game, there will be 16x16 or 16x32 characters for fighting. I'm thinking about Vigilante Ninja 2, Super Bat Puncher, Nova the Squirrel and a character I used to use in my silly romhacks called Ćiko (it's a play on a Bosnian word for "random man" or "uncle").The game will be a 2D platformer with 2 players. Each character will have its moves, normal attacks, powerups and special attacks.Ninja:B=SwordDown+B=SlideUp+B=Special WeaponSpecial weapons=Ninja star, tsunami, etc.

Super Bat Puncher:B=Boxing glove (can bounce SBP off of walls and make him roll into a ball if he has a powerup)

Nova:B=Immitates attacks

Ćiko:B=Laser gunPower up=Motorcycle

Each player can damage another by jumping on the head or by attacking him. There will be blocks like in Crash Bash to pick and throw such as brick blocks and TNT blocks as in Minecraft and Crash Bandicoot. Bricks to smash with your head and bump a player above it.

You basically play tag. If you're tagged, your timer is running out. When it reaches 0, a block of 2 tons inevitably falls onto your head and you lose; the other player gets a point. If you get hit by a TNT, you lose a bit of your time as a penalty and both of the players respawn at the initial position as an extra challenge. These settings can be tweaked for each game.

There are 8 PPU bank spaces.1k for Player 1's sprites which bankswitches by the need of Player 1's sprites.1k for Player 2's sprites, same as Player 1.1k for all the powerup sprites that all the characters have in common such as the boxing glove and the ninja star and the tsunami and etc1k for the game's things such as explosions and floating score numbers and such.2k for ASCII characters from 32 to 127 and common in-game blocks2k for level design depending on which level is being played. It can be animated like SMB3 blocks.

The game never scrolls because it's a 2D stage.

We'll use GGSound for the sound and FamiTracker for the soundtrack and sound effects.

I need someone to make the skeleton of the game with all the V-blank stuff, PPU buffering, sprite rendering API, etc.. I'll do the game physics and game entity programming as I know how to do that part. I might do the FamiTracker part too a bit.

If you ask me, about the PPU thing, I'd like it that we use MMC5 and its internal VRAM for the nametable so that we don't need to wait for VBlank, lol.

Now, we'll need permission from those whose characters will be in the game.

Who is online

Users browsing this forum: Google [Bot] and 7 guests

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