Fast chunky gouraud shadin inner loop.

Greetings, All! Subj looks surprisingly elegant and simple: ;hl-address in the chunk brightness table (256 bytes 0 brightness ... 256 bytes 15 brightness) ;de - chunky screen ;bc - 8.8 brightness step ldi add hl,bc 27 cycles per chunk you can do it like this hl- brightness bc,de - see above ld a,h ld(de),a inc e add hl,bc 26 bars/chunk however, the latter method cannot be used with 82 clock pin chunks to the screen. I wish you health, happiness and creative Uzbeks. Aleksey Malov aka VIVID/Brainwave.

Khayushki, Vyacheslav! Somehow on 01-04-00 at approximately 22:14:00 someone Vyacheslav Kalinin reported (a/o) for Aleksey Malov that "Fast chunky gouraud shadin inner loop." [ ] VK> It’s just written in the demo that they say don’t use index ones VK> registers, but for example I have no idea how to calculate mat read less stuff :-)))) And think more with your head. For DEMOCs, not using ix/iy is yes, it will be somewhat faster. For any normal person more or less big programs (especially for working with arrays) index registers come in handy. Although there would be a desire, you can do without ix/iy. Can you imagine how to calculate? - Easily! Upload your address to HL and get started! Yuzaya INC HL / DEC HL VK> rits without IX, IY, and also in matrices it is necessary to divide, but as for example VK> can you divide the number by 9 so that it also works quickly? Here is the source that FK0 sent me once. ===================================================== ; bc=bc/de hl=bc%de DIV LD A,D: OR E: SCF: RET Z LD HL,0 LD A,B LD B,16 DIV1 SLA C: RLA ADC HL,HL SBC HL,DE: JR NC,DIV2 ADD HL,DE DEC C DIV2 INC C DJNZ DIV1 LD B,A XOR A RET ; 28 bytes, 1346 clock cycles max. ===================================================== VK> And if you can, tell me how to quickly increase VK> chunk screen is not exactly 2 or 4 or 6 times, but a little bit half a pixel :-)))))))))) [ ] VK> come to you, and please explain how you output chunks in the demo VK> hey, I dug around there but found a design like this VK> like: VK> . . . VK> .. .. VK> POP HL VK> ADD HL,BC aARTYY6TYGG VK> LDD By the way, this is exactly how it comes out! What you couldn't understand is most likely due to with no comments? ;) The principle is simple: took from the table (calculated long ago) the initial ADDRESS, added OFFSET to it ==> got address for withdrawal, withdrawn to this address. Although in this case there is a slightly different option: The memory contains the complete image of the displayed image. Since we are scaling/rotating something there, then you need to output not one to one, but with correction. So DE indicates “where we will output on the screen." The starting address is removed from the stack “where to output from” and added an offset. Moreover, very much in [C] we store the offset by horizontal, and in [B] the vertical offset. Added it up and got the real address of the point that shouldbe displayed at the current point on the screen. We took her out via LDD and moved on to the next point in this line. By the way, this cannot be explained in words :) You have to feel it for yourself, for yourself. figure it out and see :)))) Well that's it *MAS* with a sledgehammer