Messages

1

ROM Hacking Discussion / Re: Can Nintendo now profit off romhacks shown on YouTube?

« on: May 17, 2013, 01:10:34 pm »

I agree it would indeed be jerky to pull all videos with Nintendo property in them and this is probably a better option. However, it's still not a cool thing to do either. I'm not lawyer, but some of these videos are probably fair use and weren't infringing anyway. It depends on what we're taking about. The potential is there for all kinds of videos including fan games, let's play, spoofs, ROM hacks, translations, reviews, etc. Some of them are going to infringing use and some of them aren't. It's one thing to choose to profit of infringing videos, it's another to do so on a fair use video.

2

Gaming Discussion / Re: Only 16% of gamers hate grinding ?

« on: May 17, 2013, 01:06:41 pm »

At least some RPGs are honest about it and give you an Auto Battle option to do the monkey work for you! 

3

ROM Hacking Discussion / Re: Can Nintendo now profit off romhacks shown on YouTube?

« on: May 17, 2013, 09:14:07 am »

Well, I guess this means they can no longer claim they loose money from fan use of their intellectual property if they're going to profit from it! 

Perhaps one could also take that as an endorsement from Nintendo. Could they take legal action against you if they are profiting from you? I'd imagine that might make for a different spin on things.

4

Gaming Discussion / Re: Only 16% of gamers hate grinding ?

« on: May 17, 2013, 09:11:39 am »

That was the point I was going to make. I've played a number of games that had other potentially strategic gameplay options, but none in practice were actually of better use than mashing the 'Fight' button. I would label that as poor game design.

I've played too many games where status and/or sleep type spells miss all the time and instead of helping, it just wastes a turn, wastes MP, and brings you closer to death.

Let's face it, certainly the earlier Dragon Quest games weren't the epitome of RPG gameplay. They were early attempts in this genre. While they were certainly noteworthy for their time, they are by no means balanced or smooth in the gameplay department. They are riddled with flaws. There's a reason they tweaked them for each iteration thereafter.

With that said, I understand Neil's sentiment. There are a number of games where people don't take enough time to really learn the battle system and take advantage of it's strategic offerings. I'm not sure I'd qualify early DQ games under this. I'd also suggest that it might also be a sign of poor game design if you can beat the game by mashing the Fight button even if it's has in depth gameplay and strategy. The game needs to be designed in a way to require using some strategy and massage the player in that direction.

5

Front Page News / Re: Translations: Glory of Heracles IV Script Translated

« on: May 15, 2013, 02:19:22 pm »

Really looking forward to this, and I really like the soundtrack. You've been working on this so long, so those menu's must be a serious pain.

Also, those two screens almost look like two different games, one's so softly shaded and the other looks...well, not.

Those screenshots look shaded differently because they game has full day to night cycles altering the coloring accordingly throughout the day! You can explore towns at night and during the day and things will be different. It's pretty neat.

Yeah, the menus are ultra tedious. HDMA vertical squishing for half tile spaces between lines and HDMA horizontal scrolling across two to three backgrounds for all the menu sizing and movement. Tons of HDMA tables to adjust even for the smallest change. While menus scroll off screen, they are actually all still in VRAM across the larger background layers, thus we need to be able to keep menus in VRAM that are not currently visible on screen. Couple all that with the normal run-of-the mill issues such as limited screen space on some screens and a plethora of things that need expanding and you have a serious nightmare on your hands!

6

Site Talk / Re: About ROM / ISO Information

« on: May 15, 2013, 08:49:29 am »

I am hesitant to add that for fear of an influx of even more wrong submissions (or wrong handling by staff) with usage of that field.

7

Site Talk / Re: About ROM / ISO Information

« on: May 14, 2013, 10:07:42 am »

1) Are we gonna impose strict rules on ROM/ISO information on hack submissions, like rejecting a submission with invalid ROM/ISO information?

Yes, staff members have bee enforcing this since the field was created. It's a required field in the system and you shouldn't be accepting anything in it that does not adequately identify the ROM or ISO! I didn't know that wasn't self-explanatory. Staff members were already doing this for most entries I spot checked since the field was added.

2) Does putting "No information available" not acceptable anymore?

That was never acceptable. I assume you must be referring to the system message appearing for old entries existing before the field was added. All new submissions require information in that field.

3) Should ROM name, Country, CRC32, MD5, and SHA1 be the basic ROM Info requirements?

Just as the article shows is ideal. However, we've accepted anything with at least ONE unmistakeable identification method since this is so incredibly hard for so many people to understand. Any effort made to provide anything listed there is head and heels above most and appreciated.

4) Should we accept hacks that needs to convert a ROM first before applying a patch? (like Donkey Kong: Pauline Edition) If so, which ROM/ISO Info should be written, the original or the converted? And should we require this kind of submission to have a converter xdelta patch -or the like.

Yes. Information for the ROM the patch is to be applied to goes in the field. That's the required information. It would of course be OK to also add additional lines identifying the original ROM to be converted.

5) Should the staffers fill the ROM/ISO Info field for the submitter?

As with all submissions, you can correct if you'd like, but you are not required and can reject. I actually prefer rejecting and linking to the guidelines to educate the submitter since vast amounts of people have no idea about any of this stuff nor have actually read the submission guidelines. Rejecting is a good opportunity to curb both.

8

Front Page News / Re: ROM Hacks: New Hacks Added to the Database

« on: May 13, 2013, 03:59:35 pm »

For the love of ROM hacking sir, please READ THIS ARTICLE (conveniently linked in the submission guidelines and help for the ROM / ISO Information field) and edit your entry with some information identifying the ROM the patch was intended for. This was a requirement to even submit here in the first place, which you side stepped to get past the system validation, and then a staffer failed to screen it properly (it should have been rejected). Double fail. This tragedy must be corrected and balance restored to the world!

Nobody here has any idea what ROM your patch was created for and it's your responsibility to provide that information. Failing to do so ends up with the aforementioned patching problems people are having and ultimately removal of such hacks from the site. If nobody can use it, it ends up being labeled as "junk" and removed. I'm sure you do not want that to happen to your hack.

9

General Discussion / Re: Living in Caracas, thinking of returning to the states

« on: May 10, 2013, 08:05:11 am »

Reading your post, I think you've already made your decision. From the way your wrote it, you are currently miserable, don't want to continue like this, and don't truly believe that this 'good' job in Venezuela is really going to pay off. So, why even consider staying? You don't need our help. You've already helped yourself by writing it out.

10

Programming / Re: Tales of Phantasia VWF Main Menu Issue?

« on: May 08, 2013, 09:11:47 am »

Congrats! Make sure you turn off the 'Squelch' option in Geiger's debugger. You're missing a lot of information in your traces that way including the VC (vertical counter) that I was talking about earlier.

Also under special tracing, there is a DMA option. Turn it on right before this transfers executes and step through. When DMA executes, you'll see a great little summary of it. That helps by translating into something meaningful without trying to process all those registers in your head.

I'm sure you're already aware, but in case you aren't, when you talk about VRAM addresses like $E720, that's an effective byte address. However, when setting $2116 for VRAM writes, it will be half of that because VRAM is word addressed in those registers. You'd see $7390 as you do in this transfer.

11

Site Talk / Re: PSP and Wii Valid Screenshot Resolutions

« on: May 07, 2013, 08:59:55 am »

OK. I think we will go with enforcing 480x272 for PSP.

All the talk about Wii is nice and all, but we need to start listing actual pixel resolutions to be of use in this endeavor.

It seems like Wii does either 640x480 or 720x480. However, it does anamorphic widescreen at 640x480 with an approximate resolution when stretched of 854×480, which is a common resolution for Wii screenshots around the net. I'd say perhaps the three of those would be OK. I'm not sure if any Wii games use anything but those.

12

Programming / Re: Tales of Phantasia VWF Main Menu Issue?

« on: May 06, 2013, 02:11:25 pm »

I agree with Lost Templar. It's likely your transfers are not all fully executing during vblank. You can debug one of the failed transfers. I assume you're using DMA for this. In most debuggers, you can break right before the start of the transfer (before write to $420b) and check your vertical scanline count ('VC:' in Geigers. Not sure offhand if it's the same on other debuggers) and then see what it's at when it finishes on the next instruction (CPU pauses execution during DMA).

The transfer needs to start and finish entirely during vblank. Vblank period is line 225 to 0 (rollover to next frame).

Often times NMI takes a differing amount of time to run each frame. I've been caught by this type of thing a few times where the normal game's NMI code takes much of vblank and there's little time left over for me to do anything extra at the end. Then sometimes my transfer fail while other times they complete in time.

If you find your transfers are not finishing in time, you will need to use some trickery by doing smaller transfers per frame or splitting up your existing transfers across frames. Alternatively you could do a force blank if the transfer takes place between visual screen loads.

You should be noticing a theme here on all these issues. They're simplest to debug by working backwards. You see that VRAM is not getting written sometimes. So, check those transfers to those locations next. Either the transfer is not working (due to not being during vblank), there is a bug in the code, or the source data is not as you expect. It can only be one of those few things! Break it down to simple steps and make it easy for yourself.

13

Site Talk / PSP and Wii Valid Screenshot Resolutions

« on: May 06, 2013, 09:19:55 am »

We don't have any screenshot validation in place for PSP and Wii submissions.

Is there anything for PSP other than 480x272?

Is there anything for Wii other than the Gamecube resolutions? ('720x480', '720x576')?

Help is appreciated so we can automatically stop people form submitting junky PSP/Wii screenshots.

14

Newcomer's Board / Re: Which Hex Editor ?

« on: May 03, 2013, 05:51:04 pm »

That's a tall order. I'm not sure you'll find any single free hex editor that can do all that. I don't know of any. It's likely you'll need more than one utility. hxD is my favorite fast, freeware general purpose hex editor and has done nearly everything I've needed it to do in years of ROM hacking. It's worth taking a look at, but unfortunately it will not do all that you ask.

15

Front Page News / Re: ROM Hacks: New Hacks Added to the Database

« on: May 03, 2013, 10:59:20 am »

I don't mind. Bring them to my attention and we'll get rid of them, and alert staff members to ones that shouldn't have made it through in case there were any misunderstandings.

16

General Discussion / Re: "the hand that killed your son now masturbates to the memory"

« on: May 03, 2013, 10:23:25 am »

If it makes you feel better, the little bitch got three life sentences, so he'll live out his entire adult life in prison.

That's not good enough for me. It's for people like this that I wish my state did not abolish the death penalty. He needs to die. He has no remorse for what he did, has no chance of rehabilitation, and there is absolutely no mistake that he did it. Why should taxpayers pay a lifetime of money for him again?

17

Front Page News / Re: ROM Hacks: New Hacks Added to the Database

« on: May 02, 2013, 09:03:48 am »

Yeah... pretty much my reaction. I thought that RHDN didn't host that sort of hack, but maybe I misunderstand the guidelines.

We don't. You understood correctly. That hack should never have been approved. It should be removed.

18

ROM Hacking Discussion / Re: Screenshots

« on: May 02, 2013, 08:06:34 am »

I might take a slightly different approach:

You only need the time to show seconds (or perhaps only even minutes). NMI is 60 times per second (NTSC). So you can just do something like decrement a single 8-bit variable 60 times (or a 16-bit values 3600 times for minutes). Only once every 60 or 3600 times do you need to do the actual work to update the time value in RAM. NMI should be kept as quick as possible.

Now, your time value is already in seconds or minutes and you're doing a much smaller computation for display. However, why not take the NMI increment one step farther and eliminate the need for this computation entirely? When you increment your timer value each second or minute, simply check for time rollovers and keep a separate byte for seconds, minutes, and hours. Then, it's ready for display at any time. Or, you might keep the timer in packed BCD (Binary Coded Decimal) format for ease of display.

19

ROM Hacking Discussion / Re: Screenshots

« on: May 01, 2013, 11:53:16 am »

I originally planned it to be a timer.  However, I'd actually have to implement it - the game doesn't track gameplay time.  I guess that I'd just increment some variable from the NMI handler.

Yep, pretty much. An NMI counter is the simplest way to do it. Remember to disable it when game is paused (Does Bof1 has pause?) or in any state in which it may not be desirable to count play time.

20

Gaming Discussion / Re: Exodus - A new Genesis emulator

« on: May 01, 2013, 11:49:27 am »

What that means is it has the ability to perform great for platforms that do not require much synchronization and takes a very large performance hit for those that really require it. Basically, it will speed ahead unless it detects a sync problem. When a sync problem is detected, it must rewind and repeat in a synchronous manner. This is extremely expensive if it were to happen often. If it doesn't happen often, it's great. The tradeoff is also one of scalable with cores going forward. I'd say that's probably good forward thinking at this point in time. Newer platform emulation will require much less synchronization and as always, we will eventually have enough CPU power and cores to run it adequately.

You have to understand that the the goal of the design was a generic, scalable emulation platform that won't be choked off going forward. Although I question the practicality of several areas and details as it applies to some platforms, the concept presented is sound. The author has spent many years on this. It's not like he just whipped it up yesterday. Much thought and care went into it.