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.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.
Super Mario Bros for VIC-20
Moderator: Moderators
Re: Super Mario Bros for VIC-20
Re: Super Mario Bros for VIC-20
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/
Re: Super Mario Bros for VIC-20
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.
[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.
Re: Super Mario Bros for VIC-20
Rush was also released for the VIC http://atariage.com/forums/topic/208887 ... he-vic-20/
Re: Super Mario Bros for VIC-20
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.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.
Re: Super Mario Bros for VIC-20
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.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 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.
- Attachments
-
- MarioDemoNew.zip
- (4.82 KiB) Downloaded 299 times
Re: Super Mario Bros for VIC-20
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.
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.
Re: Super Mario Bros for VIC-20
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 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.
Thanks, the music uses very little memory and is the least of my concerns...I really like your music. I hope it doesn't consume alot of memory.
Re: Super Mario Bros for VIC-20
Ah, bad idea was here. (deleted post)
- Mike
- Herr VC
- Posts: 4849
- Joined: Wed Dec 01, 2004 1:57 pm
- Location: Munich, Germany
- Occupation: electrical engineer
Re: Super Mario Bros for VIC-20
Not quite. The opening/closing waterholes and tar pits are also done with in-line splits of the background colour.beamrider wrote:[...] (Victragic's Pitfall has static screens), [...]
Re: Super Mario Bros for VIC-20
static as in "non-scrolling background"
- Mayhem
- High Bidder
- Posts: 3027
- Joined: Mon May 24, 2004 7:03 am
- Website: http://www.mayhem64.co.uk
- Location: London
Re: Super Mario Bros for VIC-20
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.
Lie with passion and be forever damned...
Re: Super Mario Bros for VIC-20
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.
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.
Re: Super Mario Bros for VIC-20
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.
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.