Out of memory when using uinteger array (*solved*) Darkstar Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-19-2011, 04:29 PM "Try this:" I will do that, maybe tomorrow if not today. Darkstar Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-20-2011, 12:13 AM 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? Quote:I can add a library 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 Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-20-2011, 02:26 AM 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 Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-20-2011, 03:51 AM I think I get it now, the first line only gives 86 possible combinations. boriel Administrator Posts: 1,733 Threads: 54 Joined: Aug 2019 Reputation: 24 07-20-2011, 08:30 AM Darkstar Wrote: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 Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-20-2011, 08:14 PM 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 Member Posts: 92 Threads: 8 Joined: Mar 2011 Reputation: 0 07-20-2011, 08:38 PM "The Z80 has to fetch and process all the extra instructions." Better use CAST then. « Next Oldest | Next Newest »