NuType Posted February 19, 2018 Share Posted February 19, 2018 (edited) Hi all, first post here! I'm currently working on a stealth-action game inspired by Metal Gear called Winged Victory: Phase I. I've broken the game down into Phases as a way of simplifying my work load and increase complexity as I lock down core mechanics. I'm currently working in Gamemaker Studio, and for this first phase, I wanted to approximate an Atari 2600 visual style. (Eventually I would LOVE to port it to an actual 2600). Does this look correct, or am I breaking limitations here?Here's the image at twice the original size.The game is being redesigned from its current iteration which I have uploaded on itch.io (if anyone is interested in checking it out, let me know). This new redesign will probably incorporate turn-based movement on a grid (as opposed to just grid-based movement). Was the Atari 2600 capable of turn-based movement or even grid based movement? Edited February 19, 2018 by NuType 1 Quote Link to comment Share on other sites More sharing options...
Rhindle the Dragon Posted February 19, 2018 Share Posted February 19, 2018 I don't see any immediate problems if you wanted to port this to the 2600. However, keep in mind that some things will probably need to be changed. Depending on how complex your game is, you might need to trim it down so it fits on an 8K cartridge. As for the graphics, you might have trouble rendering the background, but I'm sure with a bit of patience, it could be done. I'm also sure that turn- and grid-based movement can be done. As a matter of fact, I think it already has been done (just look at Flag Capture, although that was one square at a time.) Also, kudos if you do it in assembly. Good luck! 2 Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted February 19, 2018 Share Posted February 19, 2018 (edited) Your screen is a bit too tall. The normal resolution on an NTSC game is 192 (v) x 168(h). Your tiles appear to be about 18 pixels tall, putting the playing area at 180 with not enough room for the status menu. Your horizontal resolution is way off, at 13 18x18 tiles. The limitations of the atari are 2x 8-pixel player sprites (can be duplicated up to three times with some limitations on placements of the copies) 2 1-pixel (can be doubled,quad sized) missiles (share color with player), and one ball (shares color with Plainfield), and a low res 40 (3-pixel wide per player pixel )playfield that is mirrored (or can be modified to make asymmetrical playfields ). While I wouldn't say it's impossible after reducing the screen size to 192x168, the playfield looks higher resolution than I would expect without performing some trickery with using the ball sprite. The players look more in the 2600 style and would be very doable with a standard 2-line kernel. (The kernel is responsible for drawing the screen) As for game play, nothing prevents turn based play (it is probably easier than updating everything as quickly as you need to in a real-time game). The VCS had Chess, Checkers, 3D Tic Tac Toe, Flag Capture, etc. The same is true of whatever you mean by grid-based movement. That is controlled by the program, it isn't a limitation of the hardware. Your status menu is also a little too high resolution. You can pull off 6 character displays (there is actually demos of a 32 characters display) using both player sprites triple copies interlocked and updating the graphics during drawing the line. But, you also have two item boxes and a happy face box that would require updating the plAyer graphics. I don't think this could be pulled of without some amazing trickery. Edited February 19, 2018 by CapitanClassic 2 Quote Link to comment Share on other sites More sharing options...
Rhindle the Dragon Posted February 19, 2018 Share Posted February 19, 2018 ...Yeah, don't listen to me. I don't know shit. 1 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 19, 2018 Author Share Posted February 19, 2018 (edited) Your screen is a bit too tall. The normal resolution on an NTSC game is 192 (v) x 168(h). Your tiles appear to be about 18 pixels tall, putting the playing area at 180 with not enough room for the status menu. Your horizontal resolution is way off, at 13 18x18 tiles. The limitations of the atari are 2x 8-pixel player sprites (can be duplicated up to three times with some limitations on placements of the copies) 2 1-pixel (can be doubled,quad sized) missiles (share color with player), and one ball (shares color with Plainfield), and a low res 40 (3-pixel wide per player pixel )playfield that is mirrored (or can be modified to make asymmetrical playfields ). While I wouldn't say it's impossible after reducing the screen size to 192x168, the playfield looks higher resolution than I would expect without performing some trickery with using the ball sprite. The players look more in the 2600 style and would be very doable with a standard 2-line kernel. (The kernel is responsible for drawing the screen) As for game play, nothing prevents turn based play (it is probably easier than updating everything as quickly as you need to in a real-time game). The VCS had Chess, Checkers, 3D Tic Tac Toe, Flag Capture, etc. The same is true of whatever you mean by grid-based movement. That is controlled by the program, it isn't a limitation of the hardware. Your status menu is also a little too high resolution. You can pull off 6 character displays (there is actually demos of a 32 characters display) using both player sprites triple copies interlocked and updating the graphics during drawing the line. But, you also have two item boxes and a happy face box that would require updating the plAyer graphics. I don't think this could be pulled of without some amazing trickery. Hmm, I read a thread by a user called BladeJunker on Pixelation.org (he has also posted here) where it was mentioned you could do 320x192 for resolution. Is this not accurate? That's the resolution I was using. Unless I misunderstood what he was talking about or he was wrong. The information I have on the Atari 2600 visual capabilities came from a large thread he did on the topic: https://pixelation.org/index.php?topic=13697.0 Regarding the line kernel, how exactly do I go about choosing what to use? Is it set in the system? I don't understand the specifics, but I figured it would give me room to choose one and design based on the kernel thickness. Smaller seems better, while bigger seems chunkier. Regarding the playfield. Each playfield pixel is 4 color clocks wide, which is about eight normal pixels. So 8 x 40 equals 320. I'm wondering now if this depends on kernel line thickness more than anything. Or I'm misunderstanding something. When do pixels stretch? Maybe that's what I need to account for. Here's an image that I have been using to build upon. I might need to go over the thread again. But it's possible a lot of the info has flown over my head, and the images that were used to describe the examples are all gone now. Though I saved a few to my computer. Would it be possible for someone to edit my image and show me examples of where I'm doing something wrong? @Rhindle The Dragon: You've been helpful too! Edited February 19, 2018 by NuType 1 Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted February 20, 2018 Share Posted February 20, 2018 (edited) Sorry, I did make some errors. A playfield pixel is indeed 4 color clocks wide, not 3. It is made up by 2 8-bit registers and one 4-bit register (20 bits), and those pixels can be mirrored or updated to display a different Playfield on the Right of the screen. So, 20*2 = 40, and 4 color-clocks * 40 playfield bits = 160 pixel wide display. (Not 320). You cannot usually display all the possible pixels that could be output by the 2600. There are overscan sections of the screen that are typically cut-off by the rounded corners of most TVs, and as you increase the resolution you start running out of processing power to actually display a non-static image. That is my understanding http://atariage.com/forums/topic/169128-what-is-the-atari-2600-screen-resolution/?p=2091765 As far as thickness in height of the players/playfield, the 2-line kernel was typical of the early 2600 releases. As more RAM, ROM (with bankswitching), and co-processors were added to the cartridges, the programmers were able to create much more complex and colorful displays. Sprites in the 2600 are really only one pixel high. What makes them look like something other than a single color vertical band on the screen is that the sprite is updated each line, changing the shape and or color. One quick thing I can point out is that typically, you can only get 2 background colors on screen in the same horizontal line (the on/off colors). I see several sections where you are alternating between black, blue, light green, and green. Edited February 20, 2018 by CapitanClassic 2 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 20, 2018 Author Share Posted February 20, 2018 (edited) So still wrapping my head around all this info, thanks for the link by the way. Read through it and came out understanding things a bit more, but still need to process it all.With that being said, here is a screenshot of a previous iteration of the game that I worked on. Aside from not having only two colors per horizontal line, and too big of a resolution, do you see any other issues? Edited February 20, 2018 by NuType 1 Quote Link to comment Share on other sites More sharing options...
BigO Posted February 20, 2018 Share Posted February 20, 2018 It's a boatload of information. Way too much probably. But somewhere in here you can likely find what you're looking for.http://atariage.com/forums/forum/50-atari-2600-programming/There's a Stella TIA programming reference that may have the details you want from a technical perspective: https://atarihq.com/danb/files/stella.pdf 1 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 20, 2018 Author Share Posted February 20, 2018 Thanks for the links BigO. Will pour through that Stella programming reference. I can always go to the programming forum for when I need any help or ideas explained. Quote Link to comment Share on other sites More sharing options...
NuType Posted February 22, 2018 Author Share Posted February 22, 2018 So I have two specific questions that seem to be stumping me. One is related to the screen resolution and the other to the playfield. My searches have been unfruitful. 1) If the screen resolution is 160x192, why do all the screenshots for Atari 2600 games appear wider than they are taller? Why do the sprites appear correct and not stretched vertically? I'm doing a mockup in Photoshop and it seems that if I use a canvas in the Atari resolution, large vertical portions will remain unused. Here's an image to illustrate what I mean. 2) If the playfield is 20 playfield pixels across, and the playfield can be mirrored, how do you fit this playfield sample fully in a 160 width space? It seems the resolution would need to be kicked up to 320. Unless again, vertical portions of the screen are not used. Here's with just 20 playfield pixels. So any ideas? What am I not understanding if anything? Quote Link to comment Share on other sites More sharing options...
eshu Posted February 22, 2018 Share Posted February 22, 2018 So, it’s 160x192 with a screen ratio of 4:3, it’s quite common to mock things up in 320x192 with double width pixels as this is closer to 4:3 than 160x192 1 Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted February 22, 2018 Share Posted February 22, 2018 TV pixels arent square. 2 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 22, 2018 Author Share Posted February 22, 2018 TV pixels arent square. Need a little more than that. Quote Link to comment Share on other sites More sharing options...
CapitanClassic Posted February 22, 2018 Share Posted February 22, 2018 (edited) https://en.m.wikipedia.org/wiki/Pixel_aspect_ratio TV displays arent in square pixels like digital image formats, but are defined by lines (480i, 720p, 1080p, etc.). I dont know a proper conversion to approximate the VCS display when describing it in a digital format. The majority of 2600 games are probably 160 pixels wide and 192 pixels tall. I would just double the horizontal pixels as mentioned above to make a closer approximation of what an actual screen would display. A 4:3 ratio for TV would result in 256x192 square pixels. (1.333 ratio). 320 (double wide) x 192 = 1.6666, which is closer than 160 x 192 = 0.8333 Edited February 22, 2018 by CapitanClassic 1 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 22, 2018 Author Share Posted February 22, 2018 https://en.m.wikipedia.org/wiki/Pixel_aspect_ratio TV displays arent in square pixels like digital image formats, but are defined by lines (480i, 720p, 1080p, etc.). I dont know a proper conversion to approximate the VCS display when describing it in a digital format. The majority of 2600 games are probably 160 pixels wide and 192 pixels tall. I would just double the horizontal pixels as mentioned above to make a closer approximation of what an actual screen would display. A 4:3 ratio for TV would result in 256x192 square pixels. (1.333 ratio). 320 (double wide) x 192 = 1.6666, which is closer than 160 x 192 = 0.8333 Thanks for your help! Things are making sense little by little. Quote Link to comment Share on other sites More sharing options...
Rhindle the Dragon Posted February 23, 2018 Share Posted February 23, 2018 Things are making sense little by little. Every time I want to start working on a homebrew, I get caught up in the fact that I'm not the greatest with assembly, and for the life of me I can't understand all the TV-scanning stuff unique to the 2600 even though I am in computer science. Good on you for your perseverance! I hope this comes through. 1 Quote Link to comment Share on other sites More sharing options...
vidak Posted February 23, 2018 Share Posted February 23, 2018 The resolution for PLAYER graphics is 160x192 1 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 23, 2018 Author Share Posted February 23, 2018 Every time I want to start working on a homebrew, I get caught up in the fact that I'm not the greatest with assembly, and for the life of me I can't understand all the TV-scanning stuff unique to the 2600 even though I am in computer science. Good on you for your perseverance! I hope this comes through. Thanks! It seems overwhelming, but if I ever get into Assembly I should have some ground work done. The resolution for PLAYER graphics is 160x192 So when you say PLAYER graphics, do you mean the player's sprite object? Or the missle and ball objects? Does it also included the playfield? Quote Link to comment Share on other sites More sharing options...
NuType Posted February 23, 2018 Author Share Posted February 23, 2018 Can't seem to edit my previous response to include an image, so had to double post.Here's my newest mockup. Let me know if it looks like it would run or not on the 2600. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 23, 2018 Share Posted February 23, 2018 That looks reasonable. I think you also need to consider how the sprites will move (horizontally, vertically, both etc.), cart hardware you plan to use, and which programming language/tools you're comfortable with. 1 Quote Link to comment Share on other sites More sharing options...
NuType Posted February 23, 2018 Author Share Posted February 23, 2018 That looks reasonable. I think you also need to consider how the sprites will move (horizontally, vertically, both etc.), cart hardware you plan to use, and which programming language/tools you're comfortable with. So for this iteration of the game, movement will be turn-based, and the player and AI can move vertically or horizontally. I'm working with GameMaker Studio at the moment, and I am playing with Atari 2600 visuals as a personal aesthetic choice while also trying to develop under a similar environment. Eventually I would love to port this to the 2600. Right now my constraints with this design are to 1) Keep it at 4K max memory or less, true 2600 resolution, and following the general rules for sprites, objects, and playfield. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 23, 2018 Share Posted February 23, 2018 I think you might be able to mock this up in batari basic pretty quickly. It might be worth a try so you can get a better feel for the limitations of the system. For what you describe I believe the Multisprite Kernel with a HUD is what you want. If you prefer to go the assembly route you can do better graphics, but it's going to take longer to learn what you can do and how to do it. 1 Quote Link to comment Share on other sites More sharing options...
vidak Posted February 24, 2018 Share Posted February 24, 2018 The playfield graphics are 80 pixels horiztonally, if you wrote an assymetrica playfield. The player sprites are 160 pixels horizontally if you were able to draw a whole scanline of them. Quote Link to comment Share on other sites More sharing options...
vidak Posted February 24, 2018 Share Posted February 24, 2018 So the playfield graphics are half the horizontal resolution of the player sprites. Quote Link to comment Share on other sites More sharing options...
ZackAttack Posted February 24, 2018 Share Posted February 24, 2018 The playfield graphics are 80 pixels horiztonally, if you wrote an assymetrica playfield. The player sprites are 160 pixels horizontally if you were able to draw a whole scanline of them. So the playfield graphics are half the horizontal resolution of the player sprites. You meant 40 PF pixels right? Quote Link to comment Share on other sites More sharing options...
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.