View Single Post
Old 10 June 2018, 16:31   #55
Master484
Registered User
Master484's Avatar
 
Join Date: Nov 2015
Location: Vaasa, Finland
Posts: 328
Quote:
Good call on the multitasking. That's an aspect of Amiga programming that needs extra thought!
Indeed, I would even say that this is the most important thing when planning your general code flow.

I myself didn't realize this until I made some tests after reading some of the discussions in the assembler forum about blitter waits, and then I felt stupid when I realized that Blitz automatically waits for the Blitter to finish before executing any graphics command.

Because this is how the Amiga works: in assembler you must always wait for the Blitter to finish before giving it new stuff to draw...and Blitz Basic handles this waiting automatically for us, but what the manual doesn't tell is that the CPU then sits idle between the Blits, unless you give it something to do.

I believe that other languages like AMOS handle their graphics commands in this fashion too, so this is a good trick to try out.

---

Also screen size can affect performance quite a lot. If you are running a dual playfield on 320*256 full screen, then this eats up a lot of DMA time, because the screen is 6 bitplanes deep. This is why many dual playfield games, and games on general, run on reduced screen sizes.

So if your screen is 320 pixels wide, try reducing it to 288 or something. This way at every scanline there will be "empty space" on both sides of the display where no Display DMA is active, and this gives a good speed boost to both drawing and CPU operations.

On the Slice library reducing the screen width will automatically give you the speed boost. But on the Display library the width change is done with the DisplayAdjust command, and in it you have to set both the screen start and stop AND the correct data fetch start and stop in order to get the speed boost. If you change only the display width but not the data fetch, then it wont have any effect.

---

Also I would like to correct this code suggestion that I posted earlier:

Code:
for f =0 to num_enemies
   for g = 0 to num_bullets

       ex = enemyx(f) ; makes normal variables
       bx = bulletx(g)

       if ex > bx - 8
          if ex < bx + 8

              ey = enemyy(f)  ; makes normal variables
              by = bullety(g)

              if ey > by - 8
                 if ey < by + 8
                          collide()
                 endif
              endif
          endif
        endif
    next
next
This is the better way to do it:

Code:
for f =0 to num_enemies

  ex = enemyx(f)

   for g = 0 to num_bullets

       bx = bulletx(g)

       if ex > bx - 8
          if ex < bx + 8

              ey = enemyy(f)  ; makes normal variables
              by = bullety(g)

              if ey > by - 8
                 if ey < by + 8
                          collide()
                 endif
              endif

          endif
        endif

    next
next
In the old version the ex = enemyx(f) was done in every bullet check, even though it only needed to be done when the switch to the next enemy happened. Not sure if ey = enemyy(f) should also be moved where the ex = enemyx(f) now is, or should it be left where it is...testing would be needed to see which way is faster.
Master484 is offline  
 
Page generated in 0.04090 seconds with 11 queries