INTYBASIC 1.2 problems

[Kiwi]

I think it's this similar situation when someone say "This cup is half-full." Another person, "no it's half-empty." Then that argument ends horribly. The 2 statement means the same thing.

This is quite interesting case, does it scroll upwards, or downwards, from the bottom to the top, going down the screen, creeps up from the depth of the plastic from the screen.

Hmm... my answer is, I am uncertain. Which I put, "I think", as my get out of the argument card when I'm dead wrong.

[freewheel]

Imagine a MOB on an entirely black background.

 

If you press down on your controller, and your MOB moves towards the bottom of the screen, you say that the MOB is moving down. You could argue that it's actually your camera moving up, and you'd be correct - and yet we still refer to it as "down" in any context I can think of.

[+DZ-Jay]

Imagine a MOB on an entirely black background.

 

If you press down on your controller, and your MOB moves towards the bottom of the screen, you say that the MOB is moving down. You could argue that it's actually your camera moving up, and you'd be correct - and yet we still refer to it as "down" in any context I can think of.

 

That was my point before, that it is mostly generally understood as standard until someone comes around and says "well, technically, it could be the other way..." and then all hell breaks lose.

[intvnut]

Imagine a MOB on an entirely black background.

 

If you press down on your controller, and your MOB moves towards the bottom of the screen, you say that the MOB is moving down. You could argue that it's actually your camera moving up, and you'd be correct - and yet we still refer to it as "down" in any context I can think of.

 

 

 

 

That was my point before, that it is mostly generally understood as standard until someone comes around and says "well, technically, it could be the other way..." and then all hell breaks lose.

 

 

Actually, I assume the camera is pointed at the MOB, or at least tries to keep the MOB in frame, and so the camera generally moves in the same direction as the player's character.

 

So, when the MOB meets the bottom edge of the screen and you need to expose more world for the MOB to explore (even if it's pitch black, as in freewheel's example), do you "scroll up" or "scroll down"?

 

The camera and the MOB are both moving down. The cards in BACKTAB need to be moved to earlier addresses (and therefore "up") to preserve the illusion (even if they're pitch black, because presumably you'll get to part of the map that isn't pitch black eventually, and when you do, it'll enter on the bottom edge of the screen since you're moving down).

 

When you say "scroll down", do you mean that you shift your view so you can see things further down, or do you mean that you take the contents of the current screen and move them down on the screen so you can see things further up?

 

If you define "scroll down" in the direction of travel of the player's character (represented by a MOB) relative to the world, then the direction of BACKTAB (which holds the world) relative to that will be the opposite on the display.

 

 

My understanding from dZ's earlier post is that he defined "scroll up" and "scroll down" as the direction the BACKTAB moved ("the direction in which the screen registers are shifted"), not the direction the player moved relative to BACKTAB.

 

Did I misunderstand?

Edited September 30, 2015 by intvnut

[carlsson]

So don't expect ABS or SGN for unsigned numbers. But I've seen the usefulness of signed 8-bit variables, so next version of IntyBASIC will include a SIGNED statement.

I ran into something that might be explained by the above. A sample program using the compiler version 1.2.8:

 

 MODE 1
 SIGNED a,b,c,#f
 a=-25
 b=-50
 c=a+b
 d=abs(c)*2
 PRINT AT 0 COLOR $0007,"D=ABS(C)*2:"
 PRINT AT 12 COLOR $0007,<>d
 #e=abs(c)*2
 PRINT AT 20 COLOR $0007,"#E=ABS(C)*2:"
 PRINT AT 33 COLOR $0007,<>#e
 #f=a+b
 #g=abs(#f)*2
 PRINT AT 40 COLOR $0007,"#G=ABS(#F)*2:"
 PRINT AT 54 COLOR $0007,<>#g
loop:
 GOTO loop

It displays D=150, #E=65174 and #F=150. Perhaps that is expected behavior given the above?

 

In my case, I can use 16-bit variables all the way but for those cases where the value is known to fit within 8-bits, I would prefer to use one of those.

 

(Edited due to the AtariAge forum eats anything that is below code fragments unless BB Code mode is switched off)

Edited September 2, 2017 by carlsson

[+nanochess]

I ran into something that might be explained by the above. A sample program using the compiler version 1.2.8:

 

 MODE 1
 SIGNED a,b,c,#f
 a=-25
 b=-50
 c=a+b
 d=abs(c)*2
 PRINT AT 0 COLOR $0007,"D=ABS(C)*2:"
 PRINT AT 12 COLOR $0007,<>d
 #e=abs(c)*2
 PRINT AT 20 COLOR $0007,"#E=ABS(C)*2:"
 PRINT AT 33 COLOR $0007,<>#e
 #f=a+b
 #g=abs(#f)*2
 PRINT AT 40 COLOR $0007,"#G=ABS(#F)*2:"
 PRINT AT 54 COLOR $0007,<>#g
loop:
 GOTO loop

It displays D=150, #E=65174 and #F=150. Perhaps that is expected behavior given the above?

 

In my case, I can use 16-bit variables all the way but for those cases where the value is known to fit within 8-bits, I would prefer to use one of those.

 

(Edited due to the AtariAge forum eats anything that is below code fragments unless BB Code mode is switched off)

 

The behavior is all right.

 

Let me explain the IntyBASIC expression processing:

 

1. Every arithmetic is done internally in 16 bits (the register size)

2. SIGNED affects the reading of 8 bits variables (extending them to signed 16 bits, default is reading as unsigned)

3. SIGNED/UNSIGNED affects a single flag while processing expressions that switches between signed comparison and unsigned comparisons.

4. The PRINT <> operator always shows the 16-bits numbers as unsigned.

 

So the advantage of SIGNED with 8 bits variables is that it allows to add negative numbers to 16-bit variables without using the precious 16-bit space to preserve the value or manual sign-extending operations.

 

  SIGNED b

  #a = #a + b   ' b can be -128 to 127

The advantage of UNSIGNED with 16 bits variables is that it allows to calculate carry very easily.

 

  UNSIGNED score

  DIM score(2)

  points = 5
  IF score(0) + points < score(0) THEN  ' Carry over (easy with UNSIGNED)
    score(1) = score(1) + 1
  END IF
  score(0) = score(0) + points

Applying UNSIGNED to a 8-bits variable doesn't make anything because is the default behavior.

 

Likewise applying SIGNED to a 16-bits variable doesn't make anything because also is the default behavior.

[carlsson]

Thank you for your reply. In the mean time, I came up with the following workaround, that behaves like I expected:

 

MODE 1
 SIGNED a,b,c
 a=-25
 b=-50
 c=a+b
 d=c*sgn(c)*2
 PRINT AT 0 COLOR $0007,"D=ABS(C)*2:"
 PRINT AT 12 COLOR $0007,<>d
 #e=c*sgn(c)*2
 PRINT AT 20 COLOR $0007,"#E=ABS(C)*2:"
 PRINT AT 33 COLOR $0007,<>#e
 #f=a+b
 #g=#f*sgn(#f)*2
 PRINT AT 40 COLOR $0007,"#G=ABS(#F)*2:"
 PRINT AT 54 COLOR $0007,<>#g
loop:
 GOTO loop

Indeed each c*SGN( c )*2 generates 52 bytes more code than ABS( c )*2 but on the other hand I'm saving 1-3 16-bit temp variables that in the long run might be useful elsewhere. Edited September 6, 2017 by carlsson