7 replies to this topic

[Atarius Maximus]

I thought I'd share and explain the code I've used to create some of the hi-res title screens in a few of my bB games. It's a simple asm program that allows for a symmetrical, multicolored 96x40 playfield. Each of the 96 scanlines can have it's own color. I haven't quite figured out sprite positioning yet, I can't get the sprite to appear anywhere else but on the right edge of the screen. I'm sure that's an issue that would be easy to fix, maybe somebody with more asm knowledge than me can help with that. Changing the sprite graphic is pretty easy, it's pretty much the same as creating a sprite in a pure bB program - just change the 0's to 1's where you want a pixel to appear.

To create the titlescreen graphics, the easiest method is to go to Kirk Israel's site and use the PlayfieldPal tool. Once the playfield is designed, you simply cut and paste the PFData code and overwrite what's already in this sample. Link to PlayfieldPal:
http://www.alienbill...tml?vertsize=96

To change the colors, change the PFLColor and PFRColor tables at the bottom. There are 96 values, one for each line. The last value in the PFRColor table is the top line of the playfield, they go in backwards order from there. Link to Color Chart:
http://www.randomter...html#colorchart

It's actually pretty simple to add this titlescreen to any game, provided you have enough ROM space for it. Here's how the code logic works:

   goto titlescreen

begin
   goto GameStart

titlescreen
   <asm code here>
   <if firebutton is pressed, asm code will jump to a bB subroutine called 'begin'>
   <end asm code>

GameStart
   put the bB code for your game here.

I've found that the 'begin' subroutine has to immediately precede the asm code, or you'll get 'branch out of range' errors when you compile with bB. Also, if you use the titlescreen outside of bank 1, a few changes have to be made. You have to change the 'BNE .begin' to a 'JMP .begin', the 'begin' subroutine has to be in the same bank as the asm code, and you have to remove the code that clears the TIA registers. I'm not sure why, I just figured that out with trial and error experimentation. It all works as-is if you keep it in bank 1.

This sample uses the titlescreen graphics and colors from CaveIn, and when you press the fire button it jumps to a simple demo game.

Enjoy! I hope someone finds this useful.

Steve

Attached Files

•  titlescreen_demo.txt   18.62K   118 downloads
•  titlescreen_demo.bin   8K   116 downloads

[Random Terrain]

Thanks. I hope someone will be able to help with the sprites.

[Snider-man]

Wow. INCREDIBLY useful stuff. Thanks very much for posting this.

[Atarius Maximus]

Snider-man, on Thu Feb 28, 2008 5:33 AM, said:

Wow. INCREDIBLY useful stuff. Thanks very much for posting this.

Thanks, and you're welcome.

I looked over the code briefly again this morning, and I saw a slight problem - nothing that will prevent the demo from working, however.

This line:

 if joy0fire then x=1:goto init

Should be this:

 if joy0fire then goto init

The X=1 is not necessary. That section of code was copied from another source, and I forgot to remove that variable assignment before I posted it.

Steve

[SeaGtGruff]

Random Terrain, on Wed Feb 27, 2008 12:04 PM, said:

Thanks. I hope someone will be able to help with the sprites.

The problem with the sprites is that the code for the title screen frame doesn't include any code for positioning the sprites. I've copied the sprite-positioning code from the std_overscan.asm file, and modified it a tad to avoid duplicate line labels, and also to adjust the TIM64T value so the frame comes out with 262 lines. I also set player0x before falling into the code for the title screen. However, if you try to set player0x toward the left side of the screen, you'll see that the player colors don't come out correctly, apparently because of the timing in the scan lines.

Last year or before I'd thought about (eventually) creating a titlescreen include file, and my plan was/is to use the score trick for the title text. I'm overwhelmed with several other things right now, but someday (probably later than sooner) I'll see if I can rework this title screen code into an include file, add a 48-pixel-wide title, etc.

Michael

Attached Files

•  titlescreen_demo.bas   19.82K   59 downloads

Edited by SeaGtGruff, Fri Feb 29, 2008 12:44 AM.

[Random Terrain]

SeaGtGruff, on Fri Feb 29, 2008 1:43 AM, said:

The problem with the sprites is that the code for the title screen frame doesn't include any code for positioning the sprites. I've copied the sprite-positioning code from the std_overscan.asm file, and modified it a tad to avoid duplicate line labels, and also to adjust the TIM64T value so the frame comes out with 262 lines. I also set player0x before falling into the code for the title screen. However, if you try to set player0x toward the left side of the screen, you'll see that the player colors don't come out correctly, apparently because of the timing in the scan lines.

Last year or before I'd thought about (eventually) creating a titlescreen include file, and my plan was/is to use the score trick for the title text. I'm overwhelmed with several other things right now, but someday (probably later than sooner) I'll see if I can rework this title screen code into an include file, add a 48-pixel-wide title, etc.

Thanks.

[yuppicide]

Wow! Thanks so much for sharing this. I'm going to give it a try shortly for my new game.

[yuppicide]

Alright I have an idea. If this is possible I might even want to use this for my current game.

I've looked at your ASM for making a high res screen 96x40 available in bB. Very nice. I have an idea and I wonder if this is possible.

Let's say Superchip is enabled in bB. Let's say your title screen resides in bank 1 along with the begin statement. Once the fire button is pressed it goes to that begin statement and switches to bank two where the actual game resides and plays from.

So that means we'd have all of bank one to make a title screen. Now I don't know how much ROM the playfield data takes up for PFData0, PFData1, and PFData2. But what about if we specify PFData3, PFData4, PFData5, PFData6, PFData7, etc. etc, Then within the ASM we introduce code to delay. The screen would draw PFData0, 1, and 2 like it does now, wait a split second and then draw 4, 5, 6, wait a split second and draw 7, 8, and 9, wait a split second then go back to 4, 5, 6. Then repeat whole process and wait until fire is pressed.

This way I could have a screen that is high resolution and seems to move back and fourth.. or maybe two things symmetrical of course, move on both sides.. such as a seagull flying or two mouths laughing.

Edited by yuppicide, Fri Aug 1, 2008 10:21 AM.