BladeJunker

Is there any chance multiple difficulty settings are possible since that would satisfy both camps and give those switches on the 2600 console some much needed use.

Darn I thought that might be the case before I started but oh well 4K is a interesting challenge in itself. So 7-10 levels, I guess that sounds good too.

I think it controls very well but the death from lack of scroll down and the fall out of the world deaths are kind of frustrating, although I was never a big fan of bottomless pits in the platform genre but I'd lose one of those difficulties. I figured I'd throw some Playfield patterns at you Jan to possibly dress up your cool game. I based them on the platform block dimension you appear to be working with, Cheers.

Thought I'd throw another style that will likely work with this type of rendering. This one is ANSI based, I included a few pattern swatches at 3 resolutions at the bottom but went with Playfield based blocks for the main image simply based on a trim image format. It should be said this is not my piece, I just found it with Google Images. ^_^

Funny I called the genre Frenzy and forgot that the Berzerk sequel was called Frenzy so I switched this games title to Frantic. Anyway just experimenting with 3 bit wide enemies changing bit width per scan line to get some less blocky shapes. Avoided changing bit width mid scan line but my gorilla guy broke that rule. Things are more Halloween than Sci-Fi lately, probably all the Real Ghostbusters cartoons I've been watching lol. Decided to add vertical color zones into the Playfield instead of one default color even though the player sword will switch color but I think the larger graphics take precedence over the smaller bit graphic. Also added acid pools as a hazard but other stationary traps are possible too using the Playfield like spikes or trapdoors.

Can not, should not is an odd statement to make sir. As far as resolution admittedly the VCS doesn't have much but that doesn't mean you can't setup basic rendering frameworks based on those 6 objects with set limits that anyone could work within regardless of programming skill. I would never suggest anything high fidelity but many art styles are possible with even this most basic rendering. True the VCS is the most basic graphics and sound generator possible and yes everything is generated as you play it. However only a perfect individual has the right ratio of left and right brain thinking to get the most out of the VCS visually with good gameplay like David Crane did with Pitfall. Mostly its just that those people are one in a million or maybe even a billion that you can't depend on it to create popular content to grow interest in a gaming platform. A beautiful sentiment based on some hard facts but I think the poster of this subject is looking for ideas to increase the likelihood of homebrew projects actually getting published, with everybody getting payed so more can be made now and into the future. What you suggest will only lead to an ever decreasing VCS legacy since much like legions, churches, or other clubs you can't have a syndicate without a population.

Dude the one man show is what we already have and the programmer isn't going anywhere he just becomes part of the team structure in what I propose. "The Right Stuff" mentality will only lead a tiny group of elite 2600 programmers that will likely fade away in the future as we all do. I've seen programmers collaborate very well on this forum but are the rest of us stuck being cheerleaders chiming in with nothing more than compliments and well wishes. I acknowledge the nature of 2600 programming being singular in nature in that it will naturally gravitate to that. My suggestion of adding more disciplines is actually one that will require effort to nurture not an easy task nor one that will take off easily so you have nothing to fear. Again I think basic training on how a 2600 operates is essential to homebrew but realistically you will not garner many new people to add to the fold with exclusion of any kind. Every medium has its fair share of mediocrity it goes with the territory of having a "popular" subject matter.

Well here's my 2 cents. Other than an eccentric billionaire who funds 2600 homebrew projects are dependent on enthusiasts which has been mentioned is a minority usually older, employed, and quite frankly too tired at the end of day. From that standpoint our classic gamers need to take better care of themselves so they have more energy and can schedule at least an hour to dedicate to 2600 homebrew every day or at least every week. As a crusty old dude in the making myself this doesn't seem likely. The next best scenario is to create new enthusiasts but that is dependent on bringing people in besides programmers, by that I mean pixel artists, musicians, and game designers. While the idea of a one man author is romantic and intrinsic to the 2600 hardware it shrinks the overall talent pool down significantly to just programmers with an interest in the 2600 which is again a minority. This is what separates a 2600 game developer from all other platforms in that you can barely contribute unless you can actually write a kernel which isn't the case on other platforms. For example John Carmack when he coded the Quake engine gave the artists tools and a set of asset properties to conform to when building the models and textures, he didn't have them build paint programs, modeling programs, or define the 3D model vertices manually from the ground up. I'm not a programmer, musician, or much of a game designer so all I can really talk about is pixel graphics but I'd say the tools are lacking to bring new people into the fold. Please don't think I dismiss all the work people have already put into tools for Playfield editors or Player sprite editors but I'm just saying they could be much better. Artists still draw 3 color Nes or C64 sprite designs and mockups on pixel art forums but most of them don't even want to try 2600 pixel work. I have some specific tools and rendering standards in mind but this isn't the post for that and I think I made my point. If any code savy enthusiasts want to collaborate on some tools message me.

"I'm no programmer and 52 shitty games", you're stealing my lines. ^_^ Sure the Harmony cart is a possibility and yes it isn't cheap but there is always the option to sell to Harmony cart owners if A52 were an SD card with SD cards being relatively cheap. As far as cartridges as in actual 2600 cartridges the physical cost is always there whether you make 4K or 32K roms so I consider that a moot point to the big picture. I see what you mean about the external hardware aspect needed for 52 games as the 2600 really only handles one game at a time so a bridge is necessary. As far as the "not likely" aspect you mention, the entire forum is full of pipe dreams, hobbies, and half finished projects so I don't think that matters. I'm not saying homebrews don't happen but the singular intimate nature of 2600 programming tends to stymie very much in the way of collaboration as a whole with everybody doing their own thing.

Very nice! Although the name of the "company" is AtariAge Enterprises, but whatever. Whoops sorry, I'll remember that for all future company listings. AtariAge Enterprises is a great name.

Although mundane I thought I'd address the menu design. I have fancier designs but I don't know where or how much space would be dedicated to the front end menu so this submission is simple and compact. Mostly just tried to make it easy to read.

Well I got a bunch of things brewing but I thought I'd post something based in "frenzy" based gameplay simply called Frenzy lol. It's mostly based around the needs of the genre IE throw a bunch of crap at the player to fight versus what the 2600 can do. Player0: Player Player1: Civilians Missile0: Enemy A Missile1: Enemy B Ball: Player Weapon Playfield: Enemy C, Buildings I guess I describe the game as Robotron with a sword rather than a gun since the Player projectiles are used to generate the enemy sprites. As mentioned the enemy are Missile segments which are made with skipped scan lines so they can be staggered and multiplex further than they could if they were solid shapes, I'm sure they'll flicker anyway but mostly just trying to keep as many on screen without clipping or disappearing completely. Whether a single shape or animated they will need kernels to define them. Also varying the 2 enemy types per stage could help keep things interesting. The Ball acts as the player's weapon probably a plasma sword with its bright color. The enemies just run into you as attacks while the player runs to avoid or stands and attacks by holding the button and press 1 of 4 directions for different attacks. I'm sure some sort of joystick tap based combo system could be made. Civilians just stand and wait since they aren't so much fodder but rather guarded by enemies since the player slaps a transporter badge on them as a means of rescue. It was this or have them flicker as independently moving units or move about the screen in unison. I'm thinking of varying them per vertical zone for variety sake mainly male to female. There wasn't much I could do with the Playfield other than do Fireball lanes and a giant snake that move across the screen vertically. While simple this should add to the overall frenzy of things thrown at the player. I also thought maybe of adding enemy generators and the occasional wall like just for variety sake. The Playfield will have to be asymmetrical for the sake of using each Playfield segment independently but tiling or flopping the segments can be taken advantage of. The HUD is Playfield based mostly to generate the characters needed for the Score and number of Civilians rescued. The rules of the game are wide open to anyone willing to program this engine as I can't take it any further till someone tries it out or at least assesses its plausibility. Logan

I was looking over your change and thinking it could be pushed further by tilting the backward leg up using 2 Missile bits and extend the arm out with 1 Missile bit since the Missile bits would be on different scan lines. Man I'd love to play Renegade on the 2600, well any brawler really since Double Dragon wasn't so hot. ^_^

I like the sound of that, it has a nice ring to it.

Okay I added a score gauge but had to change SHOTS to a bullet icon.

Here's a translation or mockup of Shootout from the Genesis Action 52 collection. Anybody with some skills seeing this please try coding this.

Just thought I'd add a different style image without outlines sort of a South Park look that might work also under this rendering setup. I broke it down into width segments just to give options as I'm not sure which object renders what.

Well here's a vertical scrolling shooter mockup I call Space Maniac. Avoid banging into the walls, shoot flying saucers, collect powerups, and rack up a high score. HUD: Maniac icon=Both Player objects. Health Bar= Playfield with a few Ball related bits. Score=Missile0 & Missile1 rendered characters with skipped & staggered scanlines. Game: Maniac ship=Player0 sprite center flopped. Maniac bullets=Missile0 Enemy ship=Player1 sprite center flopped. Enemy bullets=Missile1 Explosions=Missile0 & Missile1(Stop bullet generation and start explosion rendered bits.) Space stations=Playfield+Ball bit edge smoothing. Powerups=Playfield+Ball bits. I included skipped scanlines and staggering in the bullet and explosion based sprites in the hope that it would help reduce clipping or flicker of multiple sprites. Also did my best to highlight where and when and where extra bits and flopping are used. If you think it will work please take a stab at it as the last post under this topic had only a few entries before stopping.

The best bet for this idea is a generic engine much like the Nes version. Because of the particular limits of the 2600 and its specific optimization no single engine will facilitate every game type but that doesn't mean most games can't be distilled into a few select game engine types. Generic parameters: -Scrolling, this alone greatly affects what kind of game you make and requires different engines to be optimal. Single Screen=Space Invaders, Donkey Kong, Frogger, Pac-Man Page Flip=Adventure, Jet Set Willy Vertical Scroll= Frontline, Xevious (Relatively easy to do compared to horizontal scroll.) Horizontal Scroll=Defender, Empire Strikes Back (Usually very resource heavy to produce a smooth scroll.) -Genre priorities, each game has specific needs and methods. Shooter= Projectiles galore ie heavy Ball and Missile usage with line skips + scanline stagger or odd to even scanline flicker. EG. Take your pick Action52 had a ton, this can range from bullet hell Shmups to short limited bursts of projectiles like in Zelda. Frenzy= Sprites galore ie using the Ball and Missle bits to render more sprites than the default 2. EG. Lock N Chase, Robotron. Melee=A lot of horizontal attacking which needs Player object extensions made from Ball and Missile bits ie Roundhouse kicks, sword swings, grappling hooks. EG. Cheetahmen. Puzzle=Mostly just blocks or other rudimentary shapes so plenty of opportunity for optimization and or pursuit of art friendly rendering techniques normally too impractical for action games. Platformer=Mostly about solid collision and gravity simulation. EG. Mario Bros. Well that's all I got for this topic for now, I hope this helps anybody confused or intimidated on where to start such an undertaking. I like the idea and I hope it gets off the ground someday.

Okay I'm not understanding yet. By default don't we have 3 colors possible per scanline not including the Background, as in the Playfield+Ball, Player0+Missile0, and Player1+Missile1 which can be set independently per scanline. Also are we talking about stretched Player objects since I was planning on using the default 8 pixels of width but drawn to an appear like 4 pixel wide bitmaps so they match the Missile and Ball bits which are set to 4 pixels of screen width? So is this about cycle costs or are we both talking about different objects?

First thing thanks for converting it, nice of you to spend the time. I have seen Andrew Davie's Chrono Color technique, I think it is good for photographs but not optimal enough for stylized art or full screen imagery. I agree about keeping things as trim as possible but those very first 2600 carts were too small and tied the hands of the programmers back then. I've included 2 variations on the Mario, the first is Hyper Sprite based with a height adjustment for the Playfield wide pixels and the second is closer to my concept of Playfield color fill and 4 pixel wide edging pixels and tile blocks. Thanks again for your efforts.

I see what you mean about the colors, I kind of figured painting to my whims would exceed color capacity in certain image zones. So if I change the hair color to black could I keep the eyes black? Also are we talking absolutely not or could I keep brown if I'm willing to endure some flicker? On the issue of ROM size I'm not that concerned about it, I respect the amount of rendering capacity afforded by the 2600 pipeline(4K Max) since it can't be enhanced without adding additional hardware into the cartridge like Pitfall2 did. Given modern chip capacities I think we can afford to grow as large as we need in overall program footprint size compared to the original 2600 titles, after all David Crane has said on the record that he kept begging for larger ROMs back in the day(not that he got any) and 7800 developers had the same problem. Might as well relieve one limitation if we can. Believe me the lack of graphics power from the 2600 goes with saying but it is the most popular unit globally compared to the 5200, 7800, or Jaguar which have a lot more power. I would say games should be the primary focus of 2600 programs but art and music should be a close second. I see your from Brazil, how is the weather down there?

Yeah I came across your post in my research some months ago, I liked your approach very good and catchy name Hyper Sprite. I've tried reading up on Batari etc. but I'm afraid I only understand maybe of 10-15% of your code example. I have a friend whose programming savy to try out some of my mockups but I just sent him 1 concept for now as he doesn't have much time for my projects these days.

Has anyone tried less than 48 pixel display as my intention is more strategic use of Player bitmaps instead of always using the maximum of 6 Player blocks multiplexed, that is bound to save some cycles for other uses such as color changes etc. I understand that the 48 pixel rendering is demanding on rendering speed so I'm trying to lessen its use to 16,24,32 or even 40 pixels per scanline. 30Hz acceptable, is that tolerable or barely visible? ^_^ You mention being able to change everything per line with enough cycles, does that include stretching the Player object. Also does the nullified Missile tradeoff from stretching the Player object apply regardless of scanline or can its effect be contained within a set amount of vertical screen resolution? Thank you for your info, its most helpful.

I do know that both missiles can copy 3 times by default and the Ball has no native copy ability but if you race the beam how far can you push these 3 objects in terms of copies. To add some context to my question I'm just looking into larger full screen and more heavy multicolor use on the 2600 for title screens and or art slides in the same vein of the C64 pixel art scene. The hope is a 2600 Paint type program to give pixel artists something to screw around with so here's a run down on how each object is used and object options. Background: Canvas Playfield: Bulk Fill tool. Player0: Tile bitmap. Missile0: Line tool Player1: Tile bitmap Missile1: Line tool Ball: Line tool Object Options= Background: Color set. Playfield: Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line). Player0/Player1: Tile Repeat, Tile Multiplex(2-3 Max), Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line). Missile0/Missile1/Ball: Odd to Even scanline stagger, Odd to Even scanline flicker, Width Adjust, Color Change per scanline, Pixel thickness per scanline(1 Line, 2 Line). I know that stretching either Player object cancels its corresponding Missile from use but is that effect global or just per scanline, can you stretch one Player object differently per scanline? If not dedicating one Player object to stretch use can be used in conjunction with a multiplexed non stretched Player object. If any of this works I have doubts of it being practical for real-time use on actual hardware but perhaps an external program with a trimmer more compressed format it would export for actual display purposes. Because of the technical limits I'd imagine a trial & error process in use such as composing an image, running it on a 2600 or Stella to see how much flicker occurs, and going back to revise or try it a different way. I'm including an example image of quality standards which is primarily made with 4 times wide pixels to maximize horizontal screen coverage. Its just a mockup since I'm pretty sure only one image could be displayed at a time but I wanted to show some variety. So any insight or collaboration on this venture would be appreciated.