Interesting polymorphic problem.

The forum is locked. These are the original blitzbasic.com forums, kept so they can still be read. No new topics, replies or edits can be made here. To join in, head over to the Blitz3D+ forums.

AlexO

I like the renderstate idea, I was just trying to keep the draw function as simple as possible for speed, and having to check if the renderstate has changed each time is an extra bit of code I'd rather avoid ...

This is where stacks come in handy . I refactored your original example of the types to give the same result below. Added in renderstate stacks to show you don't have to check if a renderstate has changed

example:

Type TSprite
   Field rState:RenderState

   Method Draw()
	rstate.Push()
	' draw stuff
	rstate.pop()
   End MEthod
	
	Method SpecialDraw()
		setBlend LIGHTBLEND
	end Method
End Type

Type TPlayer extends TSprite
   
 	Method Draw()
		super.draw()
		super.specialDraw()
		super.draw()
	end Method

End Type

Type RenderState
	global stack:Tlist = createList()
	field alpha
	field scalex
	field scaley
	field rotation
	field blend
	field r,g,b
	
	method new()
		r= 255
		g = 255
		b = 255
		alpha = 1
		rotation = 0
		scalex = 1
		scaley = 1
		blend = SOLIDBLEND
		
	end method

	method set()
		setcolor r,g,b
		setrotation rotation
		setalpha alpha
		setscale scalex,scaley
		setblend blend
	end method

	method push()
		stack.addLast(Self)
		set()
	end method

	method pop()
		stack.removeLast(Self)
		RenderState(stack.Last()).set()
	end method
End Type

I can't see any other way around the recursion. I imagine if you wanted specialDraw() to setup some sort of lighting algorithm you can do that in specialDraw(), but do not call Draw() in the same function. In Player you call specialDraw() then draw(). This might sound cumbersome but look at the whole picture in the end:
- when I create a player type all I have to do is calle myPlayer.draw(). no needed extra work.