Another project which may end up on the Behr-Bonz hardware ? It can provide up to 2048k of RAM or ROM.pixel wrote:Suggestion:
Grab whichever memory expander provides at least 512K RAM and go with pre-calculated chars for the scrolling and compiled sprites (generated machine code which plots immediate values).
Super Mario Bros for VIC-20
Moderator: Moderators
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Super Mario Bros for VIC-20
Be normal.
Re: Super Mario Bros for VIC-20
Someone: So you have "retro" consoles.
Me: They are computers not consoles, yes.
Someone: Wow how many Mario games do you have.
Me: What is up with MARIO AND OLD HARDWARE!!
Someone: Oh, then do you play Pac-man
Me:
Every time I talk about old computers I get this conversation.
Me: They are computers not consoles, yes.
Someone: Wow how many Mario games do you have.
Me: What is up with MARIO AND OLD HARDWARE!!
Someone: Oh, then do you play Pac-man
Me:
Every time I talk about old computers I get this conversation.
-Floopy
Re: Super Mario Bros for VIC-20
Don't think Nintendo would take too kindly to anyone selling a Super Mario clone - even free websites have been the subject of take-down action.eslapion wrote:Another project which may end up on the Behr-Bonz hardware ? It can provide up to 2048k of RAM or ROM.
Re: Super Mario Bros for VIC-20
A bit of time spare, so I thought I'd put it (your pic) on the real thing and add some music....
- Attachments
-
- MarioIWish.zip
- (4.65 KiB) Downloaded 233 times
- pixel
- Vic 20 Scientist
- Posts: 1354
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Super Mario Bros for VIC-20
Nice! Thank you!beamrider wrote:A bit of time spare, so I thought I'd put it (your pic) on the real thing and add some music....
According to https://www.spriters-resource.com/nes/supermariobros/ there'd be around 110 16x16px sprites (just one colour version and direction each – the rest can be done in software). Without sprite mask for monochrome mode compiling them would require ~160K. Why not on the Behr-Bonz? It could support every suitable memory expander.
Here's the original SMB source code with comments: https://gist.github.com/1wErt3r/4048722. Music and level data is in there.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
Re: Super Mario Bros for VIC-20
To put itt on cartridge would mean selling it I assume and therefore you risk legal action from Nintendo.
- pixel
- Vic 20 Scientist
- Posts: 1354
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Super Mario Bros for VIC-20
I'd just want the RAM and fill it on startup.beamrider wrote:To put itt on cartridge would mean selling it I assume and therefore you risk legal action from Nintendo.
We should collect sprite and tile conversions here. Perhaps the game will spring up like a mushroom.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Super Mario Bros for VIC-20
If it's widely and openly announced, maybe.beamrider wrote:To put itt on cartridge would mean selling it I assume and therefore you risk legal action from Nintendo.
The Megacart contains a lot of Nintendo/Atarisoft games as well as many other copyrighted games and there never was any problems because it stayed small scale. The same with the Berhr-Bonz
Also, look at this: http://www.lemon64.com/forum/viewtopic.php?t=63383
Be normal.
Re: Super Mario Bros for VIC-20
You forget the ability to mix. Multicolor can be changed into monochrome and back on the fly. Thus, some parts may have higher color count or more detail. Its complicated, but its not impossible.pixel wrote: It's been raining cats and dogs, you know?... So here come a couple of considerations along 1 full charset of 256 chars and 2 screens.
Challenge 1: Colours
However you turn and wiggle it: there would be no background gfx like the green bush unless you want it to become (mostly) red where a sprite is. Full gfx detail could be done in monochrome mode but that's very expensive for the sprites.
With selected areas covered as a bitmap, you can have overlaying graphics.pixel wrote: Challenge 2: Sprites
Super Mario on the NES pumps out up to 64 8x8px sprites at once. They're lined up to make the 8x16/16x8/16x16/32x16px objects. Having 16 8x8px sprites around is already kind of over the edge on the VIC. A 16x16px sprite can also eat up 9 chars.
If you move the screen, just move the sprite and it will seems to stay at the same position. As long as the scrolling is smooth, I don't see the need for concealing the edges of the screen. Anyway, you may be better off with a very wide screen to conceal it on most TV'spixel wrote: Challenge 2: Scrolling
Hardware scrolling would mess up sprite positioning and rob 44 chars to conceal it at the sides. If no more than 32 different character pairs (left/right) appear at the same time perhaps that could be managed with the right kind of bookkeeping. You've got to be able to update all scrolling chars before a retrace. Even worse: scrolling varies in speed.
Re: Super Mario Bros for VIC-20
but even with the 4 colours of Multi-color mode the green hill would have to be changed to red or some kind of dithered pattern using red/cyan/black/white to prevent colour clash when traversed by a sprite..Kakemoms wrote: You forget the ability to mix. Multicolor can be changed into monochrome and back on the fly. Thus, some parts may have higher color count or more detail. Its complicated, but its not impossible.
Re: Super Mario Bros for VIC-20
Lets look at this Mario:
Impossible to get into the VIC since you have 8 different colors in an area that is 16x16 pixels? Well, a raster spilt is a routine which changes a color on a specific position of the screen. It can be made to be cycle exact, but the VIC outputs 4 pixels in one 6502 cycle, so after a STA $ZP (which takes 3 cycles), only one color change is possible over a 16 pixel line.
The Vic-20 can only have 4 colors within a 1-byte area without doing some tricks. But the byte color can be different in the next byte, so total of 5 colors on a sprite line? Well, with a raster split one can increase that to 6 colors. And each line can have a new set of 6 different colors, so the above sprite is quite possible on a Vic-20.
With respect to changing background color, you can either limit each sprite line to 5 different colors, or you can choose wisely on were to use 6 colors.
Or pixelated it looks like this:
- 0000000000000000
0000022222001110
0000222222222110
0000666117102220
0006161117111220
0006166111711120
0006611117777200
0000011111112200
0022223222322004
1122222322230044
1112222333353344
1100323353333344
0044433333333344
0444333333000000
0440000000000000
0000000000000000
Impossible to get into the VIC since you have 8 different colors in an area that is 16x16 pixels? Well, a raster spilt is a routine which changes a color on a specific position of the screen. It can be made to be cycle exact, but the VIC outputs 4 pixels in one 6502 cycle, so after a STA $ZP (which takes 3 cycles), only one color change is possible over a 16 pixel line.
The Vic-20 can only have 4 colors within a 1-byte area without doing some tricks. But the byte color can be different in the next byte, so total of 5 colors on a sprite line? Well, with a raster split one can increase that to 6 colors. And each line can have a new set of 6 different colors, so the above sprite is quite possible on a Vic-20.
With respect to changing background color, you can either limit each sprite line to 5 different colors, or you can choose wisely on were to use 6 colors.
Re: Super Mario Bros for VIC-20
Thats a lot to manage tho whilst running an implementation of SMB.
Even just using inline splits to draw the green hill (and blocks etc) would be a big challenge in conjunction with smooth scrolling and sprites.
Even just using inline splits to draw the green hill (and blocks etc) would be a big challenge in conjunction with smooth scrolling and sprites.
- eslapion
- ultimate expander
- Posts: 5458
- Joined: Fri Jun 23, 2006 7:50 pm
- Location: Canada
- Occupation: 8bit addict
Re: Super Mario Bros for VIC-20
@Kakemoms
Usually, on most men, you expect the moustache and the hair to have the same color so you could save one there.
The yellow suspender buttons could go away and the feet/shoes could also be the same color as the hair/moustache.
BTW, I just saw a news article about the original SMB being completed in 5 minutes during a Summer Games Done Quick event.
Usually, on most men, you expect the moustache and the hair to have the same color so you could save one there.
The yellow suspender buttons could go away and the feet/shoes could also be the same color as the hair/moustache.
BTW, I just saw a news article about the original SMB being completed in 5 minutes during a Summer Games Done Quick event.
Be normal.
- pixel
- Vic 20 Scientist
- Posts: 1354
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Super Mario Bros for VIC-20
My idea about monochrome was to have the background graphics like the bush. But that would include the extra overhead of masking out the background before the sprite is being plotted. That's where I got this insane number of kilobytes for compiled sprites the first time. Personally, I'd prefer colour.
"Just moving the sprites" with hardware scrolling is barely possible as the charset wouldn't be buffered. There's only space for a single charset of reasonable size. Not enough CPU to do move sprites in time. The new frames have to be drawn over old ones, then the remains of the old frame have to be removed. Pretty much like what happened in "Pulse": As far as I could picture it.
In the end the devil's in the detail. Arukanoido is giving me surprises enough at this time. Porting SMB to the C64 wouldn't be for the faint hearted already.
"Just moving the sprites" with hardware scrolling is barely possible as the charset wouldn't be buffered. There's only space for a single charset of reasonable size. Not enough CPU to do move sprites in time. The new frames have to be drawn over old ones, then the remains of the old frame have to be removed. Pretty much like what happened in "Pulse": As far as I could picture it.
In the end the devil's in the detail. Arukanoido is giving me surprises enough at this time. Porting SMB to the C64 wouldn't be for the faint hearted already.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose
- pixel
- Vic 20 Scientist
- Posts: 1354
- Joined: Fri Feb 28, 2014 3:56 am
- Website: http://hugbox.org/
- Location: Berlin, Germany
- Occupation: Pan–galactic shaman
Re: Super Mario Bros for VIC-20
Oh, btw, that Mario example above doesn't match the VICs multicolour resolution.
A man without talent or ambition is most easily pleased. Others set his path and he is content.
https://github.com/SvenMichaelKlose
https://github.com/SvenMichaelKlose