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

Pages: 1 2 3 4 [5] 6 7 8 9 10 ... 77
ROM Hacking Discussion / Re: Post XP ROM hacking survival guide?
« on: April 08, 2014, 10:15:15 pm »
For the platforms I work on at least (8/16-bit/GBA), I don't have any problems using Windows 7. Utilities are available in every category that I need to work.

ROM Hacking Discussion / Re: [SNES] I need to detect the host emulator
« on: April 08, 2014, 10:12:31 pm »
On the topic of detecting emulators for whatever purpose, you'd want to attack something that requires the utmost accuracy. In the past many people used reading the multiplication/division registers before they were ready. Many emulators still aren't perfectly correct there. Other ideas used involved precise h/v counter capturing, proper memory map mirroring etc. Then, there there is the differences in initialization. Even BSNES does not match all the intricacies of the hardware. You do have to be careful not to use a variations that actually differ from real SNES to real SNES.

However, I think the point to detecting an emulator though would be to ensure it meets the accuracy level you need. So, you only need to test for the least common denominator that you require to run your software correctly.

Gaming Discussion / Re: Septerra Core: A total ripoff?
« on: April 08, 2014, 10:07:14 pm »
Septerra Core was a western made Japanese style RPG. I'm sure it paid homage to some of the developers favorites and took a few ideas. If I recall the developers said as such at one time (no source on that). The active time battle system was probably the biggest thing taken. However, I don't think there is nearly as much 'ripoff' as you seem to think. There are some loose similarities in characters in my opinion and that's about it. No more so than found in any other similar RPGs. The plots are as different as any other two similar RPGs. There was no time travel and other than shell worlds, didn't have much to do with Bahamut Lagoon.

You seem to be picking on this game in-particular when when you could probably take most similar RPGs, analyze them, and come to some sort of conclusion that game X ripped off game Y.  JWe wouldn't have the term 'Dragon Quest Clone' if they didn't. Perhaps some ideas were used simply because they were good ideas and they work.

Except in this case, it was a western developed RPG purposely trying to capture the best of JRPGs which is more justification than most cases.

General Discussion / Re: Gaming while married
« on: April 08, 2014, 09:06:45 pm »
Of course it is possible. If it is not, unfortunately, you have married the wrong person. :P

You're never going to enjoy every single one of the activities your spouse does or vice versa. That doesn't mean you must give them up. In any healthy marriage there should be time for him/her to do their thing and for you to do yours. In addition, often times each may partake in something they don't like for awhile in order to spend time with and out of respect for the other. You also grow each others interest. Maybe your spouse will never enjoy a particular type of game, but there are many types of games. After enough exposure it's likely you will find some middle ground that the two of you may enjoy for awhile.

I am currently married and have years of relationship experience. I also happen to know a number of girls whom will play video games. They are out there. :)

ROM Hacking Discussion / Re: Windhex columns not big enough?
« on: April 05, 2014, 01:00:33 pm »
Yes, the problem is being caused by the program not being DPI aware at all. I brought this to Bongo's attention years ago... I think you're stuck with it.

General Discussion / Re: MIDI player for the SPC, any interest ?
« on: March 28, 2014, 06:17:46 pm »
The point to mentioning vblank was not register access, but the fact that you're likely not going to be sending MIDI messages during this time, which is relevant if you're needing to stream each individual message in a time critical manner. HDMA isn't going to help as it has no logic. You're only going to be able to send 4 bytes max (one per port). You're not just going to blindly send every X scanlines or frames are you? There are a number of big problems with that. ToP is not constantly trying to stream individual midi messages as you prescribed. It's chunking samples out periodically in a controlled fashion.

The DSP registers implement a lot of MIDI's functionality (such as key-on/key-off) out of the box to begin with.
Not really. Key-off on the SNES is not the transition to decay as you expect to get out of a key-off midi event... That's just it, you will see there is actually a great deal of processing to be done to translate each event, and properly manage your voices, channels, polyphony, and features.

the SPC doesn't need to block.  it can run in a timer driven loop which at some point scans the port registers for a new event and buffers it when one is present (a suitably-sized ring buffer ought to work here) otherwise it cycles the loop and continues other processing (ie: processing of already buffered events, echo, reverb, pitch or amplitude modulation, etc.).
Good luck with that. I think you will have difficulty expecting the SPC timer and fetch code to correlate precisely enough with any fixed HDMA transfers. There could be many MIDI events that happen simultaneously such as simply two chords at once. And you're going to need to stream each one individually close enough together not to sound funny, and get it all processed before the tick time of the next event. Based on my experiences, I certainly wouldn't do it as such if you want it to be of any use beyond just a standalone MIDI player.

Regardless, I'm sure everyone would be interested in how things go for you during your development. :)

General Discussion / Re: MIDI player for the SPC, any interest ?
« on: March 27, 2014, 07:49:56 pm »
I don't think keeping the main CPU saddled all of the time streaming time sensitive midi events makes much sense when it comes to an actual game application, especially on the SNES. You can often be very busy during the entire vblank time down to the last cycle and need most of your general processing time in many instances. You're going to end up loosing cycles on one side or the other for constant blocking/handshaking, and always need to service your sound no matter what it is you're doing in-game. It certainly depends on how complicated the game is, but it's really impractical to expect to be streaming sound data all of the time like that.

It would be much smarter to simply double buffer a large amount that only needs to be swapped out periodically. Now all you've got to do is make sure you swap a new page in before the SPC has exhausted the entire thing, which is much less frequent and can be done at will when convenient on the CPU side.

Secondly, on the SPC side, the amount of work you have to do for each midi event on the DSP can be extraneous (if you want to support many features). It can be cutting it close to complete before the ticks for the next event (especially if simultaneous ones). I've done it and my earlier passes sometimes missed my time windows and events were playing late until I made some smarter optimizations. I wouldn't want to also have additional blocking waiting for the CPU during this critical time.

Programming / Re: Tales of Phantasia (Battle Screen)
« on: March 26, 2014, 06:56:56 pm »
Why not just disable BG3 via $212c? Or, if it's really just temporary, toggle the BG off in an emulator. :P

Well, you'd need to move BG3 further down in VRAM if you need to now use that B800 space for the enlarged 64x64 tilemaps on BG1+2. You'd need to set the new bases appropriately in the BG registers and then since you will break everything on BG3, make sure all the BG3 data now goes to the new locations. :)

I actually found my old work last year and was going to release it but the HDD I had the project on died shortly after I discovered it and I haven't found a back-up.

Hmmm... Another infamous DeJap hard drive debacle? :laugh:

Nice to see you again DarkForce! It's good to know you haven't been hit by a bus. :P You're never too old to satisfy that ROM hacking itch, you know. What are you up to these days?

Newcomer's Board / Re: Is it fine to hack translations?
« on: March 23, 2014, 01:25:00 pm »
Well... after a tiny research, I've found out that he's left a wabsite and his e-mail around, but his website is currently dead (it was bought by a japanese company or something) and all of his translations are dated as of 2003. Maybe I should try to send him an e-mail, but... I don't think he'll answer.... something tells me he's not active anymore. :-\

Even so, take a minute write an e-mail and be done with it rather than speculate. ;)

So if someone hacks a translation hack, which category will it be submitted? Under Hacks or Translations? And would it be an Addendum or an Improvement? We don't want to add/delete files like what happened to mziab's hacks just to correct the categories.  :(

Since it's not furthering, fixing, or enhancing the translation, then it would probably end up being in the Hacks section. I think there has been a case or two like this in the past, although I can't recall the names.

Site Talk / Re: Homebrew Section?
« on: March 23, 2014, 01:02:35 pm »
Oh, OK. I agree there. I assumed what would be written in that field would reflect the included license. We can make that more explicit in the field help and/or guidelines.

Site Talk / Re: Homebrew Section?
« on: March 22, 2014, 12:12:08 pm »
Yes, I think it makes sense then to have the Source Code Language a text only field.

Doing a write-in for Source Utility is an interesting thought, but without including a full form, we'd end up with a similar situation to the Game write-in's where it would be a bare bones entry that someone would need to edit to fill in the rest of the information all the time. A utility entry without a description and other info is certainly undesirable and what result if nobody went back and filled it in after approval. This is a problem in general with the write-in's on the site. Including the full Utility form doesn't seem like a smart idea either.

snarfblam, you want to see the full license text in the entry? The GPL and LGPL text for example are very long. I'd hate to store a bunch of redundant text copies of that and it would still be a copy of the text which would also be found in the readme or distribution. I think that would eat up quite a bit of database space for no good reason. Perhaps if the license text was only included in the case of a custom license it might make sense (this assumes the 'custom' license is just a few lines and not say a modified GPL or something).

Newcomer's Board / Re: Is it fine to hack translations?
« on: March 22, 2014, 11:54:15 am »
Although you don't need permission, it's common courtesy and good community ethics to ask/inform the author of your intentions if they provide contact information and are able to be reached. Many authors enjoy hearing where their projects may be used. Some authors may even be willing to provide you some helpful information or resources regarding the original project to make your job easier or aid if you get stuck. It's much less likely they would want anything to do with helping you if you did not extend them any courtesy. Also, wouldn't you want someone else to do the same if they wanted to use your hack?

As you know, you should certainly give proper credit in the readme, credit lists, public descriptions, or even applicable in-game splash/title screens. I think everyone will agree claiming anything as your own that is not is a cardinal grievance in any walk of life.

How would I fix that there, I can't seem to edit the post. Oops sorry about that, should have checked over it before posting.

Go to the News section and submit and edit for your News Article.

Site Talk / Re: Homebrew Section?
« on: March 19, 2014, 07:55:41 pm »
Rejoice! :) The Homebrew section is almost here! I went through this topic and came up with a rough draft of the form, guidelines, and subpage. The preview button will work, but the submission button will not. Submissions will not be allowed until all the fields and what not are finalized and properly hooked up to the queue.


Most ideas were incorporated, but I am still not sold on several of them and wish to discuss them further.

1. Source Code Language
I don't think we want to get involved in keeping/maintaining a table of programming languages. We might want to axe this field. Perhaps for homebrew, we may only be talking about Assembly, C, and C++ and need no more. I don't personally know of any written in anything else. However, I am also giving consideration that this field may be ported to other sections like Utilities which would use any language conceivable and require maintenance.

2. Source Utility:
This was done as Neil suggested linking to our Utilities 'Assembly Tools' category. If we go with this field, we may want to rename that category so it is clear to accept C/C++ compilers (or have a separate compilers category and link both to the drop down here). My issue with this field as mentioned earlier in the topic is version mismatches. Say homebrew X assembles only with older assembler version Y and not the current version Z carried by our site. Secondly, I expect lazy people will, rather than submitting the tool they used when not found to our database, simply chose 'None'. Then, we'll have a bunch of 'Nones' and the field isn't all that useful.

3.Source License
Here's another field we may choose to axe. I don't think we want to get involved with maintaining a list of available software licenses (and there are always custom ones) for a proper dropdown. So, we're left with a write-in field. Write-ins are only partially useful as it becomes just a text tag and not easily searchable for any other purpose. Also, as mentioned, the majority of content on this site has no license whatsoever. So, I certainly question how useful this is as-is? I also shudder with the educational consequences of people having no clue what a license is.

While I understand the general idea behind this one from what Neil suggested, I'm not sure how useful it is in its current iteration. What do you guys think about this? I'm not sure I understand the choices well. Everything would be 'processor' wouldn't it? Nearly everything with any screen output would also be 'Graphics' by default. I'm not sure how useful those would be for starters.

My initial thoughts were homebrew basically fits into three categories and I have tried to provide explanation of the difference between the three. Although, a case could be made that Tech Demos and Hardware Tests are basically the same. My thoughts were mainly to separate them due to the potential for archiving emulator accuracy test type ROMs. Perhaps they should be ruled out of scope here, but I don't think accuracy test ROMs are actually centrally archived anywhere else and thought maybe we should do so. Thoughts on the categories?

Lastly on all the source code fields, I am also giving consideration that these fields may be ported to other sections like Utilities. So, if we want to keep them, consideration should be made on their usefulness and application to other areas of the site.

Programming / Re: Need some 65816 assistance
« on: March 13, 2014, 06:34:45 pm »
LDA (BF 00 D8 2A) is "LDA $2AD800,x". Is that what you want? For this to work as you instruct, you need to also relocate the data. Is your data now also in bank $2a? You were loading data from bank $0a, now it needs to be in bank $2a to work with the instructions you've given. Otherwise, you want to use LDA (BF 00 D8 0A) which is is "LDA $0AD800,x". That would pull the data from the old location while your routine resides in the new bank.

You can't use the ADC instruction in the manner you expect.  ADC (69 00 D8) is immediate. #$D800 means you're adding the immediate value $D800 to the accumulator. ADC (6F 00 D8 2A) is addressed, so it's actually ADC $2AD800 which means add the value STORED at location $2AD800, which of course is not what you want. If all you did was change the bank, you shouldn't need to change that ADC instruction.

I highly advise stepping through with the debugger to see what is actually happening and where data is being pulled from. This will help you learn better what is going on and what is going wrong.

ROM Hacking Discussion / Re: SA-1 register $2225?
« on: March 08, 2014, 04:03:44 pm »
If I understand correctly then the SA-1 can see the entire  BW-RAM (mapping both 40-4F/60-6F spaces) but the SNES only sees half (the 40-4F portion)?

Right on that. I think your general understanding of the points you mentioned are also correct.

Certainly the SA-1 has great potential to hombrew if it could be fully leveraged. As you know, there is a pretty big learning curve to really being able to take advantage of this setup. It's of little surprise that most commercial games utilizing the SA-1 didn't even take full potential of it either. It's probably the most advanced and versatile of all of the add-on chips.

Site Talk / Re: mteam's Translation Fixes
« on: March 07, 2014, 08:46:28 pm »
Absolutely. Different sources can generate different hashes for the same functional ROM depending on whether or not they included header information in the hash. Most people provide the hash from a given known database like NoIntro etc. and specify the source of the hash. This avoids any confusion and will be applicable to most older translations.

In other cases where a straight file hash is appropriate because no ROM database options exists, it is recommended to provide the file hash with no header (strip it entirely off) and note the hash was calculated as such. Regardless, the source of the hash is critical for others to come up with a match.

I don't believe zeroing out the header bytes is the same as stripping them off entirely for hash calculations. I think those algorithms differentiate between that that. A quick test seemed to generate different hashes with CRC32 for example. Can someone confirm?

That looks great to me! Nobody makes 'em like you do. :)

Front Page News / Re: ROM Hacks: New Hacks Added to the Database
« on: March 07, 2014, 06:45:49 pm »
Right. It's unplayable. Both snarfblam and mrrichard999 confirmed and it was flagged as non-compliant. One of these days we'll have a publicly available listing of all the flagged non-compliant material and reasons given to avoid confusion and attempts to re-add. Such information is being kept in the submission logs like the rest of the submissions. :)

EDIT: I should note this information IS already publicly available for the past 30 days in the change log (By clicking on Changes on the top bar site menu).

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