the game has unicron's? how can you even fit one into the memory of a nesOriginally Posted by Ed Oscuro
this game must be trully epic ;-)
the game has unicron's? how can you even fit one into the memory of a nes
this game must be trully epic ;-)
wow, I totally missed this, I thought ProgAce may have been working on this, but it appears it's almost done. Very Cool. There's actually suppose to be a few good nes homebrews completed this year. The last 2 or so years for Nes Homebrew have been great. Not a whole lots of side scroller/platform games yet, but there's been some really nice puzzle games, single screen classic arcade type games. D Pad hero hasn't seen an official cart release but is available in rom form and is an amazing piece of work for a nes game.
Very happy to see more new NES homebrew.
That's certainly possible, the mine cart level is rather difficult. Normally the ape has a max health of 8. He can be hit 8 times before he dies (when he gets down to 2 health, he starts blinking red. You can see this in the demo).
We went in kind of an interesting direction with health packs. You don't get the health bonus when you pick it up, you get to choose when you get the health bonus. This allowed us more flexibility when placing the bonuses. I hate picking up a health pack when my health is already full. Unfortunately you can't apply the health bonus during the mine cart level. So if you go in with low health and get knocked around, you'll die.
As a temporary solution while designing the level, i put in some code to boost the ape's health up to 10 regardless of how hurt he was going in. But that's not a very good solution to the problem.
What i have in the back of my mind, i may save the player's health level before going into the minecart level, boost the health back up to 8, then reset it back to the initial value when you load the next level. Or i may just leave it as is. If you go into the level with 1 health, sucks to be you.
I'm going to want to watch some people play through the game in playtesting before i make a decision on that.
And another page knocked off my bug list. I'm still tracking some bugs, and i'm sure there's a few i'm still missing.
Last edited by ProgrammingAce; 09-01-2009 at 12:35 AM.
I am so glad to see an update. I know how much work this kind of project can take up and was getting worried that real life might have gotten in the way of finishing. Keep up the good work and thanks for the updates!
Yet another youtube channel:
https://www.youtube.com/channel/UCkT...tyNJnjPw-2co7g
Basically what he said. I was curious on what was happening with this game. It looks great, keep going and I will definitely buy a cart!
Hey, that looks just like BASIC play syntax. No duty cycle modes though? No hardware volume envelopes (simple linear decay) on the square channels or hardware frequency sweeps either? Both could be easily implemented in a single byte command.
Curious too (since I've been doing a lot of sound synth code in the past year), the music engine note and tempo are running off a 30hz tick? Why not 60hz? Even 60hz is kinda low for fixed pointed tempo (assuming you're using a fixed point counter), but much nicer than 30hz.Your game is expected to run at 30 frames per second and update the music loop once per frame.
Do you have an external converter to convert the ascii text into command bytes?
YES
Beyond that, nothing much I can comment on. Keep up the good work!
The NES is locked at 30 FPS on the sound channels. I can only buffer sound in between screen refreshes, so i'm stuck there.
The hardware doesn't really allow for sweeps or fades. Fades you can kind of fake by manually playing the note at a progressively lower volume, but sweeps can't really be faked. You can pull something similar off by layering the sound channels, but i haven't really tried. The NES doesn't let you play a second note without a rest in the middle, that's why NES music is always so staccato.
You mean, your code/engine is locked down to 30fps? The sound channels aren't locked to anything. You can update any of the APU registers at any time. Most engines sync the sound engine code to vblank, which is still 60fps (50 for PAL). Using an external interrupt from some mappers, you can create some interesting sounds via high speed updates.
It allows for sweeps(repeat), fades(decay envelope), or manual volume. All are hardware supported. Volume envelopes are as simple as writing the length variable. The decay is handled in hardware and the envelope tick is 240hz. Doing it manually with direct volume control isn't faking it though. Manual volume control offers the composer to do more complex envelopes like ADSR or echo effects or tremolo (low frequency volume modulation).The hardware doesn't really allow for sweeps or fades. Fades you can kind of fake by manually playing the note at a progressively lower volume, but sweeps can't really be faked. You can pull something similar off by layering the sound channels, but i haven't really tried.
But my original point was that you could easily support duty cycles or volume decay in your existing engine without writing more complex code. Just add two more commands which directly translate to the hardware. A decay command with a length counter parameter and a waveform command with a duty cycle parameter. Same with sweep - although you can't use sweep and decay at the same time. It's one or the other. Anyway, in relation it would give a little more flexibility in sound with little effort on the code side.
You mean poly voice per channel? Neither did the Genesis, PCE, SNES, etc. A more complex sound driver resolves most of this issue though. Or do you mean actual forced rest periods in between notes? That isn't true. You can adjust the frequency of the channel to whatever value without stopping the channel output.The NES doesn't let you play a second note without a rest in the middle, that's why NES music is always so staccato.
If you don't mind me asking, what mapper are you using? Are you going to add horizontal scrolling to the engine? If you do, I highly recommend using the +32 increment option for the PPU. Much easier to write vertical strips than trying to seek metatile positions in horizontal strip map format. You can still do RLE on vertical strips. Any newer demos or videos available?
Last edited by tomaitheous; 09-01-2009 at 12:08 PM.
To be perfectly honest, you've completely lost me. What you wrote is way over my head, i barely understand how sound generation works.
All i did was write a music engine that takes a binary file with the "music" in it and shoves it into the right memory register to make it play sound.
As for the mapper, we decided not to use one. Leaving out a mapper gave us a few more options when producing the final carts. Only 1 level has horizontal scrolling, the rest are static. Since we're not using a mapper, we can't swap the PPU increment on the fly, so everything is just +1.
I don't think we'll be doing any more demos, but will have some videos later on. Right now the background graphics aren't all in place.
Oh.. sorry about thatWas just trying to explain that duty cycle and volume envelope would be pretty easy to implement in your existing sound engine. Just simple as passing those values to the right regs.
Hmm.. non mapper setup. That's rough trying to fit all the graphics into two pattern blocks (4k+4k) for chr-rom. Since you're already using extended ram at $6000, why not use chr-ram too? You could fit more graphics in (like cinemas). I mean, you have 32k of non mapper PRG rom to store stuff in. Oh and you don't need a mapper to use use PPU +32 increment. It's on register $2000. But if you're not going to do scrolling, then not a big deal. Are you going to manufacture the boards yourself (i.e. not use the power pak cart or recycle old carts)? If you plan to recycle a cart, SMB/DH combo cart has a decent mapper. Allows 16k of chr-rom and 64k of prg-rom. And there's got to be a bazillion of them out there.As for the mapper, we decided not to use one. Leaving out a mapper gave us a few more options when producing the final carts. Only 1 level has horizontal scrolling, the rest are static. Since we're not using a mapper, we can't swap the PPU increment on the fly, so everything is just +1.
I don't think we'll be doing any more demos, but will have some videos later on. Right now the background graphics aren't all in place.
Last edited by tomaitheous; 09-01-2009 at 01:22 PM.
i think i understood the first 3 words in your posts :P
man u seem really knowledgeable about that stuffdid program for it before or somethin o_0
The PRG rom is getting pretty full too, we're sitting at just over 12,000 lines of assembly to make this game work, I have about 6.5 K of space left in the rom and i haven't put the meta-tile data into the rom yet. Basically, it's going to be a tight fit. I have enough features on my "wish list" to fill up every last byte.Hmm.. non mapper setup. That's rough trying to fit all the graphics into two pattern blocks (4k+4k) for chr-rom. Since you're already using extended ram at $6000, why not use chr-ram too? You could fit more graphics in (like cinemas). I mean, you have 32k of non mapper PRG rom to store stuff in. Oh and you don't need a mapper to use use PPU +32 increment. It's on register $2000. But if you're not going to do scrolling, then not a big deal. Are you going to manufacture the boards yourself (i.e. not use the power pak cart or recycle old carts)? If you plan to recycle a cart, SMB/DH combo cart has a decent mapper. Allows 16k of chr-rom and 64k of prg-rom. And there's got to be a bazillion of them out there.
We've been super efficient in our use of the CHR rom, we've managed to fit every graphic we wanted into the two 4K banks, i think we still have 5-6 tiles left blank too. We even went with "oversized" graphics compared to most NES games, the ape is made up of 8 tiles and has 9 frames of animation. A relatively unheard of number for an NES game. I'd really love to show you what the CHR rom looks like, but i don't want to ruin any surprises.
We certainly didn't skimp on the graphics in other areas either, the game has 14 different fully animated characters. Plus there's projectiles, cutscene graphics, and a few "extra" things thrown in there. Once the game is out, i'd love to sit down with Brat and go over how we managed to squeeze everything into a 128 x 128 pixel area. Quite frankly, Brat was amazing in his art design in coming up with creative reuses in tiles. The steps to assembling some of these characters is quite complex.
As for the 32 vs 1 increment of the PPU addresses, i misspoke. I was under the impression that there were some mappers out there that would allow you to change the register on the fly after the code was launched, that's all i meant.
For the final carts, we're doing a full boxed release. I have a friend who's producing the carts for us, i believe he's using donor carts.
I'll be honest here, what the lack of mapper really comes down to is my lack of knowledge when this project started. Before this, i hadn't written in 68K assembly in 10 years. I had never written a line of code for the NES and i didn't understand how all the registers worked, i didn't understand the PPU at all, and i had no idea what i was doing. The original idea was to keep the game as limited as possible so i didn't fuck it up. So i made a quick crappy demo of the ape sliding across the screen and shoehorned Brat into helping me out.
As the game progressed, we realized we actually wanted to do this the right way, actually make a fun and interesting game. In the process, i've rewritten the game engine 4 times. I have about 500 hours into the project, and while i always wish i could add more, i'm pretty happy with what we have so far. Of course there are things I would have liked to have done differently, i would have preferred the game to be side-scrolling, i *definitely* would have loved to use a mapper... Now that the game is basically done, I can't go back and make those things happen. It would take a complete rewrite of the game, delaying the release by another year, possibly killing the project all together.
In order to optimize the code and make it as efficient as possible, I had to hard-code a lot of information. Normally it's poor programming practice, but when i'm counting each calculation for number of CPU cycles, it's a necessary evil.
A perfect example... when i originally wrote the game, i just picked a random spot on the screen to be the ground height, I just made sure it was divisible by 8. It worked fine until i realized i was 4 pixels off from the attribute table and my colors weren't going to match with the background tiles. My only option was to shift the backgrounds up by 4 pixels, which leaves the ape's feet 4 pixels below "ground". When i did conditional statements ( if x > y then do this ) I couldn't use a calculation. So i could either waste more CPU calculations to calculate how high the enemy's head was from the ground, or i could just hard code it. Of course i hard coded it, and adjusting the ground height now crashes the game. Going through 12,000 lines of assembly code digging out variables i didn't bother to mark without access to a debugger would be a nightmare. Instead we're going to adjust the artwork to match the ground height, and nobody would ever know if i didn't say anything here.
This kind of stuff comes up a lot in video game development. Is it faster/cheaper to change the artwork or the code? In this case, the artwork by a landslide. It makes no difference to the player either way...
So no cinemas pics then? Like in the fake thread?We've been super efficient in our use of the CHR rom, we've managed to fit every graphic we wanted into the two 4K banks, i think we still have 5-6 tiles left blank too. We even went with "oversized" graphics compared to most NES games, the ape is made up of 8 tiles and has 9 frames of animation. A relatively unheard of number for an NES game. I'd really love to show you what the CHR rom looks like, but i don't want to ruin any surprises.
From the demo you released, I see that the rom has extra SRAM (mapped to cpu logical address range) enabled but you're not using it. I take it the final game engine doesn't use it? If not, like I said previously - SMB/Duck Hunt combo cart would work (and has a super easy mapper on the board if you wanted/needed up to twice the chr/prg rom space). Even if you don't use the extra space, the cart is a candidateFor the final carts, we're doing a full boxed release. I have a friend who's producing the carts for us, i believe he's using donor carts.
Best of luck. Hope to see this final version soon.
Me? I code for a few consolesi think i understood the first 3 words in your posts :P
man u seem really knowledgeable about that stuff
There are, but they're not quite as big and there aren't as many.
The game was far beyond what the demo showed, even when it was created. We ended up cutting several thousand lines of code and blanking out half of the CHR rom for the demo. We didn't want people hacking the rom and getting to other levels. The final game uses the entire addressable range. all 4 banks of PRG rom.From the demo you released, I see that the rom has extra SRAM (mapped to cpu logical address range) enabled but you're not using it. I take it the final game engine doesn't use it? If not, like I said previously - SMB/Duck Hunt combo cart would work (and has a super easy mapper on the board if you wanted/needed up to twice the chr/prg rom space). Even if you don't use the extra space, the cart is a candidate
So is the butter man going to be in this game?
A well reasoned and thought provoking question.
<Sothy> its the internet <Sothy> who cares
of course he will
and he will be tasting communism
necro bump for a status check. how's this coming along?
Is there going to be an ending? Don't want any spoilers, but was wondering if the ending was going to be like a 1985 type ending or an early 90s ending
American NES games left to beat: 3
Last 3 NES games beaten: Romance of the Three Kingdoms II, Nobunaga's Ambition II and Gemfire
(Updated: 7/21/10)
Posting Permissions
Reply With Quote
