• Print

Author Topic: Will QB64-GL fix this issue???  (Read 553 times)

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Will QB64-GL fix this issue???
« on: March 19, 2013, 05:17:17 AM »
Hi all,

I know that people have quite often complained about QB64's slow rendering in higher resolution screen modes (particularly 32-bit modes), but what I'd like to know is - does QB64GL automatically correct this lag issue in higher resolution 32-bit screen modes?

Take the below program for example.  It's just a basic 2d type engine, you move with the arrow keys.  I was curious as to which screen mode would be best to use and I was shocked at the performance loss when changing to a screen just one standard size up!?

All the screen modes used in this demo are at a standard 4:3 ratio.  All you have to do is push ESCAPE to change screen modes.  Once you reach the highest screen mode, the program will end.

What I would like people to do if they have a quick minute is to move around the screen in each screen mode (using ESCAPE to change between them) and let me know if they are experiencing the same perfomance destruction that I am.  My speed literally HALVES with each screen change.

I have removed ALL delay code so that you can properly see how badly the perfomance suffers...

Also, if you uncomment the _DONTBLEND statement on line 40 you will see roughly a double in performance aswell...

Code: [Select]
''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''''
' View Portal Demo.bas '
''''''''''''''''''''''''
'
' Written by Justin Richards (2013)
'
'
' This program was designed to be used as a template for creating a program
' that utilises view port scrolling (ie a 2d platform game, or top down map
' style game, etc).
'
' ...



' START '

' Declare Subs and Variables '



' Set Screen Resolution and Colour Mode

DIM SHARED ResolutionX, ResolutionY, ResolutionScale, ColourMode

ResolutionX = 320
ResolutionY = 240
ResolutionScale = ResolutionX / ResolutionY
ColourMode = 32



Restart:



SCREEN _NEWIMAGE(ResolutionX, ResolutionY, ColourMode)

_FULLSCREEN
'_DONTBLEND


' View Port Variables...

DIM SHARED ViewX1, ViewY1, ViewX2, ViewY2



' Background Tile Variables

DIM SHARED TileX1(10)
DIM SHARED TileY1(10)
DIM SHARED TileX2(10)
DIM SHARED TileY2(10)
DIM SHARED TileColourRed(10)
DIM SHARED TileColourGreen(10)
DIM SHARED TileColourBlue(10)



' Character Variables

DIM SHARED CharacterX, CharacterY, CharacterXInc, CharacterYInc

DIM SHARED CharacterMovedUp
DIM SHARED CharacterMovedDown
DIM SHARED CharacterMovedLeft
DIM SHARED CharacterMovedRight



' Set Screen Limits (this example is an area 1200 pixels x 600 pixels)

ViewX1Limit = 0
ViewY1Limit = 0
ViewX2Limit = 1200
ViewY2Limit = 600




' Set starting co-ordinates for our Character

CharacterX = 120: CharacterY = 120
CharacterXInc = 2: CharacterYInc = 2



' Set the Veiw Portal to centre on the Character's co-ordinates to start with

ViewX1 = CharacterX - (ResolutionX / 2): ViewY1 = CharacterY - (ResolutionY / 2): ViewX2 = CharacterX + (ResolutionX / 2) - 1: ViewY2 = CharacterY + (ResolutionY / 2) - 1



' Test to see whether the Character is close to the edge of the portal area and
' adjust the view portal position if necessary...


' X co-ordinates

IF ViewX1 < ViewX1Limit THEN

  ViewX1 = ViewX1Limit

  ViewX2 = ViewX1 + ResolutionX - 1

ELSEIF ViewX2 < ViewX2Limit - 1 THEN

  ViewX1 = ViewX1Limit + (ResolutionX / 2) - CharacterX
  ViewX2 = ViewX1 + ResolutionX - 1

ELSEIF ViewX2 > ViewX2Limit - 1 THEN

  ViewX1 = ViewX2Limit - ResolutionX

  ViewX1 = -ViewX1

  ViewX2 = ViewX1 + ResolutionX - 1

END IF


' Y co-ordinates

IF ViewY1 < ViewY1Limit THEN

  ViewY1 = ViewY1Limit

  ViewY2 = ViewY1 + ResolutionY - 1

ELSEIF ViewY2 < ViewY2Limit - 1 THEN

  ViewY1 = ViewY1Limit + (ResolutionY / 2) - CharacterY
  ViewY2 = ViewY1 + ResolutionY - 1

ELSEIF ViewY2 > ViewY2Limit - 1 THEN

  ViewY1 = ViewY2Limit - ResolutionY

  ViewY1 = -ViewY1

  ViewY2 = ViewY1 + ResolutionY - 1

END IF



' If the Character is not near the edge than change his co-ordinates based on the
' new screen position...

IF CharacterX > ViewX1Limit + (ResolutionX / 2) AND CharacterX < ViewX2Limit - (ResolutionX / 2) THEN CharacterX = -ViewX1 + (ResolutionX / 2)
IF CharacterY > ViewY1Limit + (ResolutionY / 2) AND CharacterY < ViewY2Limit - (ResolutionY / 2) THEN CharacterY = -ViewY1 + (ResolutionY / 2)




' These tiles form the brown rectangles (walls) in the background

FOR ResetTiles = 0 TO 9

  TileColourRed(ResetTiles) = 223
  TileColourGreen(ResetTiles) = 95
  TileColourBlue(ResetTiles) = 0

NEXT ResetTiles

TileX1(0) = 0: TileY1(0) = 0: TileX2(0) = 39: TileY2(0) = 599
TileX1(1) = 40: TileY1(1) = 0: TileX2(1) = 559: TileY2(1) = 39
TileX1(2) = 1160: TileY1(2) = 0: TileX2(2) = 1199: TileY2(2) = 599
TileX1(3) = 40: TileY1(3) = 560: TileX2(3) = 559: TileY2(3) = 599
TileX1(4) = 160: TileY1(4) = 160: TileX2(4) = 239: TileY2(4) = 199
TileX1(5) = 220: TileY1(5) = 40: TileX2(5) = 239: TileY2(5) = 159
TileX1(6) = 40: TileY1(6) = 270: TileX2(6) = 199: TileY2(6) = 299
TileX1(7) = 440: TileY1(7) = 270: TileX2(7) = 899: TileY2(7) = 499: TileColourRed(7) = 63: TileColourGreen(7) = 63: TileColourBlue(7) = 63


' Set Keyboard Constants

CONST Key_Up& = 18432
CONST Key_Down& = 20480
CONST Key_Left& = 19200
CONST Key_Right& = 19712


' Set delay/speed variables

TimeSet = 1

GameSpeed = 0



' Main Game Loop

DO


  '  ' Reset the Tick Clock
  '
  '  DEF SEG = 0
  '
  '  POKE 1132, 0


  ' Only process the loop if the desired delay has passed

  '  IF GameSpeed = TimeSet THEN


  ' Exit code

  FOR KbdLoop = 0 TO 32

    Kbd$ = ""

    Kbd$ = INKEY$

    IF Kbd$ = CHR$(27) THEN


      IF ResolutionX = 1024 THEN

        CLS

        _DISPLAY

        SLEEP 1

        _FULLSCREEN _OFF

        SYSTEM

      END IF

      IF ResolutionX = 800 THEN

        ResolutionX = 1024
        ResolutionY = 768

      END IF

      IF ResolutionX = 640 THEN

        ResolutionX = 800
        ResolutionY = 600

      END IF

      IF ResolutionX = 320 THEN

        ResolutionX = 640
        ResolutionY = 480

      END IF

      GOTO Restart

    END IF


  NEXT KbdLoop


  ' Draw the Background

  DrawImages



  ' Test for collisions

  PCharacterUpTopLeft = POINT(CharacterX - 20 + ViewX1, CharacterY - 21 + ViewY1)
  PCharacterUpTopMiddle = POINT(CharacterX + ViewX1, CharacterY - 21 + ViewY1)
  PCharacterUpTopRight = POINT(CharacterX + 19 + ViewX1, CharacterY - 21 + ViewY1)

  PCharacterDownBottomLeft = POINT(CharacterX - 20 + ViewX1, CharacterY + 20 + ViewY1)
  PCharacterDownBottomMiddle = POINT(CharacterX + ViewX1, CharacterY + 20 + ViewY1)
  PCharacterDownBottomRight = POINT(CharacterX + 19 + ViewX1, CharacterY + 20 + ViewY1)

  PCharacterLeftTopLeft = POINT(CharacterX - 21 + ViewX1, CharacterY - 20 + ViewY1)
  PCharacterLeftMiddleLeft = POINT(CharacterX - 21 + ViewX1, CharacterY + ViewY1)
  PCharacterLeftBottomLeft = POINT(CharacterX - 21 + ViewX1, CharacterY + 19 + ViewY1)

  PCharacterRightTopRight = POINT(CharacterX + 20 + ViewX1, CharacterY - 20 + ViewY1)
  PCharacterRightMiddleRight = POINT(CharacterX + 20 + ViewX1, CharacterY + ViewY1)
  PCharacterRightBottomRight = POINT(CharacterX + 20 + ViewX1, CharacterY + 19 + ViewY1)

  PCharacterCentre = POINT(CharacterX + ViewX1, CharacterY + ViewY1)


  ' Test for keypresses

  UpOn = _KEYDOWN(Key_Up&)
  DownOn = _KEYDOWN(Key_Down&)
  LeftOn = _KEYDOWN(Key_Left&)
  RightOn = _KEYDOWN(Key_Right&)


  ' Move Character based on user input


  CharacterMovedUp = 0
  CharacterMovedDown = 0
  CharacterMovedLeft = 0
  CharacterMovedRight = 0


  IF UpOn = -1 AND DownOn = 0 AND PCharacterUpTopLeft = _RGB(0, 0, 0) AND PCharacterUpTopMiddle = _RGB(0, 0, 0) AND PCharacterUpTopRight = _RGB(0, 0, 0) THEN

    IF CharacterY > ViewY1Limit + (ResolutionY / 2) AND CharacterY < ViewY2Limit - (ResolutionY / 2) + CharacterYInc THEN ViewY1 = ViewY1 + CharacterYInc: ViewY2 = ViewY2 + CharacterYInc

    CharacterY = CharacterY - CharacterYInc

    CharacterMovedUp = -1

  END IF

  IF DownOn = -1 AND UpOn = 0 AND PCharacterDownBottomLeft = _RGB(0, 0, 0) AND PCharacterDownBottomMiddle = _RGB(0, 0, 0) AND PCharacterDownBottomRight = _RGB(0, 0, 0) THEN

    IF CharacterY > ViewY1Limit + (ResolutionY / 2) - CharacterYInc AND CharacterY < ViewY2Limit - (ResolutionY / 2) THEN ViewY1 = ViewY1 - CharacterYInc: ViewY2 = ViewY2 - CharacterYInc

    CharacterY = CharacterY + CharacterYInc

    CharacterMovedDown = -1

  END IF

  IF LeftOn = -1 AND RightOn = 0 AND PCharacterLeftTopLeft = _RGB(0, 0, 0) AND PCharacterLeftMiddleLeft = _RGB(0, 0, 0) AND PCharacterLeftBottomLeft = _RGB(0, 0, 0) THEN

    IF CharacterX > ViewX1Limit + (ResolutionX / 2) AND CharacterX < ViewX2Limit - (ResolutionX / 2) + CharacterXInc THEN ViewX1 = ViewX1 + CharacterXInc: ViewX2 = ViewX2 + CharacterXInc

    CharacterX = CharacterX - CharacterXInc

    CharacterMovedLeft = -1

  END IF

  IF RightOn = -1 AND LeftOn = 0 AND PCharacterRightTopRight = _RGB(0, 0, 0) AND PCharacterRightMiddleRight = _RGB(0, 0, 0) AND PCharacterRightBottomRight = _RGB(0, 0, 0) THEN

    IF CharacterX > ViewX1Limit + (ResolutionX / 2) - CharacterXInc AND CharacterX < ViewX2Limit - (ResolutionX / 2) THEN ViewX1 = ViewX1 - CharacterXInc: ViewX2 = ViewX2 - CharacterXInc

    CharacterX = CharacterX + CharacterXInc

    CharacterMovedRight = -1

  END IF


  ' reset timer and display graphics

  GameSpeed = 0


  _DISPLAY

  '  END IF


  ' Loop here until an even amount of time has passed

  '  DO
  '
  'LOOP UNTIL PEEK(1132) >= 1
  '
  '  DEF SEG
  '
  '
  '  ' Increment the timer
  '
  '  GameSpeed = GameSpeed + 1
  '



LOOP


END



SUB DrawImages


' Clear the screen and draw each tile one at a time

LINE (0, 0)-(ResolutionX - 1, ResolutionY - 1), _RGB(0, 0, 0), BF

FOR DrawTile = 0 TO 9

  IF NOT (TileX1(DrawTile) + ViewX1 > ResolutionX OR TileX2(DrawTile) + ViewX2 < ResolutionX OR TileY1(DrawTile) + ViewY1 > ResolutionY OR TileY2(DrawTile) + ViewY2 < ResolutionY) THEN

    LINE (TileX1(DrawTile) + ViewX1, TileY1(DrawTile) + ViewY1)-(TileX2(DrawTile) + ViewX1, TileY2(DrawTile) + ViewY1), _RGBA(TileColourRed(DrawTile), TileColourGreen(DrawTile), TileColourBlue(DrawTile), 127), BF

  END IF

NEXT DrawTile


' Draw the Character (Ball in this case)

CIRCLE (CharacterX + ViewX1, CharacterY + ViewY1), 19, _RGB(63, 255, 63)
CIRCLE (CharacterX - 1 + ViewX1, CharacterY - 1 + ViewY1), 19, _RGB(63, 255, 63)
PAINT (CharacterX + ViewX1, CharacterY + ViewY1), _RGB(63, 255, 63), _RGB(63, 255, 63)


'Central
IF NOT CharacterMovedUp AND NOT CharacterMovedDown AND NOT CharacterMovedLeft AND NOT CharacterMovedRight THEN
  CIRCLE (CharacterX + ViewX1, CharacterY + ViewY1), 3, 2
  CIRCLE (CharacterX - 1 + ViewX1, CharacterY - 1 + ViewY1), 3, 2
  PAINT (CharacterX + ViewX1, CharacterY + ViewY1), 2, 2
END IF

'Up
IF CharacterMovedUp AND NOT CharacterMovedLeft AND NOT CharacterMovedRight THEN
  CIRCLE (CharacterX + ViewX1, CharacterY - 15 + ViewY1), 3, 2
  CIRCLE (CharacterX - 1 + ViewX1, CharacterY - 16 + ViewY1), 3, 2
  PAINT (CharacterX + ViewX1, CharacterY - 15 + ViewY1), 2, 2
END IF

'Down
IF CharacterMovedDown AND NOT CharacterMovedLeft AND NOT CharacterMovedRight THEN
  CIRCLE (CharacterX + ViewX1, CharacterY + 15 + ViewY1), 3, 2
  CIRCLE (CharacterX - 1 + ViewX1, CharacterY + 16 + ViewY1), 3, 2
  PAINT (CharacterX + ViewX1, CharacterY + 15 + ViewY1), 2, 2
END IF

'Left
IF CharacterMovedLeft AND NOT CharacterMovedUp AND NOT CharacterMovedDown THEN
  CIRCLE (CharacterX - 15 + ViewX1, CharacterY + ViewY1), 3, 2
  CIRCLE (CharacterX - 16 + ViewX1, CharacterY - 1 + ViewY1), 3, 2
  PAINT (CharacterX - 15 + ViewX1, CharacterY + ViewY1), 2, 2
END IF

'Right
IF CharacterMovedRight AND NOT CharacterMovedUp AND NOT CharacterMovedDown THEN
  CIRCLE (CharacterX + 15 + ViewX1, CharacterY + ViewY1), 3, 2
  CIRCLE (CharacterX + 16 + ViewX1, CharacterY - 1 + ViewY1), 3, 2
  PAINT (CharacterX + 15 + ViewX1, CharacterY + ViewY1), 2, 2
END IF



'Up and Left
IF CharacterMovedUp AND CharacterMovedLeft THEN
  CIRCLE (CharacterX - 10 + ViewX1, CharacterY - 10 + ViewY1), 3, 2
  CIRCLE (CharacterX - 11 + ViewX1, CharacterY - 11 + ViewY1), 3, 2
  PAINT (CharacterX - 10 + ViewX1, CharacterY - 10 + ViewY1), 2, 2
END IF

'Up and Right
IF CharacterMovedUp AND CharacterMovedRight THEN
  CIRCLE (CharacterX + 10 + ViewX1, CharacterY - 10 + ViewY1), 3, 2
  CIRCLE (CharacterX + 11 + ViewX1, CharacterY - 11 + ViewY1), 3, 2
  PAINT (CharacterX + 10 + ViewX1, CharacterY - 10 + ViewY1), 2, 2
END IF

'Down and Left
IF CharacterMovedDown AND CharacterMovedLeft THEN
  CIRCLE (CharacterX - 10 + ViewX1, CharacterY + 10 + ViewY1), 3, 2
  CIRCLE (CharacterX - 11 + ViewX1, CharacterY + 11 + ViewY1), 3, 2
  PAINT (CharacterX - 10 + ViewX1, CharacterY + 10 + ViewY1), 2, 2
END IF

'Down and Right
IF CharacterMovedDown AND CharacterMovedRight THEN
  CIRCLE (CharacterX + 10 + ViewX1, CharacterY + 10 + ViewY1), 3, 2
  CIRCLE (CharacterX + 11 + ViewX1, CharacterY + 11 + ViewY1), 3, 2
  PAINT (CharacterX + 10 + ViewX1, CharacterY + 10 + ViewY1), 2, 2
END IF



END SUB


Thanks in advance,
Justin
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: Will QB64-GL fix this issue???
« Reply #1 on: March 19, 2013, 05:40:22 AM »
Hi all,
    Hmm  , yes it does seem to halve the speed. Im too tired to offer an opinion why, tonight.
OlDosLover.

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: Will QB64-GL fix this issue???
« Reply #2 on: March 19, 2013, 05:50:03 AM »
Hi all,
    First obvious thing i  noticed is that every variable are SINGLE types (floating point). If you dont need fractional precision then make as many of them Integers or Longs as they are faster.
OlDosLover.

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #3 on: March 19, 2013, 06:02:38 AM »
Quote from: OlDosLover on March 19, 2013, 05:50:03 AM
Hi all,
    First obvious thing i  noticed is that every variable are SINGLE types (floating point). If you dont need fractional precision then make as many of them Integers or Longs as they are faster.
OlDosLover.

Thanks for the reply ODL

Seing as though the variables have hardly any calculations pefromed on them, I don't see how they could be affecting the speed quite this much.  I tried removing the _DISPLAY statement and I got improved performance (understandibly).  I think it is definately a rendering issue, rather than a calculation lag...

Thanks
Justin
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #4 on: March 19, 2013, 06:06:19 AM »
For example, I can run the exact same program in 256 colour mode and have nowhere near the same performance issues...
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

DSMan195276

  • Hero Member
  • *****
  • Posts: 1978
  • Yes
    • Email
Re: Will QB64-GL fix this issue???
« Reply #5 on: March 19, 2013, 07:55:29 AM »
I can't say for sure what is causing the slow down (Probably a combo of things). However _DONTBLEND, only using LONG's, staying away from commands that aren't very fast (PAINT and INKEY$ are both fairly slow commands to run), and using _MEMIMAGE when you can should all help speed up the program a bit. I would try keeping _DONTBLEND in, use DEFLNG at the begging of your program (Using singles only when needed), and get rid of your use of INKEY$ and then see how it goes.

Matt

EDIT: POINT is also slow (I believe it's in part because he does everything with float's or something, sorry I can't remember the exact reason). You can do a much faster POINT if you get a _MEMIMAGE to the screen, and then just grab a LONG from it by calculating the offset of the pixel via it's cords. I could probably make a small example if wanted. Using that with $CHECKING:OFF should help speed things up a ton.
« Last Edit: March 20, 2013, 12:35:07 PM by DSMan195276 »
"Cast your cares on the Lord and he will sustain you; he will never let the righteous be shaken" -- Psalm 55:22
QB64 Linux Installer

Cyperium

  • Hero Member
  • *****
  • Posts: 3285
  • Knowledge is good, but understanding is better
    • Cyperium
    • Email
Re: Will QB64-GL fix this issue???
« Reply #6 on: March 20, 2013, 11:18:36 AM »
You can use _DONTBLEND with a image handle so that only the images that needs blending actually have it.

For example, if you have a background image stored in the handle "background" then use _DONTBLEND background.
Venture - New Prototype, QB64 Editor v1.95b (linux compatible, if you compile the source).

codeguy

  • Hero Member
  • *****
  • Posts: 3552
  • what the h3ll did i name that code?
    • stuff at dkm
    • Email
Re: Will QB64-GL fix this issue???
« Reply #7 on: March 20, 2013, 12:02:08 PM »
for screen images, integer-domain numbers to refer to (x,y) points on a screen and long-domain variables to hold the pixel's color info are fine. afaik, nobody has a 32768-pixel display (either width or height), although it'd be pretty d@mned impressive.
http://denteddisk.forums-free.com/make-an-appointment-with-the-resident-code-guru-f34.html

SkyCharger001

  • Hero Member
  • *****
  • Posts: 1594
Re: Will QB64-GL fix this issue???
« Reply #8 on: March 20, 2013, 02:08:07 PM »
Quote from: codeguy on March 20, 2013, 12:02:08 PM
afaik, nobody has a 32768-pixel display (either width or height), although it'd be pretty d@mned impressive.
I've seen one attached to a weather-computer.
but for us it would be overkill... (either the display would be TOO large or the pixels TOO small to distinguish)

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #9 on: March 21, 2013, 04:22:19 AM »
Sorry for the late reply guys! Thanks for all your suggestions too, lots to try there.

I'd be interested to see the _MEMIMAGE example Dsman as I've never used those _MEM commands before.

I also didn't know you could use _DONTBLEND on an image handle separately either.

Somebody mentioned in another thread that CLS is slower then using a PSET array to black out the screen which seems absurd but that's also worth a try.

I'll have a look tonight and post my results.

Thanks again,
Justin
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #10 on: March 21, 2013, 04:24:37 AM »
Quote from: codeguy on March 20, 2013, 12:02:08 PM
for screen images, integer-domain numbers to refer to (x,y) points on a screen and long-domain variables to hold the pixel's color info are fine. afaik, nobody has a 32768-pixel display (either width or height), although it'd be pretty d@mned impressive.

I'm curious what you mean by this? I understand what your saying, but I'm not to sure how to apply this method? Do you have a short example?

Thanks,
Justin.
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #11 on: March 21, 2013, 05:15:27 AM »
Ok,

INKEY$ in the way that I have used it in this program doesn't affect the speed if the program.  I removed it all together and saw no difference in performance.

CLS also made no difference. In fact I wasn't using CLS at all I was using a LINE statement to clear the screen. When I substituted the LINE statement for a CLS statement it made no difference.


The problem seems to be completely dependant on the resolution. More specifically, the time it takes to reset and recolour each 32-bit pixel.

Seeing as though I'm not using any image handles in this program, I doubt that the variable types would affect the speed either.

I think _MEM might be the answer here, but I have no idea how to use it!?
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

JustinRichardsMusic

  • Sr. Member
  • ****
  • Posts: 335
  • Character names can be found in metal from the 90s
    • Email
Re: Will QB64-GL fix this issue???
« Reply #12 on: March 21, 2013, 05:27:39 AM »
Ok, so I removed the PAINT statements from drawing the ball and saw a noticable increase in speed.

Normally I wouldn't use paint for anything, but for this simple program it was a shortcut.

However, I timed how long it took to get from the far left wall to the grey wall in each screen mode and this is what I got:

320x240 = 3 secs
640x480 = 4 secs
800x600 = 5 secs
1024x768 = 8 secs

Now I know that SDL based QB64 uses no hardware acceleration so back to my original question, do you think QB64GL will fix this issue?
James Hetter's Revenge has been unleashed! Follow the games progress here:
http://www.qb64.net/forum/index.php?topic=6762.0

Download the latest version here:
https://www.dropbox.com/s/8p8gguliw1y6ink/Hetters%20Revenge.zip?m

codeguy

  • Hero Member
  • *****
  • Posts: 3552
  • what the h3ll did i name that code?
    • stuff at dkm
    • Email
Re: Will QB64-GL fix this issue???
« Reply #13 on: March 21, 2013, 06:41:33 AM »
Quote from: JustinRichardsMusic on March 21, 2013, 04:24:37 AM
Quote from: codeguy on March 20, 2013, 12:02:08 PM
for screen images, integer-domain numbers to refer to (x,y) points on a screen and long-domain variables to hold the pixel's color info are fine. afaik, nobody has a 32768-pixel display (either width or height), although it'd be pretty d@mned impressive.

I'm curious what you mean by this? I understand what your saying, but I'm not to sure how to apply this method? Do you have a short example?

Thanks,
Justin.

assign integers to refer to x,y coords on a screen and long (technically, _unsigned long) for storing or dealing with POINT(x,y).
http://denteddisk.forums-free.com/make-an-appointment-with-the-resident-code-guru-f34.html

OlDosLover

  • Hero Member
  • *****
  • Posts: 3859
  • OlDosLover
    • Email
Re: Will QB64-GL fix this issue???
« Reply #14 on: March 21, 2013, 07:44:53 AM »
Hi all,
   
Quote
However, I timed how long it took to get from the far left wall to the grey wall in each screen mode and this is what I got:
320x240 = 3 secs
640x480 = 4 secs
800x600 = 5 secs
1024x768 = 8 secs
    I havent examined the code deeply but i assume you are moving a fixed amount horizontally. Is this fixed amount a set number of pixels or a percentage of the overall screen resolution? As 320 across is half of 640 you would expect to see more difference between those two size of resolutions.
    My advice is to place your character on a unblocked horizontal path  and have it move to the other side in a loop with code not a key press ,and time (with timer) . In theory you should reach a speed that does not get faster and can be expressed as pixels per cycle (cycle = your benchmark constant between all screen resolutions). If indeed ,in each screen resolution ,the pixels per cycle are the same regardless of screen resolution ,then to get movement across the screen the same at 320 verses 640 then you need to double the fixed amount of horizontal movement.
    If it took 320 seconds to move 320 graduations then to move 640 graduations either double your speed or double your step movement.
OlDosLover.



  • Print