Jump to content
IGNORED

The Titlescreen Kernel


Recommended Posts

Ok I figured out why it was crashing. The lastest compiler doesn't like it when you use too many ":" on a single line. One seems to be fine, two seems to crash the compiler.

 

This compiles fine

 

if switchselect then swdebounce=30 : gamenumber=gamenumber+1 
if gamenumber=21 then gamenumber=1

 

This crashes the compiler

 

if switchselect then swdebounce=30 : gamenumber=gamenumber+1 : if gamenumber=21 then gamenumber=1

 

-Jeff

The lastest compiler doesn't like it whe you use too many ":" on a single line.

Are you sure it's the number of colons? I'll bet some bB programmers routinely use six or more colons on a single line. It seems more likely that it's somehow related to the nested if.

 

Michael

The lastest compiler doesn't like it whe you use too many ":" on a single line.

Are you sure it's the number of colons? I'll bet some bB programmers routinely use six or more colons on a single line. It seems more likely that it's somehow related to the nested if.

 

Michael

In testing it further it has nothing to do with the number of colons, but the total length of a single line. You just don't come across long lines of text without typically using more than one colon. I haven't nailed down the exact length, but the same code worked in releases prior to 1.1d.

 

Then again both cases were nested if's so you may be on to something. Still worked before so seems like a regression or new bug.

 

-Jeff

  • 1 month later...

I'm using the normal kernel. When you get a chance, stare at my title screen using Stella without pressing Alt + P. You'll see where the segments are in the game title and copyright info, because they bounce up and down a little every so often. In other words, you can see where the segments are 'attached' to each other.

 

When I look at it using the Harmony cart on a real Atari 2600, the places where the segments are supposed to be attached have thin black vertical lines as if the segments are one pixel too far away from each other. Can anything be done about that?

 

 

Thanks.

Edited by Random Terrain

Summary: Unfortunately not, it's a limitation of the 96x2 minikernel and analog TVs.

 

Long-Winded Explanation: Bitmap kernels normally display 48 pixels worth of data by displaying both player0 and player1 with 3 copies each, and modifying the player data right before it's displayed.

 

In the case of the 96 wide minikernel, it spaces out the players like this on one frame...

 

  • LINE 1:X X X X X X
    LINE 2: X X X X X X
    LINE 3:X X X X X X

...and like this on the next frame...

 

  • LINE 1: X X X X X X
    LINE 2:X X X X X X
    LINE 3: X X X X X X

...In a perfect world, the flickering between the two would fill in the full 96 pixels. The problem is, real hardware using NTSC/PAL CRT TVs isn't anywhere near a perfect world.

 

At the edges of each of those players there's delay before the player actually turns on, and there's delay before they turn off. Worse, the delay is slightly different for brightness part of the signal than it is for the color part of the signal. And there may be other artifacts that may creep in at these edges too, like ringing.

 

The perceived gap is less than a pixel wide, and varies depending on the TV and connection type, so I can't just move the players to shore up the gap. Moving them closer would result in a perceived overlap, which means instead of dark lines you'd see extra bright lines.

 

To mitigate these effects, titlescreen designers may choose to:

 


  • 1) Avoid the 96 wide bitmaps. The 48 wide bitmaps aren't prone to these effects in the same way.
     
    2) Darken the colors on their 96 wide bitmaps. The artifacts are lessened at lower luminances.
     
    3) Plan their bitmaps so the 8 pixel break is accounted for. e.g. use a monospaced font
     
    4) Live with it. A titlescreen is viewed for a short time, and IMO a screen full of graphics/text has a positive impact, and the glitches detract only when you stare at the screen for a while.

  • Like 1
1) Avoid the 96 wide bitmaps. The 48 wide bitmaps aren't prone to these effects in the same way.

Thanks. I'll try that and see if I can get the text to fit. Now I just have to relearn how to use the Titlescreen Kernel. :dunce:

  • 2 months later...

I was wondering two things. #1 - Are the missiles being used in making the title screen graphics in this kernel, because if not, I'd like to make the celery move left and right along with the title screen in the celery game I'm making. #2 - Why in the heck is this topic not pinned?

#1 - The missiles aren't available, sorry.

#2 - Dunno!

 

It doesn't hep you now, but I'm planning on releasing an updated titlescreen kernel next year, with a player minikernel that would allow for your walking celery or other sprites, as well as some other new features.

Well, I guess I could use a player for the celery sprite. I have a long ways to go until my game's finished, I plan to make the most of the 32k space. Maybe I can make it span 2 cartridges, like some CD games or something.

  • 5 months later...

I've had some real-life setbacks that have been major time-sinks, but I'm getting back on track with coding... if there's interest for a new release, I'll aim to put something out in a few weeks.

 

The progress so far...

 

I've added the ability to set a non-changing PF background behind the bitmaps.

 

post-23476-0-00783400-1337527442_thumb.png

 

I used the proto-code for this in the Army of Darkness titlescreen, to make the regular 48 bitmap seem wider.

 

I still have to do a player kernel. This is relatively easy code, but I want to mull over how it's going to integrate into everything instead of rushing in to it.

 

Down the road I'm also thinking about adding code so you can reposition the 48-wide bitmaps, dynamically or otherwise, but it won't make this release.

  • Like 2

I don't want to burn you out, so don't take this as a complaint or a command or a desperate baby bird peeping for more food. If you can find the time to figure out how, it would be great to be able to do something similar to this:

 

http://www.atariage.com/forums/topic/197100-asm-or-bbasic/page__st__25#entry2522391

 

http://www.atariage....-9116-level-up/

 

post-13-0-85910800-1337563132_thumb.png

 

I don't like to rely on difficulty switches, so having a menu that shows everything the player needs for a game would be wonderful. I don't care if it has a color gradient, I just need the player to be able to choose certain options, depending on the type of game.

I don't want to burn you out, so don't take this as a complaint or a command or a desperate baby bird peeping for more food. If you can find the time to figure out how, it would be great to be able to do something similar to this:

 

http://www.atariage.com/forums/topic/197100-asm-or-bbasic/page__st__25#entry2522391

 

http://www.atariage....-9116-level-up/

 

post-13-0-85910800-1337563132_thumb.png

 

I don't like to rely on difficulty switches, so having a menu that shows everything the player needs for a game would be wonderful. I don't care if it has a color gradient, I just need the player to be able to choose certain options, depending on the type of game.

 

Do you mean figure out how to put this in a title screen kernel?

Because SpiceWare said how this was done. It is just 48 kernel inverted where the font is clear and the sprite is black, showing the background color on the left and the playfield color on the right ( or vice versa) and turning off the "beam" on either side with a ball or missile mask... Wait, I guess it is quite complicated...

Do you mean figure out how to put this in a title screen kernel?

 

Yep. Just the title of the game at the top, a customizable menu in the middle, and the programmer's name and copyright date at the bottom.

I don't want to burn you out, so don't take this as a complaint or a command or a desperate baby bird peeping for more food. If you can find the time to figure out how, it would be great to be able to do something similar to this...

 

I'm always glad to hear suggestions, so not a problem there.

 

Spiceware's menus are definitely cool, but there are a couple of downsides too. Using vblank to cover up the background color means that this kind of display will only work on a black background. Also, the simplest method for the bB coder to create these menus - providing a bitmap for all possible displays on each line - will tend to be expensive rom-wise.

 

I can take a look at this for a later release. Truth be told I've been wanting to play around with 2-color bitmap code anyway.

 

Do you mean figure out how to put this in a title screen kernel?

Because SpiceWare said how this was done. It is just 48 kernel inverted where the font is clear and the sprite is black, showing the background color on the left and the playfield color on the right ( or vice versa) and turning off the "beam" on either side with a ball or missile mask... Wait, I guess it is quite complicated...

 

:) Yep, and the devil is in the details. My biggest challenge with the titlescreen kernel is making generic minikernels that are supportable, which tends to limit the types of tricks I can use.

  • Like 1

Because SpiceWare said how this was done. It is just 48 kernel inverted where the font is clear and the sprite is black, showing the background color on the left and the playfield color on the right ( or vice versa) and turning off the "beam" on either side with a ball or missile mask... Wait, I guess it is quite complicated...

 

Not only that, but the source code is available in my blog. As I mentioned here - while I won't do it, I have no problem with somebody else taking my routines and incorporating them into bB.

 

The latest version no longer turns the beam on and off, it accomplishes the same thing by changing the background and playfield colors on the fly.

 

Search the source (spacerocks.asm) for ShowTwoColorGraphic. It's only in there twice. Once as the subroutine that does the work, and once in the Main Menu loop which calls it.

 

The Main Menu loop is controlled by a datastream called MenuOptionsDatastream.

 

Before the main menu loop is run the sprites and missiles must be positioned and set for triplicate and 8x missiles. Search for MainMenu: and you'll see where that's done.

  • Like 2

Spiceware's menus are definitely cool, but there are a couple of downsides too. Using vblank to cover up the background color means that this kind of display will only work on a black background. Also, the simplest method for the bB coder to create these menus - providing a bitmap for all possible displays on each line - will tend to be expensive rom-wise.

As mentioned above, that's been changed in the latest version - you can use whatever background color you want. The current code is hard coded to black, but that's simple to change. Due to the nature of the Atari's display, any menu will be ROM expensive.

  • Like 1
Due to the nature of the Atari's display, any menu will be ROM expensive.

 

Even as bloated as Seaweed Assault was, it still had a couple of unused banks, so any future games I make should have room for a menu. If we get a nice menu system, I'll use it in every new game, but I'll probably also go back and put a menu in Seaweed Assault. Maybe that will make more people happy and my D- might be raised to a C.

  • Like 1
  • 3 weeks later...

As I mentioned here - while I won't do it, I have no problem with somebody else taking my routines and incorporating them into bB.

 

Entirely cool of you, but the routines use DPC+ and with the titlescreen kernel I can't assume that the game is DPC+.

 

But I get the gist of how 2-color bitmaps are done, and truth be told I get a kick out of deriving code from descriptions rather than adapting other peoples code. :)

Here's a bit of a teaser... The code for the next version is basically done.

 

post-23476-0-84776700-1339456902_thumb.png

 

Highlights include:

  • New player kernel added. Players have color changes on all lines, and can be single line resolution or greater.
  • Revamped gameselect kernel, has easily customisable 32-wide bitmap before the 2 score digits.
  • There are now 8 copies of each bitmap kernel.
  • 48-wide bitmap kernels now have an optional PF background.
  • All kernels except the 96-wide bitmap kernel use cycle-74 hmoves, to avoid the hmove bars at the left when using non-black backgrounds.

Here's a quick-and-rubbish demo.

 

titledemo.bas.bin

 

I'll update the first post with the code when I've had a chance to create a real demo and update the documentation.

  • Like 5

Actually, the sexiest thing I see in the screenshot above is the "GAME 02" part. Could be used for an in-game menu system/inventory/stats. Is the source available for the demo? I never knew how to mix title screen and standard sprites/kernel.

Edited by theloon

Actually, the sexiest thing I see in the screenshot above is the "GAME 02" part. Could be used for an in-game menu system/inventory/stats.

 

The only problem with that is there's currently a single instance of those. I could add copies and some sort of mechanism for tying a variable name to the value, if you guys think it's a useful as a general purpose minikernel.

 

 

Is the source available for the demo? I never knew how to mix title screen and standard sprites/kernel.

 

Prior to the new player minikernel in the upcoming release, you couldn't mix regular sprites and titlescreens.

 

I'd rather hang on the source until I've coded up a real demo, but to use the sprites basically you define the sprite data in the "player_image.asm" file, and you move them around within the player kernel using player0x, player1x, player0y, and player1y.

  • 1 month later...

This is one of those add-ons that doesn't seem so much like an add-on anymore. Especially with VisualbB support. I don't see any reason bB can't make Activision grade games now. Thank you very much for your work RevEng. Double thanks for updating it!

 

My COMFORT ZONE has been VIOLATED by your generosity!

Edited by theloon

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