logo
 drop

Main

Community

Submissions

Help

90871854 visitors

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 ... 62
1
My tools were formerly written in Java, but I finally (phew) converted all of them to another, executable, programming language. I think it was a terrible design choice to make them in Java for multiple reasons, but back then it was the only programming I could use for modern PCs that had file I/O.

Now I am very glad I learnt to use C and the bases of C++ correctly (trust me it's no simple task, especially C++) but it's worth it as the languages are compilable. There is also other issues with Java other than the lack of compilability (yes, gcj is supposed to compile Java programs into native executable files but I never got them working).

Usage of the JVM is not easy and is confusing for novices who are already new to the command line. I can't count how many complaints I got because of this. And I have to admit that even for myself it was hard to use my own tools because of that, I had to look up how to invoke the JVM properly every time, so it annoyed me just as much as other users (I made the tools first for my own personal usage, and then I share them so that they can be useful for others too).

The syntax for Java can be horrible whenever you need something *not* to be object oriented, which turns out to be pretty often. It encourages you to write unstructured programs. And you have to use the "new" keyboard all the time. The language is based on the lack of memory management, thus on the fact that you will constantly waste memory that will be garbage collected later, which can potentially be source of inefficiency.

For all those reason I'd advice against Java for new designs :) However, I have to admit that OO is much easier to understand and apply in Java than in C++. Don't learn OO with C++, just learn another OO language and then learn how to apply it to C++.

PS : Oh, to answer your question, download my tools, and you might find an archive with the "old" java version in them. You are free to study them in any way, just don't hope to get any support for those versions, they are officially deprecated.

2
Gaming Discussion / Re: Every single RPG I ever played in my LIFE...
« on: February 22, 2015, 04:08:57 pm »
Great thread idea. I hope I won't miss too many games.

RPGs Finished entierely at least once (* means finished entierely multiple times) (many of them with no '*' I played many times but not entierely from start to begin)
  • Final Fantasy
  • Final Fantasy III
  • Final Fantasy IV
  • Final Fantasy V*
  • Final Fantasy VI
  • Final Fantasy VII*
  • Final Fantasy VIII
  • Final Fantasy IX
  • Final Fantasy X*
  • Final Fantasy X-2
  • Final Fantasy Mystic Quest*
  • Final Fantasy Tactics A2
  • Final Fantasy : Dawn of Souls (1&2 remake on GBA)
  • Atelier Iris Eternal Mana
  • Atelier Iris 2 : The azoth of destiny
  • Breath of Fire
  • Breath of Fire II
  • Chrono Trigger*
  • Dragon Quest III (GBC remake only)
  • Dragon Quest IV (DS remake only)
  • Dragon Quest V
  • Dragon Quest VIII
  • Dragon Quest IX
  • Golden Sun
  • Golden Sun the Lost Age
  • Golden Sun Drark Dawn
  • Live a Live*
  • Mega Man Battle Network
  • Mega Man Battle Network 3 White
  • Mega Man Battle Network 6 Cybeast Gregar
  • Mega Man Star Force Pesagus
  • Star Ocean
  • Suikoden
  • Suikoden II

Finished Action RPGs :
  • Tales of Phantasia
  • Terranigma
  • Final Fantasy Adventure*
  • Secret of Mana
  • Seiken Densetsu 3
  • Sword of Mana*

Finished Tacticals :
  • Onimusha Tactics
  • Fire Emblem (Rekka no Ken GBA)*
  • Fire Emblem : Sacred Stones
  • Fire Emblem Shadow Dragon
  • Tactics Ogre
  • Just Breed

Not finished because of issues :
  • Final Fantasy II : Broken battle system
  • Final Fantasy XII : Broken game overall (uninteressant story, characters)
  • Breath of Fire III : Got bored, although I could finish it someday (it definitely doesn't live up it's predecessors)
  • Romancing SaGa : No complete english translation yet
  • Lufia The Legend Returns : Dungeon system is horrible
  • Fire Emblem : Sealed Sword : Too HARD / relies on luck
  • Mega Man Battle Network 2 : I lost my saves before finishing the game :(
  • Mega Man Battle Network 4 Blue Moon : The last boss was too hard
  • Mega Man Battle Network 5 Protoman Team : The last boss was too hard
  • Mega Man Star Force 2: Zerker X Saurian : The last boss was too hard

Not finished Tacticals:
  • Disgaea 2  Cursed Memories : The last boss was too hard

3
General Discussion / Re: New wireless modem works great
« on: February 22, 2015, 12:48:28 pm »
I first though this thread was an advertisement SPAM, but then I saw you were the author and thought, oh, it's not spam...

Lately I cannot afford to buy anything else than the necessary, concretely that means mainly food, dentist fees and train abonment. But I am not less happy, on other side buying stuff you don't need is useless and takes space.

4
Front Page News / Re: Utilities: GBAMusRiper released
« on: February 21, 2015, 09:18:57 am »
I found the bug. It is at line 336 of gba_instr.cpp
To fix it, replace

Code: [Select]
if(!inst_type&0x07) continue;
by

Code: [Select]
if((inst_type & 0x07) != 0) continue;

I'll include this fix in the next release

5
Newcomer's Board / Re: Correspondence between ZST and SRM?
« on: February 20, 2015, 08:14:26 am »
Save states don't have to contain the same data. They depend a lot on the exact internal emulator design. Various timing details are sure to differ greatly.
A game could rely on the state of SRAM to run, and behave wrong or strangely if the save RAM is modified unexpectedly (this is what happens if you would load a save state without SRAM information and load SRAM with another unrelated .srm file).

In SNES case the system have more SRAM than the cartridge, so games are unlikely to use SRAM for any other use than saving, *however*, in the NES it's the exact opposite, games are unlikely to use SRAM solely for saving as it is typically larger than system's RAM.

Quote
Ugh, I learned that the hard way when me and my brother were both playing Chrono Trigger some many years ago. We were both using save states and normal save files, and the save files kept getting overwritten by our use of save states.
Same here. Although used cleverly, you can have much more saves using less files, you can use up to 10 save states which themselves contains 3 saves (in the case of CT) so you can have 30 saves at a time without dealing with copy/pasting/backuping either SRAM or save state files manually, which can in turn be very practical, for example to access any point of the story quickly.

Unforutnately save states are not always portable between different versions of the same emulator.

6
Newcomer's Board / Re: Correspondence between ZST and SRM?
« on: February 18, 2015, 08:54:24 am »
I'd also add that normally the content of the SRAM (SRM) should also be included somehow in all emus save states (sometimes, as in SNES9x' case, in compressed form).

7
Newcomer's Board / Re: Help with Megaman vii
« on: February 18, 2015, 03:29:30 am »
This is probably what you should look for. The rest of the original game is re-translated, too but I don't see how that could be bothering.

8
Programming / Re: ZSNES Changing sample 44100Hz to 43200Hz permanently
« on: February 18, 2015, 03:22:02 am »
Oh MAN this is unbleivable. When I google 43200Hz, first I find this thread, and then some other pseudo-scientific bullshit that makes absolutely no sense, like just the thing us scientists really don't like.

So first of all - Apparently the pseudo-scientific bs is about the A frequency, not about the sampling rate. Therefore, changing a sampling rate will not affect the tuning of the music.

Even if you changed the sampling rate down to 43200Hz, there is chances that your computer's sound card will internally resample it to 44100 or 48000 internally before the ADC, because those are the two widely used industry standard frequencies. Note that the sound card should resample it with proper antialiasing making this resampling unnoticeable from an user viewpoint.

Second, the SNES sampling rate is internally 32000 Hz, but it is possible when emulating it to get a higher sampling rate, which can result in clearer and crispier sound in some specific cases. (For instance, Chrono Trigger uses drums with playback rate higher than 32kHz, thus using them in such an emulator or SPC player will increase the quality as opposed to real hardware. For most games it won't make any difference). The effect will be the same when using 43200 or 44100 because those are extremely close - the harmonics are gained in both cases.

Finally, if what you want is lower slightly the pitch so that a A would be 432 Hz, this is possible to do without changing the sampling rate, and just adapt the SPC player core. However, this won't make any difference other than the pitch being 32 cents lower (which is unnoticeable to people which does not have "absolute hear", which means almost everyone including most good musicians).

Finally I must say not all games respected the A=440Hz conventions for multiple reasons, programmers were free to make it pitched like they wanted. If they wanted to have a different A, they did. (and trust me, they really did, i.e. I wouldn't surprised if half of the SNES games does not have a 440Hz A, which nobody cares since nobody notices)

Last but not least the frequency of the SPC700 is itself variable, normally it should be 32000 Hz, but according to anomie they found significant variations in different SNESes. Which means the pitch of an A could vary just as much depending on the SNES it runs on / depending on the emulator's tuning.

I remember an old version of SNES9x which played music with higher pitch, for some reason it sounded quite nice.

Quote
there is 43200 seconds in a half day
Well at least this part is true. For the rest....

Also 43200 samples per second have nothing to do with 43200 seconds... :banghead:

9
Oh I misread your "EDIT" part. Of course when you change the switching mode it changes everything like on all other mappers in existence.

10
I strongly suspect that no emulator implements the $5130 behaviour since no (commercial) games ever used this register for CHR switches. Do you test in emulator only ?

Also, why do you edit the title to say "solved" if your problem isn't solved ?

11
Contrary to (almost) all other NES mappers, CHR bank are counted as actual banks, that is, the size of the switched bank matters for the number you'll going to put. In other words, the MMC5 automatically shifts the value left when using a bank size greater than 1k (if this makes sense to you).

In your particular case, I belive you should use $24 and $25 instead of of $22 and $2a, and you'd have the same result as the below code.

12
Front Page News / Re: Utilities: Compress Tools upgraded to version 3.0
« on: February 13, 2015, 10:15:40 am »
Your input file should be encoded in UTF-8, it appears you are using another encoding (probably ISO-8859-5), so you should first somehow convert it into UTF-8 before processing.

What actually happens is that the last character, 0xc9, makes it belive it's the start of a multibyte UTF-8 sequence, and "eats" the following quote, thus reporting a missing quote.

If this bothers you, you could remove the UTF-8 decoding code in main.cpp at lines 315-330 and simply replace by the statement
Code: [Select]
c = s[i++];, that should work (although I cannot guarantee it will).

13
Newcomer's Board / Re: How do I translate a Russian Mega Drive game?
« on: February 11, 2015, 03:26:33 am »
It seems all you really need is a hex editor which supports table (TBL) files using either UTF-8 or ISO-8859-5 encoding, so that you can use cyrillic writing in your table file and see the text appear correctly in your hex editor.

Using a dummy TBL file to read nonsensical text sounds as hard as editing raw HEX in my opinion.

Also there is no such thing as "english letters" or "russian letters".

14
Gaming Discussion / Re: Final Fantasy I 3DS remake
« on: February 10, 2015, 09:12:14 am »
Quote
It's not just "a bit less grinding" on GBA/PSP, it's "it's hard NOT to be OP".
I haven't played the GBA version more than once so I can't say for sure, but it's true it was incredibly easy/dumbed down as opposed to the original, I won't disagree. Although the original is way too grindy for my taste.

It's more the lack of requirements for any kind of strategy which makes the game too easy rather than too quick level-up. In later FFs, the boss requires some strategies that makes them almost undefeatable without them, no matter what your level is.

The problem is that FF1 did came out before such ideas were implemented, therefore attack or running are about the two only strategies you can do, and they had to rely on grinding requirements to make the game feel "hard". Combined with the "Innefective" attacks, this worked well but hasn't aged well.

15
Quote
I was thinking that maybe it was a proprietary format that gets decoded in memory when the game is loaded in memory, and that the decoded version is then sent to the Playstation's sound chip.
This is impossible : The Playstation can't play uncompressed sound at all, so after decoding the proprietary format, the game would have to re-encode in VAG format, which is a complicated and lossy operation, that would take much of the playstation's CPU processing power, so it'd be an awful technical choice.

For that reason I'm pretty positive no game use other codecs than the ones natively supported by the Playstation sound chip.

Quote
In fact I couldn't properly copy them off the CD-ROM image (bin/cue pair) by using the normal Windows file copy functionality.
This is absolutely normal and has nothing to do with security, as XA uses error correction data as actual data instead, so windows think the file is corrupted and displays an error. Only dedicated tools that call low level functions to access the CD-ROM (rather than the normal file handling functions) can correctly rip Playstation XA audio/video files.

Have you tried to use PSound ? Or PSMPlay ?

This also "proves" that the file is using XA audio, as if it was using anything else, the error correction would have to work normally, and you could open the file with Windows.

Also, while we are at it, the Playstation do not care at all what is the name of the files on the CD. If the game was programmed to play sound starting from sector #x, and if the sectors contains valid sound data, then it will just play them happily, ignoring completely whether the corresponding file is called "XA", "XAS", "STR", or anything else.

I am not totally sure about this but a developer who wanted to be evil enough could even split the data in multiple files and/or merge it with unrelated files, the Playstation would ignore it entierely when playing streamed audio/video. I might be wrong on that last point, though.

16
There is only 2 formats sound on the playstation can be played : XA and native (sometimes reffered to as VAG), which is some kind of evolution of the SNES' BRR.

I doubt any game use a format other than these 2, if they do they'd have to re-encode using VAG by software because the playstation can't even play uncompressed sounds natively.
In any case if it's not XA then it should be "VAG", but if the file is called "XAS" then I think it's simply another name for "XA" and that the sound is actuallly XA.

The best way is to play it in an emulator that supports the sound debugging and see.

17
Gaming Discussion / Re: Final Fantasy I 3DS remake
« on: February 09, 2015, 03:11:59 am »
Quote
I've searched the internet but been unable to find out if it follows the original gameplay or if it's the horrible, awful, dumbed-down GBA/PSP/mobile versions that has your characters level up 2x faster than the original.
If there is anything about the "dumbed down" version of GBA etc... which is *NOT* awful, it's the fact that your characters levels up 2x faster than the original. The original is incredibly grindy and this is extremely annoying.

18
Doesn't the last boss requires both the girl and the sprite casting their magic on the boy ? I don't remember exactly but there was something like that.

19
Front Page News / Re: Utilities: Compress Tools upgraded to version 3.0
« on: February 06, 2015, 03:34:11 am »
@90s Retro Game :
This program was meant mainly to compress data, not to decompress it. Compress Tools was developed for homebrew and translators that needs to compress back their script to fit a ROM.

Although, by exchanging encode() and decode() functions you could apply decompression to some data, but once again implementing proprietary compression algorithms used in commercial games is out of the scope of the maintained part of the project : Anyone can add their own extensions that does this if they'd like to : I will not merge them back with the main project because of the potential copyright issues.

What you describe (converting JPEG graphics to NES graphics) is completely impossible and has nothing to do with what this tool aims for. No offence but it seems you have absolutely no idea what a JPEG image is and how NES graphics works internally.

20
Front Page News / Re: Utilities: GBAMusRiper released
« on: February 04, 2015, 04:46:54 am »
I have many things to do these 2 weeks but in the second part of February I'll have time to take a indepth look in it and see if there is bugs to be corrected.

I have a few other corrections planned anyway for a future 3.1 release.

Besides it is not my role to teach anyone how to use a command line (or any other part of your computer for that matter), now that the program does not require Java (phew) anymore it is easy to run like any other command-line program.

EDIT : OK I looked into the problem and it seems there is empty instrumemnts : They are here but instead of containing references to samples they are empty. This is definitely a bug and I should look into fixing it.

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