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 ... 8
Gaming Discussion / Re: Strategy games for SNES
« on: July 01, 2015, 07:48:36 pm »
Both Majin Tensei games are really good

Gaming Discussion / Re: Need help identifying a golf game
« on: June 30, 2015, 01:01:54 am »
The game you're thinking of is "Nice de Shot" for the SFC.

The bad news is that that text isn't actually part of the game; a former tcrf.net co-admin and I were having some goofy discussion about the game's Engrishy title (and that of a different SFC golf game) and somehow it led to the creation of the two doctored screenshots you can still see in his signature at that link.

Gaming Discussion / Re: ZSNES has been comprimised.
« on: June 28, 2015, 09:28:49 pm »
By your logic, all Atari 2600 games should be totally bug-free, or the occurrence of bugs should be extremely unlikely.
How'd that work out in reality?

... Probably pretty well? Which bug-ridden 2600 games did you have in mind?

Using that as an example doesn't make a lot of sense to me, since "simple" is not at all how I'd describe programming for the 2600, no matter what the scope of the actual game is.

I've never really had any use for disabling individual channels, other than for fun (and it can still be done in most other emulators and SPC players anyway...)

I'm not really opposed to taking it out if there's not another practical solution that doesn't interfere with accurate DSP emulation.

Gaming Discussion / Re: ZSNES has been comprimised.
« on: June 24, 2015, 09:22:26 pm »
It's a bug in how ZSNES handles SA-1 emulation, and the exploit has likely been in place for as long as ZSNES' SA-1 support has (10-15 years?).

Here's a video of the exploit in action, and here's a recent SVN build with the bug (probably) fixed.

Note that the current SVN version of ZSNES is somewhat unusable, and a "proper" 1.52 release might not happen for a while.

I'd be very surprised to learn that any rippable SPC (i.e. excluding music engines that depend on 65816-side data streaming) from any game hasn't been long-since ripped by now

I've personally ripped either missing songs or entire soundtracks for dozens of NES and SNES games within the past few years that simply didn't have complete sets available, and there are still quite a few SNES games that, to my knowledge, don't have complete SPC sets available for one reason or another (and that's only including games for which dumping playable SPCs is actually possible). Even beyond that, there have been dozens of other games which have recently had new SPCs added to sets that were previously assumed to be complete, whether it was music that was outright unused or just obscure enough to be missed by the majority of listeners, but it's not an entirely obsolete feature, and it's one that I've made use of very many times in other emulators (especially in conjunction with a debugger such as Geiger's), so there it is.

I don't expect bsnes-plus to ever come anywhere close to the level of usage among "ignorant newbies" as ZSNES and Snes9x, both of which have had the same feature since approximately the stone age. Adding it to one more emulator, especially a relatively niche one like this, really isn't lowering the barrier to entry for would-be SPC dumpers in any significant way.


Didn't have the time or motivation to work on useful debugging stuff lately, so I spent a couple of hours banging this out instead.

I'll be rewriting the memory and breakpoint editors soon, and will probably release again after that. In the meantime, EmuCR has daily snapshots now (which I haven't tested at all, so try them and see, I guess).

The crash still happens with the latest git revision. I'll take a look later and see what's going on, thanks for pointing it out.

Fixed (see this commit + comments).

Here's an up-to-date build.

Are you aware of bsnes mercury? It includes Super FX over clocking.

I'm familiar with it, though I haven't used it before. Personally I'm not sure if SuperFX overclocking is the sort of thing I'm interested in adding to an accuracy-oriented emulator though.

The crash still happens with the latest git revision. I'll take a look later and see what's going on, thanks for pointing it out.

Site Talk / Tools mistakenly listed as DOS programs?
« on: May 17, 2015, 02:41:10 pm »

How many of the utilities currently listed as being for MS-DOS are actually command-line programs for Windows? I recall correcting this for xkas (or some other one of byuu's programs) a while ago but it seems like almost all of his other command-line stuff still has the incorrect OS listed, and it seems like dozens of other Windows command-line tools added in recent years were subject to the same mistake.

I feel like it's kind of important to get the distinction correct for two reasons - mostly because people searching the "Windows" category could potentially miss out on some very useful tools (particularly assemblers, data extractors/inserters and the like), and also because if someone were looking for programs to use in an actual DOS environment (which is unlikely, mind) they'd have to sift through who-knows-how-many programs that don't actually work as advertised because they're mislabeled Windows software.

Still slowly working on bsnes-plus in my spare time, but I also (finally) touched up xkas-plus a bit and added a link to binaries in the OP. Check it out!

Fun fact: KALE uses xkas-plus to generate limit-removing patches (in IPS format) that can be applied from the editor, as an example of how I've extended it to be useful for systems other than the SNES.

Nice! Missed this one. But about data: still we could have a diversification about read and read-written?

The usage stats actually do track reads and writes separately, it's only the memory viewer that (currently) uses the same color for both.

On a related note, I was recently discussing reworking the usage tracking, including adding more specific usage contexts (see this github issue for specifics). It'll most likely be an upstream change in bsnes-classic whenever that happens, but aside from that, I've also considered adding a way to customize the colors (including separate read/write colors if it'd be useful).

As for labels, I did plan to add support for those later on as well (probably similar to the way they are handled by the FCEUX debugger).

The debug does not show the address to the FX-BUS?

Right now, the SuperFX debugger only shows all the registers that are relevant to the current and previous instructions. I did this before writing the actual register editor, which makes it slightly redundant, and I might reduce it to showing the current instruction's registers to make room for other relevant info (like ROM/RAM access locations, such as in your example).

While this looks great and everything appears to be adequately made, there is one problem that irks me though, I write my code in Hex, not in ASM. So I prefer to write A90A or C905 rather than LDA 0A or CMP 05 for instance. The issue with this is that you cannot continue writing after one byte, sure you can press left after filling in one byte but that seems needlessly mundane and a step backwards to what is provided by Geiger's SNES9X. Also if you do use that method and you go to the end of the line instead of cycling back to the next bit of hex as you'd imagine the writing cursor is within the address line, which is just sort of silly. Another issues I have is with pasting, when you go to paste it doesn't even write to code... it doesn't write to anything really.

All in all it is a great looking emulator with good compatibility but some of the more crucial debugging aspects are still a bit finnicky and need some work. A great effort though.

The hex editor is entirely a remnant of the original bsnes debugger. I'm rewriting it, don't worry.

I plan to change it to refresh once per frame once I start reworking parts of the original bsnes debugger GUI, so hopefully that should be fast enough.

Having done some romhacking back in the day I can say quite confidently that I hate soft patching. I've had quite a few problems with it and I remember a lot of people who also did. I think it's important to remember adding features for the sake of having them can also add layers of complexity and bugs that you might not want.

As I pointed out earlier in the thread, bsnes already supported soft patching long before I ever modified it; I'm just updating it to include a format that is still in common use. It always was and still will be a completely optional feature.

Look: Konami delists itself from New York Stock Exchange
Maybe they are not making too much money anymore?

I feel the need to point out that the company that was delisted from the NYSE was Konami Gaming, Inc., which deals in slot machines and other casino-related products, and not Konami Digital Entertainment, which deals in video games.

Aside from that, it is not at all uncommon for foreign companies to stop trading on other countries' markets for any number of reasons, many of which have nothing to do with the financial status of the parent company. I doubt this had very much to do with the Silent Hills fiasco aside from timing.

I definitely plan on reworking the memory viewer and other stuff; almost all of the debugger GUI is unchanged from the original bsnes debugger, but I'll be working on improving it as time goes on. I mostly wanted to get the actual debugging features and useful stuff ready before anything else.

There's an option for it in the Tools menu (next to the "capture screenshot" option). You can also bind it to a keyboard key. It'll wait until the next time a note plays and then dump the SPC to the "exported data" directory (which is by default the same directory as the ROM).

Do you know if blargg's modified 7z code was ever updated since v073?

Oh dear god I'll be trying this out as soon as possible.

Edit: Oop.  Missing libgomp-1.dll on launch.

Fixed. I basically threw the snesfilter (and other) plugins in at the last minute without bothering to check their dependencies (compared to the program itself), but it should run now. Sorry about that

Edit 2: Are we allowed to make feature requests at all?  Probably an easier one, but could we allow any button on the keyboard be used as a button assignment?  I know you have to use Shift + something to allow the shift key, but it'd be preferable if we could just use 'Shift' as a button.  Same thing with Ctrl.  I know later bSNES version allowed that, not sure if that's really a 'bad' idea or not though.

Feature requests are definitely welcome. I plan to play around and make some changes to the frontend eventually and changing how inputs are setup might be part of that.

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