I think they were calling it 24bits because of the 24bit data bus to the video chip.. not adding up all the processors or busses.

Homebrew and hack mean two very different things. Homebrew is pure source code. Hacks are just alterations of existing games. Homebrew typically takes are lot more knowledge of designing something from the ground up. Hacks can be extensive, to point where it's silly that it's even a hack at all.

There's no NSF files. It's literally the original game.. it writes to what it thinks are NES audio registers.. I intercept them and convert that data into something the PCE audio chip can use. Sure, a set of samples for the PCE waveform memory to match what the NES would sound like on that channel.

Just to be clear, these "ports" are not homebrew written from the ground up. They are the original NES roms hacked to run on the PCE. They have video and audio emulation libraries that convert/simulate all the NES stuff (because the PCE is nothing like the NES.. all has to be converted realtime)

The Megaman games/hacks/ports for PCE have no slowdown. They ran runs at 4x the speed.. and the PCE is doing some emulation in the background for sound and graphics (because it's nothing like the PCE.. and has to be converted. I convert the assets in realtime).

"The PCE was definitely not known for its RPG library" The PCE library has a lot of RPGs.

"One could say the TurboGrafx was also a supercharged NES."
If you're gonna say that, then you'd have to say the same for SNES and MD; they're also supercharged NES.

I think you're not asking the most important question: Will there be an open source Castlevania engine for the PCE in which anyone can make a castlevania game?

The answer to that is: not currently, but there definitely should be!

Ehh.. it's just that I've spent a LOT of time comparing the too. so that small stuff stands out to me haha

Sure, but I think mappers being able to swap out whole banks of vram in just nanoseconds.. definitely lets you increase tiles to an absurd level. Just needs to be tied to a high res interrupt.

That Lords of Thunder pic is the SegaCD reduced color version haha.

Yeah, the 54 colors are pretty decent. Even just 3bit pixels would have made a huge difference.

Yeah, they really thought outside of the box. The small LUT they use on the 16px planar line to "shrink" sprites is also genius. It also inspired me to do some similar sprite shrinking routines on the PCE.

What are you crowd funding?

Blocks:
Red block area reserved for game logic. Blue block area reserved for critical player/enemy vram cell updates. Teal block is normal area. Cyan block area is the fire layer and dynamic tiles in which I "race the beam". All needs to finish in time before the start of the red block - next frame

pc-engine ＰＣエンジン #pcengine #ＰＣエンジン #pce Rough draft of cpu timing diagram. All 263 lines.

Magenta line starts fire layer. Yellow starts dynamic tile area. Green is game "sync" (fake) vblank. Red is real vblank & VDC SAT lock down sprites for frame - important to get updates in before this time.

I always hated Salesforce's motto "clicks over code". Especially when I was brought in as a developer to write code for Saleforce project backend when "clicks" proved not to be enough haha

pc-engine ＰＣエンジン #pcengine #ＰＣエンジン #pce Here's the fire layer sinewave distortion. I pulled the table used in HMDA routine, from the rom (thanks to Mesen for SNES debugging). You can see just the table in visual form, and then applied to the fire layer. And finally snes for compasrison.

This was something that I had spec'd out and proto'd in a rom about 15 years ago. Decided it was time to put out a polished proper playable demo - though the polish part is still going to take some time haha.

#pcengine #ＰＣエンジン #pce A sneak peek at what I'm currently working on for the PC-Engine:

In the pic shown, in the "VCE" side.. you can clearly see more "stepping" artifacts in the brightness of the colors - even some of the "grouping" into 2 and 3 of the same level brightness. This is the quantization artifact of the 5bit Y luma table. This has a strong effect on colors too.

PCE games that use saturated reds and greens are over saturated when viewed over normal 9bit RGB. To the point that some colors are nearly invisible.

There DOES exist straight RGB out of the VCE. It was never officially supported - only CVBS. Even in the last CD console in 1994.. no official RGB output. Later in the early 2000's, people found out about the RGB lines and started modding their consoles. But again, not official.

So it's basically a custom palette of 512 colors. You can still do RGB transforms in RGB space, since the 9bit RGB is an index into the conversion table. But the "VCE" output is a unique color table. Saturation is dialed back on the top end, make a few more colors usable than straight RGB.

Yes and no. The 9bit RGB value is actually an index into a table that returns Y/U/V equiv. Each component of the YUV is only 5bits.. so it's not enough to represent accurate 9bit (as 15bit YUV). 2nd part is the external mixing circuit that takes Y, B-y, R-y and adjusts B-Y, R-Y before making CVBS.

Do you have an idea of how you're going to fit in the larger English strings back into the original text space? Add an ascii system with 2 and 3 char dictionary LUT? Hopefully the game doesn't put the text blocks in ADPCM ram.

Looks like the font is using 12x12. You could do a 6x8 font that still plays nice with the original print routine which could be helpful (translate as you go). I've found that approach to be least invasive when it comes to modifying the print routine - if you don't have a lot of room to work with.

These are all auto-converted with my tool. They're not touched up by hand (which could look better). But here's an example for VGA->PCE less dither vs heavy dither:

TGCD vs VGA-PCE

TGCD vs VGA-PCE