RevEng Posted December 31, 2010 Author Share Posted December 31, 2010 (edited) 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 Quote Link to comment Share on other sites More sharing options...
jrok Posted December 31, 2010 Share Posted December 31, 2010 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted December 31, 2010 Author Share Posted December 31, 2010 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. Quote Link to comment Share on other sites More sharing options...
SuperNESFreak Posted January 1, 2011 Share Posted January 1, 2011 (edited) 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 Quote Link to comment Share on other sites More sharing options...
+Random Terrain Posted January 1, 2011 Share Posted January 1, 2011 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 Quote Link to comment Share on other sites More sharing options...
RevEng Posted January 1, 2011 Author Share Posted January 1, 2011 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted April 25, 2011 Share Posted April 25, 2011 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 25, 2011 Author Share Posted April 25, 2011 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted April 25, 2011 Share Posted April 25, 2011 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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted April 25, 2011 Author Share Posted April 25, 2011 48x1 is monochrome, but 48x2 can be colored per-line. (check out the samples for details) Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 23, 2011 Share Posted June 23, 2011 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.) Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 24, 2011 Author Share Posted June 24, 2011 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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 24, 2011 Share Posted June 24, 2011 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? Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 24, 2011 Author Share Posted June 24, 2011 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) Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted June 24, 2011 Share Posted June 24, 2011 (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. Quote Link to comment Share on other sites More sharing options...
RevEng Posted June 24, 2011 Author Share Posted June 24, 2011 (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. Quote Link to comment Share on other sites More sharing options...
+atari2600land Posted July 4, 2011 Share Posted July 4, 2011 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". Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 26, 2011 Author Share Posted July 26, 2011 It seems the DPC+ kernel is missing some memory locations that many minikernels need. The first post has been updated with the fix. 3 Quote Link to comment Share on other sites More sharing options...
ScumSoft Posted July 27, 2011 Share Posted July 27, 2011 Thanks for looking into it for us. Quote Link to comment Share on other sites More sharing options...
RevEng Posted July 27, 2011 Author Share Posted July 27, 2011 Thanks for looking into it for us. Glad to do my bit. Quote Link to comment Share on other sites More sharing options...
jwierer Posted July 29, 2011 Share Posted July 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 29, 2011 Share Posted July 29, 2011 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". Quote Link to comment Share on other sites More sharing options...
jwierer Posted July 29, 2011 Share Posted July 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
+Philsan Posted July 29, 2011 Share Posted July 29, 2011 Jeff, I've just tested my previous not DPC+ L.E.M. version and it compiles too. Have you tried ScumSoft package? Quote Link to comment Share on other sites More sharing options...
jwierer Posted July 29, 2011 Share Posted July 29, 2011 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 Quote Link to comment Share on other sites More sharing options...
Recommended Posts
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.