KevKelley

I was going to play around with some code later to see if I can prevent any issues. I had noticed no issues with real hardware but have yet to try a CRT, which made me wonder if it is really an issue. I no longer worry about the reset switch over cycle, but I would hate to not experience any issues with my setup only for it to be unplayable for everyone else. After reading I had found one site that said NTSC games have ranged from 246-282. I have had some games get some big screen rolls and flicker but is it safe to assume that the scanline probably jumped more than that range and if the scanline count is in that range, if there is any issue with syncing it may be much less noticeable? So let's say I have one frame where it goes to 263, that may not even present itself, versus if it jumped to 312?

I see what you were saying. Since I use pfpixels in the middle,bi couldn't see a way to make it work (except with a custom kernel). Unfortunately I am not that far along in my learning to do so... But it seems like an interesting project to undertake. Currently I will just play with background colors for now to break up the monotony.

How would you determine where the second color would start?

By doing that, wouldn't it have a somewhat of a flicker effect?

I guess my main question would be how to time it's use or if it's even practical?

After reading some of the comments and threads about splitting the color of a scanline, and after reading RT's site, I was curious if it is possible in bB to use multiple vblanks to split the colors of a play field. So the desired effect would probably be something like this: The playfield would be something like this: Playfield: XXXXXXXXX X..........x.....X X.......x........X X....x...........X XXXXXXXXX Using vblanks, basically make the border a different color and any pfpixel inside the border be a different color. I had read how to use it but my understanding was that in bB I could only use it once and it would essentially force the entire playfield a different color during the loop. Not sure if this is correct but was interested in learning more. If this is something more complex involving assembly, I may have to put off playing around with it but I thought it would be interesting, especially when seeing the amazing effects like in the Stay Frosty menu.

That is really cool that some have used it for an effect. I had noticed recently that in Stella I would get a flicker of a high scan line count during gameplay. When I tested it on hardware I got nothing. I ran them both simultaneously and nothing. But then again I wasn't using a CRT. Not a big deal with the reset switches but would hate for something like a random screen roll or flicker in the middle of playing. I haven't seen anything, but is there possibility that depending on where it occurs it won't impact the screen at all? Or should I use a CRT for main testing?

This? Taxi Panic! Kind of like Crazy Taxi?

I love the sound effects and the variety of enemies. Either this is hard or I suck. Either way it was fun. I played around with it on my phone using Javatari and ran into no issues.

That was my thinking. When I tested it I didn't really experience much issue since as soon as I let go it jumped to the beginning. I didn't want to waste bytes for a repetition restrainer but was uncertain if there was anything in addition to rolling or flicker that I was unaware of. Also made me wonder if anyone had purposely used it for an effect previously too...

Will you use multiple sprites with flicker or just a single, simplified version? One thing that always stood out to me about the O2 was the simplistic but solid colors.

I have a Pengo with I think Maze in it.

I have read about maintaining scanlines but I was curious if there were ever an occasion where the negative impact of having too many scanlines can be ignored or if there are underlying issues as to why this should be avoided? What leads me to this question was that I was programming the reset switch. When I made it the scan lines jump but since it resets everything anyway I asked myself "Does it really matter?" in this particular situation.

I was kind of thinking that with the ball. I gotta pull out my O2 to reacquaint myself with it. Did you plan on adding to it or just making a direct port?

Are you using the ball for anything?

I can't wait to check this out. I always wondered how this would look on the Atari

My understanding is that there are trade offs using bB. It does the heavy lifting in terms of graphics so there are some sacrifices versus straight up assembly, where you can get more detailed looking games. You can get somethings back but there is a trade off and on RTs website there is a section that details the different options for the playfield and what you can and cannot do. The great thing about the site is that there are code examples embedded on the page or in some instances programs you can download to look at and run. I found that the explanations on the site are very easy to understand, even from someone with very limited programming experience. It may take longer to process the information but not impossible.

That is if it was in fact the Rigelians...

I feel like the Atari needs some more platformers. Excited to see what you come up with.

Ah. Okay. Thanks! I remember reading about nybble variables early on but never knew what for but now it makes sense. I will definitely play around with this. So then if I have it count up and need to change back to 0 then I would do: If PEEK_Counter = 15 then POKE_Counter 0 And then add to it using a temp variable. I'm sure I'll get the hang of this. Thanks very much!

I was looking at possibly freeing up variables if necessary and was curious if you could use part of a variable for a counter and the rest for bit operations? So based of my understanding, say I have a counter and it only ever used up to 4 bits (%00000000 - %00001010). Can I use the 4 bits that are never used or when a variable is used does it check all of the bits? So if I were to check for x{7} while having the counter at 10 (%10001010), would it read both or by turning on x{7} would it be read as 138?

I have an old laptop that I solely use for Atari programming and related stuff. I bookmarked Random Terrain's page and this forum and have them at the top of my browser so I can do a quick reference. I also flag threads that I find helpful in my understanding for future reference too.

When I last left off trying to turn on different different bit from the playfield variables. So after playing around some, i started messing around with XOR commands to change my pfhline draws and it seemed to work well, freeing up a little over 100 bytes. So I changed this: if e{0} then var4=%11111100 if e{1} then pfhline 6 1 9 on if e{2} then pfhline 11 1 14 on if e{3} then pfhline 16 1 19 on if e{4} then pfhline 21 1 24 on to this: if e{0} then var4=var4^%01111000 if e{1} then var4=var4^%00000011:var5=var5^%00000011 if e{2} then var5=var5^%01111000 if e{3} then var6=var6^%11110000 if e{4} then var6=var6^%00000111:var7=var7^%00000001 I had started using playfield variables, which is why e{0} originally had a variable but when I got into e{1} and e{4} it stretched over two variables. Initially I wasn't sure how to flip the bits which is why I kept the pfhlines temporarily. I use pfhlines in a couple more spots in my program so I will have to fix that up too, which should free up some space.

Hey 2018 Kevin! I was revisiting this as I started messing with this effect when I first started and when I moved to DPC+ I abandoned this game mechanic since I wasn't really using it in the newer program. But since I was practicing doing all sorts of things recently, I figured I would give an update to my past self! I was trying to make a bouncing ball(really missile sprite) in a portion of the playfield but then as playfield pixels are drawn on the screen I wanted the ball to switch direction. This was the little code I had came up with today as I was playing around with bitwise operations. const _Top = 13 const _Bottom = 74 const _Left = 22 const _Right = 116 missile1height=2 if missile1x<=_Left then k{2}=0 if missile1x>=_Right then k{2}=1 if missile1y<= _Top then k{3}=0 if missile1y>= _Bottom then k{3}=1 if !k{2} then missile1x=missile1x+1:if missile1x>=_Right && k{2} then missile1y=66:k=k^%00000100 if k{2} then missile1x=missile1x-1:if missile1x<=_Left && !k{2} then missile1y=23:k=k^%00000100 if k{3} then missile1y=missile1y-1:if missile1y>=_Bottom && k{3} then missile1x=25:k=k^%00001000 if !k{3} then missile1y=missile1y+1: if missile1y<=_Top && !k{3} then missile1x=116:k=k^%000010001 if collision(playfield,missile1) then missile1y=missile1y-2:k=k^%00001100 I may try to add something in there to give a little bit less predictability if it gets stuck in a rut but I don;t think that would be too much of an issue in what I was programming. It may not be the cleanest or best code in the world, but I am proud of it. Especially since I remember first looking at the sample program and being somewhat lost. Thanks Random Terrain and everyone else who had posted in these forums or who had helped me along the way! And as an added bonus, my first grader was watching me playing around with this and had a blast asking me to change the value of the constants to see how it impacts the program. Maybe we have a future homebrewer on our hands!

Thanks. I knew I should double check! I was feeling brave enough to post something from memory. This reinforces my statement about reading the website!