tokumaru

Menne31, on Sat Oct 8, 2011 8:07 PM, said:

No, it's not. The 2600 has a very rudimentary video system, so in order to show anything meaningful, games have to rely on "kernels". Since the amount of processing available is very limited, kernels have to be carefully tailored for each game in order to make full use of the hardware. AFAIK, bB has a handful of general-purpose kernels, so it obviously can't make the best use of the hardware for every possible game.

Quote

I'm not a senior programmer when it comes o Atari (I guess I can say that about the NES though), but I can say that the forums are better for asking questions, because others might learn from the conversations as well. PM's are kinda selfish, because only you get to learn. Don't you agree?

LS_Dracon, on Tue Aug 16, 2011 8:01 AM, said:

I think both look great! Completely recognizable.

Matthew Nakayama, on Sat Jul 30, 2011 8:09 PM, said:

I think they take a peek at the code and look for instructions that appear to be mapper commands (i.e. accesses to the memory locations associated with bankswitching). You should always offer a way for the user to pick the mapper though, just in case your detection method fails.

JohnnyAtari, on Thu Jun 23, 2011 5:46 PM, said:

I'm sure it would look much more like an Genesis/MD game than an Atari 2600 game! I had never heard of this nD thing... pretty interesting! I wish them luck.

Now, since some of you are talking about the game being "ported", "sold", stuff like that, I'd just like to say that the game doesn't really exist. Unfortunately, I'm not working on it at all. I did begin some kernel coding, but real life stuff got in the way, I got a new job, and now this is just an idea I may or may not make real in the future. Sorry guys.

tz101, on Fri Mar 11, 2011 9:21 PM, said:

The graphical limitations (number of colors, players, missiles, etc.) usually refer to what can be done at any given time (not necessarily a scanline), but those parameters can be modified as the image is rendered by the console. The image is drawn from top to bottom, left to right, at the same time as the program is running. During this time, the program is free to modify sprites, colors, nearly everything. If the program keeps track of the image rendering process, it can make strategic changes to the display at appropriate times.

This makes it possible for a program to set the background color to blue at the top of the frame to draw the sky, but at some point down the image modify that color to brown to draw the ground. From the point of view of the hardware, there is only one active background color at any given time, but the program is free to modify what that color is several times per frame. The same "trick" can be used for all the other graphical elements, allowing for much more complex graphics than the raw specs would have you believe is possible.

The problem is that all these changes have to be done by the CPU, which has limited processing power. This means that the amount of changes you can do to the video is limited by how that processing power is distributed. It's much easier to go crazy with tricks in a title screen because they are very predictable. Since title screens are mostly static, you know where each graphical element will be, so you can focus the CPU power in specific screen regions. During gameplay, however, all kinds of objects can fly all around the screen, which means you need much more generic logic in order to be able to display all possible combinations of positions the game allows.

This is why you can't just "copy" a more detailed sprite from the title screen into the game, as the logic responsible for drawing the screen in both cases is completely different. Unlike an image in MSPaint, which is just a 2D array of equally sized pixels, the Atari display is composed of several objects that look and behave differently from each other, and they need a program behind the scenes to manage them. Because of this, the complexity of Atari graphics is not only dictated by the limitations of the video hardware, but also by how well the CPU is used to manage it and how much CPU time is dedicated to each aspect of the video, and this will change from programmer to programmer.

Another limiting factor that plays a part in the graphical complexity of the games is ROM space. The earlier games had only 2KB and 4KB of space, not enough to store the game program and a lot of detailed graphics. This is why most early games were very blocky and used few colors. Even if there was enough CPU time to modify the colors mid-frame, there wasn't any space left in the ROM to store the list of colors to use.

Nowadays, since we can have huge amounts of ROM (like, 512KB or even more), I believe games could have very impressive graphics. Very detailed sprites with incredibly smooth animation, backgrounds with new colors nearly every scanline, things like that.