News: 11 March 2016 - Forum Rules
Current Moderators - DarkSol, KingMike, MathOnNapkins, Azkadellia, Danke

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 7 ... 10
News Submissions / 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.

News Submissions / 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.

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:

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)

ROM Hacking Discussion / Re: Screenshots
« on: April 24, 2016, 07:57:11 pm »
Oh hey, finally another KALE user

I guess I should work on the editor a little more at some point.

Gaming Discussion / Re: Sega embraces game modding.
« on: April 21, 2016, 10:50:44 am »
Sega is not even close to the first company to make level-editing functionality available via Steam Workshop or any other means. To the best of my knowledge, it has never had any significant impact on the availability or sales of completely different games by different developers. Neither has Mario Maker, for that matter. It's something designed to appeal directly to people who are already dedicated fans of a given game/series.

The level of conditioning and manipulation is already awesome... the real reason this community is small is because people are afraid. So many people know this site exists and the tools, and they've been wishing for years that they could produce something meaningful with them but they know they risk prosecution by the publishers. (if I had a nickle for the number of single moms living on state aid who say they've experimented with the tools here...). Now they can. We've been willing pawns in their hype gambit.

So... it's bad because people will want to mod games using official means instead of unofficial tools developed by amateur hobbyists? Who cares?

Gaming Discussion / Re: GDC emulation talk "It's just emulation"
« on: April 09, 2016, 08:50:19 pm »
Interesting how he slams pirates in the summary text

I don't think "those darned software pirates" was supposed to be read as a serious attempt at condemning piracy, especially since multiple times throughout the talk he specifically does the opposite (i.e. giving due credit to people who get labeled "pirates" by the game industry just for trying to keep out-of-print games available to players).

News Submissions / Re: ROM Hacks: Communist Mario 3 Released!
« on: April 01, 2016, 02:33:32 pm »
Would be more effective if Mario == Putin.

Putin isn't a communist.

Also digging the box art/manual, nicely done.

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