02-13-2023, 12:10 PM
Well, it was a very stressful week, but I finally found the time and mental resources to finish
tackling hardware images and implement in my code. I had been hesitant, since it seemed like I
would have to overhaul a bunch of things to make it work, but after some more study and testing,
I ended up only needing to add five lines of code and change one existing line:
- At start of program, "displayorder hardware"
- At start of level editor, which does not use the same display method, "displayorder software hardware"
- At start of play level routine, which can be run from level editor, "displayorder hardware"
- In display_screen routine, "hardware_image = copyimage(full_screen, 33)"
- In display_screen's putimage statement, replace full_screen with hardware_image
- At end of display_screen routine, "freeimage hardware_image"
Rather than completely rework every image to be processed as hardware, for now it's enough to
simply offload the final resize operation to a hardware draw, since it's by far the most expensive step.
I ran tests using the frame advance playhead feature of my level editor, putting the playhead
at the end of the stage, about 12,000 frames in, which is about three and a half minutes of level.
With the stretching being done at software level, it took 260.9336 seconds, which is LONGER than the
level should take to play normally. Using hardware just for the stretch, as described above,
it took 19.78125 seconds, which is a drop by 92.42%.
(If I didn't do any drawing at all during the simulation process, only at the end to check the overall
time, it took 8.628906 seconds, so while not really relevant to the hardware image question, it is
what I'll want to do when actually using the level editor. I wonder if I can get that to be even faster,
9 seconds is a while to wait every time I want to check subtle changes I make to the script!)
I did run into some confusion, for a while I was having to hunt down an "invalid handle" error.
This was very confusing, since all my investigation confirmed my image handles were not invalid
anywhere. It turns out that when using a hardware image as the source handle, PUTIMAGE really does
not want there to be a destination handle at all. I think this should be returning a "syntax error"
or something, not "invalid handle," since the latter makes it seem like one of the handles does not
refer correctly to an image surface. It also introduces a limitation, since it means the source
coordinates can't be used, meaning hardware images can only be drawn in entirety, not pieces of them
at a time. That makes them either extremely awkward or totally useless for sprite sheets.
Under some circumstances, at the end of the simulation, the screen would go black at a SLEEP statement.
Still not sure what caused this, it's something for me to keep in mind going forward in case it causes
any issues, though I don't normally use SLEEP unless I'm running a test on something.
Clearing up the massive performance drain of a software screenwide image stretch on every frame,
it became possible for me to see perceptible differences in the expense of other elements of the
simulation loop, which gives me useful information on where performance can be improved. There are
things I haven't gotten around to yet, such as storing unit vector information, in order to reduce
trigonometric operations in favor of much less expensive linear interpolation.
This doesn't land on 100%, because these elements interact with each other, so commenting out one
influences how much the others have to do. The simulation does not include handling player input
nor player-specific collision interactions. But these are good starting ballpark figures.
Thanks very much for your help in pointing me toward hardware images, while it's not a catch-all
solution for other things, it did help tremendously in this case!
tackling hardware images and implement in my code. I had been hesitant, since it seemed like I
would have to overhaul a bunch of things to make it work, but after some more study and testing,
I ended up only needing to add five lines of code and change one existing line:
- At start of program, "displayorder hardware"
- At start of level editor, which does not use the same display method, "displayorder software hardware"
- At start of play level routine, which can be run from level editor, "displayorder hardware"
- In display_screen routine, "hardware_image = copyimage(full_screen, 33)"
- In display_screen's putimage statement, replace full_screen with hardware_image
- At end of display_screen routine, "freeimage hardware_image"
Rather than completely rework every image to be processed as hardware, for now it's enough to
simply offload the final resize operation to a hardware draw, since it's by far the most expensive step.
I ran tests using the frame advance playhead feature of my level editor, putting the playhead
at the end of the stage, about 12,000 frames in, which is about three and a half minutes of level.
With the stretching being done at software level, it took 260.9336 seconds, which is LONGER than the
level should take to play normally. Using hardware just for the stretch, as described above,
it took 19.78125 seconds, which is a drop by 92.42%.
(If I didn't do any drawing at all during the simulation process, only at the end to check the overall
time, it took 8.628906 seconds, so while not really relevant to the hardware image question, it is
what I'll want to do when actually using the level editor. I wonder if I can get that to be even faster,
9 seconds is a while to wait every time I want to check subtle changes I make to the script!)
I did run into some confusion, for a while I was having to hunt down an "invalid handle" error.
This was very confusing, since all my investigation confirmed my image handles were not invalid
anywhere. It turns out that when using a hardware image as the source handle, PUTIMAGE really does
not want there to be a destination handle at all. I think this should be returning a "syntax error"
or something, not "invalid handle," since the latter makes it seem like one of the handles does not
refer correctly to an image surface. It also introduces a limitation, since it means the source
coordinates can't be used, meaning hardware images can only be drawn in entirety, not pieces of them
at a time. That makes them either extremely awkward or totally useless for sprite sheets.
Under some circumstances, at the end of the simulation, the screen would go black at a SLEEP statement.
Still not sure what caused this, it's something for me to keep in mind going forward in case it causes
any issues, though I don't normally use SLEEP unless I'm running a test on something.
Clearing up the massive performance drain of a software screenwide image stretch on every frame,
it became possible for me to see perceptible differences in the expense of other elements of the
simulation loop, which gives me useful information on where performance can be improved. There are
things I haven't gotten around to yet, such as storing unit vector information, in order to reduce
trigonometric operations in favor of much less expensive linear interpolation.
Code: (Select All)
Performance test results of simulation loop:
- Position updates 17.25% (where most trigonometry happens)
- Script execution 21.68%
- Collision handling 31.87% (pairwise, including a sort and exclusion based on object properties)
- Object termination check 17.88% (this seems much higher than it should be)This doesn't land on 100%, because these elements interact with each other, so commenting out one
influences how much the others have to do. The simulation does not include handling player input
nor player-specific collision interactions. But these are good starting ballpark figures.
Thanks very much for your help in pointing me toward hardware images, while it's not a catch-all
solution for other things, it did help tremendously in this case!