Why was 7800 discontinued

[+Defender_2600]

43 minutes ago, Bakasama said:

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.

The 160B mode consumes approximately double the cycles compared to 160A mode, so its use must be evaluated based on the circumstances. Xevious on 7800 uses 128 pixels as horizontal resolution, so perhaps with a well optimized code it could use 160B for background graphics and 160A for sprites. You have to calculate the necessary cycles and know the exact number of sprites per scan line. However, an improvement could be achieved simply by updating some colors of the current version.

[Trebor]

On 10/20/2023 at 5:22 PM, 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.

On 10/20/2023 at 6:06 PM, Bakasama said:

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.

On 10/20/2023 at 6:16 PM, JagChris said:

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.

It comes up often, so let's look at Karateka (and a little Choplifter)...

 

Jordan Mechner developed the game for the Apple II platform.  Mechner wanted to create fluid animations for the Apple II and took his time to create animations that would utilize that hardware as best as he thought possible.  A technique he utilized was rotoscoping.  It included taking hand-drawing cartoons superimposed on top of frames of film that contained his karate instructor demonstrating various moves.  A very time consuming task.  Jordan Mechner's father, Francis Mechner, created the soundtrack for the game.  Development took approximately two years, and afterwards, Jordan Mechner submitted the game to Broderbund to be published.

 

Compare that above scenario to the conditions of porting the game to the 7800: 

 

A senior software engineer at Ibid Inc., Jack Sandberg, was tasked with porting Karateka to the 7800.  He had to create the development environment from scratch.  The environment overall was difficult with limited resources, in addition to horrible interactions.  One such interaction example provided, was Len Tramiel spending an hour yelling about the color of the sky chosen for Choplifter (Another game Ibid Inc. was tasked to port from scratch).   Meanwhile, the Tramiels would harp on getting the port out as quickly as possible, while the engineer had to handle all aspects of the game: main program, controls, graphics, sound.

 

Not technical limitation of the system, a hardware guru required, or special programming tricks were needed, but very often, limited resources and a lousy environment to develop (or port) a game, resulted in the end products that were released to retail for the 7800.

[zzip]

On 10/21/2023 at 3:08 AM, Defender_2600 said:

The 160B mode consumes approximately double the cycles compared to 160A mode, so its use must be evaluated based on the circumstances. Xevious on 7800 uses 128 pixels as horizontal resolution, so perhaps with a well optimized code it could use 160B for background graphics and 160A for sprites. You have to calculate the necessary cycles and know the exact number of sprites per scan line. However, an improvement could be achieved simply by updating some colors of the current version.

Yet you keep insisting that graphics on the 7800 is easy and straightforward.    This is exactly the kind of thing I'm talking about when I say "advanced" techniques.    To me "easy" graphics doesn't require counting CPU cycles or needing well-optimized code to get desired results.

[RevEng]

15 minutes ago, zzip said:

Yet you keep insisting that graphics on the 7800 is easy and straightforward.    This is exactly the kind of thing I'm talking about when I say "advanced" techniques.    To me "easy" graphics doesn't require counting CPU cycles or needing well-optimized code to get desired results.

You only need to "check cycles" (or test a design on real hardware or emulator, which is what most devs do instead) when you're pushing the game display so hard that you're in danger of bumping up against the system limits - it's not a factor in most games. When you're pushing the limits of other consoles, you also need to be sure you're not exhausting the resources involved. Even the NES! 😱

 

But by all means, confirm your bias again!

[zzip]

2 minutes ago, RevEng said:

You only need to do that when you're pushing the game display so hard that you're in danger of bumping up against the system limits. When you're pushing the limits of other consoles, you also need to be sure you're not exhausting the resources involved. Even the NES! 

I know this, but I keep getting told it doesn't apply to 7800

 

As for bumping the system limits:   Xevious was a 1982 arcade game, it should not require bumping the limits of a true late-80s console.

[RevEng]

31 minutes ago, zzip said:

I know this, but I keep getting told it doesn't apply to 7800

 

As for bumping the system limits:   Xevious was a 1982 arcade game, it should not require bumping the limits of a true late-80s console.

Who told you that the 7800 doesn't have resource limits you need to not be careful of exceeding?!? Citation, please.

 

NES didn't manage an arcade-perfect Xevious port either - it looks worse than the 7800 port from my perspective - despite your pet theory about it being easier to get amazing results from the NES without difficulty. It's almost as if dedicated arcade hardware from 1982 could push console tech from 1984 to the limit. So strange.

[Jetboot Jack]

41 minutes ago, zzip said:

I know this, but I keep getting told it doesn't apply to 7800

 

As for bumping the system limits:   Xevious was a 1982 arcade game, it should not require bumping the limits of a true late-80s console.

Please - don’t make such silly statements…

 

The Namco Galaga hardware was more powerful than any 8-bit home console be it 7800 or NES - they have a single 6502 (or variant) and a tiny amount of RAM…

 

Whereas the arcade board has three Z80’s each at 3mhz for a start - and whilst it’s not super flexible it can move lots of sprites and tiles very quickly…

 

sTeVE

Edited October 23, 2023 by Jetboot Jack

[zzip]

1 minute ago, RevEng said:

Who told you that the 7800 doesn't have resource limits you need to not be careful of exceeding?!? Citations please.

Scroll back in this very thread.   I was told that even 320 mode is easy on 7800 despite all threads created by people struggling with it and a relatively small number of games making good use of it.   No advanced programming required unlike other systems.    It's just lack of spending that caused inferior 7800 ports.

 

34 minutes ago, RevEng said:

NES didn't manage an arcade-perfect Xevious port either - worse than the 7800 from my perspective - despite your pet theory about it being easier to get amazing results from the NES without difficulty. It's almost as if dedicated arcade hardware from 1982 could push console tech from 1984 to the limit!

NES is a 1983 console.    The SMS (1986) has a much more arcade-like Xevious.  Atari didn't need a 1984 console.   The 5200 hadn't even been given a chance to shine.   They couldn't even get it out the door in 84!   I would have rather seen an improved 8-bit console later in the 80s or a 16-bit console

[RevEng]

15 hours ago, zzip said:

Scroll back in this very thread.   I was told that even 320 mode is easy on 7800 despite all threads created by people struggling with it and a relatively small number of games making good use of it.   No advanced programming required unlike other systems.    It's just lack of spending that caused inferior 7800 ports.

Defender_2600 commenting about cycles being something that had to be checked for Xevious in 160B mode literally didn't have anything to do with 320 mode at all. And before you infer some grand weakness, 320 mode doesn't use more cycles than 160 mode - 320 trades color for resolution, not cycles.

 

The fact that you're paraphrased what I've said as "even 320 mode is easy on 7800" and "no advanced programming required unlike other systems" is either delusional or a bad faith strawman. Since you decided to mischaracterise what I said, rather than cite, I guess I'll need to do it myself...

On 10/19/2023 at 5:06 PM, 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.

On 10/19/2023 at 6:52 PM, 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.

 

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

On 10/20/2023 at 12:04 PM, RevEng said:

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.

Show us on the doll where the 7800 console touched you.

[+Defender_2600]

On 10/10/2023 at 6:16 PM, zzip said:

I think it would be better if they told GCC to go back to the drawing board refine the design for an eventual 5200 successor in 86 or 87--

 

On 10/20/2023 at 12:37 AM, zzip said:

 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.

 

12 hours ago, zzip said:

NES is a 1983 console.    The SMS (1986) has a much more arcade-like Xevious.  Atari didn't need a 1984 console.   The 5200 hadn't even been given a chance to shine.

 

The small 5200 library shares many titles with the 2600 that have similar graphics to each other and you might even prefer some 2600 version for the clean style, a more appropriate palette and more colors on screen (e.g. Activision). The 2600 had a huge library, and innovative games were still being released in 1984 as Pitfall II, H.E.R.O., Crystal Castles, Decathlon, Mr. Do!'s Castle, and other. Also, the 2600 had many controllers: CX40 joystick, paddle, driving controllers, Trak-Ball, keyboard, Video Touch Pad, Control Pad.. and they all worked very well. So, maybe "Atari didn't need a 1982 (1979) 5200 console".

 

Imitating your sterile propaganda, we can say that the 5200 was two steps forward (background graphics and sound) and three steps back compared to 2600 (number of colors on screen, controllers, library). And again, the 5200 should be better in every way than the 2600 and it isn't. So, could the 5200, a repackaged Atari 400 (1979), have competed with the C64 and even with the NES until 1986/1987? Lol.

 

By the way, for example, the 7800 has sprites with 12 colors, so it's 12 steps forward compared to 5200 which has monochrome sprites... and I was forgetting, how many sprites does the 5200 have? 4 + 4 missiles? Are you comparing this to the 7800 which can display over 200 sprites on screen? And the SNES, which has the same low horizontal resolution as the NES (256 mode) had to go back to the drawing board because it was a step back compared to Sega Genesis which can use 320 modes? And who decides? You? Lol.

 

This discussion has truly reached the point of ridiculousness. If you really want to understand how the 7800 works, then start studying instead of continuing to ruin your reputation.

 

7800 Eighty-Six Sprites + full background by RevEng:

https://raz0red.github.io/js7800/?cart=https://forums.atariage.com/applications/core/interface/file/attachment.php?id=1054377&key=dc5b1dc081a9dae418a6682e44407568

*(if it doesn't play music, hit the reset button - some browsers mute sound until you interact)

 

12 hours ago, zzip said:

The 5200 hadn't even been given a chance to shine.

Sure, look how the 5200 can shine compared to the 7800, same modern Homebrew game, same resolution, no excuses:

 

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

 

You wrote: " I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history." Well here it is:

 

 

 

 

 

 

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

 

 

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

 

P.S. "The Micro Xevious" is an unlicensed Sega Master System game released in South Korea. It is absolutely not faithful to the arcade version and technically poorly made.

[Bakasama]

Looking at these mock-ups give me the impression that the 7800 can do 5200/8bit graphics with ease, with more colors and sprites.

 

I’m still trying get how 7800 graphics work, I get how 2600 draws per scan line with very little RAM and how CPS2 and Neo Geo draws their sprites, more or less. The 7800 seems be a real beast with sprite handling.

[+Defender_2600]

3 hours ago, Bakasama said:

Looking at these mock-ups give me the impression that the 7800 can do 5200/8bit graphics with ease, with more colors and sprites.

 

I’m still trying get how 7800 graphics work, I get how 2600 draws per scan line with very little RAM and how CPS2 and Neo Geo draws their sprites, more or less. The 7800 seems be a real beast with sprite handling.

 

The 7800 is completely different from all other 8-bit consoles, in fact it was designed and works like an arcade machine. Regarding all the images shared in the post above, they all show real games, including 7800 Bomber Hero WIP.

 

P.S. I checked, the arcade version of Xevious has 2bpp background graphics, so for the 7800 version it is not necessary to use 160B 4bpp mode. You can find a 7800 Xevious version with updated colors here.

 

 

[RevEng]

On 10/24/2023 at 1:38 AM, Bakasama said:

I’m still trying get how 7800 graphics work, I get how 2600 draws per scan line with very little RAM and how CPS2 and Neo Geo draws their sprites, more or less. The 7800 seems be a real beast with sprite handling.

If it helps, you can conceptualize Maria's operations in a couple of ways. Both are accurate, but depending on your understanding of other systems, one may resonate with you better than the other...

 

First, you can think of Maria as a soft-sprite accelerator on steroids. You hand it a list of sprite (and character) parameters (graphic data location, x, width, palette, mode) and it runs through the list and composites all of the sprite and character bitmaps for you. There's another level of detail to this explanation, due to the fact that Maria only has two on-chip scanline buffers. (one buffer is used for displaying the current scanline to the TV, the other used for generating the next scanline coming) Maria's bitmap compositing happens on a scanline by scanline basis, so you need to give it multiple parameter lists (aka Display Lists) covering different horizontal strips of the screen.

 

Second, you can think of Maria as a blitter chip, only unlike other blitter chips it doesn't run in parallel with the cpu. Instead it halts the 6502 when it needs the bus, and copies over graphics data at 4x the normal 6502 clock. (with no time wasted fetching opcodes or processing loop logic, like the 6502 would need) The extra level of detail I mentioned earlier, about Maria having a scanline-buffer, applies here too - the blitter operation is repeatedly triggered for each scanline prior to it being displayed by the TV, rather than the singe blit to a full-screen ram destination you might see in other blitter implementations.

 

It's worth pointing out here that one of the explicit GCC design goals was for the console to run Robotron well, and the Robotron arcade game has a blitter chip for compositing graphics. (as does Joust and Sinistar)

[zzip]

13 hours ago, Defender_2600 said:

The small 5200 library shares many titles with the 2600 that have similar graphics to each other and you might even prefer some 2600 version for the clean style, a more appropriate palette and more colors on screen (e.g. Activision). The 2600 had a huge library, and innovative games were still being released in 1984 as Pitfall II, H.E.R.O., Crystal Castles, Decathlon, Mr. Do!'s Castle, and other. Also, the 2600 had many controllers: CX40 joystick, paddle, driving controllers, Trak-Ball, keyboard, Video Touch Pad, Control Pad.. and they all worked very well. So, maybe "Atari didn't need a 1982 (1979) 5200 console".

 

Imitating your sterile propaganda, we can say that the 5200 was two steps forward (background graphics and sound) and three steps back compared to 2600 (number of colors on screen, controllers, library). And again, the 5200 should be better in every way than the 2600 and it isn't. So, could the 5200, a repackaged Atari 400 (1979), have competed with the C64 and even with the NES until 1986/1987? Lol.

5200/8-bit graphics were showing it's age by 86/87,  and that would have been the right time frame to replace it, not 1984.    But the geniuses at Atari decided to give us the XEGS instead.

 

As for what you consider a step back with the 5200:    5200 can put just as many colors on screen, and you can count cycles if necessary to increase horizontal colors and get 2600-like effects.   But the addition of a frame buffer makes graphics easier and you don't have to "chase the beam".   

 

The small  5200 software library is not a function of the hardware (but it is a function of the decision to kill it early).   Controller is the only actual hardware issue you meantioned, but Atari could have released revised, more durable controllers instead replacing the whole console!   It's not like they got the 7800 controllers right either.

 

13 hours ago, Defender_2600 said:

By the way, for example, the 7800 has sprites with 12 colors, so it's 12 steps forward compared to 5200 which has monochrome sprites... and I was forgetting, how many sprites does the 5200 have? 4 + 4 missiles? Are you comparing this to the 7800 which can display over 200 sprites on screen? And the SNES, which has the same low horizontal resolution as the NES (256 mode) had to go back to the drawing board because it was a step back compared to Sega Genesis which can use 320 modes? And who decides? You? Lol.

I've said before that the sprite chip is the only impressive thing about the 7800, but it still suffers from horrible sound and dated-looking 160-width graphics in most games.   I'm not saying the 5200 is better, just that the 7800 was not enough of a generational leap to replace it, and not enough time had passed.   I'm sure there were a lot of pissed off 5200 owners who vowed to never buy another Atari system after that stunt.  

 

As for 256 vs 320..   Remember that we are pushing up against the limits of CRT TV resolution here.   My feeling is a 16-bit system like SNES should be able to hand 320 resolution with a decent sized color palette.   But I can see how that would be a struggle for an 8-bit system with limited screen memory so 256-width is a fair compromise and many non-Atari systems took that approach.

 

14 hours ago, Defender_2600 said:

You wrote: " I'm judging it by its overall commercial library (the stuff that makes or breaks it) and its place in history." Well here it is:

 

I'm not sure what your point is?   Cherry pick the best-looking 2600 games and compare to 5200?   We all know what the reality was,   compare popular games like Pac-man, Donkey Kong, Zaxxon, Joust, Moon Patrol, Montezuma's Revenge,  Crystal Castles between 2600 and 5200/8-bit counterparts and it is night and day.

 

Or are you judging the 5200 by it's small library?  Again it would have been much bigger if it hadn't been killed so soon.

[zzip]

17 hours ago, RevEng said:

The fact that you're paraphrased what I've said as "even 320 mode is easy on 7800" and "no advanced programming required unlike other systems" is either delusional or a bad faith strawman. Since you decided to mischaracterise what I said, rather than cite, I guess I'll need to do it myself...

I don't purposely strawman,  but below are things you said when I said that 320 modes are difficult to use in games (and in some of these quotes you were strawmanning my argument)

 

Quote

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.

Quote

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.

 

on why Galaga uses 160 instead of 320

Quote

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.

Quote

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.

 

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.

 

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.

 

 

So if I summarize those statements as 320 mode is easy and advanced programming is not required,  it doesn't seem like I'm that far off base, because every time I say otherwise I get challenged
 

[RevEng]

On 10/24/2023 at 12:49 PM, zzip said:

So if I summarize those statements as 320 mode is easy and advanced programming is not required,  it doesn't seem like I'm that far off base, because every time I say otherwise I get challenged

Only that wasn't the entirely of your claim...

On 10/23/2023 at 4:31 PM, zzip said:

Scroll back in this very thread.   I was told that even 320 mode is easy on 7800 despite all threads created by people struggling with it and a relatively small number of games making good use of it.   No advanced programming required unlike other systems.    It's just lack of spending that caused inferior 7800 ports.

I made the statement that 320 mode on the 7800 isn't difficult on the 7800. You just need to take the time and learn the rules, and that's no different than any other system of the era. That doesn't merit a summarising of  "320 mode is easy on the 7800" without my qualifications. It's a stupid statement without qualifications, because it's not easy for children or animals. Using 320 modes would not be difficult for a professional game programmer in the 80s, because they're already need to work within rules for systems they know, and it's the same situation here.

 

Then you add the "unlike other systems" claim, which is the complete opposite of what I've been saying all along. I'm moving on from this meta discussion, because now you're not only dropping salient points from my posts, you're now dropping assertions that you yourself made as you try to defend statements. Life is too short for these kinds of games.

[zzip]

18 minutes ago, RevEng said:

I made the statement that 320 mode on the 7800 isn't difficult on the 7800. You just need to take the time and learn the rules, and that's no different than any other system of the era. That doesn't merit a summarising of  "320 mode is easy on the 7800" without my qualifications. It's a stupid statement without qualifications, because it's not easy for children or animals, and nobody was saying that. Using 320 modes would not be difficult for a professional game programmer in the 80s, because they're already need to work within rules for systems they know, and it's the same here.

Maybe the right way to say it is the 320 modes are easy in that anybody can draw pixels on the screen in them,  but hard to use if you want a lot of color variation with your hi-res, which is why most games avoid them except for maybe text portions of the screen.  When I saw hard, I'm talking about the latter. 

 

The part you say about knowing the rules applies to any system out there.   A person who's only done framebuffer graphics is going to struggle with a system like the 2600 where you have to race the beam.   Once you'd learned the concept and had practice, it becomes second nature,  in fact you might start thinking it's easy.    I think it's likely you and Defender_2600 hit that point with the 7800, because whenever I search for information on the 7800 graphics modes, literally the bulk of what I find is threads from people struggling with them, including advice to not bother with 320 modes at all.

[Jetboot Jack]

14 hours ago, zzip said:

Maybe the right way to say it is the 320 modes are easy in that anybody can draw pixels on the screen in them,  but hard to use if you want a lot of color variation with your hi-res, which is why most games avoid them except for maybe text portions of the screen.  When I saw hard, I'm talking about the latter. 

 

The part you say about knowing the rules applies to any system out there.   A person who's only done framebuffer graphics is going to struggle with a system like the 2600 where you have to race the beam.   Once you'd learned the concept and had practice, it becomes second nature,  in fact you might start thinking it's easy.    I think it's likely you and Defender_2600 hit that point with the 7800, because whenever I search for information on the 7800 graphics modes, literally the bulk of what I find is threads from people struggling with them, including advice to not bother with 320 modes at all.

Have you actually made a game or developed any software to final release on more than one system - if so you would realise the "issues" you keep raising are not issues.

 

Believe me there are SO many weird and fun hardware configurations across all hardware generations - as a developer you are always learning, always adapting and evolving, and if you can't you go do something else!

 

I have never found a hardware platform I could not understand in a few weeks of effort - and I have been developing games commercially since 1987, and still do - so 36 years of change 🙂

 

A line buffer display is no more confusing or difficult (in fact easier) than juggling a multiplexer to maximise hardware sprite usage and nothing compared to PS2 cell processor optimisation - although I do find current gen hardware (in fact the last couple of generations) with it's PC like architecture delightfully straightforward...

 

sTeVE

[zzip]

3 hours ago, Jetboot Jack said:

Have you actually made a game or developed any software to final release on more than one system - if so you would realise the "issues" you keep raising are not issues.

Yes I have, I've created games on four platforms,  non-game software on a few others.

 

4 hours ago, Jetboot Jack said:

Believe me there are SO many weird and fun hardware configurations across all hardware generations - as a developer you are always learning, always adapting and evolving, and if you can't you go do something else!

 

I have never found a hardware platform I could not understand in a few weeks of effort - and I have been developing games commercially since 1987, and still do - so 36 years of change 🙂

I never said it can't be learned.   A few weeks and some practice sounds about right for most hardware schemes.   I don't think the struggles around the 7800 having are about being hard to learn, it's more about getting the desired results out of the 320 modes.   I have the 7800 documentation, and can see the restrictions around colors and DMA usage and why people would give up and go back to 160 modes as many 7800 games did.

 

4 hours ago, Jetboot Jack said:

A line buffer display is no more confusing or difficult (in fact easier) than juggling a multiplexer to maximise hardware sprite usage and nothing compared to PS2 cell processor optimisation - although I do find current gen hardware (in fact the last couple of generations) with it's PC like architecture delightfully straightforward..

learning the mechanics is one side of it,  but there's also the creative aspect.   If my code has to spend time counting cycles to make something happen on screen at just the right time,  then I might have a hard time finding the space for the logic for all the game mechanics I had hoped to put in the game loop.   So that kind of coding becomes harder in that respect than when I don't have to worry about how the screen gets drawn.   Modern hardware is nice that you don't have to worry about color placement or sprite limits or anything like that so that's where I've spent most of my time, but I did go back and start working on an Atari 8-bit game recently for old time's sake.

[+Defender_2600]

[Zonie]

Two pages of this.  Ughh...