ld de, Sprite.SizeOf .Loop: ld a, (iy + Sprite.Class) ; Only elevators and boxes have the property of holding things. cp 3 jp c, .Check2 add iy,de djnz .Loop jp .Exit .Check2: ld a, (iy + Sprite.InUse) and a jr nz, .Do add iy,de djnz .Loop jp .Exit .Do: all the rest
increase the dead hole walking bandwidth.
another one is to remove the "InUse" variable.
ld de, Sprite.SizeOf .Loop: ld a, (iy + Sprite.Class) ; Only elevators and boxes have the property of holding things. cp 3 jp c, .Check2 add iy,de djnz .Loop jp .Exit .Check2: ld a, (iy + Sprite.InUse) and a jr nz, .Do add iy,de djnz .Loop jp .Exit .Do: all the rest
increase the dead hole walking bandwidth.
another one is to remove the "InUse" variable.
ofcourse if we don't have registers in use.... DE = a meaning, and BC = another meaning and pushed BC another meaning. See the context....!, no just the loop.
It would help to add a comment declaration at the top of the copy/pasted routine of which registers are used for what, inputs, outputs, and which can’t be modified. E.g.
; bcde = expected crc32 ; ix = this ; f <- nz: mismatch ; Modifies: af, bc, de, hl ; Preserves: hl' CRC32Checker_VerifyCRC32:
; bc' = byte count ; hl' = read address ; bcde = current crc ; ix = this ; bcde <- updated crc ; Modifies: af, bc, de, hl, bc', hl' ; Preserves: af' CRC32Checker_CalculateCRC32:
all this shaved
push iy
pop bc
push ix
ex (sp), hl
sbc hl, bc
ex (sp), hl
pop bc
jr z, .Next
to
ld a, ixh
cp iyh
jr nz, ....
ld a, ixl
cp iyl
jr z, .Next
too much faster, but If I really will implement a categorizing then all these checks doesn't matter anymore.
I am trying to decide, which way to go, because maintaining extra pointer list is also an overhead. And not always it can be maintained easily.
By example, maintain when creating the character, and maintaining when dissapear.
But right now, the "dissapearing" is not done by the class layer, it is done when executing the SPRITE RENDER routine, because that routine already know that the sprite is too far from screen scope, and that was the perfect place to insert some ld (ix +.inuse), 0 .... and include that feature of auto-dissapear without any extra cost!. If I move it elsewhere, it will cost. And I don't like to mix LAYER duties like maintaining lists.
It would help to add a comment declaration at the top of the copy/pasted routine of which registers are used for what, inputs, outputs, and which can’t be modified. E.g.
; bcde = expected crc32 ; ix = this ; f <- nz: mismatch ; Modifies: af, bc, de, hl CRC32Checker_VerifyCRC32:
; bc' = byte count ; hl' = read address ; bcde = current crc ; ix = this ; bcde <- updated crc ; Modifies: af, bc, de, hl, bc', hl' CRC32Checker_CalculateCRC32:
It is already in the comments. On the right...
It’s not as clear to the reader that way, spread out all over the place and requiring to dig deep into the code and comments to determine which values are temporary and which are return values, etc. As opposed to getting a quick overview of method name (=description) plus inputs and outputs at the start.
It’s not as clear to the reader that way, spread out all over the place and requiring to dig deep into the code and comments to determine which values are temporary and which are return values, etc. As opposed to getting a quick overview of method name (=description) plus inputs and outputs at the start, and maybe less comments in-line inside the routine (one can often rely on label names and code to document, in stead of comments).
If it were inputs/outputs of the routine, you can be sure that I put this detail on top, as you suggest.. bah, on top/right most case.
But in this routine DE being use to hold the current nearest distance to a solid floor capable object is INTERNAL, While BC is the output and the posted part of the routine inputs with BC = distance to floor tested in the MAP, and this routine must short that if a box is near than that, or BC = 0 telling there is no distance to floor, on that It measures the bottom edge of the sprite box with the top edge of something solid.
So the next layer works... hey I can fall 4 just pixels more...., lets limit our current gravity force which was currently 6, to 4, so lets do with 4!. That is the correct way to do when anything can be moves in any step
I wasn’t looking at DE here, just trying to quickly make sense of the routine so I could maybe make some recommendations. But I got quickly confused about what registers are used for what and which could be modified or not, gave up and went on to do something else. It’s not my code and my mind isn’t fully alert anymore at this time of the day.
If there had been a summary comment on the top as I suggested, I would instantly be able to tell that DE is temporary and not used for output. And that BC is output meaning distance to the floor, with 0 meaning no floor.
Anyway you can do with my suggestion what you wish. For me it would be helpful.
Some peephole stuff:
.TestY: ld c, (ix + Sprite.MapOy) ; Test for x. ld b, (ix + Sprite.MapTy) ld l, (iy + Sprite.MapOy) ld h, (iy + Sprite.MapTy) ; looks like carry flag is always zero here, so no need to clear it ; (always executed after xor a or and a took place) ;and a sbc hl, bc
xor a ret ; why not move SomeLabel up two instructions to save 2 bytes? SomeLabel: xor a ret
Some peephole stuff:
.TestY: ld c, (ix + Sprite.MapOy) ; Test for x. ld b, (ix + Sprite.MapTy) ld l, (iy + Sprite.MapOy) ld h, (iy + Sprite.MapTy) ; looks like carry flag is always zero here, so no need to clear it ; (always executed after xor a or and a took place) ;and a sbc hl, bc
xor a ret ; why not move SomeLabel up two instructions to save 2 bytes? SomeLabel: xor a ret
xor a is outputing ZF = 1 distance CERO, so BC is not check for CERO value.
Also inside this routine save it from doing LD BC, 0
