3D raycasting

With the RLE method, drawing transparent sprites goes like this:

If color is 0, then do nothing Do not draw this chunk. No blitter setup, no blitter run.
Maybe some counting in cpu registers.

For things that are round or with lots holes, this too sounds like a winner.

OK,
I cannot really understand this latter proposal
If you work on horizontal lines you have to take care of celing and floor...
but those part of the screen usually (at least in my code) is not updated if not in the areas where the columns reduced its heigth across frames
There is no update when the column increases its own size

First of all It was not really meant as a serious solution, secondly an improvement would be swapping b and c, this way we could have 1 texture of 256x64 and keep it straight *no longer 90 degrees turned* in ram. The idea behind this is that you do not have four textures of 64x64 but 256 of 1x64 (w x h)... you can make a simple brick pattern with just four 1x64 textures for instance.
And this idea can be implemented either way.
Moreover your inner loop seems slower than the one proposed by hit9918 and by NYYRIKKI
Is it?
Thirdly, switching back to the vertical approach with HMMC, the inner loop can be rewritten to:

  ld e,texture
  ld h,line ;high <offset_scale_by_line_table>
  ld l,depth

.lus
  ld d,(hl)     ; load texture offset
  inc h          ; advance to next line
  ld a,(de)     ; read texture byte
  out (9Bh),a ; out texture byte
  djnz .lus     ; 

Well how about that? Scales both ways (though limited to 256 scales total) or preforms any kind of transformation you store in the <offset_scale_by_line_table>.
And compared to the hit9918 version core, which counts 58 cycles, the above core counts 48 cycles .

@ARTRAG, I think the result of the zoom mul needs to be a fractional lengh, or else the result will be a bad mess.

I did some code which would be the cpu RLE version:

	;sp  ->RLE stream. one byte amount of runs, then length, color, length, color
	;hl'(exx) ->multable of current zoom stage (integer parts at hl'+256)
	;ix: returnaddress

drawcolumn:
	pop bc
	dec sp
	ld b,c		;amount of runs loaded into B
	
	ld a,0x80	;reset fraction adder. starting with "0.5", just an idea.
			;maybe later a fraction fed from colum draw might be fed here.

	ex af,af'	;fraction adder is in af'
nextRLE:
	exx
	pop de		;d = color, e = length
	ld l,e
	ld c,(hl)	;hl     -> multable fraction part. table must be 256 aligned.
	inc h		;hl+256 -> multable integer part
	ld b,(hl)
	dec h
			;bc = lenght 8:8 fixpoint

	ex af,af'	;switch to fraction adder
	add c		;add lengh fraction part to adder
	jp nc,adderskip
	inc b		;fraction adder overflowed, draw one dot more
adderskip:
	ex af,af'

	ld a,b
	and a
	jr z,zeropixels ;may happen with small zoom values
	
	ld a,d
fill:
	out (0x9b),a
	djnz fill
zeropixels:

	exx
	djnz nextRLE

	jp (ix)		;return after SP abuse

Tool released (matlab needed)
https://sites.google.com/site/devmsx/rle-textures
It just encodes all the png images it finds in the directory where you put the files

I think the RLE approach is very very promising.

The following 8 textures (actually 4, seen with two levels of light)

https://sites.google.com/site/devmsx/rle-textures/rletextures.bmp?attredirects=0

are stored in 6644 bytes

The plain data for the old (current) code (and is -should be- slower) need 16384 bytes !

The following 8 textures (actually 4, seen with two levels of light)

Make the palette so colors with top bit set are twice as bright.
Then turning on brightnes is just another OR 0x88 on the COLOR value.

A more extreme version would send the COLOR values thru a lookuptable.
Original DOOM looked like doing this.
This allows to use much more colors, in our case images could be of all 16 colors.
The palette just needs enough variety for darker stages to look ok.

e.g. an image got a bright brown pixel and a dark brown pixel.
in the darkened stage it would be two dark brown pixels.
in an even darker LUT, it would appear as a dark brown pixel next to a black one.

The LUT lookup increases setup overhead in the RLE version. While in classic zoom it affects the central per-pixel-draw-loop. Another case where the RLE version is fast.

p.s. if one got e.g. bright green and bright red for lights, one could force their LUT values to stay bright, this makes lights in the dark.