reject frames larger than the Update buffers (fixes #65)#116
Conversation
The Update frame buffers are fixed at 256 * 64 pixels; larger frames (e.g. a 512x128 FlexDMD or the 192x256 video screen of pinball/video hybrids) overflowed the heap in the Update* memcpy calls. Reject them with an error log instead.
francisdb
force-pushed
the
fix-update-bounds
branch
from
190f25f to
3f9f7af
Compare
|
Once this is merged we could switch to |
There was a problem hiding this comment.
Calling this function every single frame seems like it could introduce extra latency. Maybe it should be inlined or static, but I will defer to @mkalkbrenner / @toxieainc as I don't really know compilers like they do.
|
I would be surprised that a multiplication and compare add any measurable overhead but optimizing of course makes sense. Also this will probably flood logs, do I add a flag to log only once? |
|
It's not just a multiplication and compare, you're pushing the current address onto the stack, pushing two variables onto the stack, jumping to the function, popping the variables from the stack, popping the address from the stack, X however many times a second this function gets called. But I remember being told modern compilers can be smart enough to realize that, and automatically handle it. All I know is we want this stuff to be as fast as possible. |
|
@francisdb thanks for pointing that out. I think that the simple multiplication width x hight is wrong, because the aspect ratio matters as well. For 512x128 FlexDMD, it would make sense to downscale the frame instead of rejecting it. What is a 192x256 video screen of pinball/video hybrids? |
|
3 participants
The Update frame buffers are fixed at 256 * 64 pixels; larger frames (e.g. a 512x128 FlexDMD or the 192x256 video screen of pinball/video hybrids) overflowed the heap in the Update* memcpy calls. Reject them with an error log instead.
see also vpinball/vpinball@713a5f6
fixes #65