Development goes on. ⚡️👟QB64 v2.0.2 released! 🤩🤩🤩🤩Get it now!
0 Members and 1 Guest are viewing this topic.
...The main change with my code and yours, is that I removed the software rendering completely when I was running the hardware images....
Now it's my turn to be noobish. ;D
What exactly are you wanting to do here? I thought the goal was just to layer some tiles under some text. Wasn't we doing that?
What's the color swap supposed to do? Do we leave the text above the tiles and just swap the colors beneath them, or what's the end goal here? I don't think I fully understand what you're trying to accomplish.Is there a max number of colors that you're using in the tiles? Or are they any possible shade of RGB?
...The way I'd go about doing something like this would be to make myself a custom SCREEN 0-style memory array. ...Let me toss a simple demo of this line of thinking for you:...More is required to work with it, but it does run faster once all is said and done, if that's the primary concern that your program is facing -- display speeds from character rendering. :)
About 600 times in 3 seconds, for a total of 200 FPS on my machine.The faux hardware screen array is ~ 3 times faster than this, without us trying to do anything to optimize performance any more than just sticking to the very basics. ;)More is required to work with it, but it does run faster once all is said and done, if that's the primary concern that your program is facing -- display speeds from character rendering. :)
No time now to get into it in detail, but at the end of the hardware image sample, it seems to lock up. (See my version below.)Any idea why? I do a keyclear and return to screen 0 but the program just becomes nonresponsive after that.
I haven't had a chance to test the code, but glancing over it, it appears that you're missing a call to _AutoDisplay. In the Sub ScreenRender, we have a call to _Display which sets the program to only update the screen when we manually tell it to. Without an _AutoDisplay, the PRINT and INPUT statements won't display to the screen unless you add another _DISPLAY in there for them.Try to place an _AutoDisplay after the _DisplayOrder statement. ;)
Like Steve mentioned, it's just missing _AUTODISPALY. INPUT "PRESS <ENTER> TO CONTINUE"; in$ _AUTODISPLAYEND SUB Pete
One thing that would be *very* different with all hardware images vs what you're doing currently, is the fact that you have to remember: Hardware images display once and then flush themselves from the GPU buffer. ...About 600 times in 3 seconds, for a total of 200 FPS on my machine.The faux hardware screen array is ~ 3 times faster than this, without us trying to do anything to optimize performance any more than just sticking to the very basics. ;)More is required to work with it, but it does run faster once all is said and done, if that's the primary concern that your program is facing -- display speeds from character rendering. :)
DrawTile8 4,202 refreshes in 3 seconds.DrawColorTile 1,825 refreshes in 3 seconds.DrawTileHw8 26,108 refreshes in 3 seconds.DrawVectorTileLine 3,775 refreshes in 3 seconds.DrawVectorTilePutImage 2,979 refreshes in 3 seconds.DrawVectorTilePutImageHW 6,440 refreshes in 3 seconds.Solid boxes with line 1,979 refreshes in 3 seconds.
...The way I'd go about doing something like this would be to make myself a custom SCREEN 0-style memory array. Screen 0 stores all our information for each character in 2 bytes -- one for color, one for character. I'd basically do the same, but with 3 bytes -- one for tile color, one for font color, one for character.Let me toss a simple demo of this line of thinking for you:...