117 replies to this topic

[jwierer]

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

[SeaGtGruff]

jwierer, on Sat Jul 30, 2011 11:26 PM, said:

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

[jwierer]

SeaGtGruff, on Sat Jul 30, 2011 11:36 PM, said:

jwierer, on Sat Jul 30, 2011 11:26 PM, said:

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

[Random Terrain]

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, Sun Sep 11, 2011 7:12 AM.

[RevEng]

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.

[Random Terrain]

RevEng, on Sun Sep 11, 2011 8:39 AM, said:

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.

[atari2600land]

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?

[RevEng]

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

[atari2600land]

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.

[iesposta]

RevEng, on Wed Nov 23, 2011 5:54 PM, said:

I'm planning on releasing an updated titlescreen kernel next year...

6 month titlescreen status update request, please? Thanks in advance!

[RevEng]

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.



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.

[Random Terrain]

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....25#entry2522391

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



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.

[iesposta]

Random Terrain, on Sun May 20, 2012 7:26 PM, said:

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....25#entry2522391

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

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

[Random Terrain]

iesposta, on Sun May 20, 2012 7:36 PM, said:

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.

[RevEng]

Random Terrain, on Sun May 20, 2012 7:26 PM, said:

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.

iesposta, on Sun May 20, 2012 7:36 PM, said:

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.

[SpiceWare]

iesposta, on Sun May 20, 2012 7:36 PM, said:

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.

[SpiceWare]

RevEng, on Sun May 20, 2012 8:32 PM, said:

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.

[Random Terrain]

SpiceWare, on Sun May 20, 2012 8:47 PM, said:

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.