Russian Roulette [Complete!]

So basically, I'd like to have this: https://www.youtube.com/watch?v=-sXgJauYdMw turned into this: http://2.bp.blogspot.com/_pQPcqyPsbHc/R ... /trans.jpg

But this is my first NES project, and I don't know how to program.

That's why I decided to fund this project. But first I'd like to know who's interested and whether you'd like to work on a team and how this project can be split up if need be.

I'd also like to know what a good estimate is for how long it'd take to complete a project like this.

Oh yeah! I do not intend to sell cartridges; I intend to release the rom publically. With that said, I wouldn't be against anyone wanting to make a cart for themself.

Please let me know if you have any questions. You can PM me, but I'd like to have a public discussion of this first.

I'd say this would be around 6 hours, plus maybe 1-2 hours for tuning. My rate is 40$ per hour.

That's assuming the music/sfx is already in FamiTracker and famitone compatible, and the art is made in a NES-compatible way. It would need in writing the difference of game A and B, and what buttons should react, just in case the video was interpreted differently.

For such a small game, I don't think a team is necessary, but I don't mind working in a team. You could also release the source publicly if you wanted.

edit: The obvious split would be the music/sfx, if they're not in famitracker yet. I'm not good at that, so it would be better to hire someone who is.

Art I can convert if it's not suitable as-is, but that would take some time.

Is converting the art included in this estimation?

I'd be willing to hire someone alone to handle the graphics conversion and someone else to handle the sound conversion.

Here's a brief design document and a screen map to better help understand the flow:

What about the art really needs to be converted? I saw the video, and everything looks perfectly feasible. You mean just like laying it out in CHRROM and not actually redrawing it?

I assume laying out the tiles and separating backgrounds from sprites is more involved than it looks.

I know the revolver and hand would be sprites, and the faces would be background. Not sure about the spinning chamber though.

I don't even know how to get started with NES Screen Tool yet.

When working without the actual restrictions, it's very easy to accidentally use too many colors, not 8-align things, and other mistakes of that sort. Those things might add an hour or two if they're there.

The separating into CHR tiles was included in the original estimation.

The A vs B difference is that B has three bullets, 50% chance, correct?

I guess I am somewhat of a slow programmer, but I'm finding this 6-hour estimate to be terribly optimistic! Even the most basic of the games requires a good framework to handle game modes, screen transitions, VRAM updates and the like. Unless you already have a generic framework ready you can immediately develop a game on top of, you'll spend at least a few hours on that before you can even get started on the game itself. Unless you plan on hacking the game away screen by screen without a proper foundation, which I definitely don't recommend.

If I was coding this, I definitely couldn't come up with anything in less than 3 workdays or so, but if probably need more than that to fix bugs, polish things up, and organize the code.

I actually recently had to create a basic NES framework. I feel like six hours isn't a bad estimate for a rough pass, but probably not for a finished thing. That said, I'd probably not really charge much of anything over that even for the finished thing just because it'd be interesting to make some money doing this. But I'm currently working on another project, hopefully done relatively soon. If nothing happens before that's out, I guess I'll drop a quote too.

Yeah, I'd encourage everyone to post public quotes here. I haven't seen any such topic, so it might be good direction for future browsers too.

edit:
I'd use neslib and write in C, perhaps the framework comment was more about asm?

For a minimal game with a completed prototype, and (potentially) all the art assets? 6 hours is being generous, honestly. I agree that the sound/music could severely slow things down, though.

From my own NES experience, I wrote a Bubble Bobble clone for CollectorVision back in September, during a marathon coding session, in only 5 hours. Start to finish.

I showed the game to John Romero, as well. He was impressed with the quality, given the time frame. (Something about 48-hour Game Jams, and lack of efficiency was mentioned.)

...Not sure if that game is going to be published.

Yeah, I agree that the final cost estimate sounds reasonable for this project, but if it was me coding it, I'd need way more than 6 hours to finish it.

Is there a program that detects how many colors there are within a window? I've always wanted a tool like that.


Yes.

So it's been 3 days, and there's yet to be more responses. I still think 3 people is a good team for this project (graphics, sound, coding). I just need estimates. Since I have two people who are currently working on projects but are still interested, I'm willing to wait.

Feel free to give me your input.

You can take a screenshot of a window, and then analyze that in a paint program. In Windows, it'd be alt-printscreen, then paste into Gimp or similar. Gimp shows the color count in info->colorcube analysis.

I haven't received a single response in the two weeks since I've made my last post. So, calima, if you're still up to the task, I'll hire you.

But I really want someone dedicated to converting the sound. Should I make a separate post in the Music section?

Sending PM for details.

What format is the sound and music originally in?

Famitracker

Extensive progress has been made on this (thanks, Calima!), and now we need someone with a flashcart to test it on hardware.

The lightgun support in particular is ambiguous. At the title screen, shooting away from the screen should select the next option and shooting the screen should start the game (much like Nintendo's zapper titles worked). But I get different results on different emulators.

I appreciate your cooperation, everyone!

I'm guessing that most of the graphics aren't supposed to be garbled and unrecognizable?

If that's correct, then there is at least a conflict with an Everdrive N8 in a top-loader NES.

Can confirm that the graphics are garbled on a PowerPak and frontloader too.

The initialization code doesn't initialize the whole MMC3. Every register on the mapper should be presumed to have an unknown state on power-up, unless otherwise specified. Emulators don't tend to randomize these things on startup (for stability reasons it's often preferable to have a consistent startup state).

Banks 6, 0, 1, 2, 3, 4 are initialized. ($8000/$8001 pairs)

Bank 5 (CHR $0C00-0FFF) is uninitialized.
Bank 7 (PRG $A000-BFFF) is uninitialized.

The other registers (mirroring, PRG RAM, IRQ at $A000/$C000/$E000) are all uninitialized.

Thanks rainwarrior.

Bank 5 is set later on, when it's actually used, and bank 7 is not used at all, so I don't think it matters what it points to? Mirroring doesn't matter since we don't scroll.

Unless the mmc3 somehow doesn't acknowledge the last R6/R7 write, but rather expects all eight to match?

PowerPak/ED problems are probably caused by non-power-of-two CHR size.

Here's an updated version that sets the PRG RAM register, dummy switches for banks 5 and 7, and disables IRQ.

FCEUX tells me that there are 19 8KB CHR-ROM pages, which is really odd! Memory on the NES should always be in powers of 2, so you should try increasing that to 32 x 8KB, even if you don't have any actual graphics in these 13 pages.

Updated with CHR padded to 256kb.

Anybody else getting graphical glitches whenever the trigger is pulled in-game (on an NES)?

Trying on a powerpak now. The initialization didn't change anything (I think you were right that it doesn't matter; though it doesn't hurt, I suppose). Padding CHR out to a power of 2 did help though. Seems to be running correctly.

I do not see any graphical glitches, Jedi.

I do wonder why the battery backed RAM bit is set. When I reset, the PowerPak wants to save RAM for me. Does this game really have a save?

Yeah, the four high scores are saved. Of course you'd want to keep your mighty score til eternity

Are you using a lightgun?

Had not tried with the zapper (I don't have a CRT, and when you said "trigger" i thought you just meant the in-game trigger).

Tried it now. No problems in 1 player mode, but in 2 player mode if I pull the zapper (in port 2) trigger when it's player 1's turn, I get severe graphical corruption. Looks like nametables are messed up kind of randomly, and also the CHR banking gets changed.

Here's an update to the rom:

The main issue I've noticed now (on my side at least) is that the zapper trigger doesn't always register a trigger pull in-game. Let me know what other issues you run into. Thanks everyone!

I don't see any graphical problems with the zapper anymore, but the trigger is really unreliable. I might have to pull it 10 times just to get the shot to fire.

You might take a look at how Duck Hunt or other games read the zapper trigger. There's usually some kinda debounce filter going on.

I wrote some Zapper test ROMs a while ago when I wanted to know what kind of signals you get from the zapper. It's a bit of a mess, really.

Are those test roms open source?

They seem to work fine:

zapper_light.nes makes a buzz whenever the zapper is aimed at the white space (with precision) and sometimes goes off a little when I wag the lightgun at my bright, flourescent lights

zapper_trigger.nes is very interesting! The buzz goes off when the trigger is partially pulled (there is an audible click in the zapper itself), but the buzz stops when the trigger is completely pulled. (I didn't know the lightgun could do this.) Is this how the test is supposed to work?

Edit: Oh yeah, thanks!

I can't seem to find the source, but as I recall both ROMs just continually poll either the "light" or the "trigger" bit; if set it flips the value written to $4011 (buzz) and waits until the next NMI to start polling again.

Yes the trigger starts to signal on about halfway into a pull, and it turns off somewhere roughly on the "zap", and there's a lot of bounce/noise at either transition. (Slow pulls are particularly bad.)

There's also no way to distinguish half pull then release from pulling to "zap". Either way counts as a shot, generally.


Edit: I found the source, cleaned it up a little and posted it in that thread.

Is this going to be a Compo entry? I was thinking so since you linked it from the Compo planning thread.

Just thinking this could be moved into the Compo 2016 subforum.

Sure, that would be splendid.

Here's the latest update.


I'm getting graphical glitches again; this time horizontal bars in certain tile spaces. Anyone else noticing these?

Where are you running it?

This diagnostic from NDX might be a clue:
(Appears when the DEMO mode starts.)

There was/is a glitch in most PowerPak mappers causing PPU writes during rendering (which signifies a bug in the program 99.9% of the time) to leak through to PowerPak's CHR-RAM chip. Details at viewtopic.php?f=9&t=11339.

I worked around the glitch in PowerMappers v23 (at https://kkfos.aspekt.fi/), but naturally this is something that's better fixed in the game itself.

ebfa is inside the NMI routine, specifically _flush_vram_update in neslib. The first update which loads the gun writes about 55 bytes to the nametable, which should be well below the 160 bytes recommendation even with the general overhead.

The normal frame code likewise doesn't get even close to overdoing a frame, it stays below 1/5 with occasional spikes to 1/4.

I used to have those! Okay, thanks. I'll try it out when I have time.

I tried out the ROM with PowerMappers v23 and don't see graphical glitches anymore.

Is there anyone out there willing to help out solely with the Zapper functions? I'd need someone who knows how to program and has the hardware to test it.

Remind me what exactly it is you need done with the zapper? Just the bit where it's missing the trigger?

I have an NES, a CRT, a PowerPak, and a Zapper. Do you also need to shoot targets or select menu items, or do you just need to know when the trigger is pulled?

The existing issues are: the title screen menu occasionally goes down two items when shooting outside the TV (not sure if this still happens in the latest ROM), and about 10% of in-game shots do not register. Neither of these happens in emulators - in emulators, the menu always goes down one item as it should, and all shots register.

I don't have the hw to do zapper testing, but debugging this should be fairly quick for someone who does. His Zapper is in good condition, so I don't know how it differs from emulated behavior.

I can't comment on if new functionality is wanted, that's up to Jedi.

The title screen works fine now. In-game trigger pulls are still an issue, though.

calima mentioned that there was little/no room for code to add target behavior for the Zapper in-game. Instead, we added that functionality to the gamepad (holding 'left' or 'right' is like aiming the lightgun).

I'd be grateful if this could still be done with the Zapper though. I'll pay you the same rate, tepples.

Can you make a "frames since last trigger pull" variable and not register another pull if it's been fewer than ten?

@tepples

The spurious pull on the title screen is fixed, so the only remaining issue is that in-game pulls are sometimes missed.

Yeah, if you could just solve that issue, that'd be great.

Lumbergh? Is that you?

To be clear, are you asking for testing or for actual code changes?

I have been hardware testing the code, and it hasn't been working. So yes, actual coding.

Let me know if you're interested, and I'll see about giving you the source code.

I'm willing to try. But because I have another paid NES project eating a lot of my NES time, I can't guarantee a fix at "push things out of the way" priority. I may still be able to squeeze it in.

We don't have a deadline.

It's more like a gradient, where like right now it's #5c5c5c and fall is #202020. Yeah, we're lingering, but whatever.

We still haven't resolved this issue yet.

Seriously, it's not even 30 minutes of work (I think), and we've been sitting on this project for 3 months waiting to release it.

I'd be grateful if there's anyone else out there who's willing to help and has the time.

The delay was in part because at the time, I couldn't block out time to reinstall cc65 with the C compiler and the C library. I had installed cc65 without C support (that is, essentially binutils65) because all my projects so far have been in assembly language. I will try to get to that today depending on how swamped I am with The Curse of Possum Hollow and/or housework. Expect a lot of PMs.

Who knows the IRC or other instant messaging contact details of calima or Jedi QuestMaster?

If I'm on the IRC, I go by 'Jedi.' Do you go by 'Tepples' ?

I don't use any, but I can come on IRC sometime, when we find a good spot.

That or 'pino_p'.

It's done!

You might want to announce it on NintendoAge as well, the Brewery section. And depending on the response, maybe consider doing a couple carts

I don't have a NintendoAge account, but knowing the attitudes there they'd probably want boxes and manuals as well.

But I already designed a label, so whatevermaybewhoknows?

Edit: And everything in that label is a vector (except for the screenshot), so it can be scaled.

Is it that you don't know how to start writing a manual? You could start by reading some of the results from Google writing software manuals or how to write a man page. Or is it just a lack of time? Another way, if you already have a game design document, is to rephrase the important parts of this from the player's point of view.

I don't yet know of a process for designing box art. But if you have your label as layered vectors, you can reframe that to the front of a box and the front cover of a manual. The back of the box, on the other hand...

It's a combination of:

1.) I haven't designed a box/manual before

I've designed labels many times; I have a template with the proper dimensions. I'd have to create one to include every dimension of the box and booklet. Though I have some complete copies of games I can use as examples, it's still going to take time, which is another thing.

2.) I have another project I want to finish before the end of the year

To add to that, the holiday season is coming up (and it's election year!), and I'm going to be very busy at work because of this.

3.) I Really Don't Care That Much

For a simple game like this, I feel it's too much of hassle to go all out like this. Especially for the booklet; I like the idea of designing games anyone can pick up without reading any instructions. This game is like that (even the PC version!) If there's enough interest I'll most likely wait until January to do anything.

Excuse my massive misuse of the blockquote.

Looks like FamicomWorld people also wanted carts (but probably in Famicom size?). Anyway, ask them instead of guessing.

The romhacking description doesn't mention Zapper support?

OOPS!

I added it in the description.

That time Is apparently now. The main improvement that will make this fit into the multicart is overhauling how animation is done. From changing CHR pages to instead animating the nametable, with the occasional streaming of new tiles for the silly faces.

This is my plan:
- First, finish improving encoder options for the main CHR compression codec to be used, Bagel.
- Next, hook in the decompressor to a "tile shader" that swaps around the color of tile sets so that Bagel can compress the filled backgrounds more efficiently.
- Decide if it'll be faster to use the existing C code base, or to rewrite it from scratch.
- In either case I'll be using some sort of string writing vblank system, whether that be tepples popslide or something of my own.

Considering that I now only have today and next Saturday to do this, I'm not going to be able to meet the revision deadline.

Hah, just watched Deer Hunter... a nice movie to draw inspiration from for a game