Jump to content
IGNORED

[Very odd scanlines problem!] Strange B&W effect in game


Recommended Posts

Edit: Something strange is happening with the game now. It goes to 263 scanlines on seemingly random moments but always at playfieldpos = 0 and 3 lines before the top stump and branches are made. It only happens when the AI is being used. It does not seem to have to do with the missiles and coconut. (although the coconut moving up also seems to have glitched the scanlines too, but only if it also happened on this same scanline.) It also only seems to happen when AI is used. So either the AI code makes the loop too long (Which I do not expect, as then it would happen more often and regurarly?) or it does something that causes the slowdown.

 

I am a bit at a loss here and it would be great if someone could take a look. I left the rest of this topic in tact so that the answers below make sense. Check here for latest upload: http://atariage.com/forums/topic/283009-strange-b-w-effect-in-game/?p=4114107

 

 

Old topic:

 

I got a strange error in my game that draws the color slowly every few? frames. The framerate seems to be OK so I am not sure what is wrong and how to google for this error. (Black and white drawing didnt bring up anything.) You don't see it at all in Stella but on real hardware it blinks.

 

I added a screenshot of the B&W effect and the code.

post-48701-0-36032800-1537002006_thumb.jpg

MonkeyKing0.22.bas.bin

MonkeyKing0.22.bas

Edited by Coolcrab

The framerate is not stable if you set the left difficulty switch to "A" position by pressing F5 (default in Stella is both difficulty set to "B").

 

Many PAL TVs will display in B/W if there's an odd number of scanlines and that's what you're seeing on your TV (it's the same on my CRT) .

 

Stella emulates this effect: go to "Options" > "Developer Settings", then select the "Video" tab and enable "PAL color-loss". Since this is an effect that only applies to PAL TVs, you must also tell Stella to run the game in PAL60 mode: you can cycle through the various modes with CTRL+F while playing the rom, or you can set it by selecting "Options" > "Game Properites" and change the "Format" in the "Display" TAB.

Once you do all these three steps (enable PAL color loss, set left difficulty to A and set Format to PAL60), you'll see the game in Stella behave like on your TV.

  • Like 3

Don't know about your question, however:

 

this is an invalid bB command:

player1scorecolor = $fe

 

add a space after:

;dim _startgame = p

 

Then it compiles for me.

 

How many bytes does your game have left?

I see places in your source code that can get you back a lot of ROM if you need it for things.

Also, the B&W effect in Stella you screengrabbed is a feature in the debugger. The B&W portion is the previous frame, and the color portion indicates how much of the current frame is drawn, at this particular instant. If you hit the "scan +1" button a few times, the emulation will run for a few more scanlines, and you'll see a few more lines of color.

The framerate is not stable if you set the left difficulty switch to "A" position by pressing F5 (default in Stella is both difficulty set to "B").

 

Many PAL TVs will display in B/W if there's an odd number of scanlines and that's what you're seeing on your TV (it's the same on my CRT) .

 

Stella emulates this effect: go to "Options" > "Developer Settings", then select the "Video" tab and enable "PAL color-loss". Since this is an effect that only applies to PAL TVs, you must also tell Stella to run the game in PAL60 mode: you can cycle through the various modes with CTRL+F while playing the rom, or you can set it by selecting "Options" > "Game Properites" and change the "Format" in the "Display" TAB.

 

Once you do all these three steps (enable PAL color loss, set left difficulty to A and set Format to PAL60), you'll see the game in Stella behave like on your TV.

 

Aha that helped! odd that its only in PAL though. I think that I narrowed it down to branch creation of destruction. Thanks!

 

Don't know about your question, however:

 

this is an invalid bB command:

player1scorecolor = $fe

 

add a space after:

;dim _startgame = p

 

Then it compiles for me.

 

How many bytes does your game have left?

I see places in your source code that can get you back a lot of ROM if you need it for things.

That command is from a minikernel (that I didn't add here..oops) You can find it in the MK main thread.

Where do you see rom space? I would be very happy to have some more. I got ~17b now.

 

Also, the B&W effect in Stella you screengrabbed is a feature in the debugger. The B&W portion is the previous frame, and the color portion indicates how much of the current frame is drawn, at this particular instant. If you hit the "scan +1" button a few times, the emulation will run for a few more scanlines, and you'll see a few more lines of color.

Ah thats good to know! I confused that effect with the blinking. But its something else.

Aha that helped! odd that its only in PAL though.

It depends on the way old PAL TVs processed the color information. Modern LCDs probably don't show this effect at all. Edited by alex_79

This is about 64 bytes returned, by re-arranging, and dropping "goto" (in "if then goto" IF "goto label" is close).

Really you need to code "If - then - goto" and then remove the goto and recompile and see if it gives a savings or errors.

If it errors, you need to add the "goto" back.

If it saves bytes, you don't need the "goto".

 

Technically assembly can jump to a label "free" if it is within 128 bytes of the "if statement".

Usually goto jumps to the label over "collision detections" is too far away, and it will error.

 

In the attached code you need to add back my commented out player1scorecolor and add back the "inline xxx.asm" at the end.

 

 

MonkeyKing0.22.bas

  • Like 1

It depends on the way old PAL TVs processed the color information. Modern LCDs probably don't show this effect at all.

Modern tv's lose sync if you use HDMI. So I really need to kill that glitch. Trying to narrow it down but no luck yet.

 

This is about 64 bytes returned, by re-arranging, and dropping "goto" (in "if then goto" IF "goto label" is close).

Really you need to code "If - then - goto" and then remove the goto and recompile and see if it gives a savings or errors.

If it errors, you need to add the "goto" back.

If it saves bytes, you don't need the "goto".

 

Technically assembly can jump to a label "free" if it is within 128 bytes of the "if statement".

Usually goto jumps to the label over "collision detections" is too far away, and it will error.

 

In the attached code you need to add back my commented out player1scorecolor and add back the "inline xxx.asm" at the end.

 

 

No way you solved the framerate problem and freed up rom! :o

You can try using smartbranching and see if it helps with saving bytes for "if - then - goto" statements:

 

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

Modern tv's lose sync if you use HDMI. So I really need to kill that glitch. Trying to narrow it down but no luck yet.

 

No way you solved the framerate problem and freed up rom! :o

Wow.

Save very often.

Sometimes a file will compile, and then it will not due to some "invisible text character".

 

For instance, I was getting an error at the " = q " which was written okay.

Some return character or other before or after that was not letting it compile.

That's what I mean by "invisible text character".

As soon as I commented that out and retyped the exact same thing, it compiled.

 

It's hard explaining something that doesn't seem to make sense! :)

You can try using smartbranching and see if it helps with saving bytes for "if - then - goto" statements:

 

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

I went through all the goto's (got about 3 more out) and now have a staggering 90b left. THis is a good idea though.

 

Wow.

Save very often.

Sometimes a file will compile, and then it will not due to some "invisible text character".

 

For instance, I was getting an error at the " = q " which was written okay.

Some return character or other before or after that was not letting it compile.

That's what I mean by "invisible text character".

As soon as I commented that out and retyped the exact same thing, it compiled.

 

It's hard explaining something that doesn't seem to make sense! :)

I've never ad that issue yet. (fingers crossed) Very odd though.

Also do you have any tips on my AI btw? Trying to invest the new bytes into that, but if I add much more pfchecks It needs draw screens again.

 

I added a 'if missile1 < player1y then player1y = player1y - 1' then I added a y and rewrote the pf pixels to read on the AI's level. Hoewever, he only looks above him now so if he goes down he hits everything. =/ I think that it would be awesome if he had this behaviour bit IDK if its doable. (Replace the AI with this to have a look at what I mean)

 ; AI controll
 if !switchleftb then __AI
 goto __skipAI

__AI
 if _invisible0 then goto __skipAIball ; he does ! work when invisible
 if !(rand & 127) then goto __skipAIball 

 temp1 = (player1x - 14) / 4
 temp2 = (player1y ) / 8
 temp3 = player1y - bally
 temp4 = %00000000


 if player1score = $c && bally < player1y then gosub __killbranch2 : gosub __firesound
 if player1score = $d then gosub __livesplus2 

 if missile1y < player1y && player1y > 10 then player1y = player1y - 1 else  if missile1y > player1y && player1y < 82 then player1y = player1y + 1

 if pfread(temp1, temp2) then _left_right = _left_right ^ 32 : __skipAIball
 if ballx = player1x + 3 && temp3 < 30 then temp4{0} = 1 
 if !pfread(23,10) then temp4{1} = 1 
 if !pfread(25,10) then temp4{2} = 1 
 if !pfread(23,9) then temp4{3} = 1 
 if !pfread(25,9) then temp4{4} = 1 

 if temp4 = %00011111 then _left_right = _left_right ^ 32 	


__skipAIball
__skipAI

Sorry I cant help with AI.

Everything but game logic.

Sound, music, samples, graphics, color, layout...

 

I started with bB DPC+ kernel so I know that better than the standard kernel options.

 

I can optimize even if I dont understand the code.

 

The smartbranching will add back in a goto if it cant branch for free, but some dropped goto commands get missed even by smartbranching on and will error on compile, thats why I said it is best to write code using them, and then to remove and test compile later.

 

That and the put as many things=(same value) on one line using : between them, are 2 large optimizations, even though it makes the code harder to read.

 

I dont know about writing a compiler, but if I were to add a compile pass it would be to look for seperate defines to the same value and combine because it compiles like this:

 

player1x=0

player0x=0

AUDV0=0

AUDV1=0

_apple=0

_anything=0

 

Compiles To (load / store):

 

lda 0

sta player1x

lda 0

sta player0x

lda 0

sta AUDV0

lda 0

sta AUDV1

lda 0

sta _apple

lda 0

sta _anything

 

When:

 

player1x=0: player0x=0: AUDV0=0: AUDV1=0: _apple=0: _anything=0

 

compiles to (one load / store):

 

lda 0

sta player1x

sta player0x

sta AUDV0

sta AUDV1

sta _apple

sta _anything

 

So thats where you get ROM back by writing it differently.

  • Like 1

The smartbranching will add back in a goto if it cant branch for free, but some dropped goto commands get missed even by smartbranching on and will error on compile, thats why I said it is best to write code using them, and then to remove and test compile later.

 

 

Good point. I always set smartbranching on but it's probably better to not use it and check if goto is needed by hand.

Sorry I cant help with AI.

Everything but game logic.

Sound, music, samples, graphics, color, layout...

 

I started with bB DPC+ kernel so I know that better than the standard kernel options.

 

I can optimize even if I dont understand the code.

 

The smartbranching will add back in a goto if it cant branch for free, but some dropped goto commands get missed even by smartbranching on and will error on compile, thats why I said it is best to write code using them, and then to remove and test compile later.

 

That and the put as many things=(same value) on one line using : between them, are 2 large optimizations, even though it makes the code harder to read.

 

I dont know about writing a compiler, but if I were to add a compile pass it would be to look for seperate defines to the same value and combine because it compiles like this:

 

player1x=0

player0x=0

AUDV0=0

AUDV1=0

_apple=0

_anything=0

 

Compiles To (load / store):

 

lda 0

sta player1x

lda 0

sta player0x

lda 0

sta AUDV0

lda 0

sta AUDV1

lda 0

sta _apple

lda 0

sta _anything

 

When:

 

player1x=0: player0x=0: AUDV0=0: AUDV1=0: _apple=0: _anything=0

 

compiles to (one load / store):

 

lda 0

sta player1x

sta player0x

sta AUDV0

sta AUDV1

sta _apple

sta _anything

 

So thats where you get ROM back by writing it differently.

I tried some of that but im low on memory now. WOuld really be happy with a few more bytes. Want to add 2 more ifs.

Could you take a look?

 

EDIT: I found 22b and added them in. However the original error of this thread is back T_T

The AI does too much I think and it just eats frames, but only when new branches are made. So a smartly placed drawscreen somewhere might fix it. If anyone sees it please tell me!

MonkeyKing0.23.bas

score_graphics.asm

playerscores.asm

Edited by Coolcrab

How about this?

 

Found 4 bytes.

 

Made 1 drawscreen. Found 41 bytes.

 

Is the sound broken now?

Sound seems fine, but there is a graphics glitch now that appears when there is a gosub tree that goes more than 2 levels (it corrupts the memory apparently)

The scanline problem is still there though. (it drives me crazy!)

 

I'll compare the two programs for the space though, it amazes me how you squeeze so much out. :P

  • 3 weeks later...

So I am almost done with this game but when trying it out on real hardware I noticed that there still is a problem when playing with the AI. (So left difficulty to A)

I don't know why this is happening as it only seems to be an issue when playfieldpos = 0. (Also at higher scores of 60+)

 

I tried to turn off the AI when playfieldpos=8 but it doesnt seem to work.

 if !switchleftb && playfieldpos <> 8 then __AI

It might have to do with it drawing the top of the tree at playfieldpos=1, I tried setting it to 2 and that worked until the speed doubled.

 

if playfieldpos = 1 then _left_right{0} = 1 : pfpixel 8 0 8 on : pfpixel 24 0 24 on else _left_right{0} = 0

 

I'm not sure why its doing this all of a sudden. Does anybody know a way around this?

MonkeyKing1.0.bas.bin

MonkeyKing1.0.bas

When the playfieldpos transitions back to 0, it does a coarse scroll. This is expensive cyclewise, because a bunch of memory has to be moved around. Here's another thread on it.

 

You're doing the right thing, trying to eliminate cycle overages by skipping stuff, but it needs to be on the frame prior to transitioning to 0, IIRC.

  • Like 1

When the playfieldpos transitions back to 0, it does a coarse scroll. This is expensive cyclewise, because a bunch of memory has to be moved around. Here's another thread on it.

 

You're doing the right thing, trying to eliminate cycle overages by skipping stuff, but it needs to be on the frame prior to transitioning to 0, IIRC.

That seemed to work a bit it now doesn't jump when the speed is below the 254. Once it moves into higher speeds and goes >1 block per frame it starts flickering like mad. But still always at the playfieldpos = 0

I think that it is flipping when it does a double jump at either 6 or 7, but I'm not sure on how to fix that.

 

Here you can see what I do to make it scroll faster than 256 + some other stuff

 _left_right{2} = 1

 if _sum > _speed then __skipscroll
__scrolldown

 ;animate sprite 
 _animate = _animate + 1
 if _animate > 5 then _animate = 0


 ; check if a new tree block needs to be made and then see if a branch should be made
 if playfieldpos = 1 then _left_right{0} = 1  : pfpixel 8 0 8 on : pfpixel 24 0 24 on   else _left_right{0} = 0 
 if _left_right{0} && (rand & 1) then gosub __branch 


 ;Move magic stones & ball & scroll screen

 missile0y = missile0y + 1
 missile1y = missile1y + 1
 bally = bally + 2
 pfscroll down
 if !switchleftb then __AIscroll
 goto __AIscrollskip
__AIscroll
  if missile1y > player1y && player1y < 82  then player1y = player1y + 1
__AIscrollskip

__skipscroll

 if _left_right{1} && _left_right{2} then _left_right{2} =0 : goto __scrolldown

 ; speed up the tree 
 _sum = _sum + _speed

And here I increase speed to a preset maximum.


 if playfieldpos = 7 then __skip_new_row
__skip11
 if pfread(8,11) then gosub __sprite_color : drawscreen : _speed = _speed + 1 : pfhline 4 11 13 off : pfhline 20 11 28 off : score = score + 1 : gosub __bleep : gosub __sprite_color : drawscreen 
__skip_new_row
 if _speed > 254 && !_left_right{1} then _left_right{1} = 1 : _speed = 0 
 if _speed > 100 && _left_right{1}   then _speed = 100

I just wish that it worked :P

MonkeyKing_NTSC.bas

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