Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Revenant

Pages: [1] 2 3 4 5 6 ... 10
Gaming Discussion / Re: Will Nintendo target [b]here[/b] next?
« on: September 16, 2016, 12:09:41 am »
First: If it was because of copyright infringement, why did Nintendo wait for DocM64 to complete and release the game to C&D him then and not way before?

Maybe it just wasn't on the radar of Nintendo's legal department until dozens of gaming news sites started covering the actual release of the game.

Second: This is the link with the news on the ROM site raid: http://skirmishfrogs.com/2016/03/19/nintendo-tells-website-to-remove-2200-roms-including-hacks/

Okay, so a ROM site got busted for hosting thousands of ROMs. This isn't really news. If you're distributing full sets of unmodified Nintendo console games, you're helping people pirate games that Nintendo still makes money from. That's a pretty big reason for them to go after you.

Again, that's why Romhacking.net only deals in patches - distributing pre-patched hacks of a commercial game is, of course, equally illegal to distributing the original game.

Third: Correct me if I'm wrong, but aren't a huge load of the hacks hosted here centered around Nintendo games?

You're probably correct. But given that most of the downloads are patches that themselves contain very little or no copyrighted content, the chance of this actually presenting a major legal issue is still rather small.

Gaming Discussion / Re: Will Nintendo target [b]here[/b] next?
« on: September 15, 2016, 11:53:01 pm »
If Nintendo goes after a ROM site (what specific site are you even talking about?) that's because it was a ROM site, which is plainly illegal. Nintendo (and the ESA and other related organizations) have been going after ROM sites for something like 20 years now. Romhacking.net isn't a ROM site.

Nintendo shut down AM2R because it was blatant copyright infringement. The entire reason ROM hacking sites only distribute patches is to avoid copyright infringement as much as reasonably possible.

It's entirely plausible that Nintendo might try to issue DMCA takedowns against Romhacking.net for specific hacks, or send C&D notices to hack authors or something like that, but in the long run that's about as likely as it's always been - that is, not very.

There is virtually no chance of the entire site somehow getting shut down because of Nintendo. If it were that big of a legal issue, it probably would have come up already.

Front Page News / Re: ROM Hacks: And We're the Game Grumps!
« on: September 10, 2016, 12:46:58 pm »
You might as well just distribute an entire pre-patched ROM at that point.

Front Page News / Re: ROM Hacks: And We're the Game Grumps!
« on: September 10, 2016, 03:19:12 am »

Here's the patch by itself for people who want a smaller download.

A version of the hack for other regions of the game might also be nice, since this one only works on Kirby Bowl (Japanese region), according to the hack info.

There was a reason for that: the "All Courses" menu is an edit of the Japanese version's debug level select, and the Japanese version of the game had several unused courses that were used to accommodate more new stages. (Also, the English versions have no intro sequence!)

ROM Hacking Discussion / Re: Screenshots
« on: September 08, 2016, 06:43:01 pm »
Very impressive, Grimlock! Looking forward to whatever else might come of that.

Seems like a neat place ... but I see that one of the users has the title "Disgustingly Naive Smartass" ... What the actual fuck?

People with more than 500 posts are allowed to give themselves whatever title they want.

Yeah, the forum is unfortunately less active than it could be. People are still welcome to post their cool findings there though :)

Yeah, that site is officially dead in the water unfortunately.

We are? That's news to me...

From what I understand, or for what it looks like, from this bsnes fork version of yours, you look like you are turning the bsnes emulator into something like FCEUX (in which it has NES romhacking & debugging tools, and a built-in hex editor). Isn't that right, Mr. (or Mrs.) @Revenant?

Basically, yes. Well, the debugger was already there, but my goal is to make it more robust/usable (though unfortunately it's not quite as full-featured as the FCEUX debugger yet).

When a (R/W) breakpoint is hit, and I step, it just hits the breakpoint again, so I have to step again to actually step. Intended?

This can happen if a single instruction reads/writes two bytes that are both part of a single breakpoint's address range, or if a read+write breakpoint is triggered by a read-modify-write instruction (because the read and the write don't actually happen simultaneously). This is less "intentional" behavior and more just a side effect of how breakpoints were already implemented in bsnes.

Trace logs could show the opcodes+operands in addition to the mnemonics.

This is something I already wanted to add at some point, both to the debug/trace window and the disassembly window.

I don't know how to disassemble anything else than what it decides to show. This gives a claustrophobic feeling.

The disassembly window only shows stuff that has actually been marked as executed, within a certain distance around the current PC. This is another thing from the original bsnes debugger that I would like to improve eventually.

edit: In a LoROM game if I set a breakpoint at the mirror $80-$BF, it won't trigger if mirrored is accessed. Intentional? Geiger's does.

Right now, breakpoints only support address mirroring when specifying a single address, rather than a range of addresses, for performance reasons. (See this post for an explanation.) This is something I might try to revise eventually. Keep in mind that if you're only breaking on a single address, you can leave the end of the address range blank.

edit2: Memory editor could show the exact offset of the selected cell.

This is another change to the memory editor that is already going to be in the next release.

Programming / Re: Tracking Where to Write Tiles In VRAM
« on: July 12, 2016, 09:58:24 pm »
*(Technically it renders "1 pixel at a time" or even finer than that.  But given how all emulators -- even the super-strict Higan/BSNES -- emulate on a scanline-by-scanline basis and nobody really knows the details of what the SNES is doing during each individual scanline..... "1 scanline at a time" is close enough)

bsnes/higan actually does have a pixel-by-pixel renderer - that's one of the main draws of the "accuracy" profile. That's how it is able to emulate things like changing the background mode mid-scanline (that's mode 7 on the left and mode 1 on the right), and some of the visual effects in Air Strike Patrol, which is commonly cited as one of the games that made a per-pixel renderer necessary.

eh isn't it like a placeholder so people can put them there when they happen? oh this is for translations of homebrews? Yea I've never heard of any translations of homebrews. Do any even exist?

"Hebrew", not "homebrew".

Programming / Re: Question about how NES hackers do ASM
« on: June 19, 2016, 01:47:15 am »
I use my own version of xkas which I added NES support to and other things, but it's based off of v14 whereas everyone else always used v06, which has its own slightly different/incompatible syntax. You might find it useful, though. The (only) Windows build is here.

The only thing I've actually released using it is some patches to accompany my Kirby's Adventure editor, but it's probably a decent example of how to use it to patch a NES game.

(Don't mind the fact that I start comments with "//;" - the actual syntax is just "//" but I added the semicolon just for the sake of syntax highlighting that I was too lazy to change at the time :P)

I feel like fceux could also check the bank its being read from and break if my condition is met.

As I mentioned in your other thread, it already can.

Programming / Re: 65816: Direct Page vs Absolute Operand
« on: May 17, 2016, 12:55:58 pm »
Most of the time a two-digit literal address (like $50) would be interpreted as a direct page address rather than a normal absolute one. However, most assemblers have a way to specify a specific address size (e.g. "lda.w $50" would read the absolute address $0050, and likewise "lda.l" for a long address). The syntax varies from one assembler to another.

The download here is the same build as the release tagged "073+2" on GitHub. EmuCR provides more up-to-date builds here: http://www.emucr.com/search/label/bsnes-plus

I meant to mention this much earlier, but there's actually an undocumented setting for that in bsnes-qt.cfg (located in %AppData%/.bsnes/ on Windows, ~/.bsnes/ everywhere else). Changing "input.modifierEnable" from true to false will allow you to bind modifier keys by themselves instead of using them as part of key combos.

I added an actual checkbox for that (as well as "input.allowInvalidInput", which lets you press opposite directions on the D-pad at the same time) to the Input tab in the latest revision, which may or may not show up on EmuCR sometime in the next 24 hours, or you can modify the config file manually (and see what other interesting settings are available).

Gaming Discussion / Re: Odd thing with SNES text
« on: May 02, 2016, 09:19:20 am »
Snes9x also uses the console's current resolution to display text, so any game that uses hi-res or interlaced modes will make things like framerate/input displays become narrower or smaller.

Gaming Discussion / Re: Comparing game localizations
« on: April 26, 2016, 09:05:37 am »
I think we can probably exclude games like Duke that were given an M rating, though.

Gaming Discussion / Re: Comparing game localizations
« on: April 26, 2016, 01:54:14 am »
Mega Man 7 comes to mind:

(couldn't easily find a better screenshot than this weirdly dark one on GameFAQs)

Pages: [1] 2 3 4 5 6 ... 10