Hi pals!
I was playing around and I got this. But I was wondering... Is it a valid atari 2600 mockup?
[edit]
Some more:
First I must compliment your excellent work, very nice. However to answer your question, no its not valid for the 2600. I think it could work on a 5200 but it would be tight, so let's say "as is" would be Atari 7800 valid.
Actually most of it could be rendered on a 2600 with careful layout structures but nothing could overlap vertically without severe amounts of flicker since the sprites per scanline limit would exceed if anything moved. So maybe a cutscene storyboard at this graphics standard (EG. Centipede 2600 title screen versus in game graphics.)
edit.
Your color distribution is very good as the deep shadows work well and the instances of differing colors using Background color bands with Playfield holes should work with deliberate vertical scanline isolation which most of it does incorporate already.
Most of my edit deals in utilizing the Playfield resolution solely for your level graphics as the overall scale of the game sprites and the amount of vertical scanlines they occupy in total don't really allow for the use of Player object based tiles for finer detail as the 2 Player objects and there Missiles are completely occupied with the player and enemy sprite rendering. On 5200 and 7800 especially there is more leeway since you have more sprite objects to dedicate to "extra" tasks.
It probably wouldn't be too troublesome to multiplex the Player objects for the 57 numeral, the lighting fixtures, and the bottom screen hanging cables from the Player objects as the game sprites are less likely to vertically overlap with ceiling sprites or sprite zones separated by an unbroken ground line. As soon as Clarke jumps the 57s would most likely clip just to maintain his flicker stability jsyk.
Also you have exceeded 192 lines of vertical resolution which will burden the CPU more which lessens how much change you can invoke per each frame render, things like color changes per scanline and complex sprite kernels will become hard to impossible to get within CPU budget. Although I like 192 or 1 line kernel as a standard its very hard to achieve and maintain on average that exceeding 192 will only work with much more graphically simple games than this.
edit.
Sorry its crude since I just rescaled it but it does demonstrate what would be needed to achieve this size of image on the 2600 which is quadruple wide pixel standard as much of it can be rendered with the Playfield with the remaining smaller 4 pixel wide segments made from any and all applicable sprite objects. If you want it double wide pixel resolution using this style of image you're limited to 48 pixels of width or the Title Kernel Screen standard.
edit.
I'm afraid your sprites are just too big for a 2600, even if you multiplexed both Player objects 3 times max per game sprite the degree of flicker would be very high and there wouldn't be enough machine (CPU) cycles left after to do much else. The more you push each sprite object beyond there defaults the more expensive and unstable they become to render effectively.
Based on trying to maintain the size of sprite used in this mockup the following setup could work:
-Both sprites would have to share the same colors per scanline since they would be sharing color paired objects primarily the Missiles. Because of this I'm thinking a single color would be recommended as multi-color would be hard to achieve unless you prioritize Clarke and just let the Necromorphs scanline colors "twinkle" as Clarke animates.
-The Clarke sprite would be Player0 & Player1 paired together with a 3rd block multiplexed to the right to get the held gun extension. By pairing them and having both objects share the multiplexing duty of rendering the 3rd block the degree of flicker can be reduced to "reasonable" levels.
-The Necromorph sprite uses Missile0 & Missile1 in a low res bitmap manner which varies width per scanline and utilizes Missile copies and there respective color clock tile gaps. While this produces a rather blocky sprite compared to Clarke I thought the alien or monster like qualities could excuse its crudeness.
Also one monster fight at a time or 2-3 monsters of the same type moving in unison.
-Clarke's projectiles would likely flicker since they would have to be multiplexed Missiles which are already rendering the Necromorph. The projectiles would have to be less stable visually to maintain the Necromorph pixels. The problem with using the Ball object as a projectile isn't its lack of multiplexing since a vertical scanline offset per fired projectile would work but rather its that the Ball shares the same color as the Playfield so it get masked.
I'm just spitballing but it might be possible to use a Playfield rendered projectile which omits a pixel creating a hole in the graphic that a Background color line could show through which moves across the screen, kind of like a moving inverse 2600 Pac-Man pellet. Besides the CPU overhead it would kind of be fast moving as it jumps 8 pixel widths.
-Although not used in my edit the Ball object is free to draw one extra detail in the Playfield per vertical scanline zone. It can't do much but varying the width per scanline could form an interesting shape.
Anyway if you want more detail you'll have to go smaller in scale with more isolated individual floors to leverage your sprite objects further since a single floor or level limits what you can do IE. small number of sprites over a small area versus a few sprites over the entire screen.
As far as sprite size it starts out simple enough expanding past 8 pixels of screen width to a moderate size then it gets troublesome to achieve for medium scale sprites before getting easy again with giant blocky Playfield sprites.
Based on your mockup and my edits this would likely be challenging to make on the 2600, I won't lie that an experienced 2600 programmer might say maybe while a 2600 programming novice would say yes but it would take a while, need much assistance, and they would be exhausted afterwards.
It's up to you how you want to proceed since you could make it a 7800 game or with a few small changes could turn your mockup into a very respectable C64 game.
