Max positive value for Variables H2 thru Z2=32,767?

Chris H.'s Ultima / ACS-style game development system!

Moderators: Ice Cream Jonsey, Chris H

Post Reply
User avatar
Garth's Equipment Shop
Posts: 638
Joined: Fri Dec 05, 2008 5:55 pm
Location: Festering Foothills
Contact:

Max positive value for Variables H2 thru Z2=32,767?

Post by Garth's Equipment Shop » Sat Oct 17, 2009 8:07 pm

According to the manual :

* A-G and A2-G2 are one-byte values (can be 0-255) while the rest are two-byte values (0-65535).

However, I've run into a bit of a snag while trying to work up experience and leveling mechanics for a set of skills I am working on.

I originally intended on allowing the maximum accumulation of xp in each skill based on the above documented maximum value. As I approached the half-way point in the macro for the first skill I was setting the levels for, the values I entered began to change to negative values.

After a process of elimination I discovered that the switch to negative numbers begins at the value 32,768. When I try to enter a value of 32,768 or higher, up to 65535, the macro changes the value to a negative number. Here are the values and the negatives they are changed to:

32,768 = -32,768
32,769 = -32,767
32,770 = -32,766
... [skipping ahead 10]
32,780 = -32,756
...[skipping ahead 20]
32,800 = 32,736
...[100 more]
32,900 = 32,636
...[100 more]
33,000 = 32,536
...[2000 more]
35,000 = -30,536
...[30,000 more]
65,000 = -536
...[535 more]
65,535 = -1

As you can see it is a consistant progression backwards so that what we have for possible value ranges are:

-32,768...-1
0...32,767

Is this how it is supposed to be?
Which of you is interested in my fine wares?

rld
Posts: 223
Joined: Sun Jan 25, 2009 2:17 am
Location: Dallas, TX

Post by rld » Sun Oct 18, 2009 1:44 pm

For each of the two-byte variables (which ACK stores internally as two different byte values), you have a 16-bit range, which would normally allow values from 0-65535.

Depending on the way the code treats these values, they can either be unsigned integers (0-65535) or signed integers (-32768 to 32767). For the signed value, it is stored in two's complement format, which means that it 'rolls over' at 32,768 the way you describe.

I'm a little rusty on this, but from what I remember the point of two's complement storage is that the code doesn't really need to know (or care) if the 16-bit value is unsigned or signed; you can add the values either way and the sum will work out correctly after overflow.

So, if you set a variable to -1 (which is 65535 internally) and then add it to another variable set to 10, you get

-1 + 10
65535 + 10 = 65545
The high bit of the overflow (65536) is dropped, so you get
65545 - 65536 = 9
-1 + 10 = 9

User avatar
Garth's Equipment Shop
Posts: 638
Joined: Fri Dec 05, 2008 5:55 pm
Location: Festering Foothills
Contact:

Post by Garth's Equipment Shop » Sun Oct 18, 2009 9:18 pm

Thanks for the explanation rld but I'm still not sure if that means I can go ahead and treat those negatives as if they weren't really negative or not. I mean is the max value still 65535 or is it actually 32767?
Which of you is interested in my fine wares?

rld
Posts: 223
Joined: Sun Jan 25, 2009 2:17 am
Location: Dallas, TX

Post by rld » Mon Oct 19, 2009 7:46 am

Well, it looks like parts of the code might be treating the variables in different ways. I think what's happening when you enter the value in the macro editor is that the code accepts a value up to 65535, and stores that value in the variable, but the code that redisplays the macro line treats that value as a signed integer.

The question is, how do other parts of the code treat the variable value? This might take a bit of experimenting to figure out. For example, if you set variable Y to 65535 (or -1), and then do

IF Y > 10 THEN 15

you will get a different result depending on whether the macro evaluation code treats the variable as signed (-1) or unsigned (65535).

User avatar
Garth's Equipment Shop
Posts: 638
Joined: Fri Dec 05, 2008 5:55 pm
Location: Festering Foothills
Contact:

Post by Garth's Equipment Shop » Mon Oct 19, 2009 11:36 pm

ok thats easy enough to test, thanks rld.
Which of you is interested in my fine wares?

Chris H
Posts: 272
Joined: Sun Dec 02, 2007 4:07 pm
Location: California, USA

Post by Chris H » Fri Nov 27, 2009 12:46 pm

This might be a bug with whatever is displaying the value... they're stored as type "word" (0-64k) but they might be getting passed to a procedure that displays them as type "integer" (-32k to +32k)

So yeah, rld had it. :)

User avatar
Garth's Equipment Shop
Posts: 638
Joined: Fri Dec 05, 2008 5:55 pm
Location: Festering Foothills
Contact:

Post by Garth's Equipment Shop » Sat Nov 28, 2009 7:26 pm

Sorry I didnt get back to this thread with my findings. Yeah, the strange value displayed in the macro doesnt affect the value when it is displayed in a long message. I set up my skill experience tables and have a special xp/skill level screen pop up when you hit a key assigned to it's macro. With sayval I have the appropriate values for current accumulated xp and current skill levels displayed in a long message.

I'm thinking of doing my own inventory screen too so that I can use transparent mosaics with long messages to provide better control over the display of inventory items and maybe make interacting with them a little more inuitive and user friendly. I could also animate the inventory item icons this way as an added bonus. Like to show the gleam or shimmer of metal, the bubbling of a potion, or the flicker of a candle, lantern, torch, etc.
Which of you is interested in my fine wares?

Post Reply