If you're using an 8x8 texture, that's only 64 possible coordinates needed, so you could just have one byte store both the x and y coordinate in the LUT.

You don't need to unpack anything. Just store a number from 1-64 which corresponds with the index of each pixel in the texture as if it was a 1-D array.

You don't need to unpack anything. Just store a number from 1-64 which corresponds with the index of each pixel in the texture as if it was a 1-D array.

Oh that's actually a good idea. I'll try and see how faster it is.

Quote from: Matrefeytontias on January 26, 2014, 11:03:00 am

I'm sure you can make it at least twice faster with ASM, because if I had to make the drawing code in C it would be (direct translation from Axe) :

Code: [Select]

for(y = 0; y < 64; y++)
  for(x = 0; x < 96; x++)
    plotSScreen[y * 96 + x] = texture[ (ylut[y * 96 + x] & 7) * 8 + xlut[y * 96 + x] ];

Lemme get on my PC and I'll attach the source.

I hope this code is slightely faster, but I haven't been able to test it, so I'm not sure if it even works.

Code: [Select]

;°xlut -> A
;°ylut -> B

Render:
  ld hl, plotsScreen
  push hl

RenderLoop:
  ld c, 8
  xor a
ByteLoop:
  ld hl, (A)
  ld b, (hl)
  ld hl, (B)
  ld e, (hl)
  ld d, 0
  ld hl, texture
  add hl, de
  ld d, (hl)
  inc b
TexelLoop:
  sra d
  djnz TexelLoop
  set 0, a
  jr c, TexelEnd
  res 0, a
TexelEnd:
  ld hl, (A)
  inc hl
  ld (A), hl
  ld hl, (B)
  inc hl
  ld (B), hl
  sla a
  dec c
  jr nz, ByteLoop
  rr a
  pop hl
  ld (hl), a
  inc hl
  push hl
  ld de, Plotsscreen+768
  or a
  sbc hl, de
  jr z, RenderLoop
  pop hl
  ret


As I seldom have access to my PC, that will require some time before testing.

Yeah, I use 8 BPP for the texture to avoid bit unpacking. It's definitely not Axe's thing.

Actually I use another code now, based on fb39ca4's proposition. In C, it would be :

// usual for loops, x, y
plotSScreen[y * 96 + x] = texture[ tlut[y * 96 + x] ];I'll put a pointer to texture in $8000 and a pointer to tlut in $8002.

But no, in Axe I must pack the bits to plotSScreen

Okay, so I optimized your a bit and completely replaced my drawing code by it. I also replaced the translation by a simple texture wrapping. Everything happened to work, and HOLY SHIT IT'S FAST

I really think that speed was multiplied by 6 or 7. Be ready for an awesomeness galore. Note that these screenshots are still 6 MHz and that the program is actually faster and smoother on-calc

Apart from that, it now requires a little bit more than 7500 bytes of RAM, instead of the previous 13800

DEFORM.8xp is the Axe source, PLDEFORM.8xp is the executable. As before, put a number f [0, 5] inclusive in Ans before using it, no out-of-bounds test made blah blah blah. I was busy working on optimizing it

Woah that's quite a nice speed improvement !