Resident Evil: Behind the Mask [+Hazardous Battle]

[Gemini]

The engine is already capable of using automatic triggers, but I'm definitively going back to "press confirm button, description appears". In Gun Survivor it kinda makes sense to have triggers activate when you step on them because of the first person camera, yet with a classic style there isn't a single good reason to do that (I bet most people would get stuff to incidentally activate and go WTF or step back-forward in order to reread messages). I reverted message style to work with a horizontal scrolling effect (visual example here if my explanation isn't clear enough), another aspect where GS failed miserably due to rushed development or programmers simply not caring.

[Ultimacloud123]

Looking forward to your next updates.

[RaccoonSurvivor]

I know that obviously that description is just for a test/joke - but I noticed the english and grammer is off. Am I right in thinking English isn't your first language.

What you put - "What a lovely door. Wait... is it just me or that knob is shaped like a butt?

How it should read - "What a lovely door. Wait.. is it just me, or is that knob shaped like a butt?

I take it you guys have somebody helping you in this department??

[Gemini]

^ I know that sentence sounds awkward, but I do have editor friends to check on my text if needed. Still, I won't be the one to write the English scenario and some parts of it will simply be lifted from GS with a few edits, or entirely retranslated by a native English speaker. I will be writing the Italian scenario and check on the English script for consistency. I won't allow crap like "El Mona" instead of "Ellemona".

Meanwhile:

The text sub-engine should be pretty much done, unless I forgot something in the way; it probably needs a few tweaks here and there, like automatic centering and line wrappers, if those are going to be required at some point. All the stage sub-engine needs now is a nice block of code to manage door transitions, which I already wrote like last month, but it's still nothing more than a quick draft with a few drawing functions copy-pasted into it.

In other news, SonicBlue is working on the restaurant section. It's still lacks most materials and effects, but the geometry is in place and looks good already. Maybe you'll get a screenshot. Or maybe not - working with this heat is quite the distraction.

[RaccoonSurvivor]

^ It wasn't meant to sound as bad as it probably read - so sorry bout that.
Awesome - working keys..

Who can forget that scene where the zombies break through the window in the restaurant hehe ..

[Ultimacloud123]

Gemini and Sonic, excellent work. Thanks for the updates! This helps take some of my 1.5 anxiety off my shoulders. May I suggest only showing 1-2 angles per area. I want to play BTM like it's a whole new game just like REmake. I still want to work on doing the rearrangements for your music however I just got to get over the intimidation of the learning curve for the .psfs.

[Jimmy_Jazz]

Yeah, thanks for the updates, thr project is looking awesome

I do have another Q. You've said that you've got better compression for each background that the RE engine and that you're also including door screens between rooms. Will those door screens be as long as those in RE or shorter? And if they're kept as long as the RE titles (2 & 3 are definitely faster than 1), will you be able to skip them?

[Gemini]

I'll give players the possibility of skipping them partially or entirely, since compression halves the CD unit workload. There's really no good reason to have a delay of like 2-3 additional seconds while the engine is simply idling.

In other news, Kingcom and I are working on a way to create PSP-style relocatable chunks of code to avoid redundancy and allow more procedures to be handled easily (example: virtually unlimited enemy slots that can stack on top of each other). This should remove the thousand function jump tables I have for literally everything not residing in the main exe.

[EDIT] I finally took some time to make a bunch real hardware tests. Result of said tests (click on a picture to see the original):

Other than a minor bug with a register bit messing up everything accessing to the GTE, the engine is completely compatible with real hardware. The bug has been fixed last night after hours of hard work, with me trying to figure out what the hell it could remotely be. Turns out it was the SR register messing up with the GTE Enable Flag, which was available only in the main loop and completely forbidden in code executing as a scheduler task. :S Fortunately the solution was far simpler than locating the bug itself, but with no emulator even notifying the error, finding the cause took me way longer than it should really have.
A side note on this hardware test: lossy backgrounds don't look much different than lossless, tho the latter takes quite a while to load because of the multiple data fetches and software decompression; this means I'll more than likely disable lossless on real hardware and allow it just on emulators, since they tend to mess with quality when BS frames are decoded in 15 bit mode, but can load much faster in exchange.

[Northman]

[EDIT] I finally took some time to make a bunch real hardware tests. Result of said tests (click on a picture to see the original):

Oh man, this reminds me: Will you release native versions for both PAL and NTSC?

[Gemini]

Intriguing question, with multiple scenarios.

Let's say I implement some kind of in game selector for video mode: I'd have to account for all issues related to synchrony and speed. The most obvious would be objects moving at a different speed, which I could either ignore and have them to move 1/6th slower, or I could make so that animations are recreated in a way that interpolates motions and keeps a similar smoothness (you'd barely notice the difference). Unfortunately the second case [resample] means I need either need a dynamic way to keep track of several hard-coded counters, or make the code branch a lot depending on the current video mode. Another problem is other stuff such as streamed audio and video sequences moving at a different speed, which back in the day was handled by resampling everything (i.e. you need two copies of everything, one for PAL and the other for NTSC; not nice on the same disk), or I could ignore it all and easily fall into a never-ending gray area of bugs or goofy things happening.

Keeping in mind the issues from the previous case, I could always create separate builds for either version (i.e. no video mode selector), which would be definitively more doable, but still a lot of work and way too many headaches because everything would require double the planning and loads more tests.

Now, let's say I simply ignore that PAL ever existed. What would be the advantages of an NTSC-only release? No extra work whatsoever and in general no actual changes for the end user, at least nowadays. IIRC even the PSX emulator on PS3 (at least on modded consoles) forces games to work in NTSC mode, which means all efforts on a specific PAL build would make it look sped up on forced NTSC.

The only real advantage of PAL should be old TVs displaying colors a little better and the screen can display more horizontal scanlines, but if you play it emulated on any recent consoles (PSP, PSVita, PS3, PlaystationTv, etc.) or on PC, there is no visual change whatsoever. Additionally, native PSP and PC versions wouldn't need to rely on all that video mode mess because video synchrony works differently, so the extra labor would end up "wasted" on just one version.

All these things considered my final decision is: I'm keeping NTSC, for now at least. There are way too many aspects what would only make development longer than it should really be.

[Guest]

Good work on the hardware tests! Glad to see it up and running. As for video mode, most people probably aren't going to play the game on a Playstation with a CRT TV (well, I will lol), but even those that do likely already own a Playstation, RGB scart cable and compatible TV. It would be a very small group of people in PAL regions who would have a problem with this, for too few for you to worry about catering to them at this stage of development, especially as like you say modern consoles (PSP, PS3, etc) are capable of running the game correctly.

[Northman]

Well okay. PAL region here, so it's definitely emulation for me. You mention that PAL would need resampling of video and audio. Any full motion videos forthcoming? Also, is it safe to assume that there will be no artificial region locks, pardon me for sounding stupid. Are region locks in general a mandatory part of the Playstation's standards?

[Guest]

Well okay. PAL region here, so it's definitely emulation for me. You mention that PAL would need resampling of video and audio. Any full motion videos forthcoming? Also, is it safe to assume that there will be no artificial region locks, pardon me for sounding stupid. Are region locks in general a mandatory part of the Playstation's standards?

Not really, but I'm sure Gemini will be able to give you a more technical answer, games of any region can be booted fine using swap discs or mod chips, and such systems are easily available. Only requirement is an RGB scart cable to play the game in colour.

[Zombie_X]

SCART is the way to go with any retro system. I use SCART and a XRGB-Mini on my TV and it looks glorious.

[Drake]

Gemini, how will you handle the alligator bosses? If I remember right, survivor had two of them. Exploding barrels like 2 or simple bullets?