The Titlescreen Kernel

[RevEng]

Hey,

 

This is REALLY good. Hopefully I'll be able to implement it in my 'Going Dotty' game (PS. Thanks a lot for all the help with that!)

 

I saw that the compiled BIN is 16kb, which seems kinda a lot for a titlescreen, whereas my game is only 2-3kb so far. Is there a lite version of this/how far can it be squeezed down?

 

Also, why does the Robotron logo flicker? Just wondering.

 

Looking awesome. Keep up the great work; you get awesome sauce.

Thanks!

 

I recommend to leave a full 4k bank to the titlescreen, especially if you plan a lot of fancy animation or scrolling. You might be able to get away with sticking it in the last bank of an 8k image, though you won't have room for anything fancy since the bB kernel also uses that last bank.

 

Since an 8k cart costs pretty much the same as a 16k cart, I personally wouldn't bother with squeezing it.

 

The robotron logo flickers because the 2600 doesn't have enough fine-resolution objects to make a non-flickering 96 pixel wide graphic, so the 96-wide minikernel takes turns displaying different parts of the image. I use a technique called flicker-blinds to make the flicker less objectionable.

 

It could probably look even less flickery if I used a dimmer color (the same would be true for the yoshi demo) but truthfully I didn't tweak the demo's all that much.

 

Also - no problem on the help. That's what the community is here for!

Edited December 31, 2010 by RevEng

[jrok]

It could probably look even less flickery if I used a dimmer color (the same would be true for the yoshi demo) but truthfully I didn't tweak the demo's all that much.

 

This is probably a little off-topic, but I am a little curious about lum value as pertains to flicker (and human perceptions of it). You mentioned color constancy before, which I'm familiar with, and which makes logical sense to me... and yet for some reason my (wrong) instinct keeps screaming that it is better to contrast a bright flickering color against a dark one.

 

I guess some wire gets crossed in my brain because there seem to be a couple of different concepts wrapped up in what makes flicker "good" or "bad." Besides the refresh rate and perceptual color, which I think I grasp, doesn't contrast also play into it? And if so, how? I think I keep getting hung up on "bright sprite/dark background" because something tells me that a low lum sprite on a low lum background would result in a game that was practically invisible. I don't know if that's because I'm thinking of it the way I think of chroma relationships, or if it's some other shortcircuit or brain bias. I do know that I'm wrong, but I've never really been sure why I'm wrong.

[RevEng]

This is probably a little off-topic, but I am a little curious about lum value as pertains to flicker (and human perceptions of it). You mentioned color constancy before, which I'm familiar with, and which makes logical sense to me... and yet for some reason my (wrong) instinct keeps screaming that it is better to contrast a bright flickering color against a dark one.

 

I guess some wire gets crossed in my brain because there seem to be a couple of different concepts wrapped up in what makes flicker "good" or "bad." Besides the refresh rate and perceptual color, which I think I grasp, doesn't contrast also play into it? And if so, how? I think I keep getting hung up on "bright sprite/dark background" because something tells me that a low lum sprite on a low lum background would result in a game that was practically invisible. I don't know if that's because I'm thinking of it the way I think of chroma relationships, or if it's some other shortcircuit or brain bias. I do know that I'm wrong, but I've never really been sure why I'm wrong.

I don't think you're wrong - but it's all part of a balancing act. Our brains definitely use luminance as well as color to distinguish an object from the background. Decreasing the luma contrast between a flickering object and the background definitely makes it appear more washed out or translucent.

 

But one thing that partially makes up for that is the fact that the 2600 colors become more saturated as the luma decreases. So as our brains lose the hinting from luma being turned down, the chroma hinting is turned up.

 

I wouldn't recommend using the same luma values for the flickering object and background, but +2 or +4 differences generally work well enough. Your mileage may vary depending on the chroma differences involved.

 

The Yoshi and Robotron examples are nowhere near the sweet spot right now.

[SuperNESFreak]

I recommend to leave a full 4k bank to the titlescreen, especially if you plan a lot of fancy animation or scrolling. You might be able to get away with sticking it in the last bank of an 8k image, though you won't have room for anything fancy since the bB kernel also uses that last bank.

 

Since an 8k cart costs pretty much the same as a 16k cart, I personally wouldn't bother with squeezing it.

 

Hmm, I know that the Atari can only access 4kb of data at a time on seperate banks, but I don't really know alot more about them. How will I have to allow for banks in my program?

 

EDIT: Also, from looking on the store, there is no mention of size with the Atari 2600 cart that is on offer. I assume you were talking about prices at AtariAge when you mentioned 8k/16k?

Edited January 1, 2011 by SuperNESFreak

[+Random Terrain]

Hmm, I know that the Atari can only access 4kb of data at a time on separate banks, but I don't really know a lot more about them. How will I have to allow for banks in my program?

There's a section about that on the bB page:

 

http://www.randomterrain.com/atari-2600-memories-batari-basic-commands.html#bankswitching

[RevEng]

EDIT: Also, from looking on the store, there is no mention of size with the Atari 2600 cart that is on offer. I assume you were talking about prices at AtariAge when you mentioned 8k/16k?

I was talking in general, but it applies to the AA store too - its the same price for 8k/16k/32k.

[+atari2600land]

I was just wondering if there was a way to stop the title screen from flickering between two lines of an image. It would especially look a lot better in this following example (to take a snapshot I had to put posphor on):

 

EDIT: What I mean is that each line you see In the word "Alien Greed 4" is 2 pixels tall. I want both the pixels in each line to be on at the same time instead of flickering.

[RevEng]

I was just wondering if there was a way to stop the title screen from flickering between two lines of an image. It would especially look a lot better in this following example (to take a snapshot I had to put posphor on):

 

EDIT: What I mean is that each line you see In the word "Alien Greed 4" is 2 pixels tall. I want both the pixels in each line to be on at the same time instead of flickering.

The high-res minikernels are built with player sprites. Since the 2600 has 2 players, each 8 pixels wide, with 3 copies of each player, I can only display 2*8*3=48 pixels without any flickering.

 

So the only way to avoid flickering between lines is to use a 48 pixel wide bitmap instead.

[+atari2600land]

I was just wondering if there was a way to stop the title screen from flickering between two lines of an image. It would especially look a lot better in this following example (to take a snapshot I had to put posphor on):

 

EDIT: What I mean is that each line you see In the word "Alien Greed 4" is 2 pixels tall. I want both the pixels in each line to be on at the same time instead of flickering.

The high-res minikernels are built with player sprites. Since the 2600 has 2 players, each 8 pixels wide, with 3 copies of each player, I can only display 2*8*3=48 pixels without any flickering.

 

So the only way to avoid flickering between lines is to use a 48 pixel wide bitmap instead.

Can a 48 pixel wide bitmap be more than one color also? I just see that you have put the default as just one color.

[RevEng]

48x1 is monochrome, but 48x2 can be colored per-line. (check out the samples for details)

[+atari2600land]

Hi, me again. What if you're using multiple pfcolors and not COLUPF? Would it still be possible to have more than one color as the background when using the titlescreen kernel and "set kernel_options pfcolors no_blank_lines background player1colors"?

I tried fooling around with the titlescreen.asm, and weird stuff happened, but not the stuff I'm looking for. I think the problem is in lines 57-59:

lda #1
sta CTRLPF
cdc

 

Is there any way to change that CTRLPF from having one solid color to more than one?

(I don't know ASM, I'm just guessing here and when I fool around with it.)

 

 

[RevEng]

The kernel_options don't apply to the titlescreen kernel, so setting those really shouldn't influence it one way or the other. Also the assembly lines you posted just setup a reflective playfield, and don't really influence the colors.

 

Having multiple background colors isn't possible with the existing code, and I don't think titlescreen kernel can ever be made to work nicely with the bB background color lists, due to the fact it's a bunch of minikernels instead of one uniform kernel. What may be possible to implement in future versions is a unique background color for each minikernel, or minikernels with their own bB type color lists.

[+atari2600land]

So I take it something like Pitfall (where the thing scrolls from "copyright 1982" to "Activision" and back to "copyright 1982") isn't possible with more than one background image, then. That's what I was trying to do, but I had a whole bunch of PFCOLORs instead of just one. Would it work if I just had one PFCOLOR and a bunch of COLUBKs, or no?

[RevEng]

Duplicating the Activision logo scroller is tough for general-purpose code because it has 2 colors per line - the white "Activision" and the rainbow.

 

The scrolling part can be duplicated in the titlescreen kernel, but you can't get individual colors on each line using the 48x1 minikernel. You can get individual foreground colors using the 48x2 minikernel, but the downside there is the text will be twice as tall.

 

(and multiple COLUBKs won't get you what you want, unless you modify the minikernels themselves)

[+atari2600land]

 

(and multiple COLUBKs won't get you what you want, unless you modify the minikernels themselves)

Actually, that's what I'm using (since I'm using background and pfcolors.) How hard would it be to do that?

Also, in Pitfall! there is no rainbow effect in the logo, that's in Pitfall 2. And I've got the scrolling effect done perfectly in my binary.

[RevEng]

 

(and multiple COLUBKs won't get you what you want, unless you modify the minikernels themselves)

Actually, that's what I'm using (since I'm using background and pfcolors.)

When you use "set kernel_options pfcolors no_blank_lines background player1colors", it sets up certain compile-time options for the bB kernel - it doesn't actually change the way playfields work on the 2600 itself, but rather, it changes how the bB kernel draws the playfields. So kernel options don't apply to the titlescreen kernel. (or any other custom kernel a bB program may call)

 

 

How hard would it be to do that?

There's not a whole lot of cycle time with the code as-is so the 48x1 minikernel would need major surgery.

 

I was planning to backport some of the updates I made to the code for the 21 Blue display, which would help with this, but work is kinda crazy right now and I'm a bit burned out, so it's not really high on my list.

[+atari2600land]

Found a solution to another problem I had. If you're using a modified score kernel and garbage comes up at the title screen score (if you're using digits A-F during the title screen), go into the score_image file and add the extra digits before "ifconst fontcharsHEX".

[RevEng]

It seems the DPC+ kernel is missing some memory locations that many minikernels need. The first post has been updated with the fix.

[ScumSoft]

Thanks for looking into it for us.

[RevEng]

Thanks for looking into it for us.

Glad to do my bit.

[jwierer]

Has anybody has any luck getting this to work with the new bB 1.1d release?

 

DASM now complains with the following:

 

DASM V2.20.07, Macro Assembler (C)1988-2003

--- Unresolved Symbol List

pfcenter                 0000 ????         (R )
game                     0000 ????         (R )
kernelmacrodef           0000 ????         (R )
vertical_reflect         0000 ????         (R )
pfhalfwidth              0000 ????         (R )
font                     0000 ????         (R )
FASTFETCH                0000 ????         (R )

Fatal assembly error: Source is not resolvable.
Errors were encountered during assembly.

 

Of course if I roll back to 1.1c the samples compile fine. It's also possible I am missing files in my upgraded compiler folder, though what I did was make a copy of 1.1c and applied the 1.1d folders which typically works.

 

Thanks,

Jeff

[+Philsan]

My L.E.M. titlescreen continues to work with new 1.1d bB version.

 

It didn't work in 1.1c bB version.

I had to add "const scorepointers=player1x".

[jwierer]

My L.E.M. titlescreen continues to work with new 1.1d bB version.

 

It didn't work in 1.1c bB version.

I had to add "const scorepointers=player1x".

I'm not compiling under DPC+ so I am thinking something changed in the normal compiler.

 

-Jeff

[+Philsan]

Jeff, I've just tested my previous not DPC+ L.E.M. version and it compiles too.

Have you tried ScumSoft package?

[jwierer]

Jeff, I've just tested my previous not DPC+ version and it compiles too.

Have you tried ScumSoft package?

Yes I just notcied it and thought it might be my bB folder, but after testing from the commandline I can see that 2600basic.exe is crashing. The previous executable is still working fine. I'm on a 64-bit Windows 7 machine. I am going to copy it over to a different one and see if I can replicate the problem.

 

Update: Crashes my other Win7 64-bit machine as well. Have to see if I can dig up my 32-bit laptop.

Update 2: Crashes my WinXP 32-bit machine as well.

 

-Jeff