BladeJunker

Seems scientific enough for me since you used actual math and exacting results doesn't seem possible given the properties of the hardware. Funny I've been using 800X600 as my test stretch resolution, had no idea it was ideal or most convenient when I decided upon it. I'm familiar with overscan, I was trying to make a 3D cross platform game for PC and console (PS2 & Xbox era) a while back, never finished it but I did learn about overscan standards. As far as retro height resolutions I was thrilled when VGA and SVGA came around and 320X240 became a standard since I never liked dealing with the stretch issues of 320X200. Also I always thought the C64 kind of overdid it with its overscan border. Anyway yeah 5:3 is a good standard. I'm getting used to that answer when learning about the 2600 lol. Actually from the start I concluded that I could have saved my self a lot of trouble and concentrated on 5200 or 7800 based graphics design but the 2600 is the trailblazer of the three systems. Still I kind of figured there would be a heavy cycle cost to pay and that the number of mid-line color changes would be extremely limited and have significant drawbacks otherwise I'd see more obvious examples of it everywhere. Okay you're basically saying the pursuit of more than one mid-line color change per line will result in even less Playfield resolution, weird widths where color changes actually occur, and a severe cycle and color clock costs. So what is the bad news. ^_^ I see what you're saying, mid-line color changes are better accomplished through graphics object overlays. Interesting to see that a Playfield pixel can be divided finer in color if not actual pixel resolution. From what I see of this greater degrees of mid-line color change in the Playfield may be worth pursuing for an art slide but it seems horrible for actual gaming purposes. Oh I always knew careful planning would be part of art composition on the 2600 but I like to know the full potential of every object and its functions therein. As far as the lo res 40X192 and the hi-res object limits that has always been regarded in this concept. I made my peace with the fact that a 2600 paint program would be unlike any other paint program ever made. Actually much of what I'm trying for is not so much more color but a more elegant alignment of the objects using the standard amount of colors per scan line, I know it seems like I'm trying for more at times but in the long run tricks or rendering gimmicks aren't as good as art techniques that fit within standard practices.

Sorry I meant to say any pixel 4 color clocks wide is Playfield and any pixel less than 4 color clocks in appearance would be either Missile or Ball set to 4,2, or 1 color clock in width and horizontally shifted to the intended position per scan line. Also don't forget about jutting pixels since the TIA rendering layers allow wider line segments to be mostly occluded where only a small portion is visible on screen which is great for creating odd color clock distances like 3 or 6 using 1 pixel bit instead of 2. Atari hardware, its a whole different language of terminology so I keep interchanging width values for pixels and color clocks at times and get confused lol. Since there are 2 portraits instead of 1 that complicates matters in regards to the copying and clock distances between Missile and Ball line segments so you'll have to flicker multiplex both sets of line segments just to get each into there intended respective horizontal positions on the left and right of the screen. Also to be more specific about the Player object use, each portrait would use Player blocks like a "tile" which you could position horizontally to places in the bitmap pattern where the limits have been met to what can be done with Missile and or Ball copying and there respective color clock distances. The safe route would be to limit it to one Player object per portrait varying the pattern based on a set vertical height res or the "lane/band" approach but you could try for 2 Player objects per portrait if you race the beam and multiplex the 2 objects into 4. Regardless if you try this setup for the character select screen you'll probably want to stick to a minimum of colors just to get the rendering kernel working before multi-color can even be considered.

I've just been trying out your conversion table and thankfully my approximation isn't too far from it which is a relief. I think in terms of level construction my approximation should suffice but for large compositions like my perfect circle and title screens your formula will save me a lot of time spent on my trial and error approach so thank you kindly for the handy guide.

Was kind of irked by the big scale of the placeholder test sprite so I tried a few different scales. The outline of the figure really starts to become less viable the smaller it gets so I'd suggest internal outlines as in the traditional 2600 sprite approach or multi-color shape separation to maintain character clarity. Hard to say which scale is ideal, however your plan to stick to average sized characters should help. Tried a background and even tried to draw some onlookers into the Playfield but they are so big they look like giants lol. I saw a T-rex in one screen shot which would be in proper scale if drawn into the Playfield. Still this should give you an idea how things could look under the setup I described earlier.

I think Pac-Man-Red had a thread about it too, something about using Paddle lines I think. Even 2 buttons would be good as one button is a real squeeze especially with combos lol.

Did a res scale test on a basic HUD and fighter sprite size. Used Ryu from Street Fighter Alpha on GBC as a placeholder, even that seems too big so I think you'll have to go very small in sprite scale to have enough room to manuver without a scrolling background. I hadn't tried 2-line sprite design before, its very tight.

Was thinking about fighting games and SFXT which I haven't tried yet but looked up since I checked out your posting. Anyway was screwing around with a character select screen based on the game trying to find a good distribution of rendering. It's not a complete mockup visually as its really about concentrating object use to do the most efficiently so don't take it too literal. I tried to get the spacing accurate but its so easy to misplace a bit when you aren't working directly with code. ^_^ -I tried exacting replication of the original menu but 2600 based rendering tends to favor vertical isolation of rendering zones thus the stacking. Also I think its safe to say you'll need an asymmetrical screen setup for the character select. -The character icon setup is one of non highlighted(Generic) and highlighted(Specific). Generic icons are rendered with Playfield and Ball which might be able to have a unique color with some tricks but will likely be the default menu border color. The Specific icon is Player0 & Player1 paired along with a couple extra color clocks made from there Missiles, mostly tried to cram as much drawing resolution into it for good legibility. -Used the Playfield to draw the menu border and the text within just for a cheaper render. Used vertical text just so it would fit more naturally. -Likely should treat the roster area of the menu the same as a HUD in coding as in a split of the screen. -Isolated the character portraits to there own vertical band so every object could be utilized. Used a width of only the first 12 bits in the Playfield register with the remaining 8 drawing half the menu column. Basically in the portrait any pixel 8 color clocks wide is Playfield, any pixel 4 color clocks wide is handled with either Missile or the Ball, and the Player objects(Drawn double wide but not stretched in hardware.) are used whenever the Playfield and Bits fail to render the intended bitmap pattern. Not very sure if multicolor is possible in the portraits even though I imply it but a mid-line color change in the scan line rendering of the Playfield should allow a unique color for one portrait, a change to the menu color, and ending on the second portrait color. Also I think the character name would likely need to be part of the portrait image as in drawn into it. Well even if it doesn't work as good as I think it will the basic concept of the setup should be sound and I hope you find it useful.

Figured I'd throw some examples up of mid-line color change paired with scan line color changes. Sort of modern art with some variations and one based on a T-shirt I saw. Still looking for feedback so holler at me.

Can't get it out of my head so might as well post an inquiry into mid-line color changes in the Playfield. -Can you use it in combination with color changes per scan line, if so is this a common technique in games or is what I'm seeing achieved in some other way(2 colors per line where the other color isn't the Background color showing through. EG. Checkerboard pattern.)? -In the game Party Mix the buildings look like mid-line color changes combined with a per scan line gradient using skipped scan lines at odd and even alignment, is that an effective means of optimization for this technique? -How expensive are mid-line color changes to rendering as a whole? -What would be a reasonable limit for mid-line color changes, 2,3,4, etc? -Does it matter where you put a mid-line color change within each Playfield column? Was mostly thinking it might be a good function to exploit in an Atari based paint program.

It sounds like a cool project and an ambitious one too for your first 2600 game. I've been working on a fighting game design for the 2600 too so I'll give the 411 with some suggestions. -You'll want to forget about scrolling and just use a very wide panoramic background graphic. The majority of your graphics resources will be going into the 2 fighters. Also forget about background sprites unless you can draw them into the Playfield(EG.Onlookers/Ambient), better to spend your cycles on the player sprites and produce the best possible gameplay experience. -Stick to 2-line kernels for the fighters at least and consider thicker line rendering for everything else as you'll want fast smooth animation and fast gameplay responses. -Try to make the fighter sprites as small as possible sounds like an obvious statement but its very true. Try Street Fighter 2 on Gameboy and then try Street Fighter Alpha on Gameboy Color, much smaller sprites but way more fun to play and a better compromise for an 8-bit platform . The widescreen letterboxed background should help make the fighters appear proportionally taller than they are. -Standard 8 bit wide player objects won't cut it so you're going to have to use Missile and Ball extensions for any wide stances of the arms and legs. -You mention a directional based approach to fighter moves "Right or Left+Fire=Punch", I suggest using a Mortal Kombat setup to achieve the full fighter move set as it is an intuitive logical approach. Examples: *Down+Fire=Uppercut *Down Back+FIre=Roundhouse Sweep *Back+Fire=Roundhouse Kick *Forward+Fire=Forward Punch *Down Forward= Crouching Punch You'll also want tap and hold detection on the Fire button so you can tap for basic moves or hold Fire then perform a joystick move and release Fire to execute special moves. Well that's all I got, I wish you much success in your project.

This was just a correction of my past statement on the visual measurement without jutting considered so best to ignore this in favor of me agreeing with your setup of 4 color clocks and achieving the interim position much more cheaply in cycles than my original poorer setup. Got yah, 3 color clocks was mentioned as a unit of measurement not as a width setting for any object. Both circle picture examples use a top line width of 12 color clocks, 8 of those color clocks are filled by the 2 Playfield pixels with one on the left and right of the Playfields center, the remaining 4 color clocks are filled with the Missile and Ball set to 4 color clocks of width which jut out past the Playfield 2 color clocks of distance on the left and right side of the Playfield pixels. Thank you for your patience on this, my friend is a programmer and we spent many a conversation based on misunderstanding each other. Despite my best efforts at proofreading my responses I'm going to misquote terms and it will be most confusing at times but I'll do my best to correct this over time.

Okay poor choice of phrasing. I should have asked is one width for all Bit Objects used an efficient choice when making a kernel which it is according to what you've described. Sorry, sorry, sorry I messed up, I meant 2 color clocks. You are absolutely right that there would be little point in making the Bit Objects the exact width of a Playfield pixel. Right here is proof how confused us doodlers get, this is why an abridged translation description is needed for pixel art forums. Still what you describe about jutting pixels out sounds most useful and more efficient to producing maximum image crispness than using multiple width options. 3 color clocks, I keep forgetting that is an option, powers of 2 are ingrained in my brain. The top and bottom of the circle are 4 color clocks wide if we're just talking about half the circle before mirroring occurs? Darn I thought you might say that. No big loss, I'll just have to rethink this matter. Boy my math sucks lol, must be my painterly ways. I tend to just draw to draw pixels double wide as its hard to visualize at its native 50% width. I see now my choice to favor the width of the circle was wrong on account of the way an efficient kernel works per scan line, better to pad the width to achieve a "perfect circle". Still I saved off you formula and I'm going to go try it out. Well you actually answered most of my question higher up in this post, you can differ the line thickness per object but it makes the kernel less efficient overall. Good to see more options nonetheless. Again sorry as I meant 2 color clocks. However the 4 color clock option of jutting pixels has caused me to rethink things quite a bit.

So if I use only one bit width that would work better overall to the efficiency of the kernel. Ah a table that was the term I was looking for sections of predefined data. I lowered the resolution based on 4 CCs but I think all 3 bits are needed for the bottom and peak of the circle if Playfield and Bits differ in line thickness. Most of the exceptions to a circle kernel are found at the north and south end of the circle are related to the needs of a "perfect circle" primarily line kernel thickness versus the mostly vertical aspect ratio stretch. I test things for 4:3 in paint programs then measure and eyeball it to get equally wide and tall shapes but I did do the math once and it wasn't exactly a pixel divisible value lol, so I had to approximate. In an actual game I'd most likely oval the circle for a faster cheaper overall circle kernel but under this context I'm interested in differing kernels per vertical zone when needed to get an exact final result. I think also in practice under the original context of this posting being a paint program a circle tool would definitely bend towards efficiency for multiple circles instead of exacting dimensional sizes. Yes in this example the circle is centered, mostly sticking to symmetry to gauge kernel costs for shapes in general. And yes PL0 is not used in this example. Okay here's something I forgot to ask, can you set different objects to different line kernel thicknesses or is it a global setting for all objects when rendering occurs? Also in your opinion do you think 4 CCs would be the best standard width for bits being used for Playfield smoothing on the 2600, by that I mean would my original circle of maximum crispness or resolution be more appropriate on the 5200 or 7800? Thanks for your response, you're my savior, Logan:)

Thought I'd try breaking down a large circle into a visual description of its raw construction using Playfield plus Missile 0, Missile1, and the Ball. Looking for critiques on cycle costs and or possibilities for kernel optimization for primitive shapes like circles. More than willing to drop resolution if that will help make the overall setup cheaper in cycles. The foundation or bulk is a Playfield render using a 3-line kernel at 61 lines top to bottom. The edge bits pretty much switch between 1-line and 2-line kernels per scan line. There are 3 width options but only 2 possible widths per scan line per 2 objects with whatever bit that will line up correctly given the horizontal position needed. I've highlighted the bits for visibility sake but all objects would be set to yellow in an actual render. I'm still trying to grasp cycle cost overall but I thought it couldn't hurt to ask if this example would work and how costly would it be in ROM space and CPU time.

I've been working on that concept on & off for several months but its been hard to find a balance of the gameplay features (sprites) and the rendering limits on the 2600. I'd agree with Rex Dart that it would look something like Dig Dug in that the player carves paths through a Playfield graphic so the same basic engine concept as DD. I've mostly used Terraria as reference for what I'd like it to look like but its not as easy as it seems. I guess you could use mid-line color changes coupled with color changes per scanline within a Playfield graphic to create regions of different block material colors (Stone/Water/Gold) and use both Missiles set to Playfield bit width to make organic outer edges to those Playfield regions. The alternative to that would be a flicker based Interlaced Multicolored Playfield system like SeaGTGruff is working on which frees the Missiles up but has specific color restrictions to compensate for its visible flicker byproducts. I thought it might possible to do a lighting system based on clipping the Playfield using blocks of dither pattern but I don't have the know how to even try such an undertaking. I think it would be one of those situations where it would work but nothing else could be going on at the same time lol. The other major challenge is getting items, monsters, and the player rendering on the same scan lines on account of the customizing nature of the games environment. There is basic sprite work division as in Player0 is the Miner, Player1 is the monster, and the Missiles and or Ball are the items. With bit constructed sprites you can put some on odd scan lines and the other on even scan lines if you skip scan lines or use an alternating scan line renderer with some flicker to extend things a bit. For items I used a banded separation setup where tables, wall hangings, and lighting fixtures could only exist in there respective vertical positions within the "wall' height which is an example of a logical restriction. You can also use monster fiction to keep monsters at there respective vertical positions like vampires die in sunlight, slimes prefer dark caves, woodland creatues flee dark caverns, etc. If you ever take a go at it don't do what I did and try to make it pretty since Minecraft is more about function than beauty so stay true to that original spirit.

Yeah it is true that SECAM is a rather small regional standard, it has technical issues, and its the most ugly so yeah it would be an easy cut. Best left to a SECAM user to work on in the aftermath of a homebrew, they would have the equipment to test it after all. Now I never said the work for multiple kernels wouldn't be tedious work lol, I just think it would be the most optimal without saved settings. On slight flicker to PAL matters I'll bend to your expertise, you would know better than me. Thanks for the tip I'll look into the color concept of Boulder Dash, always looking to avoid flicker.

So this is what you mentioned about flicker based color additions, neat stuff and I hope you can get it to work as intended. It definitely is more work to for multiple kernels but there is a lot of variance between CRT, LCD, Plasma, and Stella. Its not just PAL, NTSC, or SECAM anymore, you could skip it but somebody somewhere will get left out of your awesomeness.

Since I broached the subject of tiles might as well discuss it a little bit. Although the 2600 Playfield only allows for 6 tile columns of four columns at 8 bits wide and two columns of 4 bits of width that should be sufficient enough to save some space using repeated columns. One unfortunate factor is the 20 bit register which reduces any space saved through tiles by 50% since every tile needs a mirrored copy because of the linear direction and order it reads bits. Of coarse center symmetrical tiles are possible as well with the tiling of the 20 bit Playfield with a supplemental overlay of Bit based walls like Adventure did that would get around that 50% loss but that will only work with certain game designs. We do however have much control over the vertical grid division with the "Infinite Vertical Resolution" the 2600 offers lol. I decided to take a pragmatic approach and assume that the greater the vertical splitting gets the higher in cycle costs such as system would use. So here we'll just look at each division option and try to predict there usefulness to games. First we have 6 by 1 which doesn't have any vertical splits. Like I mentioned 6 columns isn't half bad for interchanging bits compared to nothing and may have uses in regards to games where heavy vertical splitting uses too many cycles for the intended game play design. Next we have 6 by 2 adding a single vertical split, not terribly versatile but some saving are possible as well as built in 2 player split screen support. Followed by 6 by 4, I'd say that division would be good for a Playfield with large set pieces and a minimal repetition of tiles. Next is 6 by 8, I regard this as the best middle ground in terms of vertical division which I think will serve the greatest number of games. Still some space waste with smaller scale graphics but minimal. Last is 6 by 16, other than extreme small scale as in 1 bit wide walls I don't think further division would reap many rewards so I'll call this maximum vertical division. I think this would work well with Isometric graphics as they have a high degree of layer related rendering issues. Now these are just gross hypotheticals as I haven't included vertical HUD space splits or scrolling factors as I'm a coding Noob but I know they matter. I still think it isn't likely a single engine will serve every game in the Action26 set but I consider this an option towards reducing the number of engines to as few as possible. If anyone with experience with tile based system could chime in on this subject please do so as I have good intentions but we need real coding suggestions and limitations to iron out to get this bird to fly.

Well I like the design, its clean and cool unlike the Nes label which was just gaudy. The only thing I'd change is the coloring of the main central Action 26 title from a solid color to maybe a tropical gradient along the lines of the AM2 or Naughty Dog logo. I think that would give the label some character and draw the eyes to the title in a positive way. I'm still a bit confused by the 26th game being hidden but as far as the logo Action 25 +1 doesn't seem to fit well so I'd stick with Action 26 regardless as its just simpler to read and say.

I was thinking about the size concerns lately of multiple games not in limiting game size to a particular ROM size but rather generalizing certain elements like perhaps a universal font shared by all games on account of the particular optimization needs of text rendering on the 2600 being strict and maybe dedicating an entire section of ROM space to it much like a system character set. In practice I think 4X7 pixels is a good universal font character size as its wide enough to read with the stock RF output while 7 pixels allows for good legibility even with skipped scan lines. The Harmony Cart font looks like 3X5 with skipped scan lines which is the minimum size possible while still being readable but it works better for glancing at directory listings rather than actual reading of paragraphs. Because of the limited Bits available its impossible to not skip scan lines with Bit based kernal rendering of fonts unless you have short word widths or that most of the character graphic is being rendered with Playfield pixels which is the only context for solid character graphics other than odd to even scan line alternation which is hard to get right. Text can be generated multiple ways such as giant Playfield notepad drawings, Dual Player block word segments, and 48 bit wide multiplexed Player block Title screens seem to be the quicker more straight forward option but they tend to be space heavy in asset size compared to more cycle heavy segmented font systems. I don't see anyway around the segmentation issue when it comes to space used per game across multiple games. I bring up text but I think much of getting A52 into a practical form on the 2600 will depend on breaking data down into compact tiles whether that be Player blocks, Kernal sprites, or Playfield Blocks since rendering anything whether font or sprite is handled the same way on the 2600. Under standard 2600 game coding structures either the games will get bloated trying to resemble there original counterparts or if they conform to the original 2600 ROM sizes they will become heavily abstracted and unrecognizable. While I don't think an Action 52 game should necessarily be overly complex or deep like a dedicated game title would be such as including dialogue screens you still have to consider the costs of approximating these simple Nes games on the 2600. On that subject SeaGtGruff informs me that tile based systems are difficult to do on the 2600 since it isn't a default function like you would find on other platforms which means a method has be decided upon usually a single standard like those found in Boulder Dash 2600 or grafixbmp's Castlevania project. Just some food for thought about the project as a whole.

The menu diving could be increased to achieve what you propose, I admit switching listings and scrolling on a 2600 joystick can be awkward but I think this will work faster which is important when you have so many games to look through. The lack of a second fire button really tied my hands in a lot of ways. As far as the arrows I thought the category abbreviation next to them was clear enough that pressing the direction would take you there and if the shortening was unclear it wouldn't last since the full listing name would be shown just through trying L/R. Could add some color codes to the different areas of grouped text if I went with a purely separate odd even scanline approach. I know the scroll Window/Bar isn't as obvious as the sub menu arrows but I thought something should be included to not just visually separate the listing from the sub menu but also to indicate how large or long the information listing is through standard Windows style scroll appearance states. EG. no scroll indicator present for a single screen of text. Admitting the use of a scroll bar for a page flipping system is confusing but I didn't want to decrease the font scale to accommodate a different menu design and the Window/Scroll Bar would be easy enough to render using the Playfield. Personally I would have preferred a true page flipping visual with a numeric page indicator(Page) 4/6 (Pages) but I want to make sure the game titles get as many letters as possible horizontally under the 2600's limited rendering ability and I also hated the title shortening in the original Action 52 like Critical BP. I could drop the maximum title listings height to 7 visible and add a page indicator easily or maybe I'll have to try a new shorter font and see what fits. Nothing is written in stone as of yet so I'll see what I can do.

Decided to take another stab at the A52 Startup Menus, kept the same look but expanded on possible features. Also corrected the company name lol. Added a window border & scroll length indicator around the worded listings using Playfield pixels just to give the user some hint at how tall any given scrolling screen is and to segment areas of information. The Description screen is just for a basic storyline and or history of each game title. The bottom bar switches the company name for the author of game title the user has selected from the Main menu. As you can see game selection from the Main menu creates a sub menu of Main, Description, and Controls which are toggled with Left & Right on the Joystick with scrolling using Up & Down on the joystick. Main is an option of the sub menu simply so you can get back to the Main menu without resetting the console. Also it isn't visible in these images but the sub menu will have Go as an option to start the game actually loading and playing jsyk. As a collector of retro games I often don't have the manuals for many of my games so I thought a Control listing was in order. Although games like Space Invaders hardly need a Controls listing other games with more elaborate setups like Raiders of the Lost Ark sure do. Anyway still trying to work out ways of rendering games like Cheetahmen, Timewarp Tickers, etc. in the best possible manner. I came up with a few setups but I have doubts about there efficiency so I've been consulting SeaGtGruff on how taxing certain functions are within actual gameplay rendering so more interesting stuff soon.

It's a neat platform the Odyssey 2, I haven't been able to find a visual reference for its BIOS characters like a PNG to look at or experiment with in my usual non programmer way lol. Hard to find an Odyssey 2 locally but they come up occasionally where I live. Anyway neat stuff, pretty good color match on the AtariAge.

Sounds good to me, a few awkward sections here and there but overall very smooth track. I'm not a musician or a midi expert but is there any alternate instrument to use instead of the midi "trumpet" in particular the main one, heard that used in many midi tracks during its era and it always never sounded right to me?

Well I think your sprite looks awesome, great form and shading. The only thing I can see to change is that the legs look short and the arms seem too long but those are easy to fix, select part and push up or down, then tidy the pixels. Was reading you do good sprite work so thought I'd check it out, great stuff.