Subject: Debugging XB program

From: Owen Brand <[email-masked]>
Date: Wed, 23 Dec 2009 13:09:46 -0500

I have been working a bit on "Honeycomb Rapture" and it is close to  
complete.  I am having an issue, however, with my "enemy randomize"  
function.  I have tried to implement a random function that causes  
enemies to appear at varying rows on the screen.  Essentially, killer  
bees appear on the right side of the screen and move toward the left.   
Think "Parsec" as a reference point.  My problem arises in a boundary  
issue.. I do not want enemies to appear above the 6th row on the  
screen... With my current code, I limit it by a "IF-THEN-ELSE"  
statement.  This seems to have the effect of "un-randomizing" my  
randomization.  I realize that without a code snippit, it makes this  
difficult to diagnose--- I am on my phone now and don't have access to  
my PC to copy a piece of code.  But conceptually, does this make  
sense?  Anyone run across this before, and are there solutions/ 
optimizations?

Owen Brand
**Oprysoft**
Opry99er.com

---

From: ti99_forever <[email-masked]>
Date: Wed, 23 Dec 2009 10:15:30 -0800 (PST)

Code to _limit_ a random number looks something like:
X=INT(range*RND)+LOWERLIMIT

So, to limit a sprite to the rows from 7 to 180:
X=INT((180-7)*RND)+7
(I didn't simplify the inside parentheses so you could see what I was doing - it returns numbers from 7 to 180.)

----- Original Message ----
> From: Owen Brand <[email-masked]>
> To: [email-masked]
> Sent: Wed, December 23, 2009 1:09:46 PM
> Subject: [TI994A] Debugging XB program
> 
> ------------------------------------
> 
> Yahoo! Groups Links
> 
> 
>

---

From: Owen Brand <[email-masked]>
Date: Wed, 23 Dec 2009 13:28:59 -0500

I meant row 6 in the standard screen text configuration....  So close  
to 45 when dealing with SPRITEs.  Sorry for the confusion.  But this  
is quite helpful.  Much better than "IF MY FREAKY ENEMIES REACH TOO  
HIGH UP ON THE SCREEN THEN GOSUB REPLACE SPRITE" or the other dumb  
crap I had...  It's amazing... Step away from coding for just a month  
or two and you lose a bunch of knowledge.  I had to revisit the XB  
manual to reference color codes!!! I haven't had to do that in a year.

Owen Brand
**Oprysoft**
Opry99er.com

On Dec 23, 2009, at 1:15 PM, ti99_forever <[email-masked]>  
wrote:

> (I didn't simplify the inside parentheses so you could see what I  
> was doing - it returns numbers from 7 to 180.)
>

---

From: tursi <[email-masked]>
Date: Wed, 23 Dec 2009 11:15:56 -0800 (PST)

> lose a bunch of knowledge.  I had to revisit the XB manual to reference 
> color codes!!! I haven't had to do that in a year. 

Hehe.. I still don't know the color codes. ;)

---

From: Owen Brand <[email-masked]>
Date: Wed, 23 Dec 2009 14:22:19 -0500

Well, I still have to reference everything else....  I mean, I post  
questions on here concerning my progrming and then feel like a  
complete idiot when someone suggests something so simple and obvious  
that solves all my problems.  I'll have a function or subprogram that  
is 6 lines long, and the programmers on here will get it down to 2  
lines with a mathematical equation that takes the place of loops and  
IF THEN statements....  I memorized colors, frequencies, and all the  
graphic and music subprograms... As far as logic and math, though... I  
am sadly way behind.

Owen Brand
**Oprysoft**
Opry99er.com

---

From: "Jacques Groslouis" <[email-masked]>
Date: Wed, 23 Dec 2009 15:34:34 -0400

Just curious. Is the INT function really necessary? My understanding is that 
when a parameter in say a HCHAR, VCHAR or SPRITE statement encounters a 
decimal number that all numbers to the right of the decimal point are 
ignored. However, I agree that it might make a difference if the RND number 
is involved in a further calculation.

.Regards,

Jacques

----- Original Message ----- 
From: "ti99_forever" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 23, 2009 2:15 PM
Subject: Re: [TI994A] Debugging XB program

> (I didn't simplify the inside parentheses so you could see what I was 
> doing - it returns numbers from 7 to 180.)
>
>
>

---

From: mark wills <[email-masked]>
Date: Wed, 23 Dec 2009 11:46:52 -0800 (PST)

I think you are correct, Jacques.

IIRC, internally, numbers are represented in Radix 100 format, whether are integers or floating point. In fact, in Radix 100, there isn't really a difference.

Mark

>
>From: Jacques Groslouis <[email-masked]>
>Sent: Wed, 23 December, 2009 19:34:34
>>From: "ti99_forever" <ti99_forever@ yahoo.com>
>>To: <TI994A@yahoogroups. com>
>>> X=INT(range* RND)+LOWERLIMIT
>>>
>>> X=INT((180-7) *RND)+7
>>>> From: Owen Brand <owenbrand@opry99er. com>
>>>> To: TI994A@yahoogroups. com
>>>> ------------ --------- --------- ------
>>>>
>>>> Yahoo! Groups Links
>>>>
>>>>
>>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ------------ --------- --------- ------
>>>
>>> Yahoo! Groups Links
>>>
>>>
>>>
>
>
>

---

From: mark wills <[email-masked]>
Date: Wed, 23 Dec 2009 11:55:36 -0800 (PST)

Find the range that you want, then add an offset to stop it going lower than you want...

n=(rnd*range)+offset

Mark

>Sent: Wed, 23 December, 2009 18:09:46

---

From: ti99_forever <[email-masked]>
Date: Wed, 23 Dec 2009 11:57:51 -0800 (PST)

I may be wrong, but I think those functions actually round, so you may find yourself rounding up to the next higher number rather than truncating. There is a ROUND function in the floating point routines...
Maybe no difference, but could cause an out of range error, too, depending on the circumstances.

----- Original Message ----
> Sent: Wed, December 23, 2009 2:34:34 PM
> From: "ti99_forever" 
> To: 
> >> From: Owen Brand

---

From: "Jacques Groslouis" <[email-masked]>
Date: Wed, 23 Dec 2009 16:34:12 -0400

Ben,

You are correct. The parameters are rounded. I just ran three separate CALL
HCHAR statements using column parameters of 10.1, 10.5 and 10.8 and the last
two print one column over.

Nice to learn something new, today.

Regards,

Jacques

----- Original Message ----- 
From: "ti99_forever" <[email-masked]>
To: <[email-masked]>
Sent: Wednesday, December 23, 2009 3:57 PM
Subject: Re: [TI994A] Debugging XB program

>I may be wrong, but I think those functions actually round, so you may find
>yourself rounding up to the next higher number rather than truncating.
>There is a ROUND function in the floating point routines...

---

From: tursi <[email-masked]>
Date: Wed, 23 Dec 2009 12:48:59 -0800 (PST)

> I may be wrong, but I think those functions actually round, so you may 
> find yourself rounding up to the next higher number rather than 
> truncating. There is a ROUND function in the floating point routines... 

I believe I remember that some functions round, and some truncate, too. 
Also, if you're ever dealing with negative numbers, you may not get the 
result you expect.

Basically, use INT if you want to be sure of the integers you are getting. 
Going without it will generally work if you are aware of all the side 
effects, but every so often you might find yourself going "Huh??" ;) Or if 
the off-by-one wouldn't bother you (as in this case, most likely), then it 
is slightly faster to skip it.

---

From: "Paolo Bagnaresi" <[email-masked]>
Date: Wed, 23 Dec 2009 23:08:29 +0100

I am wishing a Merry Christmas and a Happy New Year to all the TI friends!

Paolo

---

From: "jhwhite_delphi" <[email-masked]>
Date: Thu, 24 Dec 2009 15:33:06 -0000

Almost.  X=INT((180-7)*RND)+7 results in values from 7 to 179.  To fix it, use X=INT((180-7+1)*RND)+7.

Generalized:

L=7
H=180
X=INT((H-L+1)*RND)+L

An alternative is:

X=INT((H-L)*RND+0.5)+L

Which is better?  Do both give the same sequence?  Dare I say that one gives "more random" numbers, as opposed to more "random numbers", than the other?

This is a "gimme".  Merry Christmas!

Jeff White
[email-masked]

> (I didn't simplify the inside parentheses so you could see what I was doing - it returns numbers from 7 to 180.)
<snip>

---

From: Owen Brand <[email-masked]>
Date: Thu, 24 Dec 2009 10:56:22 -0500

I changed my spaghetti plate with the aforementioned equation.  The  
speed didn't change much...  But it seemed to solve my "randomizing"  
problem.  I placed the function at the beginning of each level, that  
way the enemy patterns are set before each level begins.  I wanted to  
set it up to where the enemies would regenerate after crossing the  
left barrier, in another random pattern--- however this is proving to  
be a pain in my Christmas spirit.  So for this first version, it will  
have to remain the way it is.  After some of you have a chance to play  
it, I would be very interested in hearing some feedback and would love  
to implement some modifications.  I should have the beta version  
(minus title and music for the most part) done by next week.  Hope to  
get a few testers to help in my venture here.  Thanks

Owen Brand
**Oprysoft**
Opry99er.com

On Dec 24, 2009, at 10:33 AM, "jhwhite_delphi"  
<[email-masked]> wrote:

> Which is better? Do both give the same sequence? Dare I say that one  
> gives "more random" numbers, as opposed to more "random numbers",  
> than the other?
>