ACD games... feasible?

[Necromancer]

Anyone who buys PCE homebrew and doesn't have an AC is...an idiot, probably a mythical idiot. Don't let mythical idiots hold you back.

At the same time...if the ACD makes it easier for you to make the game you want to make (if having the extra memory helps) then by all means go ahead. It seems pretty quixotic though. That is, do you have even close to the kind of huge resources needed to fill an ACD? One of the reasons the ACD died a such a sad death was that nobody could utilize it well without losing money hand over fist. Like...not even Hudson could make it work so...good luck!

My thoughts exactly - scary, eh?  What kind of ijit would pony up $30-50 (or whatever) and yet balk at paying $20 for an Arcade Card and gaining access to its small but quality and mostly relatively cheap library?

And I don't give a hoot if going ACD just makes things easier and isn't absolutely necessary either; I've yet to see homebrew that rivals the likes of Dracula X or Xanadu (graphically speaking obviously, as I know jack shit about the underlying mechanics), but there's little reason to jump through hoops to shoehorn a bunch of goodies into a tiny little box when there's a great big box just waiting to be put to use.  Just don't do it because you can or to be the first (also applicable to multi-disc).

[nodtveidt]

When it comes to JB... we've done just about everything possible to fit it all into 256KB and we just keep coming up short every time. That's why stuff has had to be cut from the design temporarily. Masterpieces like Dracula X were made by much more experienced programmers who could really exploit the machine at the bare metal level. There's not a single programmer in the PCE scene with that level of experience, skill, and dedication all at once. That's not necessarily a bad thing though, as we simply find alternate ways to do things to accomplish the same overall end result. So if we can't make a game that can hang with Dracula X in 256KB, we'll use the ACD to make one that comes close.

[Bonknuts]

What compression schemes have you tried? Both for tilemap and tile/sprite cell data.

[nodtveidt]

None yet... wouldn't make much difference to compress stuff in JB since most sprite frames are uploaded on-the-fly. I cut some space out by loading the tile graphics from a different program, which helped, but we still have the issue of the 50KB Plantie enemy that would consume almost a quarter of the system RAM, not to mention all the other enemies and utility graphics. The tilemap is about 10KB, so if push comes to shove, we might be able to save some space there using compression. But that'd still only give us about a bank of additional space.

[sirhcman]

Sorry for the dopey question.. what is "JB"? is there a thread or link about this project?

[nodtveidt]

Jungle Bros

http://www.frozenutopia.com/projects.html

[Arkhan]

You could always cut the sprite animations down some frames to save space.    There's a reason a lot of games have only a few frames.

So, when you load everything sprite wise on the fly, what exactly do you mean?

You're using CD audio, so I am assuming you aren't loading sprites from CD as you need them like you see in some games where the background is loaded on the fly and if you remove the disc, the background ceases to exist. 

You could probably try compressing the graphics all down and only decompress/load up precisely what is needed.  Given what I've seen of Jungle Bros so far, you might be able to do that to get away with some space savings since there isn't that much crap going on all at once.   Do you have ADPCM RAM space available?  Shove stuff there if you aren't using it.


You'd just have to be really-really organized and clever/careful about how you're doing all of it.

[nodtveidt]

I think cutting down on sprite frames is the only way it'd work in regular system RAM... but then we're limiting the game's appearance, and one of lord_cack's driving points of this game is to have a lot of animation.

Since there are so many frames of sprite animation, each new frame a sprite has is loaded in realtime into VRAM with a load_vram() call. Each enemy has its own unique area in VRAM where its frames get loaded into. There's too many frames to load everything into VRAM at once and just change the sprite's pattern pointer. Of course, that means that all the sprite frames have to be kept in system RAM, which eats up space pretty quickly. The ADPCM RAM is mostly used for sound effects already so that option is out. Also, I used ADPCM RAM to VRAM transfers for some of MSR's cutscenes and the speed is atrocious.

Unfortunately, the project already is pretty well organized; I literally spent weeks ahead of the demo show making sure things could fit properly and nothing was wasted. The current scheme for sprite frames is about as efficient as it gets, I've got VRAM mapped out to the byte, and this project is why I went into pceas's code and modified it to send the proc size list to stdout... that allowed me to go into JB's code and do function shuffling until everything fit neatly with minimal space waste since pceas doesn't do this automatically, nor does it allow procs to cross bank boundaries. At this point, the only thing that would really help is to start converting finalized functions to inline assembly... but since we're already short on memory and we still have things to add, downsizing the code would just give more space to fill the void with more graphics, so we'll soon be right back where we were before... a slightly more functional game. Might not be worth it to do things that way since we have the ACD to utilize, which removes 95% of these problems.

[Arkhan]

Tons of animation frames from the get-go should have screamed "HuCard or Arcade CD", lol.


maybe see how stuff looks with some frames cut out before you make the jump to committing to a larger project and new format.

[nodtveidt]

Hucard would have been nicer, honestly. Of course, then we'd have to kick PD's butt into the realm of PSG. I honestly think that the game would fit on a hucard quite nicely when all is said and done. But regardless, it wouldn't take long to restructure it to utilize the ACD. All of the graphics data currently in the program would simply be moved to a data overlay, which would be transferred to the ACD RAM banks during the "we stole this from the Genesis" startup screen. There would be a few minor code changes in the FSMs to account for copying the data from ACD RAM instead of system RAM. The only real issue we'd run into is that it would be best to do this in one go rather than as a progressive conversion... that is to say, have ALL of the graphics and maps ready ahead of time so I can just do one big data overlay at once instead of adding to it incrementally and updating transfer points over and over again. That kind of hassle is one of the things that stalled MSR's translations. Lessons have been learned from that.

[cabbage]

I don't understand why you think compression of sprites data would not help. Couldn't you load compressed graphics data into the sys ram, thus affording you more frames in the limited space you have, and decompress them "on the fly" as they are loaded into VRAM? There would be a bit of extra processing overhead, but also there are some pretty quick algorithms to be used on pce...

[Arkhan]

My guess about that is that too many are needed at once even in that scenario.  At least that's what I assumed was meant.

[_joshuaTurbo]

I didn't read this whole thread, but would it be possible to do a complete game as just SCD, then add a few "Levels" or "Sprites" or a cutscene or something for those that venture into the ACD realm?

Sorry if this is a duplicate question, I'm just an ass that clicks on the last page......

[Arkhan]

You could fiddle around with shit like that, sure. 

[Jammaniaclord]

I would gladly pitch in if someone was stsrting a kickstarter.com budget to make an arcade card game. I have an arcade card, and have been dying to see some one make a new ACD game to utilize a format that died shortly after it was born. I say go for it!!