+- QB64 Phoenix Edition (https://qb64phoenix.com/forum)
+-- Forum: QB64 Rising (https://qb64phoenix.com/forum/forumdisplay.php?fid=1)
+--- Forum: Code and Stuff (https://qb64phoenix.com/forum/forumdisplay.php?fid=3)
+---- Forum: Help Me! (https://qb64phoenix.com/forum/forumdisplay.php?fid=10)
+---- Thread: HW image version of this little stupid thing (/showthread.php?tid=1991)
RE: HW image version of this little stupid thing - TerryRitchie - 09-12-2023
(09-12-2023, 07:30 PM)mnrvovrfc Wrote: ^The reason you're getting 1000 FPS in hardware mode is because that's the upper limit that can be calculated with TIMER(.001). Only when hardware is taxed enough will the frame rate drop below 1000. The program crashes for me when I try to go a few more than 8000 sprites. Perhaps someone with a better video card and more RAM can tax the hardware layer enough to start seeing the FPS drop below 1000 in hardware mode. (or someone has a better timing method I can use)
|
Well done!
But I purposely reduced the object count from 8000 to 4000 because with 4000 the screen was getting a bit crowded which looked gross.
I got 19FPS from "software" mode and usually 1000FPS from "hardware" mode. This was on a HP laptop which originally had Windows8 on it, with Intel Sandy Bridge CPU, MESA graphics and on Slackel Linux (based on Slackware).
Code: (Select All)[~]$ inxi -G
Graphics:
Device-1: Intel 2nd Generation Core Processor Family Integrated Graphics
driver: i915 v: kernel
Device-2: Chicony HP Truevision HD driver: uvcvideo type: USB
Display: x11 server: X.Org v: 21.1.8 driver: X: loaded: intel dri: crocus
gpu: i915 resolution: 1366x768~60Hz
API: OpenGL v: 3.3 Mesa 23.1.6 renderer: Mesa Intel HD Graphics 2000 (SNB
GT1)
RE: HW image version of this little stupid thing - bplus - 09-12-2023
Nice demo Terry, if I wasn't convinced already that would do it.
RE: HW image version of this little stupid thing - Dav - 09-12-2023
Good example, Terry. I had to lower it to 4000 on my laptop, but the hardware images speed blow the software speed out of the water.
- Dav
RE: HW image version of this little stupid thing - SMcNeill - 09-12-2023
(09-12-2023, 07:41 PM)TerryRitchie Wrote: The reason you're getting 1000 FPS in hardware mode is because that's the upper limit that can be calculated with TIMER(.001). Only when hardware is taxed enough will the frame rate drop below 1000. The program crashes for me when I try to go a few more than 8000 sprites. Perhaps someone with a better video card and more RAM can tax the hardware layer enough to start seeing the FPS drop below 1000 in hardware mode. (or someone has a better timing method I can use)
Try this little demo to showcase the difference in speed between Hardware Images and Software Images:
Code: (Select All)
DIM AS LONG HWscreen, SWscreen, DisplayScreen, TempScreen
DisplayScreen = _NEWIMAGE(1280, 720, 32)
SWscreen = _NEWIMAGE(64, 8, 32)
TempScreen = _NEWIMAGE(64, 8, 32)
'draw a few characters for screen display
_DEST TempScreen 'make a temp software screen to print on
_FONT 8 'size 8 font
_PRINTSTRING (0, 0), "Hardware" 'print the word "Hardware"
HWscreen = _COPYIMAGE(TempScreen, 33) 'make a copy of that temp screen as a hardware screen
_FREEIMAGE TempScreen 'free the temp screen
_DEST SWscreen 'Draw on a software screen
_FONT 8 'same size font 8
_PRINTSTRING (0, 0), "Software" 'And print the word Software on this screen
_DEST DisplayScreen
SCREEN DisplayScreen
HardwareMode = 0 'let's start out in software mode
xdirection = 1: ydirection = 1
DO
IF TIMER > t# THEN
IF FPS > maxFPS THEN maxFPS = FPS
_TITLE "FPS:" + STR$(FPS) + " -- MaxFPS:" + STR$(maxFPS)
t# = TIMER
FPS = 0
ELSE
FPS = FPS + 1
END IF
x = x + xdirection
y = y + ydirection
IF x < 0 OR x > _WIDTH THEN xdirection = -xdirection
IF y < 0 OR y > _HEIGHT THEN ydirection = -ydirection
IF HardwareMode THEN
_DISPLAYORDER _HARDWARE
_PUTIMAGE (x, y), HWscreen
ELSE
_DISPLAYORDER _SOFTWARE
CLS
_PUTIMAGE (x, y), SWscreen, DisplayScreen
END IF
k = _KEYHIT
SELECT CASE k
CASE 27: SYSTEM
CASE ASC("H"), ASC("h"): HardwareMode = -1: maxFPS = 0: FPS = 0
CASE ASC("S"), ASC("s"): HardwareMode = 0: maxFPS = 0: FPS = 0
END SELECT
_DISPLAY
LOOP
On my PC, I get about 100 FPS for the software image animation, and about 130,000 FPS for the hardware image animation.
I think that's enough to showcase a slight difference in the performance between the two.
RE: HW image version of this little stupid thing - bplus - 09-12-2023
(09-12-2023, 09:46 PM)SMcNeill Wrote:(09-12-2023, 07:41 PM)TerryRitchie Wrote: The reason you're getting 1000 FPS in hardware mode is because that's the upper limit that can be calculated with TIMER(.001). Only when hardware is taxed enough will the frame rate drop below 1000. The program crashes for me when I try to go a few more than 8000 sprites. Perhaps someone with a better video card and more RAM can tax the hardware layer enough to start seeing the FPS drop below 1000 in hardware mode. (or someone has a better timing method I can use)
Try this little demo to showcase the difference in speed between Hardware Images and Software Images:
Code: (Select All)DIM AS LONG HWscreen, SWscreen, DisplayScreen, TempScreen
DisplayScreen = _NEWIMAGE(1280, 720, 32)
SWscreen = _NEWIMAGE(64, 8, 32)
TempScreen = _NEWIMAGE(64, 8, 32)
'draw a few characters for screen display
_DEST TempScreen 'make a temp software screen to print on
_FONT 8 'size 8 font
_PRINTSTRING (0, 0), "Hardware" 'print the word "Hardware"
HWscreen = _COPYIMAGE(TempScreen, 33) 'make a copy of that temp screen as a hardware screen
_FREEIMAGE TempScreen 'free the temp screen
_DEST SWscreen 'Draw on a software screen
_FONT 8 'same size font 8
_PRINTSTRING (0, 0), "Software" 'And print the word Software on this screen
_DEST DisplayScreen
SCREEN DisplayScreen
HardwareMode = 0 'let's start out in software mode
xdirection = 1: ydirection = 1
DO
IF TIMER > t# THEN
IF FPS > maxFPS THEN maxFPS = FPS
_TITLE "FPS:" + STR$(FPS) + " -- MaxFPS:" + STR$(maxFPS)
t# = TIMER
FPS = 0
ELSE
FPS = FPS + 1
END IF
x = x + xdirection
y = y + ydirection
IF x < 0 OR x > _WIDTH THEN xdirection = -xdirection
IF y < 0 OR y > _HEIGHT THEN ydirection = -ydirection
IF HardwareMode THEN
_DISPLAYORDER _HARDWARE
_PUTIMAGE (x, y), HWscreen
ELSE
_DISPLAYORDER _SOFTWARE
CLS
_PUTIMAGE (x, y), SWscreen, DisplayScreen
END IF
k = _KEYHIT
SELECT CASE k
CASE 27: SYSTEM
CASE ASC("H"), ASC("h"): HardwareMode = -1: maxFPS = 0: FPS = 0
CASE ASC("S"), ASC("s"): HardwareMode = 0: maxFPS = 0: FPS = 0
END SELECT
_DISPLAY
LOOP
On my PC, I get about 100 FPS for the software image animation, and about 130,000 FPS for the hardware image animation.
I think that's enough to showcase a slight difference in the performance between the two.
heh, heh yeah slight difference. I knew Steve had something on this subject!
RE: HW image version of this little stupid thing - Dav - 09-12-2023
Can_SETALPHA work on hardware images (I get invalid handle error)? Or are hardware images just different animals altogether and cant be used like that?
I don't fully understand hardware images yet.
- Dav
RE: HW image version of this little stupid thing - SMcNeill - 09-12-2023
(09-12-2023, 10:14 PM)Dav Wrote: Can_SETALPHA work on hardware images (I get invalid handle error)? Or are hardware images just different animals altogether and cant be used like that?
I don't fully understand hardware images yet.
- Dav
It's because hardware images are the simplest things in the world. Here's what you can do with them:
1) Display them.
2) Free them.
You have to create a hardware image, and then it's a static image forever more. You can't write to it, alter it, do anything with it except _PUTIMAGE and _MAPTRIANGLE it onto the display. That's it -- and that's why it's so much faster than software images. If you need a hardware image with a different alpha level, then you'll need to create it with that alpha level to begin with. Do all the necessary changes which you need to make to the screen (print on it, change alpha, draw pictures on it, PSET, LINE, CIRCLE it...), and then _COPYIMAGE that finished software image to make it a hardware image. Once it's created, all you can do with it is _FREEIMAGE it or display it via _PUTIMAGE and _MAPTRIANGLE.
RE: HW image version of this little stupid thing - grymmjack - 09-12-2023
(09-12-2023, 01:21 PM)a740g Wrote: Made a few changes.
Code: (Select All)
ALIEN_SPRITE& = _NEWIMAGE(w% + 1, h% + 1, 256)
_DEST ALIEN_SPRITE&
PSET (0, 10)
DRAW ALIEN$
_CLEARCOLOR 0, ALIEN_SPRITE&
ALIEN_32& = _NEWIMAGE(w% + 1, h% + 1, 32)
_SOURCE ALIEN_SPRITE&: _DEST ALIEN_32&: _PUTIMAGE
ALIEN_HW& = _COPYIMAGE(ALIEN_32&, 33)
Thanks @a740g ! I was missing `_CLEARCOLOR 0` somehow, and that was the fix?
I don't quite understand that because the screen is `320x200` and the sprite is only `50x50` or so.
Why was the entire background black and not showing the blue?
Thanks again!
RE: HW image version of this little stupid thing - grymmjack - 09-12-2023
It's stunning that the documentation does not have a good example of hardware image use.
@SMcNeill
And a few more questions:
Do hardware images have to be 32bit? If so make sure that gets added to the docs.
I recalled a previous time when I was doing something and @a740g told me how I could still have all the benefits of pixel art and indexed palette (256 colors) but then simply `_PUTIMAGE` the 256 color image to the 32bit canvas, etc.
Mode 33 also needs more prominent mentions I think. It's an odd thing that no one would really consider.
Maybe add a hardware image example in `_COPYIMAGE` and `_PUTIMAGE`, call out mode `33` and also create a separate section in the wiki for hardware images which has SOS tutorials.
Thanks all!
RE: HW image version of this little stupid thing - grymmjack - 09-12-2023
(09-12-2023, 02:06 AM)mnrvovrfc Wrote: https://qb64phoenix.com/forum/showthread.php?tid=1399&pid=13603#pid13603
Thank you @mnrvovrfc ! This link was super helpful for me and got me 90% of the way there.