Newbie gravity experiment

[Vincehood]

Thanks, it really helps!

I am now looking at the value of the Y coordinate. See further down.

Is this output documented somewhere? None of these hex values seem to match the position I see on the screen...

 

> m var_Y

0110:  0000  0002  0007  0006   005A  0050  005A* 0000    # .........Z.P.Z..

0118:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0120:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0128:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0130:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0138:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0140:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0148:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

0150:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

[+DZ-Jay]

1 hour ago, Vincehood said:

Thanks, it really helps!

Great!  I'm glad.

Quote

I am now looking at the value of the Y coordinate. See further down.

Is this output documented somewhere?

Yes, indeedy-doo!  Check out the text file "debugger.txt" in the "Documents/Tech" folder of the IntyBASIC SDK installation.  This is the user guide of the debugger, written by the author.

 

Here are the relevant parts:

Spoiler

-----------------
Looking at Memory
-----------------

The 'M'emory command dumps memory.  The memory dump looks like so:

0000:  3800 3800 3800 3800  3800 3800 3800 3800   # 8.8.8.8.8.8.8.8.
0008:  3000 3000 3000 3000  3000 3000 3000 3000   # 0.0.0.0.0.0.0.0.
0010:  0000 0000 0000 0000  0000 0000 0000 0000   # ................
0018:  3C00 3C00 3C00 3C00  3C00 3C00 3C00 3C00   # ................
0020:  3FFF 3FFF 3FFF 3FFF  3FFF 3FFF 3FFF 3FFF   # ................
0028:  3FF0 3FF0 3FF0 3FF0  3FF0 3FFF 3FFF 3FFF   # ................
0030:  3FF8 3FF8 3FFC 3FFF  3FFF 3FFF 3FFF 3FFF   # ................
0038:  3FFF 3FFF 3FFF 3FFF  3FFF 3FFF 3FFF 3FFF   # ................

The numbers at the left give addresses.  The numbers in the middle
give the contents of memory.  The text at the right gives an ASCII
representation of the contents of memory, with '.' characters in place
of non-printing characters.

The memory dumper always rounds addresses down to the next lowest
multiple of 8, and always dumps a multiple of 8 locations.

 

 

The command "m" displays the contents of memory, starting at a given location, up to the number of locations given in the second argument.  The default is 40 memory locations.

 

As the documentation states, the memory dumper always rounds down to the next lowest multiple of 8, and always dumps a multiple of 8 locations.  So what you are seeing is a block of 40 memory locations, in multiples of 8, in which the location you requested exists.

 

Quote

None of these hex values seem to match the position I see on the screen...

 

> m var_Y
0110:  0000  0002  0007  0006   005A  0050  005A* 0000    # .........Z.P.Z..
0118:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0120:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0128:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0130:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0138:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0140:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0148:  0000  0000  0000  0000   0000  0000  0000  0000    # ................
0150:  0000  0000  0000  0000   0000  0000  0000  0000    # ................

 

 

Each row contains 8 addresses, and on the left margin it tells you the starting address of each row.  The first row starts at "$0110" (Hex), meaning that it contains $0110, $0111, $0112, $0113, $0114, $0115, $0116, and $0117.  That's eight addresses, so the next row starts with the next address at 0118.

 

To orient yourself, look for the address with a "*" next to it: this is the start point -- the location you requested.  And you can see that it's shown on the 6th column (counting from zero), meaning that it is location $0110 + 6 = $0116.

 

Because the CPU is 16-bits wide, byte values are treated internally as 16-bit values, of which the upper 8 bits are zeroed out.  So variables in 8-bit RAM will show up as 16-bit values with a prefix of "00".  The memory dump above suggests that your variable "var_Y" has the value $5A in Hexadecimal, or 90 in Decimal.

 

The right side is the memory dumper's interpretation of the values as ASCII characters.  This is a typical feature of memory monitors, that automatically decode numeric codes for character data, but when you are dealing with actual numeric values, it is less useful.  So, feel free to ignore it.

 

I hope this helps -- but if anything is confusing or if you have any other questions, feel free to ask!

 

    -dZ.

Edited February 13, 2021 by DZ-Jay

[Vincehood]

It surely helps!! Thank you so much for your patience and the guidance, this is really a great learning day. I will try to digest all the info

[Vincehood]

Great, I have now really been able to monitor the key variables. My conclusion is that my approach does not really work. The pattern of  applying gravity in relation to frame rate seems to have some unwanted effect leading to non linear bouncing...

I should probably have looked from start at Oscar's Intylander which have nice gravity & ignition effects.

However I am not sure I understand fully the approach taken there:

...

#Y = 8 * 256

...

SPRITE 1,X+8 + VISIBLE + HIT,#Y/256+8+6 + ZOOMY2,SPR60 + (RAND AND 4) + SPR_RED

...

 

What's the main idea behind defining the Y coordinate as unsigned and using high numeric values?

 

lander.bas

[+nanochess]

My approach for fractional positioning in IntyBASIC is a variant of this.

 

Supposing you want to preserve values from 0.0 to 9.9 on an integer variable. How you do this? Using a multiplication by 10.

 

So for example:

 

   a = 5 * 10 + 4     ' 5 * 10 + 4 = 5.4

   b = 2 * 10 + 3     ' 2 * 10 + 3 = 2.3

   c = a + b ' 54 + 23 = 77

    PRINT <>c/10,".",c%10    ' Separate digit and fraction

 

And for the pixel positioning we use only the digit part (the / 10 result value).

 

BUT WE HAVE A PROBLEM THERE!!! The CP1610 processor is not so good at processing multiplications and division.

 

So we replace 10 by 256, because multiplication and division by 256 is done with SWAP/AND instructions (only two instructions). This means also that we need a 16-bit variable to keep the position, this way using #x and #y.

 

Now to set a ball in the center of the screen.

 

#x = 80 * 256

#y = 48 * 256

SPRITE 0, $0308 + #x / 256, $0108 + #y / 256, $002f * 8 + 7     ' Draw a 'O' letter in white.

 

To get a movement on the screen we can add further two variables:

 

#sx = 0

#sy = 256

 

game_loop:

WAIT

SPRITE 0, $0308 + #x / 256, $0108 + #y / 256, $002f * 8 + 7     ' Draw a 'O' letter in white.

IF #y >= 88 * 256 THEN    ' Touches floor

    IF #sy > 0 THEN    ' Going down
        #sy = -(#sy / 2)    ' Reboots with half acceleration
    ELSE
        #sy = 0
    END IF
END IF

#x = #x + #sx

#y = #y + #sy

 

IF #sy > 0 THEN

    #sy = #sy + 32     ' Gravity acceleration

ELSE

    #sy = #sy + 16     ' Reduce ascend

END IF

GOTO game_loop

 

And then it fails because a rounding error but I'm too lazy to correct it for tonight

 

Edited February 14, 2021 by nanochess

[Vincehood]

Thanks Oscar! It really makes sense now ?

[Vincehood]

I integrated this approach and I think the falling and bouncing effect really look nice

Also you can see the bird really struggling to keep flying (on that matter, no attempt to process the button input yet).

 

I have not managed yet to complete stabilize the bird but this may be due to the rounding issue mentioned by nanochess. I guess one needs somehow to decide what fraction can be considered as 0?

 

 

gravity6.bas