Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
HW image version of this little stupid thing
#11
(09-12-2023, 07:30 PM)mnrvovrfc Wrote: ^
|
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)
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)
New to QB64pe? Visit the QB64 tutorial to get started.
QB64 Tutorial
Reply
#12
Thumbs Up 
Nice demo Terry, if I wasn't convinced already that would do it.
b = b + ...
Reply
#13
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

Find my programs here in Dav's QB64 Corner
Reply
#14
(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.  Wink
Reply
#15
(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.  Wink

heh, heh yeah slight difference. I knew Steve had something on this subject!
b = b + ...
Reply
#16
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

Find my programs here in Dav's QB64 Corner
Reply
#17
(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.
Reply
#18
(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!
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply
#19
It's stunning that the documentation does not have a good example of hardware image use.

@SMcNeill Smile

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. Smile

Thanks all!
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply
#20
(09-12-2023, 02:06 AM)mnrvovrfc Wrote: https://qb64phoenix.com/forum/showthread...3#pid13603

Thank you @mnrvovrfc ! This link was super helpful for me and got me 90% of the way there.
grymmjack (gj!)
GitHubYouTube | Soundcloud | 16colo.rs
Reply




Users browsing this thread: 12 Guest(s)