[What mistake would make new DEFs cause errors?]

...Now I have a problem where I can't add any more DEFs. If I add a new DEF, I get this...

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.]

[How is Auto-Play done?]

Nice side benefit!

 

In other circles that's known as fuzz testing.

[Okie Dokie solution]

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

[Digital Joysticks provide better control than Analog Joysticks]

Pressure is the main issue with trackpoints not some microscopic movement of the trackpoint.

No, its not microscopic. Its quite visible to the naked eye from a few feet away.

 

Considering the short axis, its pretty significant.

 

You wouldn't compare the throw of a digital and analog joystick with throw of a trackpoint as a fair comparison. Pressure on an analog joystick and digital joysticks as being compared in this thread don't affect the motion.

 

They don't? On a self-centering stick? Really?

 

Have you used an analog stick before?

 

Is your thumbstick pressure based or are you back to non-pressure based joysticks?

 

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!

[Digital Joysticks provide better control than Analog Joysticks]

Try playing missile command with a trackpoint vs. a digital joystick or a regular mouse. You'll see the difference. Now the throw distance is no longer the discussion but the pressure uncertainties. You were arguing the throw distance if you study this subject back a few messages. Now rather than admit your mistake, you want to use trackpoints and compare apples and oranges.

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.

[Digital Joysticks provide better control than Analog Joysticks]

You forgot to read the context and the word "like". I am speaking all digital. The amount of pressure doesn't matter nor do you need to spend time sampling it-- either its being touched in a certain direction or it isn't. And those digital joysticks that have very rigid sticks that hardly move resemble that.

 

If you want to compare such a thing with the analog trackpoint, that's a separate matter.

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.

[Digital Joysticks provide better control than Analog Joysticks]

I don't think you understand the point. We are comparing analog joystick and digital joystick throw. The idea of moving the stick can be reduced on the digital joystick to zero but not on the analog joystick.

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

[Digital Joysticks provide better control than Analog Joysticks]

I see how you misread things and selectively quote things. I said it's *like* a trackpoint mouse; no pressure sensitivity for analogicity needed as it's only 1/0 state. We're talking about throw distance in case you forgot. Your original point by the way.

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!

[Digital Joysticks provide better control than Analog Joysticks]

Why do you want to force people to admit things that are obviously wrong? Digital joysticks always have superior switching since you can minimize the distance as much as possible unlike for analog. In the ultimate case, you can make the throw distance ZERO so that just the pressing to move in a direction moves the joystick (like a trackpoint on a mouse).

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.

[How is Auto-Play done?]

OK, I'm getting ready to do this and there are still a few things that are fuzzy. The semi-easy part is using a bit to tell the program that auto-play mode is on, but won't I need a full variable to use as a timer, so the program will keep flipping between the title screen and auto-play every 20 seconds?

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.

[Okie Dokie solution]

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.

[Digital Joysticks provide better control than Analog Joysticks]

Your looking at it after you get to the extremes or near center. If you read post #420, you would have noticed that there's values in between which do not exist for digital joysticks. You are assuming time to switch from center to a direction is zero which is false.

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.

[Digital Joysticks provide better control than Analog Joysticks]

Your looking at it after you get to the extremes or near center. If you read post #420, you would have noticed that there's values in between which do not exist for digital joysticks. You are assuming time to switch from center to a direction is zero which is false.

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.

[Digital Joysticks provide better control than Analog Joysticks]

Neither his hypothetical description nor modern improved analog joysticks address the uncertainties. Obviously, the older gameport ones 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.

[Digital Joysticks provide better control than Analog Joysticks]

Nice, that made me laugh. Hey, aren't you from the "peace-keeping nation" from the north. Oh well, I guess that adage is from past history.

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.

[Digital Joysticks provide better control than Analog Joysticks]

Jokes aren't much fun if you need to explain them, but note the sarcasm in the first line, and the "cut-off" sentence in the second line. It was supposed to give you or perhaps just others a chuckle, but apparently everything needs to be very serious.

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

[modifying the playfield with ASM?]

Personally, I'm against Stella doing this clean frame blending by default (is there a way to turn it off for good?), because it leads programmers to believe that flicker looks OK...

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.

[modifying the playfield with ASM?]

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.

[Alien Greed Adventure]

There's a pretty straightforward way to grab that info in stella - if you hit the ` key you can enter the debugger and then choose the tia tab.

 

 

Looks like the color is $36.

[Digital Joysticks provide better control than Analog Joysticks]

You walked away WITHOUT notice in the middle of a war. Coward.

Huh? I thought we were just posting in a web forum. Did I miss the part where someone declared this a war?

 

And if it is a war... what is it good for?

[Destiny WIP]

@RevEng: Going over the CPU cycles seems to be a serious no-no but I don't understand why. Can it blitzkrieg the entire game or just make funny noise on the screen when it happens? Bataris kernel isn't going over the CPU cycles right? Just my amateur game logic code (I think, dunno).

Right, it's not the kernel, it's the bB code. The reason using too many cycles is undesirable is because it causes the overscan part of the TV frame to have too many lines, which is quite likely to cause screen jittering or rolling.

 

The "ideal" TV frame generated from a 2600 game is made up of these parts and these line counts:

• 
  [VSYNC.............3 lines]
  [VBLANK...........37 lines]
  [VISIBLE SCREEN..192 lines]
  [OVERSCAN.........30 lines]

The main part of your basic program runs in the overscan part of the TV frame until it hits a drawscreen command, at which point the rest of the frame parts are drawn. When overscan time beings again, control is returned to your basic code, just after the drawscreen command.

 

One way to avoid using too many cycles is to have multiple drawscreens strategically placed in CPU-heavy parts of your code. This approach won't work in the main loop of the game, as each drawscreen in your main loop will reduce the overall framerate, but it works well enough for screen setup code.

 

If you take this approach, you may want to set the colors of all screen elements to black until the screen is completely drawn, to avoid showing the screen as it's being built-up.

 

It's also worth mentioning that your basic program can also run partially in vblank with the vblank keyword, and similarly you don't want to use too many cycles there either, or else there will be too many vblank lines, which will cause jittering or rolling.

[Destiny WIP]

Definitely a solid start! I agree that more distinct room features could help. I'd also like to see matching up-stairs and down-stairs.

 

I don't know if you noticed, but your room drawing routine is using too many cycles.

 

Since you're after rings, why not call it "rings of the lord", and add some shadow riders.

[Bitmap Minikernel]

Ok, here's the problem in a nutshell... I need 3 temporary bytes of ram, plus the tempN variables. The bB guide says that aux3-6 are reserved exclusively for minikernels, but that's not entirely true. These same bytes are also used for various optional functions in the score display. (aux3=pointer to lives shape or pfscore1, aux4=life color or pfscore2, ...)

 

It looks like there just isn't any free ram that I can borrow without colliding with some optional bB feature.

 

So the following version uses aux3, aux5 and aux6 as before, unless your basic program has dimensioned bmmk1, bmmk2, and bmmk3, in which case it uses them instead...

 

rem *** one example...
rem *** the following are temporary bytes for the bitmap minikernel
dim bmmk1=var44
dim bmmk2=var45
dim bmmk3=var46

 

bitmap_mk.asm.txt

[Bitmap Minikernel]

Ok, I'll take a look at the scorepointer conflict. I have a feeling I know what it is, though fixing it will take some doing.

[The Titlescreen Kernel]

I knew, but it's a good point to explicitly state.

 

If you're doing anything intensive in a titlescreen loop, it's probably a good idea to double-check you're not pushing more than the usual 262/312 scanline counts. (alt+l in stella)