RevEng

Agreed. IMO turning off Phosphor Blend and using GL Vsync gives the closest approximation of a real Atari on a CRT, including color blending. Stephen A has stated a bunch of times in the past that the Phosphor blend is there to enhance games with flicker, not to accurately simulate a TV. @jrock: Definitely minimize the luma contrast between the flickered elements. But don't get too caught up on the absolute purity of the color of the guy's shirt and pants. When you flicker with a colored background color constancy kicks in and people perceive the colors as relatively pure even though they aren't in the absolute sense. BTW, kick ass start!

Actually 2k (1977 standard) Yup. And the Real Professional Atari 2600 Coder wants to make a game using only techniques documented or known from 1977 too. Its still a 2600 game when you add bankswitching and extra ram. Neither of these things is a panacea; you're still pushing everything through TIA and you're still squeezing code pieces into the jigsaw puzzle of your kernel. IMO The Real 2600 Homebrewer uses bankswitching or sc ram when he wants; not as a cheat, but to deliver an experience that wouldn't have been possible without them.

The nibble code seems to work fine in other programs, so I'm thinking there's some other condition that must to be present to trigger the bug.

I've seen "hidden" errors that don't relate to the compile error, but I haven't seen what you're describing before, so please report it if you do find it. Feel free to post or PM the source if you want help with the hunt for the needle.

Looking at it again, this is wrong in the assembly too: "LDA Ship_Up" It should have been "LDA e" instead, since Ship_Up is e{0}. Looking through the older bB source (batari hasn't released the newer source with DEF and other stuff in it, AFAIK), it seems that bit to bit assignments don't have any syntax checks for the stuff between the {} brackets. So if you do something like "b{0}=a{ }" or "b{0}=a{" you get assembly like... LDA a AND #65536 (...) ...which looks just like yours. Anyway, the upshot of this is I think DEF isn't feeding the bitwise assignment the right stuff. Hopefully batari reads this and replies. In the meantime, maybe you can reduce some of the less frequently used DEFs and use dims instead, like we used to before DEF. eg. dim Debounce_Reset=h ... lots of code later... if Debounce_Reset{1} then blah blah [edit - tokumaru, I just saw your post above mine. You win. ]

Glad to try and help. I didn't realize that it was a bit being assigned to a bit. The assembly makes a lot more sense now, though obviously the "and #65536" is invalid. For "Shot_U_Snapshot = Ship_Up" it should have been "and #1", since Ship_Up is e{0}. Why its doing that isn't as clear. When I create a .bas with your DEFs and the "Shot_U_Snapshot = Ship_Up : Shot_D_Snapshot = Ship_Down" line it compiles fine.

I don't believe there is an end game, other than an attempt to inflate self image... http://en.wikipedia.org/wiki/Superiority_complex#Definition_and_Potential_causes ...its the inferiority complex I'm pointing to in that entry, and I'm not trying to be unkind or glib. Its just the only explanation that makes sense to me at this point. I'm done with the game. I had fun with everyone examining the broken logic and the desperate attempts at patchwork, but now it's getting a bit creepy.

The generated assembly is definitely messed up, and looks nothing like the simple variable setting it's supposed to be doing. I tried to replicate it the issue by creating a .bas file with 256 simple DEFs in it. When I tried to compile it, the bB "2600basic" program segfaulted. At around ~160 DEFs it compiles sometimes, and segfaults others. It looks like DEF might have a bug or two, or possibly an undocumented limitation. If you split up the line "Shot_U_Snapshot = Ship_Up : Shot_D_Snapshot = Ship_Down" into two lines, does it help? [edit - seeing the DEFs for Ship_Up and Ship_down would help, if they are DEFs.]

Nice side benefit! In other circles that's known as fuzz testing.

The Jerk Store called, and they're running out of us!

No, its not microscopic. Its quite visible to the naked eye from a few feet away. Considering the short axis, its pretty significant. They don't? On a self-centering stick? Really? Have you used an analog stick before? I'm still on self-centering analog sticks, which require varying degrees of pressure for different in-between positions. But the xbox one isn't based around a strain gauge. Amazing how its better at Kaboom. It's almost as if the label "superior controller" depends on the type of game being played!

A trackpoint doesn't have zero throw. Have you used one before? There is deflection; it's short throw. The more pressure you apply, the more it deflects. It's just more stiff than you're used to. Look at the position of the trackpoint as you push on the side. Even on such a short axis there's clearly some throw distance, albeit superior to your digital sticks. I've played kaboom on stella with the trackpoint many times. It's nowhere near as good as paddles, but it's clearly superior to using a digital joystick on the same game. The same is true of the xbox controller thumbstick that I use on the other PC.

You opened the comparison when you imagined a digital joystick that could have as short a throw as an analog trackpoint. There isn't such a digital joystick, and there is such an analog joystick - the trackpoint itself. How exactly does a trackpoint differ from an analog joystick again? You're only now calling it a separate matter because you realize the folly of bringing it up in the first point. A digital joystick can't come close to the level of control of a trackpoint for moving a mouse. Nor can it come close in a game designed around speeds other than on/off.

Except the controller you cited as having zero throw is an analog joystick with a short throw. That's what a trackpoint is.

Sure! If you could somehow engineer a digital joystick to be as responsive as an analog strain gauge, then you would have a digital control as superior as... er... an analog strain gauge! I think the best way would be to have software limit the values to certain ranges!

Hahahahahahaha... [wipes tear] A trackpoint is a short-throw analog, specifically a strain-guage. Notice how more pressure moves the mouse faster? Amazing how useful all those inbetween states are with such a short throw. And I agree, it really is the ultimate case! Much more control than a digital stick could ever provide.

Instead of a timer, you could check that auto-play bit during some event that won't happen for a while - like the auto-player dying - and jump to the title screen when it happens. The title screen would need a timer, but you don't need all the variables during the title screen.

ZonaConcedes, in forums other than the Introductions forum people reply based on their interests. I'm sorry that you didn't get a hit in the first 24 hours, but it happens sometimes. If you do decide to post in Introductions, you might want to lead with the jerks thing. It will make for an interesting introduction.

No such assumption. I have the understanding that a digital stick also has a non-zero switch time due to the throw distance. Apparently you don't. I know digital sticks also take time, but it doesn't produce the in-between values nor are its states unstable. And if you want to equate the time, you hardly have any certainty for in-between states which was the main reason for your analog joystick to begin with. For longer throw, analog joystick loses in uncertainty and time to switch. For short throw, you have hardly any use for inbetween-states and there's still samples you get that aren't at center nor at extremes and you have to deal with them. And these aren't consistent either amongst all analog joysticks. The throw distance isn't consistent amongst all digital joysticks either. How terrible! There is a lot of use for inbetween-states in a short-throw analog. Even if you're extremely feeble and can only manage one in-between state, being able to move at less than full speed is an extra degree of control. The in-between samples are the advantage of a short-throw analog stick over a digital stick. Even as I start the throw distance my game character begins to respond with an analog. Sadly, with a digital joystick you need wait for the full throw to complete before the character responds.

No such assumption. I have the understanding that a digital stick also has a non-zero switch time due to the throw distance. Apparently you don't.

Actually, if you drop the anti-analog joystick bias you might see that his description does address the uncertainties. When I treat a modern analog like a digital stick and stam it to the edge of the range, I'm 100% certain it's full throttle, just like a digital stick. There's no uncertainty there. When I allow it to self center, I'm certain it's not engaged, just like the self-centering on a digital joystick. So all of the control of a digital stick is present.

Sadly, even the peace-keeping troops have given up on this thread. But don't let me stop you from reasoned debate. I agree that analog controls can be made to provide similar control characteristics to digital ones, and will argue that they've evolved that way with more modern implementations. The analog thumbsticks on modern consoles have a much shorter throw distance before you hit that "slam to the side" hard-stop than their old-school analog joystick counterparts. It's not quite the level of digital restriction that you're discussing, but enough that you can slam them like digital sticks when you want, but still have some finesse when it's required.

Dammit man, what do you think this is, some kind of social forum? This is a WAR!!!

I think that the stella phosphor/blending effect is only default-on for roms that are in stella's db and have the effect turned on there. This shouldn't be a problem with WIP roms. Agreed that colors with similar luma are best to flicker together. I have a semi-abandoned WIP that uses that and flicker-blinds to create a 4 color playfield that isn't too hard on the eyes. Another alternative is to draw one color on the odd lines and another on the evens. This isn't flickery at all, but it is a bit stripey.

You can change color on the fly in assembly, but the resolution is rather coarse compared to the normal playfield resolution - IIRC around 11 pixels across, using zero page memory loads. You won't have a lot of time left to do other things, like display players and missiles, while you're changing those colors. There are some other tricks that might be performed, depending on your game requirements. With this kind of question, the quality of the answer you're going to get is proportionate to the level of detail you use when describing your game's display. You might flicker 2 different playfields in 2 different colors. That would provide 4 colors in total (including the backgroud) but at least 2 of them would look flickery. If you only need 8 pixels of the playfield and no players in your game, you could use the players in wide mode as the other colors of the playfield.