logo
 drop

Main

Community

Submissions

Help

81614402 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
81
Bugzilla and Mantis are probably the most popular open source ones, but there are a number of others you can look at. I actually use a custom tracker I wrote myself because the aforementioned software was heavy and overkill. I wanted something light and more tailored to ROM hacking.

82
Congrats DD on another release! Chaos Seed is certainly an interesting title and worthy of a translation. Thanks for keeping the spirit alive!  :beer:

Speaking from experience, it's very, very easy to 1) lose track of issues that need fixing, and 2) forget that you need to do a 1.01, then when you remember that it needs to be done, find yourself unsure of what needs to be fixed. There are several items in my back catalog that need updating, but it's been so long that I've lost track of the various bugs that people find. It doesn't help that different bugs are frequently posted on different message boards. Keep a concise list of issues that are still current and that have been fixed in a place you can find, fix things as they come up regardless of how exhausted you may feel, and don't forget to release.

Absolutely. I highly recommend any hacker with large (in time or scope) project/s think about and seriously consider some type of bug tracking software. As Draken has done, I also record any bugs reported from other sources in a central tracker w/ any associated links, files, images, notes, etc so there is record and it is not forgotten. The older I get, the more I value organization and how truly beneficial it can be. :)


83
ROM Hacking Discussion / Re: Post XP ROM hacking survival guide?
« on: April 17, 2014, 06:51:43 pm »
For example for that programs that allows you to view VRAM in a ZST SNES savestate.

Why don't you just use VSNES instead? That works perfectly fine in Windows 7. ;)

84
General Discussion / Re: Gaming while married
« on: April 09, 2014, 06:08:26 pm »
As time has passed, I find myself playing games far less often than I used to. If she wanted to spend time with me, I wouldn't have any problem turning it off. She's ok with me playing, but if she said to get rid of them, I wouldn't do it.

I think this is simply getting older. The older you get, the more responsibilities and competing interests you get. Your priorities change and you realize it will take more than your lifetime to accomplish all that you'd like. So, you ultimately just end up with less and less time for certain less important things. :)

85
Gaming Discussion / Re: Septerra Core: A total ripoff?
« on: April 09, 2014, 06:08:05 pm »
Right, and furthermore, let's not forget that video games are in their infancy as far as stories go. Remember books were telling these same stories MANY years earlier. If you are an avid reader of classic literature, you've already seen the heroic journey story done many times over centuries before video games existed. You could do the same type of comparisons and conclude most video game plots simply recycled existing book plots and characters!

That is one of the inherent problems. With all of our human history, it's very hard, if not impossible to come up with something completely unique that no one could think you took/built upon the ideas of someone else that came before. I don't think it matters though. There's nothing inherently wrong with utilizing and building upon existing ideas. That's the story of human evolution after-all! :)

86
Programming / Re: Common In Games?
« on: April 09, 2014, 05:54:00 pm »
Not necessarily, maybe the ways of compression are tailored to each data type's internal structure? ;)

I thought about this, but one of the methods for example existed solely to do a mirrored back buffer copy for a few letters of the font that would have shared the same 8x8 tile if that tile were mirrored. The amount of bytes they added to the ROM for the routine exceeded the few bytes they saved. And when the whole font was treated as a stream using a single method, it still came out with a better ratio.  :laugh:

I think they tried to offer optimal solutions for as many types of data as they could up front before using it. Maybe it would have worked out if there were more data using certain methods, but there wasn't. So, most methods ended up being unjustified as they just weren't being used by enough data for the savings to eclipse the cost.

87
ROM Hacking Discussion / Re: Post XP ROM hacking survival guide?
« on: April 09, 2014, 05:44:52 pm »
However, with 64-bit systems, there is no compatibility with old 16-bit programs any longer, which can be a problem.

That doesn't change anything. I run 64-bit Windows 7. It's never been a problem for me on any of the platforms I work on. Utilities exist in every category that work fine. Really, what utilities are you using that you really need that that are 16-bit today?

Even if it WERE a problem, you can simply run a virtual machine running any OS you'd like including Windows 95 for best compatibility with your 16-bit utilities. :P Also as mentioned, DOSBox exists too.

88
Programming / Re: Common In Games?
« on: April 08, 2014, 10:18:38 pm »
It's very common for SNES era games to use multiple compression variations. I've worked on one before that had 15 different methods! Now, most were simply variations of each other and many were pretty simple, but they were distinctly different and all had their own code segments and control activations. I really have no idea how it came to be that way. It seems a bit wasteful and unnecessary. My compression ratio was better simply utilizing a single method (of which they already had) for insertion.

I've also seen the opposite where a single compression routine is used for all compressed data for the entire game. Back in that era, nothing was standard so anything goes!  :)

89
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.

90
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.

91
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.

92
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. :)

93
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.

94
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.

Quote
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.

Quote
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. :)

95
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.

96
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. :)


97
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?

98
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.

99
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.

100
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).

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