 |
| Register | Login | |||||
 |
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
|
| Register | Login | |||||
|
Main
| Memberlist
| Active users
| ACS
| Commons
| Calendar
| Online users Ranks | FAQ | Color Chart | Photo album | IRC Chat |
|
| | ||
| Acmlm's Board - I2 Archive - - Posts by Dish |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| User | Post | ||
Dish Spiny Level: 38 Posts: 581/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by kuja killer The quote of the day, everbody. This is exactly what's wrong with rom hackers these days. Nobody's willing to do real, actual work. They expect instant results with minimal effort... then get frustrated quickly after they realize that it actually does take a decent amount of brainpower, time, and busywork to get anything done. If you don't have hours (as if that were even a significant amount of time) to dedicate to a hack... then yeah... ROM hacking probably isn't (wasn't) for you. Sorry to sound like an ass about it... but man. It sounds like you gave up before you even started. |
|||
|
Dish Spiny Level: 38 Posts: 582/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Dude Man No... it takes imagination and creativity to make good game ideas. Actually making the GAME requires (in addition) a good deal of technical knowledge that the majority of these 'creative' hackers not only lack... but are unwilling to acquire. That's bbit's point. BBit drew these parallels between rom hacking and programming because the two are actually very similar. Even though that's true... a lot of people don't realize that because editors give the impression that they're an all-in-one make-your-own-game miracle tool. When they find out that it's not... they either get in gear and learn what needs to be learned (what they should do) -- or they sit around, whine and complain and make endless requests for help (far more common) -- or they even give up, make some dramatic farewell speech, then disappear. Like programming... ROM hacking takes a knowledge of basic programming concepts. Some of you may not agree with this... but it's true... and this is the problem that hits newcomers the hardest. When an editor glitches... or they break some 'rule' they weren't supposed to... or something happens and their hack is bugged/glitched/messed up... 99% of these guys are CLUELESS as to what went wrong. A programmer working on debugging his game will be able to see the glitch and form an educated guess as to what the problem is before even looking at any code. Likewise a ROM hacker should be able to see the problem in their hack (assuming it's not something generic like a lockup or crash) and make a reasonable guess as to what the problem is. And you're probably not suprised to hear this... but all the good ROM hackers CAN make that educated guess. And 90% of the time they're right. A big part of that comes with experience, yes... but it comes down to knowing what you're doing. People that "hide behind" editors don't know what they're doing... so when trouble strikes they're helpless and they come crying for the instant fix. That's the attitude I think bbit (and myself) have a problem with. Also like programming, a project will take a lot of time, dedication, and work. Sometimes it can get downright tedious. There's all these people announcing "hey I'm going to make the super most badass hack of XXXX game ever" and then they either disappear off the face of the Earth... or they announce their hack is cancelled a few days/weeks later. So many things about ROM hacking are just like programming... I mean it's astounding. In fact.. I would even argue that ROM hacking is harder in a way than programming. Sure it's easier because you have a game base to work off of.... but it's harder in that you're restricted to that game base... and you have to work within the boundaries, not only of the system, but of the game. Trying to expand on the game's engine (aka "asm hacking") is harder than expanding on your own engine... since you already know how your engine works... whereas with ROM hacking you have to examine, study, and understand someone else's code... which is FAR more difficult. Which brings me to another point: comprimise. Too many ROM hackers do it. They ALL (no exceptions here... EVERY SINGLE ROM HACKER) get to the point where they want to do something that can't easily be done. Whether it be some kind of level/graphics change... or some major asm change. The difference between the good hackers and the bad ones is the good ones actually learn how to do what they want to do... and the bad ones comprimise. They say "oh well I guess I can't do that"... then their super-cool-delux-best-hack-ever turns into some lame hack any monkey with Lunar Magic could make. "But it's so hard to learn all that." "Do you expect me to learn asm just for this hack?" "That sounds like a lot of work!" "I don't understand anything you just said... I guess I can't do this idea" --- some of the various ways of saying "I'm a lame wanna-be hacker who doesn't have the drive to actually do what I want to get done". That's what my beef (and, from what I gather, bbit's beef) is. YES it will be hard. YES it will take a lot of time. YES you will have many problems along the way YES you will scrap several projects YES you will end up redoing a lot of the same things over and over YES it will get tedious Welcome to programming/Rom hacking. That's how it is. As for unwillingness to help... that's not true at all. It's more like unwillingness to do all their work for them. If someone asks a question I can answer, I will certainly try to answer... and I'm not alone... many people on these boards are equally as willing to help. Though, yes, I do have a bad attitude towards the "bad hackers". When people post things like "GAH THIS IS TOO HARD I GIVE UP" I'm certainly not going to feel sorry for them.. and I'm probably not going to help them. There will always be problems/hurdles to overcome... and if their first problem fills them with that much dispair, then I don't see much hope for them in the future... so I'm not going to waste my time with them. |
|||
|
Dish Spiny Level: 38 Posts: 583/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Disch My point was that simply having the ideas isn't enough. Lots of people get good ideas. Actually making them work is the half of the job that people are lacking. |
|||
|
Dish Spiny Level: 38 Posts: 584/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Thanks for wasting my bandwidth with bitmap images. | |||
|
Dish Spiny Level: 38 Posts: 585/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I guess I originally took your clip out of context as much as you took mine out. Sorry about that. I don't disagree with what you're saying... but at the same time I don't see the relevence to what you're saying. You're saying that making hacks cannot be done solely with programming/hacking skills. Nobody here is saying otherwise. What we're saying is that some programming/hacking skill is required. You (usually) can't make a good hack solely with pixel artistry and good level design any more than you can make a good hack solely with programming ability. They're two pieces of the puzzle... you need them both to make the product. Now of course there are a handful of exceptions, but they're the rarest of the rare. Typically graphics-only hacks are small scale, boring and unimaginative. Ditto for level-only hacks. Many of the high quality graphics/level only hacks DID require a bit of hacking/programming ability (Auxmines' Justin Bailey Super Metroid hack comes to mind -- something like that DOES take hacking ability despite only being graphics changes). ...Which is what bbit was saying. You can be the best level designer in the world but it won't make any difference if you can't hack for shit. Likewise you can be the best programmer in the world and it won't matter if your level designs are drab. So... in short... you're right... but that's not really what bbit was talking about  At least not from what I gathered (certainly wasn't what I was talking about -- although I did take your quote out of context -- again sorry about that)EDIT: forgot to address this:
If you can make a polished product with only X editor, power to you. In all honesty, though... can you think of a single popular/fun/good hack that was made with an editor only? I sure can't. Besides... people that want to stick with an editor is fine. If that's what you want to do, go for it. But when you have problems don't expect everyone to fix everything for you. Again the original note of the topic was that the people who want to go beyond what the editors are capable of aren't willing to learn the knowledge/do the work necessary. If you need to do something that the editor doesn't allow... or you need to fix something the editor broke... guess what. You need to go beyond the editor. So you better get ready for some nitty-gritty, old fashioned ROM hacking. Those who get to that point but aren't willing are the ones I have beef with. If you're content with X editor then that's all fine and dandy. (edited by Disch on 09-28-05 10:56 PM) (edited by Disch on 09-28-05 10:57 PM) |
|||
|
Dish Spiny Level: 38 Posts: 586/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
The part you quoted from me wasn't so much from Kuja Killer as it was from others. This part of my rant was mainly 'inspired' by Kuja Killer's post:
There's a difference between taking advantage of the help available, and being dependent on others to help you. Even if your question goes unanswered (which, as you pointed out, can happen sometimes)... you should still be able to function without the external help. I'm not saying it will be easy... I know it can be hard and frustrating... I've been there before. We've all been there before. For example, look at DD... when's the last time he posted a ROM hacking related question on here? Does that mean he's not learning anything new? Not at all. He's just able to function without someone holding his hand. Now I'm not saying all hackers should have to be on the same level as DD... I was just using him as an example. My point is, assistance in this form (Q&A on a forum) is a helpful, but unnecessary resource. Hackers can use a forum for help... but should not rely on a forum to solve all their problems. |
|||
|
Dish Spiny Level: 38 Posts: 587/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm sure I don't have to tell you this... but PLEASE make every effort to make this a legitimate ROM (uses a real board/mapper, does all necessary startup prepwork, follows the strictest of rules, able to be played on the real system, etc, etc) Of course I recommend Nintendulator for testing, as it's usually the most strict about such things. And yeah, very cool =) good luck! |
|||
|
Dish Spiny Level: 38 Posts: 588/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| One screen consists of 262 scanlines. ------------- 20 scalines of VBlank ------------- 1 "pre render" scanline ------------- 240 rendered scanlines ------------- 1 Idle scanline ------------- The pre-render scanline is used to fetch tiles for the first render scanlines (tiles have to be fetched a little earlier than they're drawn). The idle scanline does absolutly nothing... and it's sort of a ripoff (it might as well be VBlank time... but NMIs don't fire until after that scanline is complete). Every scanline consists of 341 PPU cycles except for the pre-render scanline which alternates between 341 and 340 every odd frame on NTSC systems. On an NTSC system there are 3 PPU cycles to 1 CPU cycle, so a scanline is 113.66666667 CPU cycles. On PAL systems, there are 3.2 PPU cycles to every 1 CPU cycle (PAL scanline = 106.5625 CPU cycles) For details on what PPU fetches happen on what cycles and further details, I'll refer you to Brad Taylor's excellent PPU doc. EDIT -- although note that the mentioned doc's MMC3 information is inaccurate. MMC3's IRQ counter is actually tied to A12 not A13, and operates very differently than how described in that doc. (edited by Disch on 09-29-05 11:03 PM) (edited by Disch on 09-29-05 11:15 PM) |
|||
|
Dish Spiny Level: 38 Posts: 589/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Forgot to mention that PAL actually has 70 scanlines of VBlank and not 20. But yeah Anyway... mind if I ask what you're doing? ^^ I freaking love the NES |
|||
|
Dish Spiny Level: 38 Posts: 590/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Well there isn't really one doc which has it all, unfortunately. The closest thing to that would be the nesdev wiki, although it's not given nearly enough attention... so it's not really as complete as it could be. As far as 6502 goes.... This page seems to be the best one. I've been using it forever and have yet to find a single error. The infamous "6502.txt" does a better job of explaining each instruction and its operation... however it's riddled with misprints and errors. It still might not be a bad read to get the idea... but for the technical stuff (which instruction uses which opcode, how many cycles they take, etc) I'd use that above linked doc as the final word. A few 6502 quirks worth mentioning that aren't really covered in many docs: - NES is an NMOS processor... not CMOS. So if you come across a doc which is talking about NMOS/CMOS differences... you're interested in NMOS. - There is no Binary Coded Decimal on the NES (controlled by the D status flag). The D flag still exists on the processor and can be set/cleared normally... however its state does absolutly nothing. ADC/SBC always work as though the flag was off... even if it was on. - BRK is actually a 2-byte opcode (well not really.... but it might as well be). The byte after a BRK instruction is skipped over when a game returns with RTI. However this isn't really important... as BRK is seldom/never used in NES games. - There is no "Reserved" or "Unused" or "R" flag in the processor status reg (bit 5). It's just that whenever status is pushed to the stack (PHP,IRQ,BRK,NMI) the bit is always set. - Likewise there is no "Break" or "B" flag in the processor status reg (bit 4). Bit 4 is just set/cleared when status is pushed to the stack depending on HOW the status is being pushed. (PHP/BRK set the bit... IRQ/NMI clear it) - I have yet to see a document ANYWHERE which does a decent job of explaining how the V flag is set on ADC/SBC. On ADC... it's set when Positive+Positive=Negative... or when Negative+Negative=Positive, and cleared on any other conditions. And on SBC it's set when Positive-Negative=Negative or when Negative-Positive=Positive... and cleared under any other conditions. But the V flag is seldom used so it's not that big of a deal. This doc on nesdev has a very cool section near the bottom which explains what every instruction is doing on every cycle. It might not be useful for what you're doing but I like recommending it anyway just because it's very detailed. As for NES operations... honestly... I don't really know of a good doc which covers all of it without error. NEStech is still a favorite of mine.. despite being very old and somewhat outdated (and often incorrect). Although it should be "good enough" for most things. There were a few spinoff docs... FP made one called "Nintech" which I never looked at... mainly because I'm spiteful towards FP. There was also one made by the No$GMB guy semi-recently which seemed to have the least errors but it's not on nesdev and I don't have the link to it anymore. NESdev has another one called "NES System Architecture" by Marat Fayzullin... but it's even older than NEStech so I wouldn't recommend it (it's what NEStech was written to replace). I'll stop rambling now ^^ EDIT - crap.. forgot probably the most important link! As far as mappers go... Kevtris' docs are pretty much the FINAL authority in that department: Link. (edited by Disch on 09-30-05 11:59 AM) |
|||
|
Dish Spiny Level: 38 Posts: 591/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| I'm really glad to see you stuck with it and are making progress =). Sorry if I was an ass before (I get like that sometimes). But yeah... great news to hear you're sticking with it. Keep it up =). Don't let those snags get you down. |
|||
|
Dish Spiny Level: 38 Posts: 592/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by 46 Ah yes... the "good" old days. Back when hacks were of such high calibur as "Super KKK Bros" and "Wheel Chair Mario". And let's not forget "Garbage Graphics mario" or whatever it was called which just replaced all the CHR with random pixels. Thank god things changed. |
|||
|
Dish Spiny Level: 38 Posts: 593/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by kuja killer http://2a03.org (edited by Disch on 10-02-05 10:04 AM) |
|||
|
Dish Spiny Level: 38 Posts: 594/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by infidelity Well for starters there is no "value of INC" as you put it. All INC does is: 1) Read a byte from memory 2) Add 1 to that byte 3) Write that value back to memory Are you sure an INC is being used? or are you just saying INC because the value is incrementing? It's possible the game uses ADC to add 1 to the value rather than INC... and if it does that, it might be followed by a CMP #$09 or CMP #$0A instruction so that it knows when it reached it's max (9), so it can reset.... or it may use INX/CPX instead. |
|||
|
Dish Spiny Level: 38 Posts: 595/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
| Open up a graphics editor like TLP and start copy/pasting. CHR is pretty easy to recognize just by flipping through the file (unless it's compressed -- but in MM1 it's not) |
|||
|
Dish Spiny Level: 38 Posts: 596/596 EXP: 355646 For next: 14801 Since: 03-15-04 From: Disch Since last post: 18 days Last activity: 18 days |
| ||
Originally posted by Mattrizzle That's an awfully stupid "feature". Who the hell is going to input offsets in decimal? I think Thingy did that too.. but it's been a while since I used any of those. |
| Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 |
| Acmlm's Board - I2 Archive - - Posts by Dish |
Blehhh