The software rendering world

dithering – part 2 May 23, 2006

Yesterday I was coming back from work when I remembered the idea about doing realtime dithering… I had started in 1999 to make some routines but since the concept was not that complex, I prefered to recode rather than lose 2 hours searching on the amiga hd… lo and behold, some time later I managed to make a simple moving stripe routine in 256 greyscales, and later added the filter to convert the 256 greys to 16 grey values via floyd-steinberg dithering…

Using 4 bitplanes instead of 8 (16 instead of 256 colors) gained half of the speed of the chunky2planar routine (the dumping from fastmem to chipmem), but the dithering is still far from optimised so perhaps there is still hope about using it for more complex routines :)

dithering – part 1 May 22, 2006

I don’t exactly remember the first time I saw a dithered picture, but I must have been a lot of ages ago… since then, I was really fascinated with all those patterns which seemed to multiply the colors… soon after I started coding demos, I tried to make my own dithering routine but of course the first attempts failed :)

Later on, just before the euska party 5, we were preparing a nice invitation demo and for some strange reason the dithering theme appeared on #amycoders… this led me to code a little “dithered-rotozoom” by making some 4×4 ordered dither patterns and using them as a virtual character mode screen:

But dithering was not forgotten as you will see soon…

How about some more advanced texturing? May 17, 2006

So, I recall sometime about 8 years ago, Ryan/Centolos told me that he had added support for texture + RGB interpolation to his 3dfx renderer, and was bitching about the fact that, while adding the support to the software renderer was possible, it would probably take a big hit on the speed due to the need to interpolate another 3 values per-pixel…

Fast forward a couple of years later, and you’d find me bored one day when I remembered this conversation and, like any bored amiga coder would do, started to think… RGB interpolation, if PC can do it, why not on amiga?… I already had a routine which interpolated 4 texture coords and had released it on synthesis (the tex+bump+env+shade rotozoomer), and recalled that registers were a bit short so didn’t realize at first how to cram not 4 but 7 interpolators into the inner loop, but luckily I had just started to work near home so every day I had a full hour of emptiness to fill with arguments about this optimisation

I recall this took one or two weeks, but finally I managed to cram all the crap into the registers…

;
; texture + bump + environment + shadetable + additive RGB texturer
;
; interpolated RGB values are added after modulating
; the texture color with the environment, so I'm not
; too sure this is really of any help for visual effects,
; but anyhow...
;
; pending: if (when) i get a 060, attempt to
; better utilise the dual pipelines
;
; d0	JJjjVVvv	a0	DJdjDVdv
; d1	IIiiUUuu	a1	DIdiDUdu
; d2	RRrrBBbb	a2	DRdrDBdb
; d3	ccGGgg--	a3	01DGdg--
; d4			a4	TT00DJDI	texture.b + 0.b + bump.w
; d5			a5	EE		environment.b
; d6			a6	RRGGBB--	screen.l
; d7			a7	RRGGBB--	shader.w

.xloop	move.l	#$ff00ff00,d4
	move.l	#$00ff0000,d5
	move.l	d4,d6
	move.l	d4,d7
	and.l	d0,d6		; d6 = JJ--VV--
	and.l	d1,d7		; d7 = II--UU--
	and.l	d2,d4		; d4 = RR--BB--
	and.l	d3,d5		; d5 = --GG----

	lsr.l	#8,d7
	or.l	d6,d7		; d7 = JJIIVVUU
	or.l	d5,d4		; d4 = RRGGBB--

	move.l	(a4,d7.w*4),d6	; d6 = TT--DJDI
	swap	d7		; d7 = ----JJII
	add.w	d6,d7		; d7 = ----JJII + bump
	swap	d6		; d6 = ----TT--
	move.b	(a5,d7.w),d6	; d6 = ----TTEE

	add.l	(a7,d6.l*4),d4	; d4 = RRGGBB--
	move.l	d4,(a6)+

	add.l	a0,d0
	add.l	a1,d1
	add.l	a2,d2
	add.l	a3,d3
	bcc	.xloop

This was done after I had stopped making any productions, so it has sit unused for some years… but lately I’ve been thinking about normal mapping for amiga and the though of having to interpol the normal for the per-pixel lighting calculation reminded me of this one…

ps. notice that this routine doesn’t need any memory accesses besides the texture ones. keeping the deltas on the stack would free 3 registers, so it would definitely be possible to interpolate even more values ;)

normal mapping May 2, 2006

Code-wise, I was already expecting some amiga demos to use HDR or at least light-bloom effects, so it didn’t take me so off guard upon seeing it on both tbl and ephidrena demos… but ephidrena’s use of bloom + normal mapping gave a very very very great look to the demo, even if it was a bit too slow… but then again i haven’t coded any complete 3d engine yet (no, i’m not kidding, i always were a 2d effect junkie) so maybe it’s just too damned complex…

So, while taking a walk back from work today, I started to wonder about how I’d implement normal-mapping on amiga, and later on I’ve downloaded some normal-mapping lightwave plugins for OSX that manage the creation of normal maps via the well-known method of having both a low-poly and a high-poly object and somehow mixing them. The page even provided a simple and effective manual on how to make a test from start to finish, so I was able to make a simple and crappy blob, generate a normal map and then use it to render the lowpoly object. So, providing I could manage to endure the creation of some lightwave scene exporter or at least a newschool lightwave object loader, I’d be able to use a normal-mapped in some yet-to-be-written-engine.