PAL/NTSC Distinction

[andwhyisit]

Would it be worth using "JU" (or simply "U") as the region in the header (src/boot/rom_head.c) for ntsc and "E" as the region for pal rather than "JUE" for both? It seems that Gens looks at the region info to determine whether it should be using pal or ntsc.

[andwn]

I'll throw in an #ifdef for it

[sikthehedgehog]

Wait, isn't it the same ROM for both NTSC and PAL? I thought it did autodetection. In that case having JUE in the header is definitely correct.

[andwn]

The game would be way too slow on PAL if they were the same ROM.

[sikthehedgehog]

Project MD checks the video signal and changes values accordingly, so not exactly impossible.

But weird, I thought it was just a single ROM (since I only ever see one). I guess that if they're different ROMs then yeah the header should reflect this.

[andwn]

I've only ever put the NTSC one in releases since I never tested PAL (nor could get emulators to treat it as PAL... but guess I know why now).

The reason is I know no fast way to change the speed based on framerate, and instead have these TIME() and SPEED() macros to let the compiler take care of it.

[andwhyisit]

I finally compiled the PAL version for the first time. The most notable issues is that the music is really slow and the pal 320x240 resolution isn't being applied (unless that is just the emulator being weird).

Oh.. and this: http://andwhyisit.bugsiteguardian.com/csmd/missingsomebgthosetileswilldo_zpska2bb7cy.gif

Oh, and hey, I set up a PAL nightly: http://www.cavestory.org/md/nightlypal.zip

[andwn]

I forgot I removed the switch to 240 but kept the SCREEN_HEIGHT sizes as 240. I'll add it back in. A lot of random stuff will likely break especially the window so be aware.

I'm almost certain the music should not slow down... the sound driver has ways to handle the difference maybe I just have to explicitly tell it to do so.

Also, since you are getting your hands dirty with the build process again do you think you could update SGDK on the build server? There are some issues that still happen in nightly I have not been able to reproduce locally (#65, #67, #76).

The commands from the gendev dir are (yep this guy makes you do everything elevated sorry): sudo make sgdk_clean sudo make sgdk_build

If the build fails the old one should still work.

[andwhyisit]

I've rebuilt gendev in its entirety. Hopefully that should be sufficient.

In any case I re-tested the pal version and it looks like nothing of substance was broken besides what I already noted. There is one issue which I kinda expected, and that was the background being too short:

Other than that the message boxes and inventory screen need to be offset 8px down. This looks to be the case for the all UI elements really. Small maps (such as the opening scene with Kazuma) need to vertically centre properly.

Oh, a last minute issue I noticed: Entity sprites are unloaded early in those bottom 16 pixels: http://andwhyisit.bugsiteguardian.com/csmd/palentities_zpsezusdcse.gif

I haven't noticed anything beyond that.

[sikthehedgehog]

In other words, the game just keeps acting like it's still 224px at everything.

EDIT: btw, with objects it may be better to just have the object manager act like it's 240px all the time (this is what the Game Gear Sonic games do actually... they just act like it's a Master System with different camera position limits). Everything else is probably just a matter of adding an offset or something like that.

[andwn]

My idea is to use SCREEN_HEIGHT as much as possible instead of the hard coded 224 based values I have now. The window and menu don't do a good job of this, and apparently the map scrolling and sprite clipping don't either.

The Moon and Fog backgrounds should be an easy fix. I'll just duplicate the first and last rows.

The room with Kazuma is also forced to be pushed down because the message box would cover everything in NTSC. Can just... ifndef it.

[sikthehedgehog]

Yeah most UI is easy, just do SCREN_HEIGHT-blah for things at the bottom, and SCREEN_HEIGHT/2-blah for things at the center. Or similar, you get the idea.

The textbox is the only big hazard here. First you need to lower the boundary for textboxes at the bottom (register $92xx), that part is easy. But then you need to make sure everything is shifted down by two rows too (because everything in window plane is relative to the top left of the screen). So plan this one ahead of time.

Textboxes at the top are a non-issue and shouldn't change in PAL. Same with UI elements placed at the top of the screen.

[andwhyisit]

The textbox isn't a hazard at all (or at least not in the way you were suggesting).

Effectively you just need to move all UI elements (inventory, healthbar, y/n prompt, exp, weapons, map, item preview, exp, ammo, facepics, message box), down 8 pixels from where they are now when in pal mode. It's fine if everything is measured from the top because most of everything is 8px away from where it needs to be.

As far as the NTSC version is concerned 8px of air was removed above and below all UI elements when compared to the original, and that has been pretty consistent. So just add that air back in for the PAL version and everything should work fine.

[sikthehedgehog]

I meant the textbox is a hazard in that it's extremely easy to forget that everything rendered on it needs to be explicitly adjusted (as opposed to just adjusting the boundary). This goes for anything rendering in the window plane, really (I think the inventory is window, too?).

So more hazard in the "you need to touch a lot more stuff than you think" sense.

[andwhyisit]

That's no less than for the inventory or healthbar though, which are also made up of numerous component parts.

[andwn]

The HUD is just 2 sprites directly next to each other I can push down. I think I have fixed most of the obvious PAL problems (commit incoming) except those involving the window plane, but I'll worry about that after making another release.