Jump to content
IGNORED

Creating your own High Resolution Titlescreens with asm


Atarius Maximus

Recommended Posts

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.com/2600/playfieldpal.html?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.randomterrain.com/atari-2600-me...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. :D

 

Steve

titlescreen_demo.txt

titlescreen_demo.bin

Link to comment
Share on other sites

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

Link to comment
Share on other sites

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

titlescreen_demo.bas

Edited by SeaGtGruff
Link to comment
Share on other sites

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. :thumbsup:

Link to comment
Share on other sites

  • 5 months later...

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
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...