DSP in a HuCard & Max Storage Size of a HuCard

[spenoza]

I would certainly believe that HuC could be implicated.

[TheOldMan]

Wait, I don't see how SuperCD was a limited medium for Mysterious Song.

You also don't have an idea of how complex MSR is under the hood.

Rover's right. Let's take a simple example, and show you that it's not the graphics, nor the maps that become a problem...

Every RPG has a menu system. Yet there is no support in HuC for that. You have to build it yourself.
So, think about these questions:

How do you actually draw the menus?
    Do you use sprites or do you use background tiles?
    if You use sprites, how do you get the text in them?
      How much time will it take to set them up?
    if You use background tiles, how do you restore it when it goes away?
       How much space will that take?

    How do you handle high-lighting the current selection?
      How do you know what the curent selection is?
      How do you indicate to the main program that something has been selected?
   
   How do you store the menu text?
     How much space does that take up?

   Since the menus can be various sizes...
      Do you use a large, parameter driven routine for all text output?
      Or, do you use multiple versions of a routine for different sizes?
      How much space is it going to use?
      How fast is it going to be?

There are lots of other questions there, but I think you get the basic idea: There's a lot of code there to do
something basic to most games. HuC doesn't generate very efficient code, either. So for just the menu system
you probably have 1 bank of text (at least) and another 3-4K of code. You still have to have room for the parameters and things needed to run the menu. Don't fool yourself - the CD-Bios uses about 1/4 of the system RAM for it's own operations. HuC uses another generous portion for just the program stack. So, if you are lucky, you have maybe 2K for -all- your variables. Sad, but true.

Then, look at the bigger picture: Huc uses at least 3 banks for it's own libraries/code. Another bank is system ROM. Still another is the CD-bios. That's 5 of 8 that the cpu can reach. Now you have the graphics and the sprites - figure another 3-4 banks, for about 1/2 of the total banks available. And you still have to have room for the code...

Bottom line: Even if he uses a different overlay for each level, and comes up with a great way to load graphics and sound directly from cd, it's still going to be a tight fit.

[spenoza]

Well, every RPG has to construct a menu system and track variables. Variables are a pain on the PCE due to limited memory, but the challenges of a menu system are universal. All this points to HuC being not at all ideal for RPG coding. Sounds like HuC is the primary problem, here.

[nodtveidt]

Amazingly enough, HuC takes some of the headache out of making RPGs. I can't even begin to imagine the level of difficulty an RPG must be in assembly language... and I never want to find out either.

I don't quite get what you're saying about "track variables" though... all games require variables. All of them. There is not a single exception.

[nodtveidt]

As for menus... rarely do non-RPGs feature complex menu systems. Most other games just have basic stuff, like title screen menus or maybe some kind of basic pause menu with a few option. These are rarely complex undertakings, and you often get to skip worrying about some of the details. RPG menus, on the other hand, are quite often nested, which introduces a whole new level of complexity. And that's just one of the details that makes RPGs such a pain in the ass... nevermind a scripting system for dialogue, a sprite entity handler for things like NPCs, and let's not forget about the battle system... which can end up being a project all its own. I've actually never seen an RPG that didn't use a menu system. Zelda and its ilk are not RPGs.

[spenoza]

Yeah, menus can be a pain. When I talk about tracking variables, what I mean is that RPGs typically feature quite a bit of bookkeeping of variables, not just of the various characters stats, but when there are side quests and inventory to track and such, there's just a good bit of data to shepherd.

[TheOldMan]

I don't quite get what you're saying about "track variables" though

Not "Track Variables": Track where in memory variables are. Ie, keep "track" of where variables are.

the challenges of a menu system are universal.

Exactly. But when you only have 8K of ROM and 64K of cpu space, it's a bigger portion of the code.
Under those conditions, every byte counts.
I'm pretty impressed that all the code fits at all. RPGS tend to have a lot of special purpose code to run, and it has to be in memory most of the time because things can happen in an RPG at -any- time.

As for HuC not being ideal...You work with what you have. HuC may not be the best choice for an RPG, but it sure
beats assembly (which is the only other choice).

It's really not that HuC is a problem, either. It's the scale and scope of RPGS that are the "problem". You either have lots of loads from cd, or you fight to pack things into memory.
All programming is tradeoffs like that.

[nodtveidt]

OK I see what you're saying. Yeah, not all RPGs have to maintain massive libraries of data, though many do. It's perfectly possible to get away with miniscule amounts of data... mainly if you're doing a linear story. Sometimes, you can't avoid it though... Cosmic Fantasy 2, for example, uses 338 bytes of data (iirc) for its save file. That's pretty hefty. MSR uses under 150... much smaller.

[spenoza]

Funny you should say that. RPGs proliferated on early PCs because early PCs were not especially good with actiony kinds of games, but even with limited RAM and CPU speed, RPGs were the perfect game for the hardware. The PCE's system design seems slightly less well-suited to RPGs than the competition, but then again, the NES did have some impressive RPGs on it.

[SeymorOnion]

If you designed MSR for the Arcade Card, would you still have had issues with not having enough room for the menus, text, items & Equipment Inventory, and other variables?

[nodtveidt]

Don't forget though that many of those early games did not feature code-heavy sequences... menus consisted of simple text output and pressing hotkeys, dialogue was rarely impressive in presentation, combat systems were ridiculously simplistic, graphics were terrible (if they existed at all) but used up very little space... and many of them didn't have sound, or just had your basic PC speaker bleeps and bloops. These kinds of games would be easy to convert to the PCE.

[SeymorOnion]

I mean, would it be better to put MSR on an advanced HuCard, or would the Arcade Card/CD Format good enough?

[nodtveidt]

If you designed MSR for the Arcade Card, would you still have had issues with not having enough room for the menus, text, items & Equipment Inventory, and other variables?

If designed for the ACD, I could put 95% of the graphics into ACD RAM, which would cut down load time tremendously, possibly even eliminating the need for independent subprograms (map and battle). System RAM would still fill up, but it now would largely be with code rather than code + graphics. It would not affect variable usage whatsoever, as that's all done in scratch RAM, which is unaffected by the ACD. Cutscenes would be complete; no dropped frames whatsoever. It'd have turned out to be a better game, but would have fewer people able to play it on real hardware.

Oh... and the game itself, without the cutscenes, would fit nicely on a standard hucard. It'd be nice to put on ACD but it's already too late for that now anyway.

[SeymorOnion]

I also have plans on mass producing Arcade Cards (it'll probably be a few years before I can do it) because (and correct me if I'm wrong) Neutoipa III is being designed for it.

However, someone posted in this thread that it would be very beneficial to add additional scratch ram to a system card,
should someone make new System Cards.
Is it safe to assume that additional scratch ram on a system card (in addition to the chips found on the Arcade Card)
would make it much easier to make RPGs for the PCE/TG16?
Or can it not be used in the same way as the scratch ram on the system's mobo?

[spenoza]

What I proposed was additional scratch RAM on a HuCard paired with ROM/flash for HuCard game development, not as a new system card.

Rover, I loved those old RPGs. They were actually just as complex, if not more, than the typical, basic JRPG. JRPGs have more going on graphically, but at their core they're not necessarily any more complex as games. Maybe in code, but not as games.