+- QB64 Phoenix Edition (https://staging.qb64phoenix.com)
+-- Forum: QB64 Rising (https://staging.qb64phoenix.com/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://staging.qb64phoenix.com/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://staging.qb64phoenix.com/forumdisplay.php?fid=10)
+---- Thread: A faster way to scale images? (/showthread.php?tid=1433)
Pages:
1
2
RE: A faster way to scale images? - TerryRitchie - 02-16-2023
(02-16-2023, 08:28 AM)johannhowitzer Wrote: I tried some more tests, commenting various things out, moving stuff around, adding in extra calls,
and the mystery only gets weirder.
- When I added SOFTWARE to the DISPLAYORDER at the start and commented out the others - or just
commented out every DISPLAYORDER and went with default - I got everything to show up, but it was
twice as slow.
- When I commented out the running frame counter display during the simulation, the ending result
display afterward flickered once and went black.
- When I added a DISPLAY statement before the simulation, the ending result stayed visible.
I also noticed that without it, the window size did not change after leaving the editor (which
operates at 1:1), until the simulation was done. It seems SCREEN does not resize the window
by itself, if you are not in AUTODISPLAY; you have to use a DISPLAY statement to get it to realize
the window size should change. I understand how this would update the window size, but still have
no idea why this prevents the flicker, or rather, why neglecting it causes the flicker in the
first place!
And still no clue why PUTIMAGE is sending to the SCREEN handle and ignoring the subsequent DEST.
Do hardware images just ignore DEST and place straight to whatever's SCREEN at the time?
Since adding hardware images, I had not run through other parts of the program, just the level
editor and the frame counter on simulation. Upon trying to start the game from the title screen,
there were several other sticking points where I ran into black screens when it seemed like I
shouldn't. Putting a DISPLAY in a few spots did seem to smooth them over, but now I'm going to
have to go through everything and comb for black screens and figure out how to prevent them.
Hardware images apparently behave very strangely with regard to DISPLAY, SCREEN, and DEST.
It will take me some time to test things, and figure out how the behavior works in detail, enough
to use hardware images confidently. There are some really unusual quirks.
I hear ya. I've played around with hardware images in the past and wow are they fast. However, every single time I've tried implementing them into one of my software projects I've run across the same quirkiness you are describing. I'm working on a project now that would benefit greatly from hardware images so I'm going to give it another go.
I may end up writing a new tutorial topic on just hardware images to help get everything straight in my own mind and have documentation on how exactly to implement them.
RE: A faster way to scale images? - SMcNeill - 02-16-2023
I think the biggest issue you guys are having is in thinking of hardware images as being some sort of normal image. The reason why you don't have to specify which handle to put them on is because they only have one place where they can go -- the hardware layer.
Our hardware layer is completely independent of any of our software layers. Think of it as being on a separate piece of paper completely. You draw on your software page, and then -- depending on your displayorder -- either lay that software page on top of the hardware page, or else lay the hardware page on top of the software page. Two distinct pages, and what you do to one has absolutely no effect on the other.
Try this, for a mind opening example:
Code: (Select All)
tempScreen = _NEWIMAGE(200, 200, 32) 'a temp screen to draw a circle on
_DEST tempScreen ''destination is the temp screen
FOR i = 1 TO 100 'and a filled red circle
CIRCLE (100, 100), i, &HFFFF0000
NEXT
_DEST 0 'destination back to our default screen
CircleHW = _COPYIMAGE(tempScreen, 33) 'make a hardware screen
_FREEIMAGE tempScreen 'free that temp screen
'Now at this point, we're going to work with a TEXT-only screen.
SCREEN 0
DO
CLS
PRINT "This is all in SCREEN 0!"
PRINT " How the heck do we have GRAPHICS on SCREEN 0?!!"
_PUTIMAGE (50, 50)-(250, 250), CircleHW
_DISPLAY
_LIMIT 30
LOOP UNTIL _KEYHITHere I make a red circle and transform it into a hardware image. I then work with a SCREEN 0 text only screen.... and still display my graphics!!
If that doesn't showcase that the two are completely separate layers, I don't know what'll show it any better!
_DISPLAYORDER _SOFTWARE, _HARDWARE <-- change those as needed for what's on top on what's the base.
And that's why _PUTIMAGE doesn't need any handle specified as to where to put a hardware image -- they all go to the _HARDWARE layer.
RE: A faster way to scale images? - TerryRitchie - 02-16-2023
Thanks Steve. Between this explanation and the post you made a few months ago about hardware images I'm hoping to sort this out in my head.
RE: A faster way to scale images? - johannhowitzer - 02-25-2023
So that's definitely a yes, hardware images will just always behave as if they went to SCREEN,
no matter what DEST is set to. The additional info about DISPLAYORDER makes me wonder... in that case,
why would a preceding DISPLAY stop a following PRINT statement from flickering once, then vanishing,
when it was a part of the hardware image?
Another question - if I only have DISPLAYORDER HARDWARE, will there be a black screen due to some
weirdness like QB64 assuming something about the SOFTWARE side of things? In light of the flicker,
it seems like DISPLAY does have some unusual interaction.
I will run plenty of tests on all this as I have time, there is now a need for me to understand
hardware images as well, and I'll try to answer these questions myself either way, but any extra
light you can shed will likely speed this process up!