Jump to content

bogax

Members
  • Content Count

    860
  • Joined

  • Last visited

Community Reputation

218 Excellent

About bogax

  • Rank
    Dragonstomper

Profile Information

  • Gender
    Male

Recent Profile Visitors

11,338 profile views
  1. changing banks takes time if you were doing alot of that it could cause problems
  2. yes the rr##'s are the individual rotation routines they just rotate three sprites (you could think of a swap as a rotation of two sprites) and the sp##'s are the sprites they're sort of place holders, exactly what they'd end up being would depend on your code they could be plain bB variables, or you could pack them as nibbles. or you could make some of them nibbles and use the sprite x,y for some (assuming the x,y positions would be (different, unique) constants. it would be sort of inside out, the positions would get shuffled among the sprites instead of the sprites shuffled amongst the positions)
  3. I'm thinking something like this this rotates through three for each bit of rand you could probably find better choices for the three I tried swapping two but it didn't look very random (and neither does this really but it looks better than swapping) I didn't try to analyze it, I just picked some random looking stuff that is a notoriously bad idea the details would depend on exactly what you're doing there's like 500 million permutations of twelve, rand is only 8 bits and rand16 has a cycle length of 65535 dim rand16 = z rnd = rand for i = 0 to 14 step 2 p = (rnd & 1) | i on p goto rr_0 rr_1 rr_2 rr_3 rr_4 rr_5 rr_6 rr_7 rr_8 rr_9 rr10 rr11 rr12 rr13 rr14 rr15 nxt rnd = rnd/2 next rr_0 temp1 = sp0 : sp0 = sp3 : sp3 = sp10 : sp10 = temp1 : goto nxt rr_1 temp1 = sp0 : sp0 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr_2 temp1 = sp1 : sp1 = sp9 : sp9 = sp10 : sp10 = temp1 : goto nxt rr_3 temp1 = sp1 : sp1 = sp4 : sp4 = sp11 : sp11 = temp1 : goto nxt rr_4 temp1 = sp2 : sp2 = sp7 : sp7 = sp10 : sp10 = temp1 : goto nxt rr_5 temp1 = sp2 : sp2 = sp10 : sp10 = sp11 : sp11 = temp1 : goto nxt rr_6 temp1 = sp3 : sp3 = sp5 : sp5 = sp10 : sp10 = temp1 : goto nxt rr_7 temp1 = sp3 : sp3 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr_8 temp1 = sp4 : sp4 = sp10 : sp10 = sp10 : sp10 = temp1 : goto nxt rr_9 temp1 = sp4 : sp4 = sp6 : sp6 = sp11 : sp11 = temp1 : goto nxt rr10 temp1 = sp5 : sp5 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr11 temp1 = sp5 : sp5 = sp9 : sp9 = sp11 : sp11 = temp1 : goto nxt rr12 temp1 = sp6 : sp6 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr13 temp1 = sp6 : sp6 = sp9 : sp9 = sp11 : sp11 = temp1 : goto nxt rr14 temp1 = sp7 : sp7 = sp8 : sp8 = sp10 : sp10 = temp1 : goto nxt rr15 temp1 = sp7 : sp7 = sp10 : sp10 = sp11 : sp11 = temp1 : goto nxt
  4. I found this PCG: A Family of Simple Fast Space-Efficient Statistically Good Algorithms for Random Number Generation (from this page) interesting bB rand16 is kinda like that (with an LFSR instead of LCG)
  5. How would you get 12 sprites?
  6. Here's some scatters I did of some LFSRs combined with a simple LCG x'=x*17+103
  7. so you want a shuffle? that's a somewhat different problem (Wikipedia)
  8. here (pastebin) is some javascript to do scatterplots of the bB rand LFSR(s) did this a while ago and just came back across it so you may have seen it looks like there's points clustered at the edges. that makes me wonder if it works the way it should I don't specifically recall (and I haven't looked yet) but I assume it plots this value against the previous value rand 16 looks a lot better
  9. rand is just a counter that counts in a funny sequence if you start from the same spot it will count through the same sequence
  10. bogax

    Polarium

    heh I just realized you're telling it to turn on the 12th line in phline (you want row 10)
  11. bogax

    Polarium

    1line13.bas has 10 lines in the playfield definition I don't know why pfhline isn't working, but maybe that has something to do with it
  12. bogax

    Polarium

    this is untested assuming a set of flags in ram consisting of 18 consecutive bytes (for a 16 x 9 matrix) here starting with h also assumes the puzzle is in the middle two byte columns ie the flags are for pfpixels 8..23 x 1..9 with pfpixel 7, 0 being puzzle 0, 0 visited(col, row) will return true (non zero) for a set pixel flag (kinda like pfread) and setvf(col, row) should set a flag the parameters are column x row in pfpixels and assume that the upper right corner of the puzzle matrix is at 1, 1 (at least that's what they're meant to do, like I said, untested) dim vfx = temp1 dim vfy = temp2 dim vfptr = temp3 const vbase = h ; z - 18 const midsb = setbyte + 8 function visited() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vfptr = midsb[vfx] & vbase[vfptr] return function setvf() vfx = vfx - 1 vfptr = (vfy - 1) * 2 vfptr = vfx / 8 | vfptr vbase[vfptr] = midsb[vfx] | vbase[vfptr] return
  13. bogax

    Polarium

    I think this is what you want you need to increment by 1 and write another byte then increment by 3 I put some junk on the right of the first one to show where it's going asm ldx level ; ballx ldy x11,x ; level x 11 look up ldx #$0A lda #>col0_dat sta temp4 lda #<col0_dat sta temp3 loop_col0 lda (temp3),y sta var0,x iny inx lda (temp3),y sta var0,x iny inx inx inx cpx #$26 bne loop_col0 end return otherbank data x11 0, 14, 28, 42, 56, 70 end data col0_dat %01111110, %00000000 %01000010, %00000000 %01110110, %11100001 %01101110, %10000001 %01000010, %10000001 %01111110, %11100001 %00000000, %00000000 %00100100, %00000000 %01100110, %00000000 %00111100, %00000000 %00100100, %00000000 %00011000, %00000000 %01100110, %00000000 %00000000, %00000000 %00111100, %00000000 %01011010, %00000000 %01111110, %00000000 %01011010, %00000000 %01100110, %00000000 %00111100, %00000000 %00000000, %00000000 %01000010, %00000000 %01111110, %00000000 %01001010, %00000000 %01111110, %00000000 %01010010, %00000000 %01111110, %00000000 %00000000, %00000000 %01000010, %00000000 %00110010, %00000000 %01011010, %00000000 %01011010, %00000000 %01001100, %00000000 %01000010, %00000000 %00000000, %00000000 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %01111111, %00000111 %00000000, %00000000 end
  14. bogax

    Polarium

    not sure what you mean by overlay you could just swap the pixel visited flags with the play field and/or flicker them
  15. bogax

    Polarium

    well there's the aux1..aux6 variables which are part of the stack you can probably use (some of) them if you don't go to deep on the stack (I think the score uses some of the aux variables) there's var44..var47 don't know but they may be available if you're only using one sprite there maybe some associated space there you could use my point was, doesn't seem like you would need that much
×
×
  • Create New...