Quote from: ScoutDavid on December 18, 2010, 12:28:43 pm

Quote from: Fast Crash on December 18, 2010, 10:09:48 am

I'm playing civilization V so it will be later  

Hum... OK.

It didn't work, the appvar is created, but the HS is always 0, both for easy and hard.

Code: [Select]

!If GetCalc(NAME)→H
Fill(0→{GetCalc(NAME,SIZE)→H},SIZE-1)
End
I gotta try that too

Runner always optimizing

That leaves the pointer in the Fill( statement at zero, so you're basically copying size-1 bytes starting at address $0000, instead of the address of your appvar, which is definitely not what you want.

Try

Code: [Select]

!If GetCalc(NAME)
0→{GetCalc(NAME,SIZE)→H}
Fill(H,SIZE-1)
Endinstead.

Storing the value to a static pointer would return 0, but storing it to a variable pointer returns the pointer. For example, whereas 0→{Str1} would return 0, 0→{A} would return A.

EDIT: And just a side note, storing a two-byte value to a variable pointer, like 0→{A}^r, would return A+1.

Instead of a For() loop, you can use the Fill() command to fill a section of memory with a value. That, and a few other optimizations:

!If GetCalc(NAME)→H
Fill(0→{GetCalc(NAME,SIZE)→H},SIZE-1)
End
It might be a good idea to check whether or not creating the appvar was successful, though. You wouldn't want the game to proceed, thinking that the appvar exists when it really doesn't.

Yeah, I already stole borrowed your routine for the fact that it can output a 32-bit result.

Yes, the textures have a lot to do with it. Even if you don't know assembly, you can probably guess that drawing an untextured wall slice:
ld de,12
DrawWallSliceLoop:
ld a,c
or (hl)
ld (hl),a
add hl,de
djnz DrawWallSliceLoop

Will run a bit faster than drawing a textured wall slice:
DrawWallSliceLoop:
ld de,(var_N)
ld bc,(var_R)
WallSpriteShiftLoop:
ld a,d
or a
jr nz,WallSpriteShiftEnd
ld hl,var_S
ld a,(hl)
or a
jr z,WallSpriteShiftEnd
dec (hl)
ld hl,(var_T)
add hl,hl
ld (var_T),hl
ex de,hl
add hl,bc
ex de,hl
jr WallSpriteShiftLoop
WallSpriteShiftEnd:
dec d
ld (var_N),de
DrawFirstWallPixel:
ld hl,(var_P)
push hl
ld bc,-plotSScreen
add hl,bc
pop hl
jr nc,DrawWallPixelSkip
ld a,(var_T+1)
rla
jr nc,DrawWallPixelSkip
ld a,(var_M)
or (hl)
ld (hl),a
DrawWallPixelSkip:
ld de,12
add hl,de
ld (var_P),hl
ld hl,(var_U)
dec hl
ld (var_U),hl
ld a,h
or l
jr nz,DrawWallSliceLoop


Because of this, my primary optimization goal is to try to do something about this.

EDIT: I already have some ideas about how to try to normalize the time drawing a wall slice takes.

This is a somewhat challenging routine I've been trying to develop for z80 assembly. I'm trying to find a way to multiply two signed 16-bit operands together and get a signed 32-bit result.

I already have one working method, although it's fairly hacky. Its general structure is as follows:

• Xor the high bytes of the two operands and push af
• Convert the operands into their absolute values
• Multiply these two values with the normal restoring multiplication algorithm
• Pop af and return if sign flag is unset
• Negate the result of the multiplication and return

Somehow, I get the feeling there are faster and/or more elegant solutions than this.

The most elegant solution would just be a modified restoring multiplication algorithm that deals with signed numbers correctly. After having stared down the restoring multiplication algorithm for about the past hour, I don't know how reasonable this is, though. And unless there's some simple change I'm not seeing that would suddenly make this work, any solution of this form would probably consume a lot of extra cycles in each iteration.

Something that has occurred to me as a more achievable and probably faster solution, albeit larger, consists of a test that branches into one of three different versions of the restoring multiplication algorithm. Which algorithm to use would be determined based on whether neither, one, or both of the operands are negative. This is the method I am currently trying to develop. After a bit of messing around with the restoring multiplication algorithm, though, I'm still fairly confused about how to form the two modified algorithms that would be needed.


Any ideas?

You know ld h,d / ld l,e is faster than push de / pop hl, right?

Oh, I thought you wanted to split it up into 8x8 sprites so you could then use the built-in sprite routine to draw an array of 8x8 sprites. If you're fine with just copying the 24x24 sprites aligned to byte boundaries on the buffer, then may I suggest a routine like the following:

Syntax: sub(24S, Column (0-9), Row (0-40), Sprite pointer)

Lbl 24S
  24+1
  Lbl 24L
  Return!If -1→r₄
  Copy(-1*3+r₃,r₄+r₂*12+r₁-12+L₆,3)
  r₄
Goto 24L
Lbl 24S
  +72→r₄
  ⁻()→r₅
  r₂*12+r₁-12+L₆→r₆
  r₃
  Lbl 24L
  Return!If +r₅
  Copy(+r₄,r₆+12→r₆,3)
Goto 24L