I think I finally have something worth showing. This video shows off a few sections of the game. Not much else to say, so enjoy.
http://www.youtube.com/watch?v=syY80GyfRYM - Video #1 (very old)
http://www.youtube.com/watch?v=wVJVPkxv2D4 - Video #2 (the old, incomplete first area and a rough boss #1)
http://www.youtube.com/watch?v=BJGEknTXZio - Video #3, commentary and some epic fail on the easy boss...
http://www.youtube.com/watch?v=oj7_CDzKmtQ - Video #4 - Shows off the areas from video #1, but in their hopefully final form.
Hey! Pretty cool! I think the concept of the room where you have to quick run to the safe area is clever/cool. The game seems rather revolved around some weird gravity effects, could you explain that?
And yeah, it does remind me of Mega Man 2 as someone said there a little bit. Keep up the good work!
Checked the video and it look nice. Seems interesting and promising. Only the puzzle part that I like less but that's a personal preference (I'm looking at you capcom, for your #$@$ disappearing blocks in mega man!)
Like Celius said, the physic is quite different so it would be good to know why it is that way when the story will be told.
Still, I would prefer to test the alpha in a rom version but I guess for now the video will suffice
I love you & wish to birth your man babies.
OMFG I WANT A COPY OF THAT GAME NOW!
That is so neat. I think it would spice up the spike puzzle if you had just enough time to make it to another free spot. That way you can play it safe or gutsy.
Looks more awesome than awesome!
Lookin' good, man! Was the game inspired by I Wanna Be The Guy?
Awesome, I see you we're inspired by I Wanna be the Guy :D
Mega Man 2 sound engine?
Game looks nice... Gimmick inspired, too, perhaps?
Looking awesome as usual Sivak : ) Can't wait to see the finished product!
Celius wrote:
The game seems rather revolved around some weird gravity effects, could you explain that?
What effects do you mean? If you mean that little part where I fall slowly through the spikes near the beginning, that's cause I'm using the feather fall item (see the top).
SecretServiceDude wrote:
Lookin' good, man! Was the game inspired by I Wanna Be The Guy?
Yes, it says that in the video description. Although it's my own take on things.
Looks awesome and absolutely hardcorely hard.
Nicely done. I'm not big into platformers (I never did finish SMB-1). However, your game looks very impressive to a non-genre player.
Excellent work!
It looks really good. I can imagine seeing someone breaking their controller while playing this.
What mapper does your game use?
How much PROG and CHR rom?
Would this game ever be a candidate for a future "garage games" cart?
Is there a default double-jump ability or is that an additional item as well?
clueless wrote:
What mapper does your game use?
How much PROG and CHR rom?
Would this game ever be a candidate for a future "garage games" cart?
UNROM, 128KB (may go to 256 if need be. It'd be an easy upgrade)
I don't know about any "garage cart", but there would certainly be a regular cart for it.
noattack wrote:
Is there a default double-jump ability or is that an additional item as well?
Yes, it'll be an item you get after beating some boss. I just have it in there to show it off (and to satisfy myself that it actually works) The keys are also items you'll find. There will be numbered blocks or doors or something and you'll shoot them. Having the key will destroy them, otherwise they stay.
Sivak wrote:
clueless wrote:
What mapper does your game use?
How much PROG and CHR rom?
Would this game ever be a candidate for a future "garage games" cart?
UNROM, 128KB (may go to 256 if need be. It'd be an easy upgrade)
I don't know about any "garage cart", but there would certainly be a regular cart for it.
Memblers assmebles nominated games into some sort of a multi-cart and then fabricates them for sale. Seems pretty cool to me. It's like "being published" when writing a college or industry research paper.
Looks interesting. It looks like it is more puzzle-based than action based, which is a nice twist. I think people have been afraid to attempt a full-fledged homebrew platformer because the inevitable comparisons to the NES's classic platformer games, which set a high standard to live up to.
This is very nice! I can get somewhat frustrated with puzzles sometimes, but at least technically what you have there is pretty impressive. And platformers are the best games, period! =)
Jagasian wrote:
Looks interesting. It looks like it is more puzzle-based than action based, which is a nice twist. I think people have been afraid to attempt a full-fledged homebrew platformer because the inevitable comparisons to the NES's classic platformer games, which set a high standard to live up to.
Well, puzzles are always fun. But I want to have more enemies and such. Enemy AI is fairly simplistic thus far. It won't be until I want to have a guy who shoots diamond missiles that explode into four diamonds that kill you in 1 hit or something that I'll have a mini program to write.
Now that I think of it, I don't think I've seen anything in the platform genre out of NES homebrew. I'd like to see how this turns out.
Quote:
Now that I think of it, I don't think I've seen anything in the platform genre out of NES homebrew.
There have been a few, but they're either unfinished, buggy, or both. Go look up Sack of Flour, Heart of Gold, Dikki Painguin, and Neotoxin.
CartCollector wrote:
Quote:
Now that I think of it, I don't think I've seen anything in the platform genre out of NES homebrew.
There have been a few, but they're either unfinished, buggy, or both. Go look up Sack of Flour, Heart of Gold, Dikki Painguin, and Neotoxin.
Neotoxin looks very promising, It is a shame that it was canceled. Hopefully somebody picks it back up and finishes developing it.
I've only seen demos of Neotoxin in video form. I never played the demo rom myself (couldn't find it anywhere), but it looked interesting for what it was.
Sivak wrote:
I've only seen demos of Neotoxin in video form. I never played the demo rom myself (couldn't find it anywhere), but it looked interesting for what it was.
From NesWorld's Homebrew page, you can download a zip file containing both the source code and a precompiled ROM for the Neotoxin prototype:
http://www.nesworld.com/homebrew.php
Maybe RetroZone will complete development on Neotoxin and release it in cartridge form?
Well, I looked at that demo and that's not the same as in the videos I've seen. That has some random sprite for the player and "ghosts" going back and forth. What happened to the red and white guy? What happened to the dialogue scenes?
to get back on the main topic... sivak, i am really impressed! i hope you can get the game done. it's hard to finalize things and most projects (such as neotoxin) are getting stuck in the middle of beeing complete most of the time...
I want to see more. When will we get the next video demo?
Hey Sivak, your game looks pretty playable, won't you release a beta?
I think he cant if he wants to do a retrousb release. Wait....I think theres a loop hole in the contract where it states the complete game. But ah well.
Oh I wasn't aware of a "retrousb"
The site that sells the powerpak. Siv sells most his games on it.
That's bad news, the game seemed actually good.
He'll sell it...you can buy it.
No, it's my game I can do what I want with the rom. I don't enter into any contracts until I'm ready to put carts into production and even so, the only person who agrees to NOT distribute the rom is Brian, the retrousb owner. In theory, I could give out the rom, but won't.
I do give out betas to a few people and I'm planning to have a public demo rom with the first boss or something. (I need to code the actual boss first! I just got some graphics for it last night)
But after that point, I don't think I'll be doing too many other demos. I may gather a select group to do testing but I haven't figured out how that will work yet.
The final rom will not be available by me. That isn't to say eventually some crook will dump and distribute it, but hopefully there will be some more respect on that matter. I don't plan to charge an insane amount of money for the final product. Maybe $30.
Anyway, that's that.
Ya I know you dont have a contract yet...but you'll eventually will have to sign. Didnt know only brian couldn't distribute.
edit: I mean you'll eventually wil have to get it if you decide to go retrousb....like all your other games.
Well, do whathever you like but don't except us to buy anything from you just because we're on NESdev. Not that we don't like you or your game, but seeing how expensive the games are plus the port, it would really need to be a really good and long game to be worth it. And wihtout playing it, it's hard to guess how good or long the game is. Personally I'll give all my games for free so that I'm sure all people that want to play them will be able to, I'd rather have much more people playing my game than just get money, but it's a personal choice.
Just remember that when you come to ask question on NESdev, we don't ask you money in exchange of advice. I would really feel bad to come ask some people some advice, and use this advice to make money from the same people that give you advice.
However, I 100% agree it is not a good idea to spread betas. I won't do that, as I only want one version of the ROM to fload arround the net (well, two actually, one for NTSC and the other for PAL). It would be very bad if people would download the beta thinking it is the final version, and think "his game shucks and isn't even complete", when it's actually not the case.
Hehe dont forget i'm not the one making the game. I dont think siv is "expecting" you to buy it.
I think he knows all that Bregalad, it sounds like you're trying to guilt him into giving us the game.
He doesn't deserve a hard time, it's his decision.
In fact I feel the same way about some concepts of open source. I fully support the rights of someone who spent a long time creating something to keep it as private as possible. If someone else really wants to hack the source, as is completely possible, then let them go to that trouble. If somebody wants to be totally open source, then that's ok, too.
If I ever get to the point of releasing something, my personal philosophy will be to release a ROM so the internet at large can play it - that might get some blog posts or something and make it known. Then if I can sell the game somehow I might put in a bonus for people who buy it, but I wouldn't want to make any money on it, the main thing would be to own my own NES game on a cartridge which is of course the coolest thing in the world.
Or do what PS1 publishers did: release a 1-level demo to the public.
Did you make everything? The programming? the graphics? the music? if so, that's great! you'd be a graphics artist, composer and programmer. I hope I get to do all three things as well someday.
egfelixdcg wrote:
Did you make everything? The programming? the graphics? the music? if so, that's great! you'd be a graphics artist, composer and programmer. I hope I get to do all three things as well someday.
Programming and music yeah. Graphics - somewhat. I did some but I've had help for others.
Sivak wrote:
That isn't to say eventually some crook will dump and distribute it
Somewhat more on topic, you can (rather, should) consider using FCEUX to do a code/data log and then rip a stripped ROM, after fully doing whatever is expected in the one-level demo. Then you wouldn't have to do any actual work involving commenting out blocks of code or whatever.
I remember the SMB3 hack demo by DahrkDaiz that was distributed as a stripped rom. After doing some random jumping around, you could get the game stuck in an unexpected state which the rom stripper never encountered, and end up unable to play the game further without resetting.
Yes, hence the "doing whatever is expected".
A crashed ROM leads into a thrilling mystery! Buy the full game and find out what happens for only $39.99!
I must say I find Sivaks anti-piracy standpoint laughable. Virtually every dedicated NES enthusiast has at least a gigabyte or so of pirated ROMs on his drive. Anyone who claims otherwise is either a blatant liar or just too much a saint for his/her own good.
And no, the these-games-aren't-sold-anymore-but-new-games-should-be-supported argument doesn't hold up. (maybe it would if you're holy enough to either buy or delete every game available on Wii virtual console or the like)
I have no objections to people trying to make money from a game they've spent late nights coding on, and I can't claim that I myself would be first in line to dump and distribute a NES game if I had made it. But whining about people pirating your precious game only makes you look silly.
Hey let him release it, Ill buy it. I cant make my own games so I rely on people like Sivak to put the time and work into it so I have something new, its well worth it to me.
Hey folks, I put up a second demo video:
http://www.youtube.com/watch?v=wVJVPkxv2D4
Enjoy.
Nice! This is looking like a lot of fun. I can't wait to play it when it comes out
.
So what's your estimated percentage on the completion of this project? It looks like you've pretty much completed the engine, now it's just data creation?
Celius wrote:
Nice! This is looking like a lot of fun. I can't wait to play it when it comes out
.
So what's your estimated percentage on the completion of this project? It looks like you've pretty much completed the engine, now it's just data creation?
Well, regarding the engine, I still need to get some water mechanics and it's POSSIBLE I might have weapon changes. Maybe have you shoot a big fireball.
I'm not too worried about water yet as that should only be a jump modification. (plus nowhere uses it yet)
Right now, the main focus is enemy creation and level design. I've got a guy who does some good graphic work and he's made up some nice designs for some future areas.
I recently implemented some RLE and LZ compression for the room tile data, which will be handy. I just need to apply it to all the uncompressed rooms eventually... I wish a C++ program to do it for me would be simple to write...
I guess if we needed a percent... I'd say 12-15%
Game looks amazing. Looks like a professional release to me. The art is great. I love the exploding effect and fadeout when you defeat the boss. Can't wait until the next demo!
Looking really good now! Nice to see a full level with boss and everything.
But the one thing I'm missing in it is scrolling. A nice trait of the NES is how all games had nice n' smooth scrolling for free, while on many other platforms it was a luxury that cost lots of software cycles. I really think you should consider it, at least horizontally.
Man that looks awesome. I hope you finish it. I'm totally gonna buy it!
Bananmos wrote:
Looking really good now! Nice to see a full level with boss and everything.
But the one thing I'm missing in it is scrolling. A nice trait of the NES is how all games had nice n' smooth scrolling for free, while on many other platforms it was a luxury that cost lots of software cycles. I really think you should consider it, at least horizontally.
I haven't played I Want to be the Guy but I could understand if that's how it does scrolling and he wants it to be the same. The demo I'm working on now is meant to be similar to Knytt Stories and it works the same way.
Additionally I have been playing a lot of NES games lately and the little things really get to me. A lot of games have annoying little forced slowdowns here and there, and his game is going to be faster and smoother overall without something like Megaman/Zelda edge scrolling.
Anyway that looks really great, I especially like the way the bricks look at the end. I haven't seen a lot of homebrew sidescrolling engines.
Bananmos wrote:
Looking really good now! Nice to see a full level with boss and everything.
But the one thing I'm missing in it is scrolling. A nice trait of the NES is how all games had nice n' smooth scrolling for free, while on many other platforms it was a luxury that cost lots of software cycles. I really think you should consider it, at least horizontally.
Regarding scrolling: I considered it, but by this phase I don't think it'll happen. It's another layer of complexity that seems beyond the scope of this project by this point.
If it's any consolation, the credits screen will scroll upwards.
Not bad, but it looks like a Space Hunter (J) clone.
I think the non-scrolling aspect kind of adds appeal to it. And besides, I believe he said the screens are individually RLE or LZ compressed, and that would be a nightmare to decode in real time (though I've decoded RLE in real time for an RPG map scroller). But trying to decode between multiple compressed screens when scrolling would be a painful task. Especially considering the presence of a status bar
.
And the scrolling isn't
quite like Zelda's, though it's similar. Well, this one doesn't have scrolling, I guess. In Zelda, the screen scrolls really quickly to the next one. This one just goes screen to screen with no scrolling.
I actually have a scrolling engine which scrolls all directions (diagonally too). Since I'm using vertical mirroring and no special tricks, I had to make a small status bar out of sprites. A BG status bar I don't think would work without doing really tedious garbage. In Sivak's case, I imagine this would equally suck.
Celius wrote:
I think the non-scrolling aspect kind of adds appeal to it.
That or it'll invite comparison to A Boy and His Blob.
Celius wrote:
I believe he said the screens are individually RLE or LZ compressed, and that would be a nightmare to decode in real time (though I've decoded RLE in real time for an RPG map scroller).
At one point, I was planning to make a platformer that decodes a screen at a time based on some RLE+Markov scheme, yet still scrolls smoothly. I rejected it in favor of a column at a time when I realized I might not be able to fit the decoding, physics, and NPC/monster logic into a single frame.
I remember my RLE decoding took almost an entire frame for the RPG map. But it really doesn't matter for an RPG map, because it scrolls 16 pixels in one direction per button press, and there's almost no game logic when on the map. This is only an issue when dealing with scrolling like 8 pixels per frame or something if you're on some super fast airship.
There's always partial decompression. For example, my game handles collision on the 16x16 pixel metatile level. I don't have enough room to fully decompress each room in RAM(it would take 8k, each room being 128x64 metatiles), so I decompress to 32x32 pixel metatiles, decreasing the decompression size to 2k. Each 32x32 pixel metatile is composed of 4 16x16 pixel metatiles. It is a good compromise between time and space consumption, though it does require the use of WRAM (it's okay since I use SRAM for saving games).
After all, unlike us, he's a professional, let him do whathever he wants he should know what he's doing by definition.
In my game I have a status bar with fast scrolling technique and RLE compressed maps, if sivak don't want to do it or is unable to do it that's his problem, not anyone else's.
Quote:
A nice trait of the NES is how all games had nice n' smooth scrolling for free, while on many other platforms it was a luxury that cost lots of software cycles.
This could make the game easier ported to such other platforms tough. Yes you're probably refering to the C64 here where you have to move all the screen characters manually when you want to do coarse scrolling (only fine scrolling is done by hardware).
Bregalad wrote:
After all, unlike us, he's a professional, let him do whathever he wants he should know what he's doing by definition.
In my game I have a status bar with fast scrolling technique and RLE compressed maps, if sivak don't want to do it or is unable to do it that's his problem, not anyone else's.
Hey, we get the point, you don't like the fact that he's selling his games. Drop the attitude already.
^^I agree you're being a douche.
Ok back on topic. I dont think this game really needs scrolling. Gimmick! didnt scroll up. Only left and right. However it didnt feel weird jumping to a screen above you even though there was no scroll. So I dont think it'll matter in this case either.
Bregalad:
Like others have been saying: drop your childish attitude. You're getting close to deserving a ban if you continue your bitter campaign every time Sivak's game is mentioned.
Going on to the subject, I still think scrolling would make the game cooler, but I can see at least one good aesthetic motivation for leaving it out altogether: When you want to have distant scenery in your BG, you have to choose between keeping it really simplified so you can use some taylor-made parallax scrolling trick, or just accept that scrolling will break the illusion of distant scenery. :)
yeah i don't think a lack of scrolling is all that bad, while i can't play the game personally the transitions are fast enough that i can't imagine my gameplay experience being affected really.
it's likely i won't ever be playing this game although of the homebrew games i've seen put exclusively on cart i think this one stands out from the rest. it really does approach commercial quality in it's presentation although none of us (outside maybe a select few?) can really judge the gameplay ourselves. will you be releasing a playable demo?
smkd wrote:
Will you be releasing a playable demo?
Yes. I plan to do this, but only when things are more or less EXACTLY finalized. i.e. I want all physics/level design for the first area and all that good stuff done.
I'm currently expanding the first area by about 8 screens as I felt it was too short, especially after seeing myself playing it in the video. I also added a new enemy last night.
I watched the video a few times. Looks pretty cool. The music is catchy too. I wouldn't worry about the scrolling too much. Not scrolling gives it character and some charm. It does remind me of legacy of the wizard.
Which mapper are you using? (I didn't see it skimming over the past few pages). Also, do you plan to produce a specific cart for this or are you going to use the powerpak? The powerpak just seems overkill to sell a game on.
Edit: Never mind. I see that they have non dev carts too.
I'm also curious what mapper you are using.
The mapper's UOROM, 256k PRG-ROM with 8k CHR-RAM. It's in the comments of the second Youtube video. Sivak should put this in the first post in this thread and on the grey boxes to the right of his videos, as this is a fairly common question.
CartCollector wrote:
The mapper's UOROM, 256k PRG-ROM with 8k CHR-RAM. It's in the comments of the second Youtube video. Sivak should put this in the first post in this thread and on the grey boxes to the right of his videos, as this is a fairly common question.
Yeah, and it's actually quite weird why people really want to know. I don't mind saying it, but why are people so curious?
People probably just want to know what makes your game capable of doing what it does in terms of hardware. It's cool to see how someone's game works, too, and what mapper someone uses can reveal a lot of that information.
Probably the most valuable piece of information in learning the mapper/specs of this game is that the game uses CHR-RAM. Lots of people have trouble deciding between CHR-ROM and CHR-RAM, so looking at this game and seeing that it uses CHR-RAM can help people decide better on which to choose.
Mapper 2, if you translate it to iNES.
Sivak wrote:
CartCollector wrote:
The mapper's UOROM, 256k PRG-ROM with 8k CHR-RAM. It's in the comments of the second Youtube video. Sivak should put this in the first post in this thread and on the grey boxes to the right of his videos, as this is a fairly common question.
Yeah, and it's actually quite weird why people really want to know. I don't mind saying it, but why are people so curious?
I was curious to know because if you could or plan on building the mapper yourself with discrete logic. A UxROM type mapper would be quite easy to make yourself. It would be cool to design and fab your own boards/mapper.
Celius wrote:
People probably just want to know what makes your game capable of doing what it does in terms of hardware. It's cool to see how someone's game works, too, and what mapper someone uses can reveal a lot of that information.
Probably the most valuable piece of information in learning the mapper/specs of this game is that the game uses CHR-RAM. Lots of people have trouble deciding between CHR-ROM and CHR-RAM, so looking at this game and seeing that it uses CHR-RAM can help people decide better on which to choose.
This is exactly the reason I wanted to know. I was (and still am) just about to make a thread in the newbie section asking for advice on choosing a mapper for my little game. And one of the issues that I wanted advice on was CHR-ROM vs. CHR-RAM
.
Also, you (you being Sivak, not Celius) tend to put your games on real carts, so I'd assume that any mapper you choose would be easy to get a hold of. I want my game to go on a cart too, so that's useful info for me.
Regarding the mapper: The main reason was indeed for the physical carts. My last game, Mystic Pillars, used UNROM with 64kb of PRG ROM and that made for a cart that wasn't much more expensive than NROM.
If I could use a more advanced mapper like MMC3, I would like to as the bank switched CHR seems very handy as does all the PRG capacity, but the only downside is that MMC3 would be expensive and I don't think people would want to shell out $50.
UOROM will get the job done. The compression routines I recently implemented are coming in handy.
MetalSlime wrote:
And one of the issues that I wanted advice on was CHR-ROM vs. CHR-RAM
This may be a little off-topic, but:
I think the main advantage of CHR-RAM is you can change it at runtime, for example if you want random or custom generated tiles.
CHR-ROM can't do this of course, but, its advantage is that you can have more than 1 bank (don't know up to how many) and switch between them so you can get more than 512 tiles.
Also, with CHR-ROM you don't waste PRG-ROM or RAM, for storing tiles previous to loading them on VRAM.
Hope this helps.
I've got some more things to consider on the CHR-ROM vs. CHR-RAM debate:
If you use CHR-RAM you can also compress your tiles so that you can fit more data into less ROM. I think there was a thread here somewhere about a program for CHR-RAM compression that compressed graphics data down to around 70% of the original file size. So a 256k UOROM, using that program, could store more data using the same size graphics file as an MMC1 with 128k PRG-ROM and 128k CHR-ROM.
And it's more flexible, as games with CHR-ROM bankswitching are restricted to certain-sized chunks of data called banks (from as small as 1k on the MMC5 to the full 8k used with CNROM). CHR-RAM allows one to change not just each tile, but even the individual bits that make up each tile.
The benefits of CHR-ROM are that it's usually easier to use and faster to change out what tiles the PPU can access. To switch out CHR-ROM banks all you have to do is change some bits in the mapper. Changing the data in CHR-RAM, however, requires lots of time and also a routine to load the data in to the RAM. The speed also allows one to do certain effects that would be impossible with CHR-RAM, like using a raster interrupt to change which tiles are displayed on a certain part of the screen (for instance having different background tiles for the score area and the game play area). The bus between the 2A03 and the CHR-ROM is far too slow to update that much data in between scanlines.
Oh and the amount of banks a certain cart with CHR-ROM has is the total ROM size divided by the bank size. Go look up different mappers in the Wiki for more information.
UNROM really is a nice mapper, only problem I've ran into with it is the limited number of DPCM samples. Garage Cart #2 is turning out to be quite a unique hack because of this (but so was the first one).
I've always been a big fan of CHR-RAM. GC#1 for example was 64kB. One game on there (Solar Wars) was originally a 64kB game.
A little known fact also is that GC#1s menu uses bankswitched CHR-RAM (rather pointlessly though).
Another advantage of CHR-RAM is that it means there's half as many chips to program. It can go straight from tube or reel to the board.
It can be banked just as easily as CHR-ROM, and as I mentioned on the hardware forum, just like 8kB ROMs - you can't buy 8kB RAMs anymore either. Though I actually have a nice reel of 8kB SMT RAMs, it's only because I'm a bargain hunter and get lucky sometimes.
Quote:
It can be banked just as easily as CHR-ROM, and as I mentioned on the hardware forum, just like 8kB ROMs - you can't buy 8kB RAMs anymore either.
Only problem is that original NES era mappers that supported bankswitched RAM are rare. The only one I can think of is CPROM and that board was limited to 32k PRG-ROM, which isn't that much if you want to take full advantage of the extra RAM. So this means that you pretty much have to make your own mapper if you want bankswitched CHR-RAM support, and the new mapper will probably need a new iNES mapper number to be emulated (though this would be a benefit for someone who wants to sell real carts without being pirated). It does make programming harder if you can't use an emulator to test your code.
You know what, I am going to make a thread in the Newbie Help Center about the pros and cons of banked CHR-ROM, normal CHR-RAM, and banked CHR-RAM.
Can a RAM chip replace a ROM chip for a normal MMC3 board?
CartCollector: You'll have to make your own board to use a ROM larger than 32kB anyways (mass rewiring quickly starts to suck), that's also the best time to make a new mapper.
For programming/testing, the tool for that job is an EPROM emulator.
Dwedit: If you mean CHR, some (most or all?) MMC3 boards don't have the CHR write pin, you should be able to tell by looking at the bottom of the cart. Seeing all the pins there would be a good sign.
Sure! Any bankswitched ROM can be swapped for RAM if you don't mind some work
I don't really condone large CHR RAM outside of copiers though, it just seems like a huge waste of potential putting them in a fixed game cart, that's the whole point of ROMs! No matter what tricks people gain from CHR RAM, they could all be implemented with enough CHR ROM/a talented enough mapper. I think the only time where RAM is a real necessity is when you want to reprogram it for another game
So by all means make an awesome bankswitched CHR RAM game for PowerPaks, but please don't put non-reusable RAM in real carts when it really isn't needed.
Maybe this will put my point in perspective: a 6264 can be used for the CHR of a UNROM game or it can be used for the well over 100 FDS games, and millions of more possible CHR sets homebrew considered. Be efficient--save a RAM from a monotonous fixed existence.
kyuusaku wrote:
No matter what tricks people gain from CHR RAM, they could all be implemented with enough CHR ROM/a talented enough mapper.
Unless you're letting the player edit tiles. Think of Mario Paint's stamp editor, or possibly a shooter maker. Or a game where the player can choose a style of hair and clothes, and you don't want to waste the 8 sprites per scanline on overlapping them as separate graphics. I'm preparing a wiki article about CHR ROM-exclusive effects.
Quote:
Unless you're letting the player edit tiles. Think of Mario Paint's stamp editor, or possibly a shooter maker.
Or drawing a picture like in Videomation and Color A Dinosaur.
You should
check out my thread in the Newbie Help Center which has a list with explanations of CHR-ROM and RAM effects.
Well, with just a talented mapper (ROM not even necessary), you could still do drawing apps or other dynamically "generated" tiles, that was my point. I just think there's a certain threshold where it becomes justified to use RAM; where exactly that is, I don't know, but I think everyone would agree the best use of RAM is when it can be reused between games or is absolutely necessary, or both. My opinion would be completely different if CHR-RAM was internal to the system like most other consoles, it's the hardware waste that irks me.
It was pretty necessary for my Glider game (advertising!
) All of the cabinet/shelf/table/etc objects can be any size and placed anywhere. All other vent/books/obstacle objects are fixed size but still placed anywhere. They are too big to be sprites, but aligning them to 8x8 borders wouldnt work either. I was already making my own board to be CopyNES flashable, so adding 32KB of CHR RAM switched in 8KB banks was easy. Name tables are just filled sequentially and timed loops handle the bank switch. I wrote picture copying, rectangle filling, line drawing code that would write to the correct tile/bank.
The board could be used for anything else that needs both big PRG and banked CHR RAM.
One side effect of my solution was the whole screen has to be 4 colors, because objects in the bg will overlap the 16x16 borders. Stupid attribute table! This isn't such a problem because the original Glider game is b/w so grayscale works.
kyuusaku wrote:
Well, with just a talented mapper (ROM not even necessary), you could still do drawing apps or other dynamically "generated" tiles, that was my point.
Yes, the MMC5 has features that came close to this, and altough it only supports CHR-ROM it have features that can get rid of most usual drawbacks of CHR-ROM.
It would be possible to create a mapper that would feed the PPU with customized tiles as it fetches pattern/name tables, the MMC5 doesn't do exactly that, but comes pretty damn close, changing almost all adress lines of the CHR-ROM as the PPU does that.
If you have a mapper that would allow up to 2^128 bits of CHRROM, then you can do every possible combination possible. Come on it's only twice the number of rice you have to put on the last panel of a checkerboard (if you start at 1 and double the amount on each panel).
Hey all. Sorry for reviving this old topic, but I just wanted to post some updates. I saw that I only had like two videos linked here, but I put up my fourth one and have them all organized in the first post now with some descriptions.
Anyway, progress continues. Hoping to be done by next month.
Any chance of releasing an updated nsf? That temple music is AWESOME!
Kasumi wrote:
Any chance of releasing an updated nsf? That temple music is AWESOME!
Actually, I was working on doing a port into Famitracker. Funny story about that particular music. It was a song I wrote in 2002, but ported over directly into the game's music engine. Since I had a midi handy, there was no need for me to make it in Famitracker first. Unlike all the other original stuff I did.
I will definitely work on getting that ported into Famitracker and will put a newer NSF sometime later.
Actually, if you care to hear the 2002 midi recording, go to:
http://www.soundclick.com/bands/page_mu ... dID=111104
Then get "The Flooded Spire". 8 bit NSF action in the near future though!
Checked the last video. Look nice. The only thing... Mega man like disappearing block (sound fx too), the thing I hate the most about the series. If they are everywhere in the stage, that will turn me off
I hate, hate , hate , hate that.
Game looks awesome! I think I'm going to have to buy an NES just for the chance to play it!
I never saw this somehow until now. The game looks great. I'll be keeping an eye out for when it is released.
You could make the game a little more challenging by adding enemies to the screens where the spikes disappear. Maybe have enemies that are only visible when the spikes are hidden so not only do you have to jump to the next safe spot but possibly shoot your way through the baddies too.
Wookie wrote:
You could make the game a little more challenging by adding enemies to the screens where the spikes disappear. Maybe have enemies that are only visible when the spikes are hidden so not only do you have to jump to the next safe spot but possibly shoot your way through the baddies too.
Nah. Keeping track of those is tough enough. The spike rooms get trickier. The ones shown in the videos are the introduction to them. Later ones are faster.
I took a page from Quick Man's stage with these. Have a few not too tough ones and then have a gauntlet of them later on.
They also appear briefly in the final area.