Out of memory when using uinteger array (*solved*)

[Darkstar]

"Try this:"

I will do that, maybe tomorrow if not today.

[Darkstar]

Hi.

I tried what you suggested and I came up with this:

Code:

rn=(randint()/86)+1
if rn>3 then border 4:stop:end if
print at 0,0;rn;

Two of those are for testing purposes but this code fails because it is not random enough as the sequence begins to repeat itself. But rn is an 8bit value so I should change it to uinteger and provide a different
divider unless you know of a faster way other than division?

I can add a library <rand.bas> which contains a randint() routine, for example (it's just a simple call to RAND routine).

I think that would be a very good idea 8)

EDIT:

Code:

__LABEL__DrawTriangles:
    call _randint
    ld de, 21846
    call __DIVU16
    inc hl
    ld (_rn), hl

It worked by changing the divider from 86 to 21846 using a uinteger variable.

Thanks.

By the way, the library, it would be "nice" if it would accept arguments like RND. For example, UIRND for unsigned integer RND or a ULIRND for a unsigned long integer RND.

[Darkstar]

Turns out that chancing the divider only to a 16bit value is enough and leaving the rn variable as an 8bit value is OK.

Code:

__LABEL__DrawTriangles:
    call _randint
    ld de, 21846
    call __DIVU16
    inc hl
    ld a, l
    ld (_rn), a

But why would you need a 16bit resolution in a divider that covers an 8bit range or ubyte to ubyte? Unless of course the range is 256*176 = 45056 and 45056 / 4 = 11264 and 11264 / 3 = 3755.
Or the resolution needed for the random sequences and that relates to the number of pixels on the screen for each triangle.

[Darkstar]

I think I get it now, the first line only gives 86 possible combinations.

[boriel]

I think I get it now, the first line only gives 86 possible combinations.

That's it!

In fact, better do CAST(Ubyte, Rand()). This is the fastest way, however, many random number generators suggest to use a middle 2nd byte, so:

Code:

Function Fastcall RandByte as Ubyte
    asm
    call RAND  ; 32 bit rand number in de:hl
    ld a, e       ; take the 2nd higher byte; Ubyte functs returns result in A reg.
    end asm
End Function

Another way is to use AND 0xFF (byte), or AND 0xFFFF (ubyte), but CAST is the best way (or just direct assignement).

[Darkstar]

That did it!

Code:

rn=(RandByte()/86)+1

Turns into:

Code:

    call _RandByte
    ld h, 86
    call __DIVU8_FAST
    inc a
    ld (_rn), a

Now it works "without" the limitation of the random number generator. Less division and now the routine can use a 8bit division so thanks a lot.

I think it would be better to use something like RandByte and such instead of adding to the size of the compiler with "nice" features, unless there is a cheap way to do it.

But I have another question.

Code:

__LABEL__DrawTriangles:
   call _randint
   ld de, 21846
   call __DIVU16
   inc hl
   ld a, l ; Transfer
   ld (_rn), a

Here it has to use an extra instruction to transfer between 16bit and 8bit and I do notice that there are many such instructions in my code and sometimes there is a accompanying statement like "ld h,0" and
thinks like that. On that level, minus the calculation routines, isn't then the 8bit data type slower than the 16 bit data type even though there is twice as much data to transfer? The Z80 has to fetch and process all the extra instructions.

[Darkstar]

"The Z80 has to fetch and process all the extra instructions."

Better use CAST then.