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

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 - Nightcrawler

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 50
Newcomer's Board / Re: Spc Jukebox/player on real hardware/flashcart
« on: August 05, 2015, 08:18:21 pm »
This is hardly believable. The only way this can be technically achieved is by cloning the SPC chip in the cartridge and use the expansion sound pin. Perhaps that's what they did.

No, it is certainly believable. I have an SD2SNES. I can tell you approximately how it works. SPC files are basically savestates and contain the entire music engine for a given song, right? So, what they do is simply load in the state of the DSP, and the full SPC memory contents, and start execution. Presto! You're now playing back your given SPC file. Now, this method is of course only valid to play a single song. So, any time you stop playing, there is a quick screen flicker. I assume the system is being reset during this time. Since the SNES retains all of it's memory during reset, it recovers near instantly ready to load the next song in the list.

I imagine the PowerPak must do something similar.

Programming / Re: Getting Started on a VWF?
« on: August 02, 2015, 12:05:59 pm »
Congrats! Perseverance pays off in ROM hacking. Add another skill to your bag. :)

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 22, 2015, 06:41:09 pm »
I use Notepad++ which allows you to set up syntax highlighting -- but it doesn't have auto complete.

Yes it does. Settings -> Preferences -> Auto-Completion

Also related to Notepad++ and SNES IDEs, I have used this setup a few times before. It's not your ideal SNES IDE, but pretty cool nonetheless.

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 20, 2015, 08:09:11 pm »
I have reviewed the documentation in detail and... I like it! It seems like a very capable assembler with some reasonable and consistent syntax. You get bonus points for good documentation too! It seems you have most things covered.

1. Does #IncBin and #IncSrc handle relative paths?
2. When declaring variables like 'SomeVar = $001800', are you required to always use long addresses?
3. Is there a way to output the pc or embed it into debug message like #Warn/#Error? I have to do this often to get the breakpoint I need to use to debug various specific areas and lines of code. I didn't see a way to do this.
4. Can expressions be used in variable declarations? Something like 'Foo = (5+2) - 1 * 7 ;my secret constant for sprite animation.'? What about a variable within a variable declaration? I'm getting at equivalent functionality for defines in xkas/bass. You can do some interesting things with them being able to define almost anything. Not all of that power is needed, but it is a frame of reference when evaluating abilities of schasm.

I know you probably choose #Byte,#Word,#Long,#Dword for consistency with all directives and ease of parsing, but what do think about also supporting traditional db (define byte), dw (define word), etc. type syntax many assemblers do?

1. #Var is a nice addition. It is annoying to add variables in the middle of your list, change your mind about a variable length throwing addresses of everything else off, and what not.

2. Interesting approach to #Org with the independence between platform address and file offset. That's great for more difficult mappings as long as it is not a burden for simple mappings. I see it is optional, but I'm not sure I understand how optional with the explanation given. If you have a no header, traditional hirom mapped ROM, and all your code is in the linearly mapped region for example, you wouldn't really have much need to declare file offsets more than once at the beginning. All other instances of #Org in the project probably wouldn't need it (nor would I want to have to declare it all the time). Is that allowed here? When can you omit the file offset on #Org exactly?

3. It's dangerous to make assumptions that some things will never be used. Either I saw, or I read about (damn old age, I can't remember!) a game that used brk to call a decompression subroutine, for example! Few would expect that usage, but yet it was done. Perhaps that was not the smartest thing to do, but I'm sure there are other cases where something was used unconventionally and it was actually very clever. I guess my point never assume something would never be used and use as an excuse not to put it in! You'll need another excuse! :laugh:

Small mistakes observed:
1. In both readme.txt and directives.txt your passage says 'changes how the compiler assembles its code.' Technically it's an assembler rather than a compiler.
2. typo in readme.txt -  'jmp Label       ; legal, Label is vidible here'

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 19, 2015, 01:00:22 pm »
It's explicitly given by the user.

I don't need much for DP awareness.  Just a way to specifiy what direct page is and have the assembler take advantage of it.  Many assemblers don't even do that much -- if you want to use DP you have to actually specify the size of each individual instruction.  Like in xkas, you have to use the '.b' mnemonic suffix (lda.b) or it will always use absolute mode.  I didn't see anything in Asar's notes which changed that -- though maybe I missed it.

Oh, right. I forgot xkas didn't actually support direct page in the assume command. Then, I think asar removed it entirely in favor of auto 24-bit to 16-bit optimizations, but apparently leaving direct page optimization out in the cold. So, supporting it at all would indeed be an improvement! ;D

Yes.  You specify a range of banks for data to be mirrored across.

I was going to respond by mentioning that the WRAM mirroring is a fixed scheme on the SNES, but I see in your documentation that you you already map it by default and allow additional mirroring via that directive. Nice! :)

It looks like you're off to a great start so far. I will read through what you have a little more closely when I have some more time and see if I have any other useful comments to muster. I know it's early in the game, but it would be great to support SPC700, and a few other SNES co-processers in the future. asar does SPC700 and includes SuperFX for example.

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 18, 2015, 09:35:45 am »
Asar is interesting, but it still doesn't have the mirroring acknowledgement or the awareness to shrink to directpage when appropriate which are two things I REALLY wanted.  It does have some other interesting ideas that I might steal, though  ;D

How do you intend to do any better than the aforementioned assemblers on direct page awareness? You will always have the inherent problems that you don't know the starting values (unless explicitly given by the user), it can be changed in code outside the assembler between functions, and you can't handle it being changed by stack pulls, or if the value is a result of a calculation, table grab, etc.

For mirroring, have you accounted for the fact that WRAM is not mirrored in all banks?

Programming / Re: 65xx Assembler Alpha release: Schasm
« on: July 16, 2015, 05:58:36 pm »
I suggest you also take a look at Asar. It's a fixed and extended version of the old xkas lineage. It's not well known in these circles, so I thought I'd throw it out there.

Programming / Re: Getting Started on a VWF?
« on: July 11, 2015, 01:19:21 pm »
Speaking of Tales of Phantasia. Didn't already do this there? You had an 8x8 VWF there for the menus, right? To do that you had to draw tiles dynamically to RAM. It's the exact same concept here.

Yes, it looks like your problem is coming from the FMVs. No patching format is going to be able to do anything about that. Since you hard coded it, you've changed nearly every frame of the video. The resulting full video will be vastly different resulting in a huge chunk of marked different data (especially if compression is involved). The reason your custom patcher is 2 megabytes is because you already know the new data ahead of time and are storing a video editing procedure to apply it. The patcher needs to reverse engineer that with only strict binary difference rules. It will never come up with the same results.

In any event, if you absolutely need hard coded subs, it probably would be more appropriate to include a utility to apply the subs to the videos.

I would say it is about the same as the background analogy. It would be convenient to be able to disable channels in the emulator, however you can live without it. When I have had a need to disable a specific audio channel, I have usually done so temporarily in software and rebuilt.

If I were in your shoes and trying to streamline and simplify the code as such, I'd probably omit it. I don't think the added complexities are worthwhile for the feature even though I do think the feature itself would be a nice convenience.

So as to purify the situation once and for all [future entries], what do you think of the following format:

This utility was designed for the site and it's output format is the desired standard output. Please either use this utility or follow the rules it employs.

See all the backing discussion on the discussed rules for certain platforms below. The term hash as applied to ROMs of various platforms can be ambiguous.,16846.msg246949.html#msg246949

Most advanced hacking is done with hardware documentation, a debugger to reverse engineer with, and a cross assembler to assemble new code into the ROM.

If you know of translations that aren't here and should be, by all means add them for benefit of all! :)

If for some reason the license or readme file of the project may not allow for distribution here, you can still add the entry page. You would simply use the 'No File' checkbox and note distribution is not allowed per readme/license in the description in that case.

Programming / Re: Sailor Moon SuperS - Fuwa Fuwa Panic APU Question
« on: May 01, 2015, 09:08:04 pm »
It's not weird, I don't think. The way the APU works is you have your sample that was recorded at some sampling rate, and then the VxPITCHL/VxPITCHH registers scale the original pitch up or down for playback. So, in order to come up effective scaling value for those registers, you have to know the original sample rate. The same value in those registers will play different samples at different rates since it scales proportionately to what the original was recorded at. That's also why when you rip samples, you don't know what the original sampling rate was without some trial and error guesswork.

Anomie's SPC700 Doc
Anomie's S-DSP Doc
SNES Programming Wiki
SNES Development Wiki

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: April 16, 2015, 06:31:09 pm »
That seems like quite a bit of programming to accomplish viewing or editing some tiles. I think that might put it out of reach for most for anything you don't supply out of the box. I think it is simpler to use the aforementioned tools in this thread that do the same. I think the concept of blindly extracting portions of data from a ROM and then defining attributes on how to parse and view that data is interesting and good. However it seems a little overcomplicated for what it is. I'd be curious what other people's opinions are.

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: April 15, 2015, 07:42:42 pm »
Congrats! :beer: I know all too well how much effort goes into making some of these constructs that result in very little to the untrained eye on the surface! It's hard to really appreciate the 'under the hood changes' from the end user position.

What did you end up doing for the tile definitions?

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: April 10, 2015, 06:21:13 pm »
Right, and it was all done for FEIDIAN before that. There's a whole pack of definitions for that.

You should probably hang out and do your tutoring in instead. :P

Gaming Discussion / Re: Farewell tri-Ace =(
« on: April 01, 2015, 06:06:45 pm »
The first thing it does well, right out of the gate, is present a unique, beautiful setting that's exceptionally nice to look at and listen to. Then you're hit with the voice acting, and it really helps sell the fact that this game was unlike anything else that was released at the time. The sprites are absolutely gorgous, and unlike most games in the genre, at least around that time period, your protagonist was a female, who begins to question her role, and not a typical JRPG hero.

The second thing it did right was present some of the most absolute heartbreaking moments in gaming. Some characters you catch glimpses of before you recruit them, some are brave, some are scared, some heroes, other villains, but they're all gonna end up the same way if they're joining you. Seeing the pieces fit is where most of the story is.
Also agreed, except that's all you get with any character. They are nearly all throw away immediately after you acquire them. In fact, the very nature of the game is to train them and throw them away. Aside from Lucian and Valkyrie, none of the other playable characters get any development. That was a huge letdown for me. Most chapters had very little actual game story either (it was all packed into the end). So, with no story and few characters that meant anything, it made for a pretty boring game after a fantastic intro. It didn't really deliver what it set up.

The game's primary flaw was the way the difficulty presented. Easy is harder than Normal and Hard due to the lack of time to train, and making the endgame bosses almost impossible to beat, Hard was better for min-maxing. Also, the endings were too frustrating to ever get without a guide, but those are relatively minor complaints about an otherwise astounding game.
The whole game needs a guide really. You're basically required to get certain items and skills to have a chance in the game. And you have no idea where they may be. You just have to waste your periods since you are penalized to enter and exit a dungeon, or visit a town. It really kills exploration when you are always penalized for everything you do. You can't afford to exit, heal, and re-enter to look for missed things without potentially sacrificing the ability to enter unexplored dungeons or towns. The Cave of Oblivion was random and could contain nothing and be a complete waste of time. While the idea of limited time was fine in concept, I thought it was poorly executed in the game with not enough periods to play successfully and be fun. (I played on normal.)

It's a game that you generally have to use tactics for. Lezard's Tower is easily one of the game's hardest dungeons, due to its size, and puzzles, as well as difficult battles. Getting the right party out, using magic correctly, and making good use of item creation solves many of those issues those. Save Scumming is also useful in deciding which areas to tackle when, but most everything is beatable, even if a perfect run is nigh impossible. The random element may have hurt you, due to some areas opening up earlier or later, meaning you were less prepared, but everything's beatable for the most part.
The moment you leave the tower and do ANYTHING else (like train, enter a town, etc.), when you re-enter it's impossible to get the good ending. I played to the best of my ability up to that tower and enemies easily killed me. If you leave and train, you get the bad ending. There seemed to be many poor game design choices like this. It seemed to half-baked, and the difficulty ramp looked more like a third order polynominal rather than a ramp!

Personal Projects / Re: Fischmare - General Purpose Rom Editor
« on: March 31, 2015, 08:52:52 pm »
This sounds like an interesting project. I love the idea of turning it into a more generic tool. This is the direction utilities need to go in to really evolve to the next level. This of course involves being able to input game structure into the utility. You just have to watch out for the scope. The more generic it becomes, the more abstract high level concepts you need to add, and it can grow in scope very quickly after you examine several games in detail. It's a good thing you're starting with one.

I probably should have thought more about using scripts to do the structure and data translation parts as you have here, rather than attempt to make a nice GUI interface for it all (much more work) in my utility. That's one of the reasons I have not yet finished a releasable version of TextAngel. I look forward to seeing how this will develop. Try to stay out of the holes I have fallen into with scope creep getting out of hand. Either that, or be able to throw more free time at it! :laugh:

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