What were the life time sales for the PCE/PCEDuo

[A Black Falcon]

Stupid in the way of he's not realizing that you're making fun of him all the time?

Idiots who can think of nothing better to do than throw insults around should be ignored, not responded to.

Since no one can define what the hell the Laseractive is, let's try another oddball.

WTF is a Turbo Express?  Is it its own system?  The games are the same as the TG16, but there is no TV out, where can you plug inanother controller, etc.  It isnt a console, what is it?

The Nomad is another one.  Is this the Genesis 4?  Or is it its own console?

I wouldn't consider those two their own consoles, myself; they are handheld models of those consoles, that's all.  Handhelds are just consoles with a built-in monitor, so I'd just consider these another model of the system.  I sometimes do separate handheld (consoles) from (tv) consoles, but both are video game systems, and I don't think that just switching the format from one category to the other makes it an entirely new system, as long as it plays the same games.

You can also apply this to TV versions of handhelds, such as the Super Game Boy, Game Boy Player, or Playstation (Vita) TV.

[ClodBuster]

Hi Falcon, no harm intended. I'd even go as far to say that I share a good chunk of your opinions in the initial discussion, but after crawling through so many pages with the same arguments over and over and over again, I'm pretty much bored. Plus, I can't understand how you are apparently not realizing that there's no need to repeat yourself, which makes it possible to get ridiculous posts out of you. Stand to your opinion like everybody else does, and don't give a f*ck if somebody disagrees. 'Cause there'll always be people who are not likeminded, and that's OK.

[Bardoly]

Disclaimer:  I have not read up enough on video game console hardware to call myself an expert by any means.

Someone please correct me if I'm wrong.

I understand that ALL of the PC Engine CD games, Super CD games, and Acade card games COULD have been made as HuCARDs and played on the base Core Grafx if the HuCARD chips had simply been large enough.  Is this correct?  (Yes, I know that the theoretical HuCARDS would have been much bulkier, maybe even sticking out from the sytem, and would have needed RAM chips (like many SNES games) to be able to play most Super CD games and all Arcade cards games.)  The difference between the HuCARD format and the CD format (not counting the extra RAM for Super CD/Arcade, which COULD have been put into the HuCARDS) is simple the way that the data is stored.  As was referenced above in regards to computer games, I can remember a time when computer games could be purchased in multiple different formats - 5" floppy disk, 3 1/2" disk, CD, etc..., yet they were (and are) all considered Windows '95 games.  Even many games today can still be purchased as physical media or as digital download media.  Now, I do understand that computers are continually changing, but it seems to me that all of the PC Engine games are actually PC Engine games  :-"  , just with 2 different storage mediums.  I mean, if a video game console today has 2 different storage mediums, say for example, physical disks, or digital downloads (like the Wii virtual store, are they all considered Wii games?  Or if Playstation had regular-sized CD disc games, small-sized disc games (like Gamecube or PSP), and/or DVD disc games, would they all be considered Playstation games?   

Sorry for the necro bump, but while browsing some old posts of mine, I realized that no one really ever answered my above question.  Maybe one of our resident PC Engine game developers?

[lukester]

Bardoly, from what I know some developers used the extra sound hardware to improve graphics, such as Spriggran and Monster Lair.

Black Falcon is an idiot for thinking SNES Gradius III is the best shooter. I like it plenty, but it has way too much slowdown and even Konami's own Salamander outclasses it.

Yes, snes hardware has a great gpu, but it has a large amount of slow paced games and the sound is often bland.

[Black Tiger]

Disclaimer:  I have not read up enough on video game console hardware to call myself an expert by any means.

Someone please correct me if I'm wrong.

I understand that ALL of the PC Engine CD games, Super CD games, and Acade card games COULD have been made as HuCARDs and played on the base Core Grafx if the HuCARD chips had simply been large enough.  Is this correct?  (Yes, I know that the theoretical HuCARDS would have been much bulkier, maybe even sticking out from the sytem, and would have needed RAM chips (like many SNES games) to be able to play most Super CD games and all Arcade cards games.)  The difference between the HuCARD format and the CD format (not counting the extra RAM for Super CD/Arcade, which COULD have been put into the HuCARDS) is simple the way that the data is stored.  As was referenced above in regards to computer games, I can remember a time when computer games could be purchased in multiple different formats - 5" floppy disk, 3 1/2" disk, CD, etc..., yet they were (and are) all considered Windows '95 games.  Even many games today can still be purchased as physical media or as digital download media.  Now, I do understand that computers are continually changing, but it seems to me that all of the PC Engine games are actually PC Engine games  :-"  , just with 2 different storage mediums.  I mean, if a video game console today has 2 different storage mediums, say for example, physical disks, or digital downloads (like the Wii virtual store, are they all considered Wii games?  Or if Playstation had regular-sized CD disc games, small-sized disc games (like Gamecube or PSP), and/or DVD disc games, would they all be considered Playstation games?   

Sorry for the necro bump, but while browsing some old posts of mine, I realized that no one really ever answered my above question.  Maybe one of our resident PC Engine game developers?

The RAM in the IFU and System cards is cart space, the same as other 16-bit carts. It's RAM instead of ROM because the CD-ROM fills it up each time it loads. CD2 game stages are <0.5 Mb each. So a 6 stage CD2 game could be a 3 meg HuCard. But a HuCard version would be even smaller, because carts can draw assets from anywhere in the rom, but CD games must load certain assets each time as well as duplicate code. Tom has said that the code in CD games can take up 0.25 megs, or half the space a CD2 game segment has. So you can see how much smaller a HuCard version could be compared to the sum of each loaded segment of a CD game.

Some developers used unconventional tricks, like how Monster Lair stores some graphical assets inside the adpcm ram. In theory, some SCD games could have used some of the segment storage RAM to make large calculations easier to program at the development level. I've asked the experts several times and the closest answer I've received is that the Arcade Card ram is too slow for anything but simple segment storage.

Even if some games (maybe Populous TPL?) did use some of the SCD ram for something you'd do with Work RAM, that still doesn't mean that the PCE could only have done it that way. The way that the PCE updates the screen and maybe does other things(?), is not the same as the MD and SFC. It is extrenely fast and doesn't need to load everything into RAM before it's rendered a frame. I can never remember the exact technical terms, but the bottomline is that the PCE doesn't need much RAM to pull of 2D games. PCE HuCards obviously prove this. It might help with real-time effects like polygons though. I believe that the SuperGrafx was given so much RAM as overkill to compensate for lazy developers who couldn't push the hardware well enough through skill and work and to just make it future proof in general.

Some devs who didn't want to put in the work to make their code efficient enough might have dipped into the SCD RAM, but it should have been a rare occurance if it happened at all, because the limited segment space was already so tiny and valuable. I'm guessing that you might ve able to use less space on code if you used some extra ram for calculations, but then you've just wasted the extra space you gained.

I'd love for one of the programming experts who have examined CD games to say whether any CD games definitely have or have not used RAM for more than content. Because too many console war fanboys like to say that the CD-ROM is a major hardware upgrade and that the System cards don't allow larger content segments, it only upgraded the Work RAM so that the PCE could handle running 16-bit quality games. But as Tom likes to say, SFII' alone proves that the PCE can do anything a CD game can (other than the exact same redbook and adpcm audio*) and actually more, as the SCD format couldn't handle SFII'. SNES fans like to say that CD games cheat to give consoles 4000 meg roms, but in reality it's the opposite: you get a string of tiny roms instead.


*The base PCE hardware can do adpcm audio through brute force. Tom has made some great HuCard examples.

[elmer]

I've asked the experts several times and the closest answer I've received is that the Arcade Card ram is too slow for anything but simple segment storage.

The Arcade Card memory isn't randomly accessible ... you set a starting address then grab a byte at a time.

Think of it like a modern SSD, it is fast storage, but you need to load things into real work RAM if you want to execute code. (There are limited exceptions, but the basic point is accurate.)

OTOH, you can pretty much copy sprites/tiles from the Arcade Card to VRAM very fast without copying them to work RAM first.

That's what it was designed for ... to give CD games access to a lot of sprite and background data, just like the SFII cartridge.

I believe that the SuperGrafx was given so much RAM as overkill to compensate for lazy developers who couldn't push the hardware well enough through skill and work and to just make it future proof in general.

I'd suspect that it was more to allow for developers to store compressed data on the HuCard, just like people do on the SNES and Genesis.

You need to decompress the data into RAM before you use it, and the original 8KB in the PCE is just too small to store much sprite/map data.

"Yes", you can decompress directly into VRAM, and that's great for some things, but it's not really useful for "real-time" graphics, and decompressing into RAM gives a programmer a lot more options.

I'd love for one of the programming experts who have examined CD games to say whether any CD games definitely have or have not used RAM for more than content.

Well, I've only looked at one PCE CD so far, but it's doing some pretty sophisticated dynamic asset juggling in-and-out of RAM.

And by "assets", I'm including "processor-code" and "scripting-language" as well as graphics data.

Because too many console war fanboys like to say that the CD-ROM is a major hardware upgrade and that the System cards don't allow larger content segments, it only upgraded the Work RAM so that the PCE could handle running 16-bit quality games.

Well, that's because way too many "fanboys" are talking out of their behinds because they've never written a game!

It's so easy to poke fun at SNES owners ... just ask them why their 8-bit processor runs at 1/2 or 1/3 the clock speed of the PCE's processor.

They'll always come back about how much better the SNES video chip is, and there's a good argument there ... but Hudson and Nintendo both had access to similar technology back-in-the-day.

Nintendo decided to use the complete VRAM bandwidth to produce more screen layers. That meant that you had very little time available per-frame for the CPU to actually update any graphics.

Hudson only used 50% of the VRAM bandwidth to produce the PCE's background and sprites, and let the CPU have free access to video memory at any time.

As a programmer ... I much prefer Hudson's design choice.

[Black Tiger]

You need to decompress the data into RAM before you use it, and the original 8KB in the PCE is just too small to store much sprite/map data.

"Yes", you can decompress directly into VRAM, and that's great for some things, but it's not really useful for "real-time" graphics, and decompressing into RAM gives a programmer a lot more options.

So if I understand this correctly, some CD games use some of the IFU/3.0 Card ram to decompress assets that are loaded into vram? If so, wouldn't this mean that a HuCard could run the same content, only it would take up more space in the rom because it wouldn't use the same level of compression or maybe none at all?

[elmer]

So if I understand this correctly, some CD games use some of the IFU/3.0 Card ram to decompress assets that are loaded into vram? If so, wouldn't this mean that a HuCard could run the same content, only it would take up more space in the rom because it wouldn't use the same level of compression or maybe none at all?

Well, I was actually talking about the using the SuperGrafx's extra RAM for decompressing from HuCard ... but "yes", CD games could typically do the same thing.

For one concrete example ... Xanadu II keeps everything compressed on CD, loads it into SCD RAM, and then actually leaves some of it compressed-and-resident until it wants to decompress it and copy it to VRAM. Then it will overwrite the VRAM later with something else ... but still be able to quickly decompress a new copy when it needs it.

At the end of the day ... "yes", none of the decompression would be needed if you had enough RAM or HuCard space. But you don't.

Compressing data in ROM was a standard way of fitting more data into a smaller (and therefore cheaper-to-manufacture) cartridge.

Nintendo could easily have released 640MByte cartridges for the SNES, it was never a question of technical capability. It's just that nobody would have wanted to pay the ridiculous price that it would have cost to manufacture cartridges with all the dozens of ROM chips that it would have needed.

CD-ROM was a revolutionary reduction in the price-per-megabyte cost of data storage for games ... which allowed people to make much more expansive games affordable.

IMHO, the original PCE CD was just too starved for memory to more than hint at the capabilities. SCD was when things really took off.

[Arkhan]

I am pretty sure the CD hardware preemptively killed the SuperGrafx.

That thing basically launched dead in the water.

Why bother going back to card-only shit when you have the cheap, seemingly endless CD storage?

Nobody wants to go from anime cutscenes and fancy audio, back to a "new" console that can't do any of that...
....


unless you bank on people buying the RAU-30, and hoping enough people have SuperGrafx SuperCD setups to make it worth the effort it takes to write the game.


I joked about making a SuperGrafx arcade cd game for all 4 of you.

[elmer]

I am pretty sure the CD hardware preemptively killed the SuperGrafx.

Yep, I agree.

That, and the SuperGrafx pricing, the stupid H.R. Giger Alien-inspired design rather than just making it slip directly into an existing IFU-30, the very few and expensive games, etc, etc.

Pretty much a text-book example of how not to try to fracture a console's marketplace.

I joked about making a SuperGrafx arcade cd game for all 4 of you.

That's still my dream ... it's the most interesting 4th-gen "combination-console" to me, with the most elegant technical design (not physical look).

X68000 was a multi-thousand-dollar home computer and so doesn't really count as a "home console"; Neo Geo really was an Arcade-machine-in-a-box, but it was still a cartridge machine, even after the Neo Geo CD came out; Sega CD was the usual brain-damaged Sega mess of a design, totally hampered by the Genesis's 4-palette 60-color video output; and the SNES was a nice video chip with a slow CPU and a brain-damaged memory-map (with no CD).

Is there anyone that I missed offending there? 

[Necromancer]

Is there anyone that I missed offending there? 

You missed a chance to point and laugh at the CD-i. 

[elmer]

You missed a chance to point and laugh at the CD-i. 

Damn, how on Earth could I have forgotten that excellent target! 

[Bonknuts]

The limited amount of system ram on the PCE prevented devs from using more complex compressing schemes (although technically they could have used a small ring buffer). If you look at hucard games, except for the late gen ones - they all use simple RLE-ish style compression. That means less animation or grafx overall (Parodius PCE vs SNES). The smaller amount of ram also means less decompressed asset space for quick updates to vram dynamically throughout a level (animation, etc). The SGX is definitely a better setup with the additional 24k. 64k would have been prime though. 8k is just fairly limiting. It means throwing more rom at it or putting ram on the hucard.

 Yeah, original CD games are starved for ram too. Except for a few games, most load all sprites and tiles into vram for that level, all sound FX into ADPCM, and leave the 64k of ram for code and map/level data. Most original CD games don't even bother compressing the graphics. The SuperCD breathes much easier thanks to the extra ram. Not only that, but optimized SCD games tend to use LZss compression schemes and leave the data compressed in CD ram. A small amount is coupled with the 8k to give the "work" ram area a large working range. Usually +16k. A few games use self modifying code (more of convenience than speed; no need to take up variable space at page $2000 or map ram in, for temporary work variables) like Dracula X.

 If you look at Gate of Thunder and Lords of Thunder, both games compress the graphics with LZss schemes, and while the game logic is running, it'll run a background process to decompress assets ahead of time. IIRC, GoT even does linear to planar conversion after decompressing.

 The original CD should have been 192k-256k range and the SCD as 448k-512k range. The ADPCM ram is slower in speed and port based/accessed. They could have made that area much larger for hybrid fast/slow ram configuration. I'm sure that ram was cheaper than the faster ram.