Simon4 for Intv

[pimpmaul69]

I haven't tried it, but the 4 colors should have pallette equivalents that are darker - to really make it pop. At least enough to more than "slightly" stand out

on emulation i cant tell when it changes to the new color. I only notice when it changes back to the old color and it is ever so slightly changing

[mthompson]

I haven't tried it, but the 4 colors should have pallette equivalents that are darker - to really make it pop. At least enough to more than "slightly" stand out

 

To simulate "lighting up," the green quadrant seems backwards right now. How about dark green for the "off" state and either light green or bright green for "on"? Blue/cyan and red/pink would work well. For yellow, orange is probably as good as you can get to simulate an "on" state.

 

If all four squares had a border around them and dividing lines between, like the original Simon, the border could "light up" in white to emphasize which panel is "on." Little things like this might also start to give the game a more polished look.

[freewheel]

on emulation i cant tell when it changes to the new color. I only notice when it changes back to the old color and it is ever so slightly changing

 

OK fine, you guys broke me down and I tried it. My suggestions (because I see what you mean):

 

1. The colors need to be more distinct. Instead of violet and cyan for the bottom right, try blue and cyan. I'd probably go with cyan as the "base" color and blue as the highlight color - I think a darker, richer color when lit up makes sense. Similarly pink-red, yellow-orange, light green-dark green. I think some of these combinations are in place already but I really noticed the blue square as being not distinct enough.

 

2. When you have the same color twice in a row, it's not very obvious. The sound effects are the only way I could really tell. I think it needs to flash back to the "base" color longer, then show the highlight color again. This will be tricky to balance, as at higher levels Simon should speed up how quickly it displays the colors.

 

3. There is as way to avoid re-drawing the text on the screen constantly. Right now it flickers a lot and is a bit annoying. You should be able to separate the printing of text so that it doesn't have to flash like that. I suspect it's doing a CLS every time which isn't necessary for a game like this.

 

4. It would be very cool if you could make the gameboard rounded, instead of just 4 squares. This would take a bit more "smarts" but not too difficult.

 

And yeah, as just mentioned - a light-up border would help a lot.

 

On the sounds - some are good, some are ... iffy. I wonder if we can dig up the pitches for an original Simon game. You should be able to get damned close to the original.

Edited November 15, 2014 by freeweed

[+Tarzilla]

 

On the sounds - some are good, some are ... iffy. I wonder if we can dig up the pitches for an original Simon game. You should be able to get damned close to the original.

 

From wikipedia

Simon's tones, on the other hand, were designed to always be harmonic,^[2] no matter what order they were played in, and consisted of an A major triad in second inversion which resembles a Trumpet fanfare:

• E-note (blue, lower right);
• C♯-note (yellow, lower left);
• A-note (red, upper right).
• E-note (green, upper left, an octave lower than blue);

 

Of course I know nothing about music, so this is all greek to me.

[+Tarzilla]

 

From wikipedia

Simon's tones, on the other hand, were designed to always be harmonic,^[2] no matter what order they were played in, and consisted of an A major triad in second inversion which resembles a Trumpet fanfare:

• E-note (blue, lower right);
• C♯-note (yellow, lower left);
• A-note (red, upper right).
• E-note (green, upper left, an octave lower than blue);

 

Of course I know nothing about music, so this is all greek to me.

This link refers to a different set of tones.

 

http://books.google.ca/books?id=N2_eAgAAQBAJ&pg=PA388&lpg=PA388&dq=atari+touch+me+tones&source=bl&ots=f5Ix8jBMFx&sig=uXu7CNA-SNzpqtRCM3vpWikBGPw&hl=en&sa=X&ei=091mVMX9JcStyATztoKwBg&ved=0CFAQ6AEwBw#v=onepage&q=atari%20touch%20me%20tones&f=false

 

G,C,E,G

I'm assuming the second G is an octave lower

[freewheel]

Either way that is very easy to translate into the proper tones in IntyBASIC. Awesome find, I had no idea it'd be that easy!

[vprette]

thanks for all suggestion, I will work on 3-4 changes.. still do not know how to translate the tones since I understand nothing about music composition

[+DZ-Jay]

You shouldn't have to "translate" the tones. Doesn't IntyBASIC allow you to play musical notes by name?

[freewheel]

You have 2 options on the tones:

 

 

1. Use PLAY and MUSIC, and just have a single-note song for each. This way you can easily state which tone is which.

 

2. Use SOUND. You can figure out the frequency of every note with a quick Google Search. The IntyBASIC manual describes how to convert frequencies to values, to pass to the PSG via SOUND.

[vprette]

new version:

 

- changed colors and added a spot to ease to reconnaise

- no CLS calls

 

I need to fix the sound, I will study better how to use sound tomorrow

simon4_v3.rom

Edited November 15, 2014 by vprette

[+DZ-Jay]

new version:

 

- changed colors and added a spot to ease to reconnaise

- no CLS calls

 

I need to fix the sound, I will study better how to use sound tomorrow

 

I played it, and I have feedback:

• The colours are good, and the spot you added to highlight the tiles is fine. However, I rather it not be black. Can you try with a different colour spot?
• I still see the entire screen flicker for a frame whenever something changes. This includes highlighting the tiles, updating the status message, etc.
• The input response is much improved! I can now press the buttons at a faster pace.
• I still feel that the speed of the tune is too slow. What I mean by this is the time delay between each note is too long.
• Is it me, or does the game seem to always use the same pattern? OK, I see different patterns, but it seems to repeat the same patterns over and over. Most of the time, I get the same one.

Edited November 15, 2014 by DZ-Jay

[vprette]

 

 

I played it, and I have feedback:

• The colours are good, and the spot you added to highlight the tiles is fine. However, I rather it not be black. Can you try with a different colour spot?
• I still see the entire screen flicker for a frame whenever something changes. This includes highlighting the tiles, updating the status message, etc.
• The input response is much improved! I can now press the buttons at a faster pace.
• I still feel that the speed of the tune is too slow. What I mean by this is the time delay between each note is too long.
• Is it me, or does the game seem to always use the same pattern? OK, I see different patterns, but it seems to repeat the same patterns over and over. Most of the time, I get the same one.

 

 

-I did the spot white, but for some reason it appears only over the blue and over the other colors it is not showed... instead the black always work..

- for the flicker I'll check more... I would rather test it in real hardware because I have a pc only

- I will study the tunes tomorrow

- i will add more rand call

[intvnut]

 

-I did the spot white, but for some reason it appears only over the blue and over the other colors it is not showed... instead the black always work..

- for the flicker I'll check more... I would rather test it in real hardware because I have a pc only

- I will study the tunes tomorrow

- i will add more rand call

 

Ok, I definitely see the flicker on real hardware and not in jzIntv. This makes me a little worried that jzIntv's timing is off (or at least a little too forgiving).

[intvnut]

 

Ok, I definitely see the flicker on real hardware and not in jzIntv. This makes me a little worried that jzIntv's timing is off (or at least a little too forgiving).

 

A little more information. The flicker doesn't affect the entire screen, but rather all the "status areas" outside the four squares.

 

I put a watch on one of the BACKTAB areas that holds that information, and it appears that you're overwriting those areas with $0000 (all black) and then rewriting them with actual text/information, repeatedly (basically whenever one of the squares changes color). It seems to be triggered by a SCREEN statement.

Edited November 16, 2014 by intvnut

[freewheel]

 

A little more information. The flicker doesn't affect the entire screen, but rather all the "status areas" outside the four squares.

 

I put a watch on one of the BACKTAB areas that holds that information, and it appears that you're overwriting those areas with $0000 (all black) and then rewriting them with actual text/information, repeatedly (basically whenever one of the squares changes color). It seems to be triggered by a SCREEN statement.

 

Either that or a CLS followed by PRINT with every action. I mentioned this earlier, there's no reason to do it this way. Only update what needs to be updated, when it needs to be updated.

 

SCREEN, if that's the offender, should only be called at the setup phase. It will cause massive flicker (plus other performance problems eventually) if you're re-drawing the entire screen continually. At least that's been my experience with IntyBASIC.

[intvnut]

 

Either that or a CLS followed by PRINT with every action. I mentioned this earlier, there's no reason to do it this way. Only update what needs to be updated, when it needs to be updated.

 

SCREEN, if that's the offender, should only be called at the setup phase. It will cause massive flicker (plus other performance problems eventually) if you're re-drawing the entire screen continually. At least that's been my experience with IntyBASIC.

 

To be clear, I actually disassembled it to see what's going on, and verified with breakpoints in the debugger. It's not a CLS. The function that erases the text is CPYBLK, which is used by SCREEN. Also, the 4 large colored squares don't flicker.

 

I suspect Valter's using SCREEN to draw the various configurations of the 4 colored squares, and in the process that wipes out the other information on the screen. PRINT statements, for all their code-bloatyness, would be a better choice here.

Edited November 16, 2014 by intvnut

[+DZ-Jay]

 

To be clear, I actually disassembled it to see what's going on, and verified with breakpoints in the debugger. It's not a CLS. The function that erases the text is CPYBLK, which is used by SCREEN. Also, the 4 large colored squares don't flicker.

 

I suspect Valter's using SCREEN to draw the various configurations of the 4 colored squares, and in the process that wipes out the other information on the screen. PRINT statements, for all their code-bloatyness, would be a better choice here.

 

Valter had CLS, then said he removed it. So what's left now is probably a SCREEN call on every draw call.

 

 

 

 

Ok, I definitely see the flicker on real hardware and not in jzIntv. This makes me a little worried that jzIntv's timing is off (or at least a little too forgiving).

 

I recall during the development of Christmas Carol, I noticed a slight "flicker" whenever I changed screen modes. This was mostly manifested when the title screen changed to the credits sequence, and only happened in jzIntv. In real hardware, the transition was always smooth, but in jzIntv the screen flickered for a frame or two.

 

Since the SCREEN statement in IntyBASIC sets the screen mode (or re-asserts it, when called again with the same parameters), Valter's flicker could be related to that other problem.

 

Wait, never mind, I just realized that you noticed the opposite in this case: it flickers in hardware but not in the emulator. Still, there's that problem in Christmas Carol, and it happens when I clear the screen.

 

-dZ.

Edited November 16, 2014 by DZ-Jay

[vprette]

hello

 

in fact Joe is right, flikering originates from SCREEN calls: I have fixed that now :-)

also I reworked the RAND calls findind that i forgot to put wait before calling rand in some place, reducing the random generation, now this is fixed also...

 

so I only have left the sound topic:

I still dont understand exaclty what I'm suppose to do..

Nanochess: say that I want to call the note E for the blue color, should I write something like this?

 

play bluenote

....

 

bluenote: DATA 8

Music E

Music s

Music -

 

Music stop

 

Doing that the result is not proper....

Edited November 16, 2014 by vprette

[catsfolly]

hello

 

in fact Joe is right, flikering originates from SCREEN calls: I have fixed that now :-)

also I reworked the RAND calls findind that i forgot to put wait before calling rand in some place, reducing the random generation, now this is fixed also...

 

so I only have left the sound topic:

I still dont understand exaclty what I'm suppose to do..

Nanochess: say that I want to call the note E for the blue color, should I write something like this?

 

play bluenote

....

 

bluenote: DATA 8

Music E

Music s

Music -

 

Music stop

 

Doing that the result is not proper....

I think you are close!

Try something like this:

bluenote:
	DATA 8
	MUSIC E6, -
        MUSIC S, -
	MUSIC STOP

[vprette]

 

I think you are close!

Try something like this:

bluenote:
	DATA 8
	MUSIC E6, -
        MUSIC S, -
	MUSIC STOP

 

not the solution.. this part look so strange to me :-)

I would prefere to reproduce note E by using SOUND lke I use now

[+DZ-Jay]

 

not the solution.. this part look so strange to me :-)

I would prefere to reproduce note E by using SOUND lke I use now

 

Why, what's strange about it?

 

The MUSIC statement is to play musical notes. The SOUND statement is to play sound effects. If you want to use SOUND, you'll have to play with the frequencies and timing to get a proper sound effect that matches the tones you're looking for. With MUSIC, it does this for you, since it plays the note you asked.

 

For MUSIC, the first DATA value is the number of "ticks" for the duration of each note, where 50 ticks equal one second. You've chosen 8 ticks, which is rather short (about 1/6^th of a second). You may want to make it a bit longer.

[freewheel]

I would prefere to reproduce note E by using SOUND lke I use now

 

Then you'll need to figure out the frequency of E (in whatever octave you're looking for), and follow the formula from the IntyBASIC manual:

 

Desired frequency value can be calculated as:

 

value = (3579545 / 32 / frec)

 

Please note this changes for PAL.

 

value = (4000000 / 32 / frec)

[vprette]

 

Why, what's strange about it?

 

The MUSIC statement is to play musical notes. The SOUND statement is to play sound effects. If you want to use SOUND, you'll have to play with the frequencies and timing to get a proper sound effect that matches the tones you're looking for. With MUSIC, it does this for you, since it plays the note you asked.

 

For MUSIC, the first DATA value is the number of "ticks" for the duration of each note, where 50 ticks equal one second. You've chosen 8 ticks, which is rather short (about 1/6^th of a second). You may want to make it a bit longer.

 

well, see what I get with my music statement... this is not a note....

music_e.rom

[+DZ-Jay]

 

well, see what I get with my music statement... this is not a note....

 

LOL! That's kinda cool, but yes, it's not a note. Did you forget the "MUSIC STOP" statement at the end?

[intvnut]

I recall during the development of Christmas Carol, I noticed a slight "flicker" whenever I changed screen modes. This was mostly manifested when the title screen changed to the credits sequence, and only happened in jzIntv. In real hardware, the transition was always smooth, but in jzIntv the screen flickered for a frame or two.

 

...

 

Wait, never mind, I just realized that you noticed the opposite in this case: it flickers in hardware but not in the emulator. Still, there's that problem in Christmas Carol, and it happens when I clear the screen.

 

The issue you saw with jzIntv and Christmas Carol's transitions is an artifact of how I handle screen blanking in jzIntv. If you let the screen blank by not pinging location $20, then jzIntv actually stops most of its rendering pipeline and sends a single blank frame to the display. When the display unblanks, one of the double buffers contains a frame from before the blanking took effect and it gets displayed. The result is a visual stutter. That's unrelated to what Valter sees here.

 

Sorry, was having a little fun with the bold there. It does interrupt the flow of the text. Good natured ribbing. Reminds me of this guy...

 

The SCREEN statement copies data to BACKTAB, and that races with the STIC for fetching cards from the display. jzIntv does try to model this race; however, I think I may have disabled it at some point, because I broke something and couldn't figure out how to fix it. (My graphics renderer also has a dirty-rectangle detector, and it too was broken.) So that's probably why the flicker doesn't appear on jzIntv—at least the build on my machine—and does appear on the real hardware.