I'm pretty sure it wasn't originally meant to be anything other than a novelty type thing (from what I've been told). I think, while additions were made for it (the lib grew, CD support, syscard lib extensions, etc) - it was never intended to be taken seriously.
Yes. That's exactly the case, even if I wasn't able to properly express it earlier.
Although nobody is likely to believe it, it was only ever intended to be a proof-of-concept and a potential fast-prototyping platform.
I had always expressed, as Bonknuts notes, that the platform doesn't have too many spare cycles to be throwing away by doing 16-bit macro math on loop iterators, so it was never targeted at full-scale game writing.
In a way, it was actually intended to show how to write something in assembler on the PCE; a lot of assembly coding is knowing how to hit the hardware, and HuC does all the basic register setup - and tries to deal with a fair bit of variation (ie. resolution sizes, etc.). The libraries were intended to read by other programmers; that's why they are so heavily commented. (Anybody who has ever read somebody else's code in a professional capacity would see that the libraries are heavily-commented. Not the compiler itself, though. That was only modified in specific sections, and i never understood large parts of it.)
Other goals for the compiler were to use it as a platform to explore the concepts necessary for writing larger games on the PC Engine - that is to say:
- how to make use of banks (pin one code bank in memory, and use it as a pivot to bank another code bank in and out; store data in prescribed bank locations, etc.)
- *testing* CDROM card function accesses and other hardware features -> HuC was actually used as the test platform for determining how to use most CDROM card functions and other hardware accesses, as most of the functionality had never been discovered/used by hobbyists before. Then standard HuC functions were written around them.
- writing standard everyday functions like joypad poll, BRAM access, etc. which would be used in every game, so they wouldn't need to be rewritten a million times. I'm pretty sure it reads mouse position too, if I remember correctly.
- implementing overlays as a way of writing a game larger than memory. This was more of a technology test/proof-of-concept, and probably the last thing I did before I had to give up and go back to 15-hour workdays (in my business, it's usually too much work, or too little - no middle ground).
My own "ultimate" goal was to use it to prototype a game; I had no confidence that a game would even be possible at the performance levels HuC afforded, but HuC generated assembler code which would work, and which could be modified and optimized after the fact. My goal was to rough something in, see how it runs, then optimize as much as necessary in assembler for performance(I assumed that entire sections of the game would need it, but potentially only critical sections might).
So it begs the question, why then even bother with HuC if you can handle assembly just fine? There really isn't a good answer to that.
See above - quick prototypes, and roughing in a concept, to be optimized by hand. Much faster than writing from scratch.
I even had ideas at one point of automatically removing library code which wasn't required, for space reasons. Never got around to it though.
Anyway, I don't think documentation is the problem/reason why the console doesn't have more devs for it. There's plenty of documentation for it. Sure, it might not all be in one place - but it's out there. Actually, not really much different than SMS, NES, SNES, or the Genesis scene. People that know how to code for these type of old consoles, WILL find that documentation. They'll figure it out. I did.
I couldn't agree more.
That doesn't mean I don't sympathize with the fact that it is a struggle.
