Blitz Basic 2 basics

[Daedalus]

Originally Posted by witchmaster

Ok thanks, so I need to handle the scrolling for both bitmaps separately somehow since they get "out of sync" every frame if scrolling.

Yep, it should be far quicker than copying the whole bitmap though since you're only blitting a strip each time instead of the whole thing.

[Retro1234]

Ill have to check that I think the Rtype map was about 5000, so at 8191 theres distortion?

no screen copying should be used although some people have had good results.

- I wont get into it in this thread but the first example by idrougge " Smooth vertical scrolling in AMOS" have unlimited scrolling all directions when applied in both Horizontal and vertical - when youve reached the end of the screen you flip back to beginning of the screen where you have a copy of the beginning and then continue scrolling

or you combine the cork screw for horizontal scrolling with the other method for vertical.

and theres other methods but I ask if a separate thread could be used for discussion of this

[Retro1234]

I will just say I ran the Rtype map upto 10000 and some time after 8000 there was corruption at the top of the screen and the Tiles start Pasting in the Middle of the screen and not the side.........

[MickGyver]

Originally Posted by Daedalus

Yep, it should be far quicker than copying the whole bitmap though since you're only blitting a strip each time instead of the whole thing.

I see thanks. I guess I can try to store the map_x and map_y positions for both bitmaps and update the bitmaps according to that. Back to the experimentation.

[Retro1234]

Next Question Differences between InitCopList and Slice and Pros and Cons of both?

[MickGyver]

Originally Posted by Retro1234

I will just say I ran the Rtype map upto 10000 and some time after 8000 there was corruption at the top of the screen and the Tiles start Pasting in the Middle of the screen and not the side.........

Yep, to be a bug, it's working when using slices instead of copperlists. I have read that it's best to avoid using slices though, I wonder why...

[Retro1234]

Originally Posted by witchmaster

Yep, to be a bug, it's working when using slices instead of copperlists. I have read that it's best to avoid using slices though, I wonder why...

Thanks for sharing

[MickGyver]

Originally Posted by Retro1234

Next Question Differences between InitCopList and Slice and Pros and Cons of both?

I found this:

"The display library is similar in concept to the slice library described above, however it uses a more flexible approach, and also supports the extended capabilities of the AGA chipset. It translates more closely to how the Amiga display hardware actually works, which gives the programmer more control over its behaviour. Unfortunately this can also make it appear slightly more complicated to use."

So AGA support is at least one advantage of using the display library.

[Retro1234]

Originally Posted by witchmaster

I found this:

"The display library is similar in concept to the slice library described above, however it uses a more flexible approach, and also supports the extended capabilities of the AGA chipset. It translates more closely to how the Amiga display hardware actually works, which gives the programmer more control over its behaviour. Unfortunately this can also make it appear slightly more complicated to use."

So AGA support is at least one advantage of using the display library.

So theres no AGA support at all with Slice?

[MickGyver]

Originally Posted by Retro1234

So theres no AGA support at all with Slice?

Slices do work on AGA machines but they probably don't support 256 colours etc.

[Retro1234]

Originally Posted by witchmaster

Slices do work on AGA machines but they probably don't support 256 colours etc.

Thanks again - what about AGA dual playfield 16*16?

[Cylon]

NO. Never. Or hardware banging ASM.

[idrougge]

Originally Posted by Retro1234

Next Question Differences between InitCopList and Slice and Pros and Cons of both?

InitCopList is part of Display library, which replaces the old Slices library.

The main advantage of Display library is AGA support and flexibility with regard to copper usage. The disadvantage is that it is trickier in its initialisation and that some aspects were never finished by Acid.

But overall, it's best to stay with Display, since it has more modern support.

[Anakirob]

Simplest but not entirely accurate explanation of the difference between Slice and Display is the former is OCS and the latter is ECS and AGA.

I used slice in one production that I personally released. Loadershit was released at Syntax 2007 I seem to recall.

But I much prefer display for so many reasons. I personally set up the Blitz display routines that the two ECS Disaster Area demos I was involved in on YouTube feature. Although Dave did the demo effects in 68K we were using Blitz to do stuff like set-up elaborate copper effect with just a few commands. I don't mean to boast but I even saw that Ript seems using my palette fading technique in his more recent demos too. so copper and/or bitplane palette tricks is what I know. Ask me about stuff like palette fading, manually setting up double, triple or with the aid of sprites even quadruple playfields >256 colours on screen and the like I really like interference circles and if you don't know how to do these I can explain, but I seem to recall that there is a reasonable example bundled with Blitz 21. anyway.

i also have a trick I used on the BeachParty invite I like to call "PAL:Super-low res" it's pretty simple. Just use the copper to double the vertical resolution and Bob's your uncle, now your hi-res graphics will display with the correct aspect ratio on a lo-res screen. The demo in question also features an example of one method of producing a the triple playfield routine I was talking about. Which is achieved by drawing the interference circles onto 2 bitplanes and using the remaining bitplanes to display the actual information and logo graphics. Also if you have a bright monitor you will notice the full-screen background animation which is about a dozen frames if I recall correctly. Which brings me to my next newbie trick which is...

...When your executable is ready for final release, if all the data will fit in memory at once then INCBIN EVERYTHING. And if you either need to meet a size requirement and/or plan on the user running the game from floppy then compress the bejesus out of the final executable with CrunchyDat or something similar.

Also seeing as nobody complained about previous MOD attachments i have included the module from the intro I mentioned. I was pretty pleased with myself to have a progressive structured 2:50 song in under 30KB as MOD is not the most efficient format.

And with Blitz it can be a bit of a pain and may require ECS, but it will handle most complex tracker tricks of later Protracker versions as well as giving you the ability to read the 8xx command which you might use to store misc game data and save some CPU time reading enemy attack wave tables by using the data that is already loaded into memory with the module.

[MickGyver]

Thanks for the explanations of Slice and Display, very valuable information!

Another question, is it somehow possible to hide the Workbench / AmigaDOS screen entirely when starting a game made in BB2? I created a bootable CD with SetPatch quiet in startup-sequence and this hides the AmigaDOS screen but when the BB2 executable runs the WB screen is visible for a brief moment even if the executable goes to Blitz mode directly and creates a slice.

[Anakirob]

Originally Posted by witchmaster

Thanks for the explanations of Slice and Display, very valuable information!

Another question, is it somehow possible to hide the Workbench / AmigaDOS screen entirely when starting a game made in BB2? I created a bootable CD with SetPatch quiet in startup-sequence and this hides the AmigaDOS screen but when the BB2 executable runs the WB screen is visible for a brief moment even if the executable goes to Blitz mode directly and creates a slice.

Well, there are commands to move WB screens to front/back. But I don't think that's going to help you. There is a command which can move a screen. I used this in a demo once to create the effect of the workbench screen sliding down to reveal a black screen, but you could set the value much higher and it would scroll all the way down so that it's not visible instantly. But even this I don't think will solve your problem.

Have you tried adding the text ">NIL:" after the name of your blitz program in the startup-sequence? This should direct the program not to output to the current shell (or anything) and should prevent the Workbench screen from opening

Alternatively if that does not work another way you could ensure the screen stays blank is to is use the Workbench 1.3 preferences program to set all the colours to black.

It's not elegant but it works, I've seen a few disks use this method.

[Coagulus]

Can't remember but is it possible to set all the wb colours to black including the pointer? Then you wouldn't see it before the program starts...

Edit: ah that was already said!

[Anakirob]

Originally Posted by Coagulus

Can't remember but is it possible to set all the wb colours to black including the pointer? Then you wouldn't see it before the program starts...

Edit: ah that was already said!

It should be noted that saving the "system-configuration" file using 1.3 preferences may be tricky to do after you've set your palette to match the name of New Zealand's national rugby team (The "All Blacks")

Be sure to take note of the on-screen location of the save button, I have used my index finger to point to the spot so I can easily locate this. But a removable sticker may work too, albeit with the undesirable effect of leaving some of its adhesive residue on your screen.

You may like to leave a single white pixel as your pointer graphics to make it easier to save the preferences, as far as I recall the 1.3 preferences program does not feature hotkeys for things like saving your settings.

But I think that the best option is to add the argument >NIL: to your startup-sequence on the line where you call your program. This should work.

[MickGyver]

Originally Posted by Anakirob

It should be noted that saving the "system-configuration" file using 1.3 preferences may be tricky to do after you've set your palette to match the name of New Zealand's national rugby team (The "All Blacks")

Be sure to take note of the on-screen location of the save button, I have used my index finger to point to the spot so I can easily locate this. But a removable sticker may work too, albeit with the undesirable effect of leaving some of its adhesive residue on your screen.

You may like to leave a single white pixel as your pointer graphics to make it easier to save the preferences, as far as I recall the 1.3 preferences program does not feature hotkeys for things like saving your settings.

But I think that the best option is to add the argument >NIL: to your startup-sequence on the line where you call your program. This should work.

Thanks for the help!

The problem with the AmigaDOS screen showing up on the CD32 seems to be when I show a CDXL with the cdgsxl command, after that the AmigaDOS screen is shown, I have no idea why. I have tried replicating a similar startup-sequence where this does not happen but to no luck. When I comment out the cdxl it boots into the bb2 app without showing anything so that's good, I just have to figure out the cdxl problem. Seems kickstart 3.1 shows a black screen until something is output to the CLI so using >NIL: with commands works here.

When it comes to booting from floppy, I tried putting >NIL: for every command in the startup-sequence like this:

SetPatch >NIL: quiet
Assign >NIL: ENV: RAM:
JoyTester >NIL:

But that did not work, the AmigaDOS screen is still showing. Nothing is output to it though.

Doing the all colours black thing works, the sticker trick helped when doing this. I made the mouse pointer one pixel darkest of blues, impossible to see if location is unknown. I copied the system-configuration file from the WB floppy to the devs folder of my bootable floppy.

I'm attaching the system-configuration file here if somebody else needs it. It's created using WB1.3.

EDIT1: Well duuuh, the all black system-configuration works for the CD32 CD also of course, I just created a devs folder for the CD and copied the system-configuration file there. It actually looks like the CD I was comparing with used the same trick. All good, thanks again for the help!

EDIT2: Laying the final piece of the black puzzle I figured out that it's better to create a Bitmap before creating a Slice. In some examples I have made, a Slice is created before creating a Bitmap and this causes a flash of random gibberish on the screen at start.

[Cylon]

There are also DisplayOff/On commands in Blitz to hide visible artifacts.