Denial

eslapion wrote:@Kakemoms
Concerning music...

When I was a kid, I dabbled around the music functionality of the Super Expander and I always set the volume to the max (15). I was rather frustrated that most polyphonic music came out as very noisy.

Then I realized many games used polyphonic music without the level of noise I was experiencing with my own creations but the volume was lower.

Only about 10 years ago I bothered to really investigate this problem with an oscilloscope. I noticed, when playing polyphonic music, the square waves generated by the VIC-I add (in amplitude) to each other and the sound amplification internal to the VIC-20 doesn't account for this effect.

When all 3 voices (normal, non-noise) add to each other then setting the volume to 8 should be considered the maximum. Any higher volume will cause waveform clipping and cause noise.

Well, I'm a completely noob with regard to music on the VIC. The tune above is really nice, but as someone else mentioned, it would only be possible to get such music using double buffering. The "racing the beam" approach of my demo wouldn't have much resources to spare for complicated samples.

have you considered multicolor or petscii on an expanded screen ... here is a great example on the commodore pet https://www.mobygames.com/game/pet/rush ... Id,256166/

that's good for the pet, but I think the Vic is capable of better...

[edit] - btw, from my perspective, the music and smooth scrolling are no longer issues for this game. My current concerns are lack of graphics characters in the pool to use for rendering sprites (only 60 with double buffering and smooth scrolling), lack of colours in multi-color mode to make Mario look good against the background (without colour clash) and the limited pixel pushing power of the Vic's cpu.

Rush was also released for the VIC http://atariage.com/forums/topic/208887 ... he-vic-20/

beamrider wrote:that's good for the pet, but I think the Vic is capable of better...

[edit] - btw, from my perspective, the music and smooth scrolling are no longer issues for this game. My current concerns are lack of graphics characters in the pool to use for rendering sprites (only 60 with double buffering and smooth scrolling), lack of colours in multi-color mode to make Mario look good against the background (without colour clash) and the limited pixel pushing power of the Vic's cpu.

Enemies that only move on the ground would only require 3 double height character bytes (or 4 while falling), and there are not many enemies present at the same time. You could also make the coin effects simpler (=1 character byte) since it doesn't affect the gameplay.

Enemies that only move on the ground would only require 3 double height character bytes (or 4 while falling), and there are not many enemies present at the same time. You could also make the coin effects simpler (=1 character byte) since it doesn't affect the gameplay.

I got as far as making the status line look okay (see attached), combining raster splits and smooth scrolling was/is a tall order. I am still working (slowly - I got distracted to other hobbies 3d printing/learning electronics) on my sprite engine and if Mario proves to be a step too far I have a simpler game in mind with 4-way smooth scrolling. Speaking with Misfit (of Cheese and Onion fame) , he tells me that getting sprites to work over a smooth scrolling background is a real pain on the Vic. You have to redraw every sprite on every scrolled frame because, 1) otherwise they move with the background, 2)you have to swap over to the shifted character bank and they become garbage.

I didn't use double height characters as I wouldn't have enough memory to flip between different sets to achieve my scrolling effect if I did.

The approach I have gone for uses a lot of characters to represent the various combinations of graphics shifted by a multi-color pixel. This has the advantage of not taking any CPU for the smooth scrolling and being flicker free (the banks are switched during the VBI) but at the expense of available characters for graphics and sprites.

btw, the demo only really looks good on a real Vic where you don't see the scrolling effect on the right or any tearing effects that you get in VICE.

Looks really nice, and with the music its a winner. I hope you manage to squeeze in mario and some enemies.

Yea, raster split with scrolling is problematic due to the cycle intensive behaviour of the scrolling. Rotating the background "earth" tiles is not so bad. One "only" rotates the characters on screen by 2 pixels. Since they will "move" into the next character, a 2x2 tile needs a 1x2 "end" tile and 1x2 "start" tile to account for that. But then comes the bushes and other stuff that are not repeated and needs double the amount of characters (just for the scrolling).

Using 4 different sets of characters is a good idea though. It saves cpu cycles and makes it easier to get scrolling. I like it.

For mario one needs a 3x3 "sprite", meaning 9 characters. You always need to copy the background into these, then mask out mario (shifted the correct number of bits), then add mario (shifted the correct number of bits again). "Shifting" (using ROL/ROR/ASL/LSR) is the most cycle intensive, so its a good idea to pre-shift at least one set (e.g. 4 pixels for example). But these can be anywere in memory, so it should not be a problem.

For mario I have a 2x2 character figure. It has 4 different stages to make him run (=16 characters), two directions (=32 characters*8=256bytes). Since pre-shifting requires a 3x2 character "copy" for storage this becomes 48*8=384 bytes per preshifted set (of mario). Since its multicolor, one has to shift two pixels at a time, so one get three preshifted sets for a total of 256+384*4=1408 bytes.

So I think this becomes a balance between preshifting some of the things and using on-the-fly shifting of other sprites to get everything working 1) within the allowed time (=1 frame) and 2) within the available memory.

I really like your music. I hope it doesn't consume alot of memory.

Thanks. Maybe someday, as you likely know there's a huge world of difference between a simple demo and full blown game.

I saw your rotating approach, I had thought of it before but feared it would get too complicated when you moved away from the predictable shapes and regular edges etc. I liked you raster effects for overcoming the Vic's colour limits too, but I also thought it would be too difficult in a real-world scrolling game scenario (Vic Tragics Pitfall has static screens), but happy to be proved wrong

Actually I only use 2 characters sets for the four possible positions of a multi-color scroll before doing a full character scroll

- (0) Normal char set, $9000 = N
- (2) 2px Shifted char set, $9000 = N
- (4) Normal char set, $9000 = N+1 (4 pixel horizontal offset)
- (6) 2px Shifted char set, $9000 = N+1 (4 pixel horizontal offset)

but allowing for all unique character pairs for shifting leaves 60 available for the stage-1 Mario background (haven't tried the others).

Actually Mario could need up 24 characters for free movement in all directions if you honour the original 4x4 sizing (see above the tiles are 2x2). Yeah, I'm less worried about the storage for pre-shifted animated frames as they can be in external RAM. In Popeye I did 3x2 sprites and that was pushing it.

I really like your music. I hope it doesn't consume alot of memory.

Thanks, the music uses very little memory and is the least of my concerns...

Ah, bad idea was here. (deleted post)

beamrider wrote:[...] (Victragic's Pitfall has static screens), [...]

Not quite. The opening/closing waterholes and tar pits are also done with in-line splits of the background colour.

static as in "non-scrolling background"

Yeah even better, a lot of the original code is in there as the NES uses the 6502, so you can do pretty much all the tricks as per the NES.

True.

I was more alluding to the fact that it got taken down though, as a dampener on anyone attempting a Vic-20 port.

Severn years busting a gut only to be smacked down after releasing it.

Still up on lemon when I looked and got it.

Will have to load it up on the sd2iec

To be fair so long as Nintendo do it after it's finished and released it just leads to more people checking it out.