vindar
runtime viewport size?
It's a little inconvenient to have viewport size as template parameters to Renderer3D, as an application may support several resolutions.
I didn't see any static buffers created using these parameters, so it would be down to advantages of compile-time optimization. I'm skeptical that tgx needs these parameters to be static for performance.
I remember doing some test when I was creating the library and it think it did give a slight speed up to put these parameters as template. I will do some more testing to check if this is really needed... Note that, in the meanwhile, it is possible to create several renderer, each one with its own size. Each renderer object will use 640 bytes of RAM.
I did some test and it turns out you are right :-)
Setting the viewport dimension as regular parameters instead of template parameters does not yield any significant slowdown. In all the examples I have tried, it only reduces the framerate by 0.5 to 1 fps which is negligible
I just pushed a commit that removes the template parameters. Now, the viewport size is simply set by calling the setViewportSize() method from the class.
Thanks for the suggestion !
Oh-- I expected the size would be constructor args for Renderer3D. Wasn't it added complexity to allow the size to be changed dynamically on an instance?
Even if it's not a burden to support dynamic size, I'd still expect constructor args, as having an arbitrary default is awkward-- the user should be explicit about it.
Thank you for considering.
Oh-- I expected the size would be constructor args for Renderer3D. Wasn't it added complexity to allow the size to be changed dynamically on an instance?
No, it did not really cost anything and it provides more flexibility this way.
Even if it's not a burden to support dynamic size, I'd still expect constructor args, as having an arbitrary default is awkward-- the user should be explicit about it.
I understand your point of view but the renderer already has several parameters that must all be set correctly before being able to perform any rendering operation (the image pointer, the offset...). I think it does not make sense to force the user the set to the viewport a construction time but not all the other parameters... I used the default size 320x240 mainly to reduce breaking changes with previous examples but I agree it is ugly and was probably not a good idea.
However, I do not want to force the user to initialize the renderer to a valid state at construction time. It may look look good practice in theory but does not work well for embedded system where memory management is often static/hand managed...
Maybe a reasonable middle ground would be to add the viewport dimension (and maybe also the image pointer and the z-buffer pointer) as optional parameters in the constructor, with default null values ? It is C++ after all so we should let the user decide how it wants to shoot itself in the foot :-)
Thank you for considering.
I understand your point of view but the renderer already has several parameters that must all be set correctly before being able to perform any rendering operation (the image pointer, the offset...).
I think only setImage() is essential, correct? Offset has a reasonable default of (0, 0).
I was surprised that tgx quietly does nothing if setImage() is not called. I supposed you can default viewport size to (0, 0) and treat it similarly.