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

Pages: [1] 2 3 4 5 6 ... 78
Zelda: A Link to the Past on the SNES which is 1991
Right away I could tell you that A Link to the past was beaten by it's NES predecessors. Controller 1 presses Start, followed by controller 2 pressing Up & A simultaneously, and you get to the save screen.
Correct me if I'm wrong but those don't count, even though you can save anywhere, you will not restart where you saved, but where you would restart if you lost (i.e. last checkpoint). Zelda 1 and 2 on the NES or FC always restarts at the same place in the center of their respective world maps. In addition to that, you don't restart with full health, which suck.

Romancing SaGa could save anywhere, but it's *very* easy to get stuck in an impossible to win situation. Final Fantasy Adventure could save anywhere, I'm not sure of the release date, probably 1991. You can even save during boss battles (but the boss' health will be full when reloading the save). It also have the "impossible to win" problem.

The reason why many games doesn't allow to save anywere is not due to technical limitations, but mostly because saving in a desperate situation is problematic. Having save points whre the player can reliably restart in a good state is a better strategy to avoid frustrations.

If I'm not mistaken, most GBC only games were programmed to display an error message when booting on incompatible hardware (either GB, Super GB or an emulated GB). In addition to that there was the physical impossibility to insert GBC only games in a GB because some plastic thing that prevented to insert the cart in a regular GB.

Many GBC games were designed to be GB compatible, the so called "black carts". Those that weren't weren't for a good reason, that is, they needed the extra RAM and extra graphical possibilities.

Because of the lack of any extra RAM, even if you somehow bypass the error screen, the games will imediately freeze, because there is not enough RAM. Not really interesting.

ROM Hacking Discussion / Re: Sprite Ripping to BMP?
« on: February 08, 2016, 04:04:16 pm »
I don't want to sue TileLayer pro, it takes way too long, and too many sprites.
Then you're not ready for romhacking any day soon.

Newcomer's Board / Re: Help with gbamusriper command prompt "
« on: February 05, 2016, 04:12:00 am »

Programming / Re: Algorithm for best optimizing string compression?
« on: February 04, 2016, 09:58:44 am »
It's a public wiki. Don't hesitate to write on it.
Invest time to have my changes immediately reversed because of lack of sources? No thanks.

Programming / Re: Algorithm for best optimizing string compression?
« on: February 04, 2016, 03:32:15 am »
I definitely knew it as DTE originally, when used non-recursively.

I'm surprised Wikipedia claims byte-pair/digram encoding wasn't publicly described until 1994, given how simple it is. In fact, I've personally found one obscure example that is dated 1993 (and I decompressed all of it by hand, which was rather interesting to slowly watch, given the text). I'm curious as to what the real earliest example of it in the wild is.
I don't know, but at least the US version of FF1 used this (1990). I'm pretty sure it wasn't the first, however.

I am also surprised how undeveloped the WP article is, considering this compression works so well for text. Well, it's just WP the way it is, likes developing hundreds of pages about extinct dialects which aren't spoken by nobody anymore, but they don't cover anything useful.

Programming / Re: Algorithm for best optimizing string compression?
« on: February 01, 2016, 03:53:10 am »
Yes, it can be defined using recursion. But the same result can also be gotten by using longer marks and even longer strings.
Yes, "recursive DTE" is the same as dictionary compression with the following differences:
  • Dictionary entries can reference other dictionary entries
  • The length is always 2, so the length of each word do not have to be stored

Because the dictionary can re-use itself, and because no length table has to be be used, it makes the compression typically more effective, as couter-intuitive as it may seem. (Now, there is probably cases where dictionary will be more efficient, but for the texts I tested my algorithms on, recursive DTE beat all the other algorithms).

Programming / Re: Algorithm for best optimizing string compression?
« on: January 31, 2016, 04:49:30 pm »
Well - there is absolutely no need for the compression algorithm to be fast or optimal - it runs on the host PC and there is all the power and memory of a modern PC at disposeal. The decompression code is supposed to be run on a game console, and it's where the performance are limited.

If it runs awfully slow on your PC, then I'd consider optimizing the code, but otherwise I wouldn't care as long as it works and that the code is clear to the readers.

Programming / Re: Algorithm for best optimizing string compression?
« on: January 31, 2016, 03:33:48 pm »
I haven't looked at CompressTools' source yet -- I find that having the algorithm explained is easier than trying to decipher it from source.
All CompressTool's source codes are extensively and boldly commented, and at the top of each algorithm there is a long explaination on how the algorithm work, so it's not like you'd have to reverse-engineer anything here.

Wow, what you're describing is overly complicated, much more than how I compress using recursive DTE. It is a little how I had to implement dictionary compression, which is surprisingly hard to compress optimally in finite time. I guess I do something that is not optimal, but pretty close, and it takes sometimes very long, but it is a lot faster since I rewrote CompressTools in C++. I had to cheat a bit with the code to speed things up by overwriting some hash array funcitons, so it would not look up the same hash multiple times a row.

Back on topic, 256x256 table works, because the DTE are included in the table. I do not care how long the replacement sequence is because I do not care how may times the recursion works : For me, all DTEs are byte pair, no matter if they point another DTE or not. I do not know why you say 256x257 / I do not threat the end character as a symbol or anything - when the end of a block is reached, it just doesn't count.

I only search for byte pairs, and do not take in account strings longer than that.

There is multiple passes : One for each potential DTE. So for instance if you use characters 0x00-0x7f directly and reserve 0x80-0xff for byte pairs, there will be 128 passes. This still compresses fairly fast overall, because each pass is very simple. Dictionary encoding on the other hand has many passes *and* passes are complicated, which is why it is so slow, and why I put it all at the end so the user can cancel before it completes without skipping any other algorithm.

Just in case you missed it earlier, I've been keeping backups of my saves, so let me know if there's a spot in the game you need to fix so I can be ready for it and send you a save.
Maybe if you have one I'd be interested at a save at anytime where you can easily access the Returner's hideout (if possible after the 1st time, so that I don't have to deal with the story).

Another thing I'd be interested is a save where there is the 2nd world map music (the one which is a little "depressing") when you are in the world of ruin, but before there is the 3rd world map music.

That way I can test how well the sound effects and music blends together :)

Also one last place I'd be interested to check is the begining of the phantom train (I have your save from the middle of the phantom train, but I'd like to check the begining of the scene to be sure - I don't remeber exactly, but there is another special sound effect playing there I believe).

I guess that's all. Normally everything should be fine in theory but I'd rather verify.

PS : Also if you guys are interested in bet-testing a version with no opera and only about 1/3 of the sound effects there, just ask.

Well - obviously - I just have the recording of the whole thing, not of individual parts.

I don't understand your comments. All I can do is do effects on the existing recodings (such as chaging pitch/tempo/volume). I cannot do anything else, so your comments doesn't make any sense. You guys seem to assume I was there in the studio recording the orchestra and have the ability to mix it to my liking. This of course isn't the case, I just have the CD recording and I can only edit that recording.

The only other realistic option I'd have would be to record myself singing and using the SNES synth to accompany that, but I don't think if this'd sound any good.

How does a KKK member and a giant erect penis have anything to do with Nazism?  :huh:
I of course didn't mean hacks about all 3 simultaneously, I meant hack about either of those 3 elements.

The opera's lyrics are in Japanese, not in Italian.

Vanilla FF6A is pretty much exactly what she should sound like in my opinion)
As far I know, all the original SNES FF6, the original FF6a and my hack are on the same pitch. If one of them is to low to fit Celes, then all 3 are. I don't understand your logic, it doesn't make a difference whether the voice comes from a real recording or a synth.

For some reason they changed the pitch of the Aria when doing it with the real orchestra, but my personal opinion is that the original SNES pitch is the "real" intended pitch from Uematsu, and as such should be preferred.

EDIT : Now that I listen to it again I can see what you see, the voice sounds unnatural, not only because the pitch, but probably because we can hear it was edited, as such it sounds worse than if a female singer actually sound at that pitch. Unfortunately, unless you can lend me an orchestra I can't do much about it :) I could keep a higher pitch but then it wouldn't sound the same as the SNES... so something's going to be wrong in all cases.

If you're implying that Celes's original SNES voice is too low, I disagree.
You were the one implying that. I just set the tune so it would be the same as on the SNES, and you said it was too low. I only lowered the pitch by 2 or 3 semitones I don't remember exacly, but it's not like if I made it half an octave lower than the original.

I do not agree with you Zunar, it just sounds like a Contralto to me.
It sounds like a normal alto to me.

This type of hacks about comunism/nazism/sex stopped being fun long ago.

But yes, to get back on topic... Are you using the same opera stuff from the old version, Breg? That was one thing that really bugged me, in the old restoration Celes's voice is so deep she doesn't even sound like a woman. It pretty much ruins the entire scene. >_>
Right now I'm not using anything but yes I was planning to use pretty much the same as the 1.1 version. Celes' voice was originally a different pitch, but I changed the pitch so it would end up in the same key as the SNES version. Since I needed to modify the tempo anyway for synchronization purposes, I would change the pitch as well.

If it is too low for a women, it means it is also too low for a women on the SNES, so it's not my fault.

One other question, are you planning to make the patch compatible with the U and J versions just like you did with FF5?
Yes, I am planning to, whenever possible, however the E version has the priority. If it is easily portable to the U and/or J version I'll do this, but if I encounter any major problem I'll pass.

Programming / Re: Algorithm for best optimizing string compression?
« on: January 27, 2016, 05:04:27 pm »
With DTE you have to look at frequency of pairs recursively.
Look at CompressTools' source code. It's a 256x256 entry array, which counts the frequencies. Whenever a byte pair is substitued with a single byte, the table is updated. When recursion is disabled, any pair containing a DTE already doesn't count and keep a frequency of 0, however when recursion is possible, the update is full. It's really that simple

Programming / Re: Algorithm for best optimizing string compression?
« on: January 27, 2016, 03:24:48 am »
"Recursive DTE" is complicated for variable length tokens. That is roughly the same as huffman, with huffman being able to have non fixed size characters.
No, you're completely 100% wrong. It is probably the 3rd simplest compression sheme after RLE and non-recusrive DTE, and it has absolutely nothing to do with huffman.

I forget who it was exactly, and I didn't verify his numbers, but he was someone I trusted on that site and I don't think he would have lied.
Wow I didn't know I was that much reliable ! I did this text compressing two english books, but that doesn't mean it will work best on all english text. Nevertheless it's a good indication. The simplicity of the algorithm makes it even more considering.

What is your favourite restaurant meal?
There is quite a few I could name here. I'd whether possible get anything nobody in my family can cook (or at least not well enough), so that eating out is worth it.

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