Another renderer redesign and a bit of a rant

Actually not a complete redesign but it's just too much code to write if you want to create optimized loop for every possible special render command. This is especially true for combinations of alpha or palette changes as I'll have to iterate through buffers very often, meaning a lot of code to check and a lot of loops that profit by dropping the rather heavy buffer macro logic.

Instead, I'll drop the palette stuff and add provide multi-stage alpha renderer that'll draw a colored background rect followed by n images taking from the image input buffer. You can of course also do multiple render commands for one image, but as it's common for color graphics or blend them with other of the same size, this process can be speed up a bit. This makes the renderer smaller and the parameters to set in a command far fewer for the user. Large grids or series of images you don't want to generate huge arrays of positions for can be done using matrix operations before each image render command. Actually I think it would be more beneficial to implement some sort of loop or command for n times long recursion so that you don't need to bind repetition to the display list or the command string. This makes it possible to use fully use matrix operations, position arrays or a mix of both.

Yep, I guess that's the best approach I can think of right now. I don't have much time besides doing rather dull QA work every day at work. I'd be glad to get to the programming part of my internship... I mean yes, QA surely is an important in this particular company (and this has more than a triple meaning...), but I'm not made for such information overload as I'm getting it right now. They'll start to use Scrum in the next few days, so I hope that stuff gets more ordered and less last minute. I'm not a simple thinker to beeing able to cope with QA work but I just can digest too much ever-changing informations or even do many things at once. I can perfectly focus one thing and get it done very well - in essence just like a Unix program. So if there isn't coming anything interesting or fulfilling out of it the next few weeks I'm gonna check whether I can start do 50/50 QA and programming or even tool programming work. I can't even properly study their code base (undocumented) or their engine (rather documented though horribly concepts) when doing QA stuff, so it takes just too much time. Ok, it's been two weeks of 6 months, so what am I complaining about... I know how fast I loose motivation if something isn't made for me and escrow phases are exactly that kind of thing where I don't like to do QA cause you really need to do QA there.

I'd rather like to find and reproduce hard-to-find bugs and point the mistakes they made during development. That's way more rewarding than once again testing whether the designers managed to hit the right commit button!!

No comments: