84238754 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
Site Talk / RHDN File Hosting for Submissions
« on: April 23, 2014, 08:38:44 pm »
Although there are many good reasons not to do so, we recognize the growing inconvenience for new users to come up with direct URLs for our submission system without their own web pages/hosting. Many free services used to offer such direct links, but that list has dwindled considerably and/or made it difficult and confusing (such as dropbox) to do so.

In an effort to make it easier for such guests to use our submission system, we have taken some steps to offer a service of our own to alleviate the problem. This half-step paves the way as a trial run to potentially offer uploads directly in all the submission forms at a later date. This will depend on the statistical analysis of the new service, and the impacts observed on our server.

With that said, this new service is currently up and ready for some testing. If you have submissions you'd like to make to the site, and want to upload the files to the new service and help test, please PM me. Once it is working satisfactory, the link can be posted here for all members. :)

Glad to see everything is coming together for you and you are on your way to mastering the new skills presented in this topic! The most time consuming part of doing an 8x8 VWF on menus is the management code. Having to convert existing tilemap font based menu code to now utilize VRAM tile management, new tilemaps, conversion to coordinates, RAM management, static methods etc. can be a real bear. The end results sure are nice though. :)

Site Talk / Re: Homebrew Section?
« on: April 18, 2014, 12:42:19 pm »
Since there was no further feedback, I made those changes to turn those fields into text fields. I also revised the 'Mod' bits to be 'Feature' bits. I think there's probably some value in differentiating code that features sound, addons etc. for searching.

If there is nothing else, we will go with this and can do a soft launch shortly so anybody interested can help submit and get some material in there.

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.

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

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

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

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! :)

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.

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.

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!  :)

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?

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