[blitz basic] How much amiga-blitz friendly is this?

[saimon69]

Handbook is kinda fumous on how to do double buffering though, any hints?

[Cylon]

What is your idea on how to do

start:
Show actual screen
draw next screen (hidden)
copy next screen > actual screen
loop
(This is AMOS like or so).
...

[saimon69]

well i am trying to figure out this, so some pseudocode

initialize bitmap 0  and 1

a var that points the bitmap id
id=0
first cycle

write on 0
show 0
id+=1
write on 1
show 1
id = 0 
write on 0
etc.

is it correct?

[saimon69]

Got the Ultimate Blitz Basic CD and am trying to read what other coders did. Wish to keep the buffering part as much separate from the drawing itself as possible but still not certain this can be done...

[clebin]

@saimon69

I got double-buffering working last week from examples I've found. Here are the relevant bits of my code. Hope it helps. I welcome any corrections from more experienced Blitz programmers!

Chris

; initialise my bitmap (I'm using 16-colour high-res)
BitMap 0,640,256,4

; load the background image
LoadBitMap 0,"Work:path/to/background.iff",0
Use BitMap 0

; make a copy for double-buffering
CopyBitMap 0,1

;Use Blitz mode
VWait 300
BLITZ

; set up two buffers for bblitting
Buffer 0,36384
Buffer 1,36384

; db alternates between 0 and 1 - which are my two bitmaps
db=0

; create my slice (for the 16-colour high-res screen)
Slice 0,43,12
Use Palette 0

; main loop (until Esc key pressed)
While NOT rawstatus($45)

  ; show the current bitmap
  Show db
  
  ; now do my drawing on the second bitmap
  db = 1-db
  Use BitMap db

  ; clear the current buffer
  UnBuffer db

  ; blit onto the hidden bitmap
  BBlit db, shapeNum, x, y

Wend

[saimon69]

Going to try to implement it tonight if wifey let me work, however that game is NOT using blitz mode yet

by the way,for latter use, if i have a data include file, how to point the read cycle to a well defined subroutine (like level0, level1,ecc.): can i say gosub level+num or need to do something more complex?

[clebin]

Originally Posted by saimon69

Going to try to implement it tonight if wifey let me work, however that game is NOT using blitz mode yet

I knew I'd forget something... The code above uses Blitz mode so I've added the two lines for that.

Chris

[Cylon]

Originally Posted by saimon69

Going to try to implement it tonight if wifey let me work, however that game is NOT using blitz mode yet

by the way,for latter use, if i have a data include file, how to point the read cycle to a well defined subroutine (like level0, level1,ecc.): can i say gosub level+num or need to do something more complex?

Of course you cannot use just Label+lev.w.

Macros, mate.
Here is an example for the use of Restore/Read.

;macro data label reloc

Macro levrestore
 CNIF `0=1    ;should be my level number
   Restore levdata`1
   ;do something else
 CELSE
   CERR "Macro levrestore needs level num as arg!"
   ;restore levdata0
 CEND
End Macro

; main test
!levrestore {2}
Read testdat.w
NPrint testdat

!levrestore {1}
Read testdat.w
NPrint testdat

MouseWait
End

CloseEd

levdata0:
Data.w 0
levdata1:
Data.w 1234
levdata2:
Data.w 5678

Of course, this will not solve your problem, as you can't use a runtime-variable for a label.

A good way to go is using an array for all the levels and read the data into it before the game starts or use files.
Also, if you use a Select/Case/End Select block you can switch level data as well:

readlevel:
Select newlevel.w
  Case 1: Restore levdata1:Gosub readdata 
  Case 2: Restore levdata2:Gosub readdata 
  Case 3: Restore levdata3:Gosub readdata 
  ...
  Case 99: Restore levdata99:Gosub readdata 
  Default: Stop   ;error unknown level
End Select

Using procedures and files, you can save yourself some serious typing, as you don't have to create a select block for hundreds of levels.

function readlevel {newlevel.w}
  ok=loadlevel {newlevel}   ;open level file
  ok=setlevel {newlevel}    ;set init level vars
  function return ok
end function

Good luck!

[saimon69]

Still here, am moving home so lately had no time to code but weant to put this thing up, while still stuck on the double buffering example.

@cylon

the code provided by clebin could work even when NOT in blitz mode?

[Cylon]

the code provided by clebin could work even when NOT in blitz mode?

Did you try?

[saimon69]

@cylon

not yet, however i set up my machine so tonight can try to do tests

[saimon69]

So last time i tried to modify the code was very well stuck, need some hints

[ReadOnlyCat]

Guys, you really do not want to do any screen copy while double buffering.
Doing this means you are copying a full screen for every refresh of your game and that completely negates the advantage of a double buffer in the first place.

What you want to do is instead swap the currently visible screen and the drawing screen identifiers so that the copper list uses the ex-drawing screen to construct the display.

The general idea is the following:

Frame 1:   Screen 1         Screen 2     
--------  +------------+   +------------+
        +->            |   |            |
        | | displayed  |   | draw here  |
        | |            |   |            |
        | +------------+   +------------+
        |                                
        |  +-----------+                 
        |  |Copperlist |                 
        |  |           |                 
        +--+ScreenBPL  |                 
           +-----------+                 
                                         
Frame 2:   Screen 1         Screen 2     
--------  +------------+   +------------+
          |            | +->            |
          | draw here  | | | displayed  |
          |            | | |            |
          +------------+ | +------------+
                         |               
           +-----------+ |               
           |Copperlist | |               
           |           | |               
           |ScreenBPL  +-+               
           +-----------+

Update: Ah, forget it. I misunderstood the Blitz code and thought you were blitting from the hidden screen from the visible one. The way you are doing it is the correct one, sorry for this short but fairly pointless interruption. You can resume working as if nothing happened.

[Daedalus]

Originally Posted by saimon69

So last time i tried to modify the code was very well stuck, need some hints

That code is using Slice commands, which are Blitz mode only. What is it you're trying to do, and what's happening with the code that isn't working?

[saimon69]

@Daedalus


Well is more matter of plain incompetence from my side on what to put and where; add that i lack time to proper study stuff (Blitz and Amiga implicit "rules of the play" are not that transparent to newcomers), but am not giving up.

[Daedalus]

Yeah, some things can be quite tricky to get your head around alright. But once you get it, you should be fine. Most commands work ok with both Blitz and Amiga modes, it's just things like Slice that are Blitz only because they control the display chip directly. It's also possible to do double buffering in an OS-friendly way, but it will look a little different, swapping Show to ShowBitmap and Slice to Screen.

What does your code look like now, and what's it doing wrong?

[saimon69]

@Daedalus
So far i did port the tetris source with the help (actually majority of the work) of Cylon, so that thing draws directly on the screen using a spare window to intercept keyboard events; i started some efforts to port it to lower resolution (and use graphic slices instead of drawn boxes) but had no time to work; so far i can say no double buffer code is in there.

[Daedalus]

Ah, I see, you're switching to using Blitz mode instead of OS friendly mode.

Reading the keyboard is still easy enough if you don't need to do anything complicated. For example, the arrow keys are the same raw key code on every Amiga so you only need to check for those 4 codes, and inkey$ can be enabled in Blitz mode to read single characters from the keyboard.

Using shapes instead of drawing the rectangles should be relatively simple using the standard blitting commands that work in both Amiga and Blitz mode, so if that's the only reason you were looking to switch to Blitz mode, it's probably not necessary.

[Cylon]

The easy ways to do doublebuffering in an OS friendly way (with BlitzBasic2) are:

A: Make two windows (backdrop+noborder) and bring them to front as needed,
B: Make two screens and flip (bring to front) between them,
C: Make a screen with double the height(!) and repositioning the yPos of the Screen as required, while drawing onto the hidden part,
D: Create GFX buffers for each frame and copy the required one to the visible screen entity as needed.
...
and so on. The experience in AmigaOS coding will give you more options.

[Cylon]

Originally Posted by Daedalus

Using shapes instead of drawing the rectangles should be relatively simple using the standard blitting commands that work in both Amiga and Blitz mode, so if that's the only reason you were looking to switch to Blitz mode, it's probably not necessary.

Blitting in Blitz will use HW, means it will not work on RTG. WBlit might be different.
When you start with OS-friendly code you should stick to it. As i tried to explain before, the key to success is to understand the meaning and behaviour of the src in the first place, then trying to improve.
A "modern" (sic!) gfx card on Amiga can draw lines and boxes much faster than every Classic Amiga before. The logical next step would therefore be to use graphics.library cmds to enhance compatibility and performance boost on RTG cards - despite other things.