Jump to content

Photo

Thoughts about method for Super Mario Bros. on ColecoVision

mario colecovision idea

20 replies to this topic

#1 Enig OFFLINE  

Enig

    Star Raider

  • 58 posts
  • Location:Space, Arkansas

Posted Tue Apr 3, 2012 9:54 PM

I know this has been heard before on this board, but this time, I've gotten some ideas that could make SMB on CV work, and pretty nicely.

Note: the sprites attached aren't exact or supposed to be how a stock CV would output, they're just close approximations.

smb_coleco_mockups.PNG

If you're wondering why they're horizontal, that is one of my ideas- since the CV is choppy when it comes to horizontal scrolling, since the vertical is smoother, simply set the game up so that you merely have to rotate whatever you're playing on (hopefully a small TV- I can't see rotating a 52' flat-screen just for this) and it will not only look normal, but the scrolling will be smoother.

Secondly, since it uses 8x8 sprites, to overcome the palette limitations, some sprites can use this to their advantage. Take the mushroom and Mario, for example- they both switch palettes halfway down, but use either common coloring or a fitting dither in order to combine. Others, like the coin, simply spread out of two 8x8 sprites into four in order to use two palette sets (orange+white, orange+black) in order to keep color quality.

So, with that being said, would this help bring a port of SMB to Coleco closer to reality?

#2 tokumaru OFFLINE  

tokumaru

    Chopper Commander

  • 209 posts
  • Location:Rio de Janeiro - Brazil

Posted Wed Apr 4, 2012 9:19 PM

The sprites look good, but I think that using 8x8 sprites is a terrible idea. Don't forget that there's a limit of 4 sprites per scanline, which will make it impossible to draw even a single large Mario/Luigi. Being 32 pixels tall, even if they used a single color they'd already use all 4 sprites. Since you want to layer sprites in order to have more colorful objects, and considering that objects will often share the same scanlines (for example, Mario often walks below coins, and since your screen is rotated that would mean they'd be sharing scanlines), 4 8x8 sprites are not nearly enough.

If you use 16x16 sprites, the characters will be able to look like you imagined, but there will still be a lot of flickering when they show up on the same scanlines. Using 16x16 sprites with lots of empty areas may seem like a waste of memory, but it really is the only way to get a significant number of objects on the screen with the ColecoVision's video chip.

Edited by tokumaru, Wed Apr 4, 2012 9:22 PM.


#3 Bill Loguidice OFFLINE  

Bill Loguidice

    River Patroller

  • 2,089 posts
  • Armchair Arcade Managing Director
  • Location:Central New Jersey, USA

Posted Thu Apr 5, 2012 1:48 PM

Personally, I'd consider the rotated the display idea a non-starter since I think few people would be able to accommodate that. I think the idea of bringing SMB to the ColecoVision is a good one in concept, but I'd suggest playing to the ColecoVision's strengths and make an inspired-by variation rather than a poor clone. I don't see the point otherwise.

#4 roland p OFFLINE  

roland p

    Stargunner

  • 1,850 posts
  • $23
  • Location:The Netherlands

Posted Thu Apr 5, 2012 2:12 PM

Is the tms9918 even capable of vertical smooth scrolling?

This level should be possible to scroll smoothly on the colecovision (by changing characters):
http://www.randomrac.../mariones-1.gif

By the way, here is an msx version of super mario (with some horrible jumping :D):
http://www.youtube.com/watch?v=fHbZdczvl7Y

Edited by roland p, Thu Apr 5, 2012 2:13 PM.


#5 o.pwuaioc OFFLINE  

o.pwuaioc

    Dragonstomper

  • 725 posts
  • It's pronounced "ho Rhomaios"
  • Location:NYC

Posted Thu Apr 5, 2012 2:29 PM

^ What, no warp zone?!

Also, at 5:00, Mario falls into lava but doesn't die.

Edited by ὁ Ῥωμαῖος Νέος, Thu Apr 5, 2012 2:33 PM.


#6 Enig OFFLINE  

Enig

    Star Raider

  • Topic Starter
  • 58 posts
  • Location:Space, Arkansas

Posted Thu Apr 5, 2012 4:19 PM

SORRY NOTHING


Oh god my sides

#7 tokumaru OFFLINE  

tokumaru

    Chopper Commander

  • 209 posts
  • Location:Rio de Janeiro - Brazil

Posted Thu Apr 5, 2012 10:37 PM

Is the tms9918 even capable of vertical smooth scrolling?

No, but you can shift all patterns up or down and it will look just like smooth scrolling. It's not very practical though, it's a lot of data to move around.

Some games simulate smooth scrolling on the TMS9918 without requiring the screen to be rotated, such as Malaika - Prehistoric Quest on the MSX. You just have to design the tiles carefully, so that they can be shifted into each other without causing color clashes.

I once considered making an Atari 2600 side scroller that required the TV/monitor to be rotated, but that's a very extreme measure, so I gave it up.

Edited by tokumaru, Thu Apr 5, 2012 10:39 PM.


#8 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,570 posts
  • CD C9 01
  • Location:Austin, TX

Posted Fri Apr 6, 2012 7:11 AM

Don't forget that there's a limit of 4 sprites per scanline, which will make it impossible to draw even a single large Mario/Luigi.


Also, the sprites support only ONE COLOR. (1 bit per pixel, transparent background), so you have to stack two together for a second color.

Just one of those sample sprites would use up 2 of your 4 sprites per scanline limit even if you didn't make them rotated.

I highly recommend doing mockup screens on a real CV or emulator before going any further.

Is the tms9918 even capable of vertical smooth scrolling?


Nope. Though I will admit that I was impressed when I did my RPG experiment that 8-pixel scrolling with 16-pixel tiles didn't look bad at all.

Edited by Bruce Tomlin, Fri Apr 6, 2012 7:21 AM.


#9 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,570 posts
  • CD C9 01
  • Location:Austin, TX

Posted Fri Apr 6, 2012 7:39 AM

By the way, here is an msx version of super mario (with some horrible jumping :D):


Wow. I wonder how much of that is being done with "name table sprites". In other words, putting them into the background graphics. It's very well hidden. The static picture that YT shows before you start the video shows that Mario probably is done as a sprite, which means that all the turtles would be background graphics sprites. It does work a lot better with solid backgrounds, that's for sure.

#10 roland p OFFLINE  

roland p

    Stargunner

  • 1,850 posts
  • $23
  • Location:The Netherlands

Posted Fri Apr 6, 2012 8:36 AM


By the way, here is an msx version of super mario (with some horrible jumping :D):


Wow. I wonder how much of that is being done with "name table sprites". In other words, putting them into the background graphics. It's very well hidden. The static picture that YT shows before you start the video shows that Mario probably is done as a sprite, which means that all the turtles would be background graphics sprites. It does work a lot better with solid backgrounds, that's for sure.


To me, it looks like enemies are sprites, at 0:08, 5:31, 5:55 there is some flickering noticable.

#11 Bill Loguidice OFFLINE  

Bill Loguidice

    River Patroller

  • 2,089 posts
  • Armchair Arcade Managing Director
  • Location:Central New Jersey, USA

Posted Fri Apr 6, 2012 9:05 AM

I'd look to the excellent homebrew Ghostblaster for a way to do SMB-style scrolling on the ColecoVision. Again, I'd see no point in recreating a game that's already perfect on the original, but to create something similar would be quite cool...

#12 Pixelboy ONLINE  

Pixelboy

    Quadrunner

  • 5,866 posts
  • Location:Montreal, Canada

Posted Fri Apr 6, 2012 10:00 AM

I'd look to the excellent homebrew Ghostblaster for a way to do SMB-style scrolling on the ColecoVision. Again, I'd see no point in recreating a game that's already perfect on the original, but to create something similar would be quite cool...


I have to disagree with you there, Bill. Ghostblaster is indeed an excellent homebrew, but the way scrolling is implemented in that game is exactly the way it should NOT be implemented in a CV version of Super Mario Bros.

From a homebrewer's perpective, doing SMB on the CV is an interesting challenge because the CV doesn't offer hardware scrolling like the NES does. So the whole point of doing SMB on the CV is to reproduce the smooth scrolling of the original game, with fully destructible environments (i.e. where bricks can be removed or modified on the fly). Anything less would be seen as a wasted opportunity, given the graphic capabilities of the CV.

We could discuss the technical aspects of a theoretical scrolling system (it has been discussed before, and it's pretty much been proven to be possible) and also the sprite flicker management, but that's not the bottom line here. The OP asked if his intervention would "help in bringing a port of SMB to Coleco closer to reality".

The quick answer is no, but this has nothing to do with the OP, the reasons are purely logistical: A smooth-scrolling engine would probably have to be coded in Z80 assembly to reach maximum optimization in execution speed. The problem here is that once you've got the engine coded and working for a single game level, add all the sprite characters and other basic characteristics of SMB and you've already reached the 32K ROM limit. SMB on NES is roughly 40K, but that's because the NES offers hardware scrolling which simplifies things on several levels. Doing the same thing on the CV would be far more costly in terms of ROM space.

There are solutions available to break the 32K ROM limit, like Opcode's MegaCart, but those who have the expertise to use these solutions are few, and practically none of them are interested in doing SMB on the CV.

For those reasons, I'd say the chances of ever seing a version of Super Mario Bros on the ColecoVision are next to nil, sadly. :(

Edited by Pixelboy, Fri Apr 6, 2012 10:01 AM.


#13 Bill Loguidice OFFLINE  

Bill Loguidice

    River Patroller

  • 2,089 posts
  • Armchair Arcade Managing Director
  • Location:Central New Jersey, USA

Posted Fri Apr 6, 2012 10:07 AM

Fair enough, Pixelboy, but I still don't see why we NEED Super Mario Bros. on the ColecoVision. I understand the technical challenge, but if that challenge is even mostly met, I think it'd be far more valuable to create a variant than a partially-there clone. As you say, even having that type of engine in place would be huge, as it could be re-used and re-implemented in a variety of ways.

Honestly, that MSX version of SMB was pretty pathetic... One of the key hooks of the original SMB was the precision jumping and that MSX demo showcased what can only be described as the complete opposite...

#14 Pixelboy ONLINE  

Pixelboy

    Quadrunner

  • 5,866 posts
  • Location:Montreal, Canada

Posted Fri Apr 6, 2012 10:21 AM

Fair enough, Pixelboy, but I still don't see why we NEED Super Mario Bros. on the ColecoVision.


Which is one more reason why SMB on CV is unlikely to ever happen. Many homebrewers out there share your opinion. :)

I understand the technical challenge, but if that challenge is even mostly met, I think it'd be far more valuable to create a variant than a partially-there clone. As you say, even having that type of engine in place would be huge, as it could be re-used and re-implemented in a variety of ways.


But then you'd have many CV fans saying "gosh, if you've got the engine working, why not give us SMB?" It's a catch-22 situation, where you'd have a portion of the fans unsatisfied no matter what the homebrewer would do! :D

Honestly, that MSX version of SMB was pretty pathetic... One of the key hooks of the original SMB was the precision jumping and that MSX demo showcased what can only be described as the complete opposite...


I'd say they did what they could with what they had. They just made the wrong design choices, when the time came to cut a few corners to make the game fit both in RAM, and on a cart/disc.

#15 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Dragonstomper

  • 938 posts

Posted Sat Apr 7, 2012 11:33 AM

Well... since the MSX computers are close to the Colecovision in architecture, how about porting the MSX version to the Colecovision and just improving it a bit (mostly the game physics and logic, but not the graphics and scrolling)?

#16 Enig OFFLINE  

Enig

    Star Raider

  • Topic Starter
  • 58 posts
  • Location:Space, Arkansas

Posted Sat Apr 7, 2012 12:15 PM

Fair enough, Pixelboy, but I still don't see why we NEED Super Mario Bros. on the ColecoVision. I understand the technical challenge, but if that challenge is even mostly met, I think it'd be far more valuable to create a variant than a partially-there clone.

Honestly, that MSX version of SMB was pretty pathetic... One of the key hooks of the original SMB was the precision jumping and that MSX demo showcased what can only be described as the complete opposite...


1) Wow, that's rather shortsighted and rude. That's like asking why we need so many ports of Tetris or Pac-Man for anything. That, and a variant isn't always guranteed to be accepted by the public. Just look at all the mascot platformers plaguing the Genesis and SNES because of Mario and Sonic, for example- most are mediocre at best, but there is still a large portion of badness there.

2) That wasn't a demo, that was more likely a pirate clone that's been passed around over the decades. If it were a fan's own project, it'd be more likely to not be as floaty, along with not having "SORRY NOTHING" at the end of a castle.

Also, I've also had thoughts about the possibility of a Battle City port/homebrew, seeing as the technical level seems to be lower (2 sprites- tank and overlay shadowing-, and 3 sprites for the shield frames), but still might be tough to lower flickering at times.
bcity_colecomockups.PNG

#17 Tursi OFFLINE  

Tursi

    River Patroller

  • 2,524 posts
  • Location:BUR

Posted Sat Apr 7, 2012 12:22 PM

I'd say they did what they could with what they had. They just made the wrong design choices, when the time came to cut a few corners to make the game fit both in RAM, and on a cart/disc.


I'd argue that good jumping takes no more ROM space than bad jumping, it's just that few programmers really understand how to do it. It's not complicated, it just seems to elude people. (That said, that MSX SMB demo looks fantastic graphically!)

To do a jump that "feels" right, you have to implement gravity. To implement gravity, you need a variable to track your vertical speed. Most games with a jump already have something that indicates going "up" or going "down".... often this is just used to add a fixed offset to the vertical position. There's also often a counter to track how long to jump up for. This creates a "floating" feel in many cases, and an abrupt direction change at the top of the jump. Something like this:

  if direction is up
    move player up one pixel
    if top of jump reached, change direction to down
  else (direction is down)
    move player down one pixel
    if landed on ground, end jump
  end if

In the real world, gravity is a downwards force that causes acceleration on all objects. By saving a vertical speed indicator rather than a direction indicator, you just apply gravity to it each frame. You start a jump by setting it to a negative (upwards) velocity, and that velocity will determine how high you jump. Then, you per frame update is just:

  add velocity to player Y position
  add gravity to velocity (gravity can be '1' to keep it simple, usually looks fine)
  if player has landed on ground, end jump

It really is that simple to create a jump that looks and feels like it "has weight".



#18 Bill Loguidice OFFLINE  

Bill Loguidice

    River Patroller

  • 2,089 posts
  • Armchair Arcade Managing Director
  • Location:Central New Jersey, USA

Posted Sat Apr 7, 2012 12:30 PM


Fair enough, Pixelboy, but I still don't see why we NEED Super Mario Bros. on the ColecoVision. I understand the technical challenge, but if that challenge is even mostly met, I think it'd be far more valuable to create a variant than a partially-there clone.

Honestly, that MSX version of SMB was pretty pathetic... One of the key hooks of the original SMB was the precision jumping and that MSX demo showcased what can only be described as the complete opposite...


1) Wow, that's rather shortsighted and rude. That's like asking why we need so many ports of Tetris or Pac-Man for anything. That, and a variant isn't always guranteed to be accepted by the public. Just look at all the mascot platformers plaguing the Genesis and SNES because of Mario and Sonic, for example- most are mediocre at best, but there is still a large portion of badness there.

2) That wasn't a demo, that was more likely a pirate clone that's been passed around over the decades. If it were a fan's own project, it'd be more likely to not be as floaty, along with not having "SORRY NOTHING" at the end of a castle.

Also, I've also had thoughts about the possibility of a Battle City port/homebrew, seeing as the technical level seems to be lower (2 sprites- tank and overlay shadowing-, and 3 sprites for the shield frames), but still might be tough to lower flickering at times.
bcity_colecomockups.PNG


Shortsighted and rude? I think you missed my point, there. I'm acknowledging the accomplishment, but again, don't see the point of recreating something that's universally available - and better - elsewhere. The ColecoVision is just not designed to recreate SMB properly, and even if it was, what's the point? The buying Coleco community - of which I'm a part - would just as readily - if not moreso - support a tuned variant than a "best effort" clone just to have it. I know I've slowed my support of similar products on other platforms simply because I'm tiring of rebuying the same games over and over again. The novelty of having "missing games" on classic platforms is starting to wear off a bit. The point is, there are talented people out there putting all this effort into programming, why not put just a little more effort into something a little original? It's not THAT much more work.

#19 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,570 posts
  • CD C9 01
  • Location:Austin, TX

Posted Sat Apr 7, 2012 1:36 PM

One other thing... those rotated sprites won't work at all. The color mapping for background tiles is two colors per horizontal row. (And one color plus transparent for sprites, as I mentioned before.)

Also, the background color in them would count as a third color, so you couldn't even do them unrotated as background graphics.

Seriously, the TMS9918 has some severe color limitations with sprites. (The palette sucks too. Commodore tweaked the C64 palette to be actually useful. TI didn't.) The CV is not in the same generation as the NES. Unlike generation changes these days, this one isn't in RAM or CPU speed, but in colors available. (and more address pins on the cartridge to allow external RAM and bank switching)

It is possible to work around the limitations (see MSX Dragon Quest II as an example), but you really have to pay attention to what you're doing. And you have to make actual screen mockups on an actual 9918 or emulator before you move on to the next step.

#20 Kurt_Woloch OFFLINE  

Kurt_Woloch

    Dragonstomper

  • 938 posts

Posted Sun Apr 8, 2012 1:00 PM

Unlike generation changes these days, this one isn't in RAM or CPU speed, but in colors available. (and more address pins on the cartridge to allow external RAM and bank switching)


I don't know if I would call the adress pins a generation change... it's just a different architecture. On the Colecovision, the cartridge ROM is only visible for the CPU which has to feed all the data to the VDP. All TMS9918 systems work like this. On the NES, there's two address spaces as well, but the video chip has its own ROM chips on the cartridge, hence there are two address and two data busses as far as I understand it... which has the advantage that both chips can access their respective ROM's simultaneously, but adds complexity to the cartridge design and bus. Another type of architecture would be memory-mapped like on the C-64 where both the CPU and video chip access the same shared memory, including the cartridge ROM. As far as I know, the NES and Super NES were the only systems having that double-access. Don't know if that was carried on to the N64 or further... all other cartridge based systems I know have only a single address space on the cartridge.

#21 Bruce Tomlin OFFLINE  

Bruce Tomlin

    River Patroller

  • 3,570 posts
  • CD C9 01
  • Location:Austin, TX

Posted Wed Apr 11, 2012 6:56 AM

Unlike generation changes these days, this one isn't in RAM or CPU speed, but in colors available. (and more address pins on the cartridge to allow external RAM and bank switching)


I don't know if I would call the adress pins a generation change...

Sega Master System was part of the NES generation. And so was the 7800. Both had the necessary pins (in particular a R/W line) to make bank switching and cartridge RAM easy, and many games used it.

The 2600 bank switching was quite a hack, but 4K just wasn't enough space for a decent game, so it was kind of forced. The 5200 had one bankswitched game back in the day, and the CV none. I don't think the Intellivision had any either. Aside from the 2600, bank switching basically didn't happen until the 7800/SMS/NES generation.

The video chip bus on the cartridge slot was specifically an NES anomaly, but it also had R/W support.





Also tagged with one or more of these keywords: mario, colecovision, idea

0 user(s) are browsing this forum

0 members, 0 guests, 0 anonymous users