Why was 7800 discontinued

[zzip]

15 hours ago, RevEng said:

Maybe that's true of the 5200, I don't know. It doesn't match any of my experience on the 7800. Many of the impressive looking games coming out on the 7800 are using 7800basic, which manages the display in a very generic way. There is no arcane months-long tinkering involved, just a small bit of system knowledge, some great game mechanic coding, and some kick-ass art.

There was no 7800basic BITD.   Developers had to deal with whatever dev system and documentation Atari provided, and those often weren't the greatest.

 

15 hours ago, RevEng said:

mksmith got the 7800 Petscii Robots port up and running in petscii character mode, and it was my job to juice up the display for the 7800. That uplift work on the tile engine - which is most of the visual impact - took me less than a week of dev time. The rest of the dev time we spent on more mundane stuff - hooking up the rest of engine fully, adding controls, creating menus, QA and fixes, etc - all very pedestrian stuff and totally comparable to what you'd do on any non-Atari systems.

PETSCII robots appears to be running in 160 mode except for the text at the bottom of the screen.    I'm specifically talking about the 320 mode being difficult to work with except for developers with a special skillset.   That's why the majority of games used 160 mode back then, which looked outdated compared to the competition.

 

5 hours ago, DavidD said:

Dumb question... not to sidetrack things too much, but if Atari had gone ahead and released Nintendo's Famicom in the USA... based on the timeframes we know about, wouldn't that have been AFTER the 7800?

 

That is, we'd have 2600 -> 5200 -> 7800 -> "Atari/Nintendo Famicom"

 

I believe they wee talking to Nintendo around the same time they were evaluating the 7800.   I think they were planning to go with one or the other, not both.    Also the fact that Atari snubbed Nintendo is why the NES launch in North America was delayed until 85

[RevEng]

4 hours ago, zzip said:

There was no 7800basic BITD.   Developers had to deal with whatever dev system and documentation Atari provided, and those often weren't the greatest.

There's two aspects that programming in 7800basic differs from traditional development. First, it allows you to not know a lot of assembly language and still create impressive games, and second, it provides what amounts to a library of assembly macros to accomplish certain tasks. Since we're comparing development in comparable systems like the NES, the first aspect is moot - the NES devs would have also had to program in 6502 assembly.

 

The second aspect is a hill to climb with your first 7800 assembly game. On your second game, you reuse a ton of your 7800-specific routines from your first game, turning that hill you originally climbed into a mound. If you're part of a game dev company with decent funding, you share those routines with team mates - same as what happened on the NES. This second aspect isn't the big advantage you think it is, nor is the NES markedly easier to program than the 7800.

 

Your "dev system and documentation" points aren't relevant to the argument that 7800 hardware (and Atari consoles generally) is intrinsically more difficult to program, compared to NES and other contemporaries. If anything they bolster what I've been saying this whole time - the poorer 7800 commercial titles were due to lack of dev support, not the tech.

 

4 hours ago, zzip said:

PETSCII robots appears to be running in 160 mode except for the text at the bottom of the screen.    I'm specifically talking about the 320 mode being difficult to work with except for developers with a special skillset.   That's why the majority of games used 160 mode back then, which looked outdated compared to the competition.

Even narrowing the hardware superiority discussion to just hi-res... We only have a handful of commercial carts (in any mode) to actually point at, and at least three of them are using the 320 modes. (One on One, Jinks, and Tower Toppler) The difference in usage bitd is just a preference for high color (which matches my own taste) vs the lower color 320 modes.

 

It's the exact same on the A8 - most games didn't use Antic F despite it having the highest resolution, because greater color depth was often desired. In no way is using Antic F any harder than using the other modes.

 

I don't know where you're coming up with this notion that it's sooo hard to use the 320 modes that nobody was able or willing to attempt it under now, without your having any experience programming the console. And then you debate the point with someone who has experience, because you have some inferred knowledge that trumps actually knowing the console's inner workings.  Hubris.

[zzip]

54 minutes ago, RevEng said:

3 hours ago, zzip said:

 

We have a handful of commercial carts to actually point at, and at least three of them are using 320 modes. (One on One, Jinks, and Tower Toppler) The difference in usage bitd is just a preference for high color (which matches my own taste) vs the lower color 320 modes.

The fact that there's only a handful proves my point.   If it's just a design choice, then why were even low0color games like Galaga implemented in 160 rather than 320?    Look at the extra detail in the NES screenshot on the right to see that increasing the resolution does make a difference.  The detail on the player's ship especially.

 

 

Rampage looks horrible on the 7800 and the NES and SMS versions to the right even managed to pull off extra color-shading at a higher resolution

 

 

High colors are nice, but there are times more resolution is needed to bring out the details,  and the 7800 ports fail to do this more often than not.

I can go through the library and I see this time and again, yet I'm told the 7800 is better than NES,  and it's just as easy to program for, and high-res is not a problem

 

But I've read developer descriptions of the pitfalls in 320 modes and know it has several limitations that make it challenging to work with, and that's why it's infrequently used.   It's unfortunate but that's the way it is..

[RushJet1]

On 10/17/2023 at 4:10 PM, zzip said:

But even Pokey was kind of dated by the 7800 launch.  (it has a harsh quality to it compared to other sound chips-  Can't imagine what the happy, bouncy music of NES games would sound like on Pokey)

here's the next best thing, NES music being played through a TIA FPGA with corrected pitches and 3 channels (NES noise and DPCM are retained):

 

http://blog.kevtris.org/blogfiles/nes tia/

Edited October 19, 2023 by RushJet1

[Jetboot Jack]

2 hours ago, zzip said:

I've read developer descriptions of the pitfalls in 320 modes and know it has several limitations that make it challenging to work with, and that's why it's infrequently used.

Truth is there was no money in 7800 development - and that means what was developed was done quickly, cheaply and in many cases poorly.

 

The systems spec and tools was no more or less challenging to use than the other contemporary systems - there was just no motivation for developers to make the effort.

Let alone those not developing for Atari…

 

And before any one shouts me down - I was there, doing work for Atari in the 80’s - it was a struggle…

 

sTeVE

 

Edited October 19, 2023 by Jetboot Jack

[RevEng]

6 hours ago, zzip said:

The fact that there's only a handful proves my point. 

Reread what I wrote again. I was talking about all of the commercial releases together only being a handful of titles, and even then we got three 320 mode games.

 

6 hours ago, zzip said:

 If it's just a design choice, then why were even low0color games like Galaga implemented in 160 rather than 320?

Dunno. Maybe they didn't want to go over 32k. Maybe they thought filling out the width of the screen was better than using vertical bars at the side. The GCC stuff was co-developed with the hardware, so maybe the 320 modes weren't finished when Galaga development started. Maybe the dev wanted to reuse 160-specific routines from some other project, to save time.

 

It's a mistake to make up your mind about a technology based on it's worst implementations, and you've done again and again here. We've provided examples of 320 mode used well, both during the commercial console life, and after. Pointing at some of the worst commercial games in 160 mode as evidence for your pet theory - when there were so many non-technical challenges going on at that time - is misguided.

 

6 hours ago, zzip said:

But I've read developer descriptions of the pitfalls in 320 modes and know it has several limitations that make it challenging to work with, and that's why it's infrequently used.   It's unfortunate but that's the way it is..

Here's the thing. There are certain, very clear, rules about using color in 320 modes. 160 mode is simpler, but not in some "oh my god, 320 mode is impossible!!1!" kind of way. It just takes a little bit of understanding and planning. We're successfully using 320 for all kinds of homebrews now, and the tech is the same as it was when those original three 320 mode games came out. We haven't discovered anything new about the hardware regarding 320 mode.

 

Sometimes new devs start using these modes without bothering to read or understand the docs (which admittedly are a bit arcane - I do wish Atari would have invested in the docs a bit more) and then they complain about the results or ask for help in the forum. On the other side we have Defender_2600, who is a master at designing art for these modes, and he's not even a programmer - he just spent a little bit of time to understand the rules.

 

I dare say that if a non-programmer can understand the 320 rules so well, then maybe... just maybe... they aren't the difficult challenge that you're making them out to be. But what do I know, I just program for the console.

[zzip]

11 minutes ago, RevEng said:

It's a mistake to make up your mind about a technology based on it's worst implementations, and you've done again and again here. We've provided examples of 320 mode used well, both during the commercial console life, and after. Pointing at the worst as evidence for your pet theory - when there were so many non-technical challenges going on - is misguided.

I agree that you can't judge the hardware by a bad implementation or two.    I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history.   It was supposed to be the successor to the 5200 and carry Atari through the late 80s,  And as such, it falls short,   Compared to the 5200 it's two steps forward, and two steps back.   Better sprites, worse sound, it should be better in every way.   There shouldn't be 5200/Atari 8bit games that look or play better than the 7800 version, but there are a few.   And its games should be able go toe to toe with the competition without showing obvious inferiorities. 

 

17 minutes ago, RevEng said:

Here's the thing. There are certain, very clear, rules about using color in 320 modes. 160 mode is simpler, but not in some "oh my god, 320 mode is impossible!!1!" kind of way. It just takes a little bit of understanding and planning. And yes, creatively working within those rules. Rules which have been laid out since 1984.

I never said it was impossible, just that it was difficult and hence the tendency to avoid it.   Yes there are some homebrewers that have done amazing work.   I really like the homebrew Frogger for instance that's nearly arcade quality.    But the problem is you need to be a hardware expert to achieve that quality and that means the vast majority of coders won't be able to do it.    Every system has elite coders that can make it do wonders,  so I wouldn't judge the system by the exceptions, I judge it by the norm.

 

[RevEng]

2 hours ago, zzip said:

I never said it was impossible, just that it was difficult and hence the tendency to avoid it. 

It's not difficult, you just have to follow the rules of the mode. It doesn't take some exceptional elite coder guru to follow those rules. As I already pointed out, we have a non-programmer non-hardware guru regularly demonstrating a perfect understanding of them. Every console has rules and constraints you need to adhere to, and this one is no different.

 

2 hours ago, zzip said:

 But the problem is you need to be a hardware expert to achieve that quality and that means the vast majority of coders won't be able to do it. 

I'm likely gonna blow your mind here, but NES coders also have to understand their hardware and follow the rules.

 

2 hours ago, zzip said:

 I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history. 

There's too much noise in your data (other factors like lack of funding, lack of dev support) and too few data points (game titles) for you to soundly come to the conclusion that the tech was lacking. That's why I'm saying your pet theory is the result of confirmation bias. Well, that and the fact that I've actually used the 320 modes before.

[Jetboot Jack]

15 hours ago, zzip said:

I agree that you can't judge the hardware by a bad implementation or two.    I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history.   It was supposed to be the successor to the 5200 and carry Atari through the late 80s,  And as such, it falls short,   Compared to the 5200 it's two steps forward, and two steps back.   Better sprites, worse sound, it should be better in every way.   There shouldn't be 5200/Atari 8bit games that look or play better than the 7800 version, but there are a few.   And its games should be able go toe to toe with the competition without showing obvious inferiorities. 

 

I never said it was impossible, just that it was difficult and hence the tendency to avoid it.   Yes there are some homebrewers that have done amazing work.   I really like the homebrew Frogger for instance that's nearly arcade quality.    But the problem is you need to be a hardware expert to achieve that quality and that means the vast majority of coders won't be able to do it.    Every system has elite coders that can make it do wonders,  so I wouldn't judge the system by the exceptions, I judge it by the norm.

 

Let me re-iterate - the 7800 is no more or less difficult or complex to develop for than other platforms of a similar time frame. The SMS and NES (esp with Mappers) have their quirks too - so that does not explain the rather ho-hum game quality on the 7800 - and I would refute the assertion "The reason for that is on the other systems it's easier to get better results." - its that other platforms/systems generated more income and therefore in those markets there was more competition which means games had to be made well to stand out is the more correct reading to that Rampage etc comparison..

 

My opinion, 'cos there are few absolutes, there were games developed for the original release - and they are of their time in terms of visuals and complexity. Early games on any system are rarely using the hardware to it's max - they we're also developed by solo developers or very very small teams, unlike the Japanese products where even in 1984 they were quite large teams of people making one game.

 

Then there are later developed games that are highly variable in terms of overall quality - but in my opinion mostly lacklustre, because they were made with low budgets - the impetus to make the best games possible is a market driven, you are competing for an audience - Atari had a tiny audience, fewer sales than other platforms and combine that with the fact they ALWAYS wanted the smallest ROM size possible means that games had to be compromised. Later in my career (around 2001) I worked at what was once called Sculptured Software and anecdotally I am aware that the games developed by them were done VERY quickly, by a couple of people, and had to fit into small ROM's because Atari did not want to spend much money on the games...

 

No 7800 game ever had the budget of a Castlevania or a Super Mario Bros for instance or the ROM size, extra RAM, the support chips etc - quality and fully exploiting the hardware takes time and resources - not things Atari was prepared to pay for..

 

sTeVE

Edited October 20, 2023 by Jetboot Jack

[zzip]

14 hours ago, RevEng said:

It's not difficult, you just have to follow the rules of the mode. It doesn't take some exceptional elite coder guru to follow those rules. As I already pointed out, we have a non-programmer non-hardware guru regularly demonstrating a perfect understanding of them. Every console has rules and constraints you need to adhere to, and this one is no different.

There's a huge difference between making static images that follow the rules and making a moving game.    When you move objects around,  they'll move to zones where they can't use the colors they had been using if you aren't careful.  Sometimes even when you understand the rules, you will find they are too restrictive for your project.   If the 320 modes were easy to use, there'd be more games using them and not so many threads around from coders struggling with them.   

 

The more complex the rules. the fewer coders are going to understand and master them, and the worse the results are going to be,  and the more fans are going to complain about untapped potential.   You might not think the rules are complex, but if there's only a few people around that understand them and/or they aren't documented well..   well that's pretty much the definition of specialized/elite knowledge.

 

14 hours ago, RevEng said:

I'm likely gonna blow your mind here, but NES coders also have to understand their hardware and follow the rules.

Of course, but the fact that they consistently got better results on NES says a lot about the complexities. 

 

15 hours ago, RevEng said:

There's too much noise in your data (other factors like lack of funding, lack of dev support) and too few data points (game titles) for you to soundly come to the conclusion that the tech was lacking. That's why I'm saying your pet theory is the result of confirmation bias. Well, that and the fact that I've actually used the 320 modes before.

That's hilarious!    I hated the NES, wanted Atari to succeed, and I thought the 7800 looked amazing at first.    If I had confirmation bias,  then it would be that the 7800 is superb and I'd have a blind spot to its issues.    Problem is, every time I play a 7800 game, its shortcomings are just too apparent.   And I'm talking mostly about the commercial titles that would make or break the system, not the homebrews that some 7800 wizard came up with decades later.   Looking at the situation objectively, I came to the conclusion that the 7800 as it exists was not worth killing the 5200 over in 84,   it should have been sent back tand refined a bit more as the eventual 5200 successor and it could have been an amazing console.

[zzip]

50 minutes ago, Jetboot Jack said:

"The reason for that is on the other systems it's easier to get better results." - its that other platforms/systems generated more income and therefore in those markets there was more competition which means games had to be made well to stand out is the more correct reading to that Rampage etc comparison..

Eventually the NES was a cash cow, but that wasn't true when it first released.   When launching a new console you have to invest in games to make the system shine and give people a reason to buy it.   This often means spending more on those games than you might recoop..   The payoffs come later if/when the system is successful.   One of the problems was the Tramiels didn't seem willing to make this kind of investment in their game libraries until it was too late.

 

I think there was a better chance that Warner would have made such an investment if they weren't crashing and burning.   Assuming Warner could have righted the ship without selling Atari,  I think the 7800 would have been in a better place and they would have made life harder for Nintendo at the very least.

 

1 hour ago, Jetboot Jack said:

My opinion, 'cos there are few absolutes, there were games developed for the original release - and they are of their time in terms of visuals and complexity. Early games on any system are rarely using the hardware to it's max - they we're also developed by solo developers or very very small teams, unlike the Japanese products where even in 1984 they were quite large teams of people making one game.

 

Yes, and most of the those 7800 launch titles titles were already dated in 1984.   They were EXTREMELY dated when the system finally launched in 86

 

1984 was an innovative year in games,  but then here comes this console offering up mostly games from 1982 and older, like Ms-Pacman, Centipede, Joust, Asteroids, Dig Dug..   These are games that had been out on other systems for a year or more and most people weren't going to buy a new console to play rehashes (this was one of the 5200's problems too),  it needed something new and unique.    But Tramiel seemed to think all you needed to do was sell anything cheaper than the competition and you can make it a hit

 

1 hour ago, Jetboot Jack said:

Then there are later developed games that are highly variable in terms of overall quality - but in my opinion mostly lacklustre, because they were made with low budgets - the impetus to make the best games possible is a market driven, you are competing for an audience - Atari had a tiny audience, fewer sales than other platforms and combine that with the fact they ALWAYS wanted the smallest ROM size possible means that games had to be compromised. Later in my career (around 2001) I worked at what was once called Sculptured Software and anecdotally I am aware that the games developed by them were done VERY quickly, by a couple of people, and had to fit into small ROM's because Atari did not want to spend much money on the games...

The sad thing is Atari went from the undisputed king of videogames to a side player in just a few short years.    Unfortunately you can't cost cut your way to success,  you have to have game budgets that are competitive with the others if you want to remain one of the big boys.   Atari Corp wanted to be a computer company and videogames were just something they inherited.   They didn't invest enough in the gaming side until it was too late.

 

 

 

[RevEng]

3 hours ago, zzip said:

There's a huge difference between making static images that follow the rules and making a moving game.    When you move objects around,  they'll move to zones where they can't use the colors they had been using if you aren't careful.  Sometimes even when you understand the rules, you will find they are too restrictive for your project.   If the 320 modes were easy to use, there'd be more games using them and not so many threads around from coders struggling with them.   

I can't think of a single game that switches between 320 modes for different zones, with the exception of switching for a non-game score/status area. Certainly none of the previously mentioned 320 mode games - the same ones that you said required elite programming skills to pull off.  

 

All of the palettes you can assign to a sprite are available anywhere on the screen. Those palettes aren't pegged to any particular zone, like you're thinking. Sure you can use a raster interrupt to change the values in those palettes, but it's not as widely used a trick as on the A8, because we have different palettes to choose from. In any case, dealing with the palette values you yourself changed via interrupt hardly requires the elite programming skills you've claimed are needed.

 

Defender_2600 produces graphics that are directly actionable on the console, and they can move around without problem within the game screen area. Sorry, you're just flat-out wrong here about vertical movement being an issue. You're inventing complications that aren't actually there, not even on the games you said required elite 320-mode programming skills to pull off.

 

3 hours ago, zzip said:

Sometimes even when you understand the rules, you will find they are too restrictive for your project. 

This is true for any given system constraint or rule, on any console. There is no console from the 80s where any game design choice can be made without regard to the console hardware - even your imagined super 5200 successor would have had them. Ask an NES dev how simple raster interrupts are on their platform (without resorting to advanced mapper hardware) or how they add together BCD numbers for score display.

 

[leech]

On 10/18/2023 at 2:48 PM, zzip said:

I think it's like so many Atari systems where if you have the time and skills you can make it do amazing things.   But the average programmer hired to do a port BITD didn't necessarily have those skills and had a deadline, so you got games that looked inferior to the competition.   The reason for that is on the other systems it's easier to get better results.

For sure; there is also the 'lowest common denominator' factor.  Like when the Amiga and ST first launched, the ST was where everyone created the games, and then they were ported to the Amiga.  When developers finally figured out how to use the Amiga, the games suddenly got far better than the ST versions.  Unfortunately that never got the translations back to the STe.

The lack of deadlines is a crazy thing.  There is a bit of 'people know all the hacks and crazy things you can do with the hardware better 30 years on down the line...' but the hardware hasn't changed, just the tools and knowledge, and being able to take your sweet ass time to release things means that you can make things bigger and better! 

 

A great example of this would be something like Ultima IV, where we know full well the A8 is more  capable than what we got, but it was an Apple II port, and used artifacting for colors.  Looking at what was done for the C64 version, makes me want to learn how to code and do the same thing for the A8!  (though I want to cheat and make a VBXE enhanced version).  I need to live on Mars so I have longer days. 

[zzip]

13 minutes ago, leech said:

For sure; there is also the 'lowest common denominator' factor.  Like when the Amiga and ST first launched, the ST was where everyone created the games, and then they were ported to the Amiga.  When developers finally figured out how to use the Amiga, the games suddenly got far better than the ST versions.  Unfortunately that never got the translations back to the STe.

The lack of deadlines is a crazy thing.  There is a bit of 'people know all the hacks and crazy things you can do with the hardware better 30 years on down the line...' but the hardware hasn't changed, just the tools and knowledge, and being able to take your sweet ass time to release things means that you can make things bigger and better! 

Amiga is a good example too.   It also had HAM and half-bright modes that might make for pretty pictures but not ideal for game use

 

Another example, on the Atari 8-bit,  if I browse screen shots on Atarimania from 82 or 83-  so many of the games had these  muddy-looking unappealing color palettes.  But now we get homebrews like "Albert" that are extremely colorful and show what could have been accomplished.    But I'm not going to judge a system by the 21st century exceptional homebrews,   I'm going to judge it by the average experience during the system's commercial life when it mattered.   It could have used those exceptional techniques to get a leg up on the C64 or Colecovision, but too few programmers of the time had the skills or time to pull it off.

 

There's a tendency in the fan bases of older hardware to be enamored with the potential of the system (real or imagined), and make excuses for mediocre actual results.

 

26 minutes ago, leech said:

A great example of this would be something like Ultima IV, where we know full well the A8 is more  capable than what we got, but it was an Apple II port, and used artifacting for colors.  Looking at what was done for the C64 version, makes me want to learn how to code and do the same thing for the A8!

Atari's hi-res scheme is closer to Apples.    Only problem is Apple II sacrificed resolution for two extra artifact colors (on Apple II for every 8-bits of graphic data,  one bit determines if the artifact colors for that byte are orange and blue or green and purple,    The Atari 8-bit doesn't have that,  there's only two artifact colors, usually orange and blue but it varies, creating an additional headache for developers trying to use that mode.

 

C64 took a different approach.   Their high-res 320x200 mode is still a two color mode technically,  but it allows each 8x8 cell to have a different set of two colors.   While this might be a tough scheme to use for many games,  it's perfect for a tile-based game like Ultima.   So C64 got the most colorful versions while sticking to palettes true to the original look,  (unlike the ST/Amiga versions of U3/U4 where I can't stand the color choices).   I suppose the Atari-8bit versions could have resorted to PMG overlays to color individual tiles,  but that might look funny.   Or it could have gone to a lower res like the Ultima V port that's being worked on

[Jetboot Jack]

1 hour ago, leech said:

Like when the Amiga and ST first launched, the ST was where everyone created the games, and then they were ported to the Amiga.  When developers finally figured out how to use the Amiga, the games suddenly got far better than the ST versions. 

That's not what happened...

 

The ST initially sold large numbers, far more than the Amiga - so developers/publishers followed the money and produced games for the platform where consumers were spending. Once Commodore produced an affordable Amiga consumers started buying the platform and so it became more economical to produce games that took advantage of the Amiga (and some companies leaned on that heavily in the early 90's) - as if they did they could not be easily ported to the ST (Shadow of the Beast on ST anyone?), which was a large market - so overall there are relatively few Amiga only games in that generation, just because of the economics of the market...

 

Commercial software development and leveraging a platform's power is always a factor of the economics.

 

I realise that fans of a platform find that difficult, but the 7800 died on its ass because it sold in small numbers and the game made for it were sadly mediocre..

 

sTeVE

Edited October 20, 2023 by Jetboot Jack

[+Defender_2600]

 Before continuing, just a comic to lighten things up. Any reference to persons is absolutely coincidental.

 

 

[JagChris]

5 hours ago, zzip said:

The sad thing is Atari went from the undisputed king of videogames to a side player in just a few short years.    Unfortunately you can't cost cut your way to success,  you have to have game budgets that are competitive with the others if you want to remain one of the big boys.   Atari Corp wanted to be a computer company and videogames were just something they inherited.   They didn't invest enough in the gaming side until it was too late.

 

 

I think that is what they were trying to say. it wasn't lacking in technical capabilities it was lacking in developer motivation. Because of Atari cheapness. 

 

That god damn Choplifter made by I-Bid-Inc. Lol.

[Bakasama]

41 minutes ago, JagChris said:

 

I think that is what they were trying to say. it wasn't lacking in technical capabilities it was lacking in developer motivation. Because of Atari cheapness. 

 

That god damn Choplifter made by I-Bid-Inc. Lol.

B-but there's Karateka. I didn't think that wasn't too bad until I heard about what was cut out of 7800 port, like killing that annoying bird.

[JagChris]

I heard the 7800 version was really bad. Its a rather simplistic game and made me wonder how they screwed that up. 

 

I haven't played Karateka in a long long time. I should fire it up soon.

[fluxit]

The deficiencies in 7800 Karateka just seem completely unnecessary.  Control response is sluggish when compared with the game on other platforms. 

 

Karateka is already one of those games where you give your character a command, and then wait for him to complete the action.  On the 7800 you have to wait for your character to *start* the action.  You basically have to be ahead of the game with your control inputs, or it will be an even more miserable experience.

 

One of things that people enjoyed about Karateka back in the day, was the 'story' being told by the cut scenes.  The scenes on the 7800 have been abbreviated, with the final scene having been reduced to a still image, with seizure lights added.  The final boss fight was also removed.

 

If I'd never played or completed the Apple II, or IBM PC version, perhaps I'd appreciate the 7800 version more, but it isn't very good.

Edited October 20, 2023 by fluxit

[Trebor]

The released Double Dragon ROM with graphical updates, demonstrated that even working within the relatively restrictive template some of the titles were developed under, if a bit more attention was spent designing the graphics, and even something as simple as better palette choices, makes a huge difference:

 

 

 

Let's put that in motion with POKEY music:

 

 

It wasn't about needing to know advance hardware or programming techniques.  It had nothing to do with a lower resolution missing some details.  There is a tremendous amount of details with the graphic updates shown above.

 

Unfortunately, it was about going cheap and rushing the job with limited resources.  The system was not utilized as intended.  Even under the relatively limited programming template provided for the Double Dragon port, a little more care with the graphics and using an external sound chip as intended by console design, it is a completely different game.

[+Defender_2600]

1 hour ago, Trebor said:

The below Double Dragon ROM with graphical updates that was released, show even working within the relatively restrictive template some of the titles were developed under, if a bit more attention were spend designing the graphics and even something as simple as better palette choices makes a huge difference:

 

 

 

Let's put that in motion with POKEY music:

 

 

It wasn't about needing to know advance hardware or programming techniques.  It had nothing to do with a lower resolution missing some details.  There is a tremendous amount of details with the graphic updates shown above.

 

Unfortunately, it was about going cheap and rushed for the port, and the system was not utilized as intended.  Even under the relatively limited programming design template provide for the Double Dragon port, a little more care with the graphics and using an external sound chip as intended by system design, it is a completely different game.

 

Absolutely true. Not to mention if it would be completely rewritten from scratch.

 

 

 

 

[Trebor]

Regarding Rampage, it is another case, like Double Dragon, of poor palette choices, and rushed graphic work.  Once again, same template as the retail original, but just some TLC with updated graphics:

 

 

What was released to retail had nothing to do with some sort of hardware limitation, but everything to do with the resources allocated to it.

 

Nevertheless, as Defender_2600 mentioned with Double Dragon, this too could be completely rewritten from scratch and be even better than the above captures.

[+Defender_2600]

Regarding Rampage, the 7800 version has solid gameplay and can display George, Lizzie, and Ralph on the screen, instead the NES version excludes Ralph, reducing the number of monsters to two. Another feature I appreciate about the 7800 version is that it only has the sound effects without the music, like the arcade version. The Master System version has music and you can't turn it off, it is very repetitive, boring and ruins the atmosphere of the game. However, the 7800 version has basic graphics that do not show the real performance of the hardware.

 

Some years ago, KevinMos3 worked on a Graphics Hack of 7800 Rampage (Trebor beat me to the punch as I wrote this!), he only updated the graphics without changing anything in the code, and the result was surprising. This proves once again that a pixel artist can make a big difference, and once again demonstrates that judging the performance and limitations of the 160 mode requires skill and experience.

 

Also, wanting to take another step forward, you could insert larger sprites using the 160B mode, and much more. And I want to mention that compared to 7800, the SMS puts more colors on screen at one time for the background (SMS 31 colors from 2 palettes vs 7800 25 colors) but for the sprites the SMS has only one 15 color palette while the 7800 can use any palette available (24 colors).

 

Here are the comparison images between the original 7800 version, the Graphics Hack and the updated Graphics Hack (mock-up) with a new sprite of George in 160B.

 

 

 

----------------------------------------------------------------------------------------------------------

 

Regarding 7800 Galaga, obviously it can be made using the 320 mode. Some time ago I started working on sprites in 320C and they are not difficult to make, in fact in this circumstance it is easier to draw them in 320C than in 160A. For the moment we still don't have Galaga320 on 7800, but we can already have fun with the fantastic Galaxian320.

 

 

 

 

Regarding the original 7800 Galaga in 160A mode, KevinMos3 made a Graphics Hack with some improvements, including a new player's spaceship. To get the best and correct result, the ideal would be to use real hardware and CRT, if instead you use emulation, don't forget to adjust the correct aspect ratio and enable the CRT filter to get the experience close to the real thing.

 

 

One last thing, since a comparison with the NES version was shown, I attach some comparative images that show that the playing field of the NES version has reduced horizontal resolution due to the positioning of the score on the right, and this compromises the gameplay.

 

 

[Bakasama]

On 10/17/2023 at 2:12 PM, Defender_2600 said:

The NES features a palette of only 48 colors and 6 grays, 8x8 or 16x16 tiles / 3 colors from 4 palettes, and 8x8 or 8x16 sprites / 3 colors from 4 palettes. The 7800 features a palette of 256 colors and, with the 160B mode, a single sprite / tiles can have 12 colors from 2 palettes + transparent / background and without limits of size (25 colors per zone).

 

In other words, the NES can only use 4 palettes 2bpp (13 colors available) for tiles and each NES tile is limited to 3 colors, instead the 7800 can use 2 palettes 4bpp (25 colors available) and use all 12 colors in a single tiles. The same rule applies to sprites, the NES can only use 4 palettes 2bpp (13 colors available) for sprites and each NES sprite is limited to 3 colors, instead the 7800 can use 2 palettes 4bpp (25 colors available) and use all 12 colors in a single sprite.

 

Basically a stock 7800 can display 4bpp graphics that a NES + MMC5 can't and in any case on NES you would still be stuck at 3 colors per sprite/tile, stuck at 8x8 or 16x16 pixels, instead no restriction on the size of the sprites / tiles on 7800. Not to mention the maximum number of sprites per scanline, only 8 sprites on NES, instead 30 sprites on 7800. And maximum number of sprites on screen, 64 sprites on NES, more than 200 sprites on 7800.

If I'm understand this correctly, 160B mode has a lot of colors to use and spare a lot of time. A game like Xevious can have more colors to use, like red. I felt the color depth in that game seems to bit lacking when compared to arcade version.