<div dir="ltr"><div><div><div><div><div><div>The other day we were talking in IRC a bit about fps, and I mentioned that I had problems with my experiments at doubling the fps<br><br></div>When I double the fps, that screws up pixel-based movement speeds. For example, in my sidescroller's scripting, there are many objects that move at a speed of 3 pixels per tick, or 5 pixels per tick. If the fps is doubled, the tick length is halved, and so to keep the movements the same, I have to halve the movement speeds.<br>
<br></div>However, we can only have integers in plotscripting right now, so I can't do speeds of 1.5 or 2.5<br><br></div>I got to thinking, and I imagined a ScruchSlice<br><br></div>The ScrunchSlice would be like a ContainerSlice, but it would have the added property of modifier for x and y coordinates of its immediate children.<br>
<br></div>For example, if I made a ScrunchSlice with a modifier of 2, and set it to fill the screen, it would behave as if it was 640x400 instead of 320x200. This would (with appropriate scripting) be a way of easily simulating sub-pixel resolution. The actual ScreenX and ScreenY of the child slices would be rounded to the nearest pixel.<br>
<br></div><div>This would be very handy for my own game, but before I implement it as a built-in feature I want to discuss it, because I would not want it to interfere with any other plans.<br><br></div><div>I imagine that at some point in the future we might be fancy enough to have a ScaleSlice that actually transforms not just the position, but also the size of its children and grandchildren, so that is why I would name this slice a ScrunchSlice, to make it clear that it is not a ScaleSlice<br>
<br></div><div>Does this sound crazy?<br><br>---<br></div><div>James<br></div><div><br><br></div></div>