Quote:
Originally Posted by gamevet
Track and Field 2 looks more like a 16-bit game:
http://youtu.be/ZxA9ORtEhTY
Quote:
Originally Posted by gamevet
Track and Field 2 looks more like a 16-bit game:
http://youtu.be/ZxA9ORtEhTY
But they at least look kinda like people. I didn't even realize they were people in the coleco version (I watched it first). The characters/athletes have more detail on the NES one, the track objects have more colors/detail (like the barricades to jump over), and there's actually a ribbon to break at the end on the NES version. Not to mention other areas where the NES has more color/detail. I mean if it's a prototype.. then his statement makes even less sense (it's missing stuff/levels). How exactly is the coleco version superior, or other coleco games?Quote:
Originally Posted by gamevet
Well if you look at the start of this thread, you can see I created it 6 months ago from today. I've been playing ColecoVision this whole time, which isn't a whole lot of time but enough to get an idea. And of course I've been playing NES since I was barely able to walk.Quote:
Originally Posted by turboxray
What are the other games that make me think the ColecoVision can handle early NES games? Theres Antarctic Adventures, Gyruss, Cosmic Advengers, Pop Eye, Cabbage Patch Kids.
It seems it was pretty easy for me to confuse you guys. I'm actually playing Track and Field 1, but all the YouTube videos are crappy for it. This should've been mentioned.Quote:
Originally Posted by Black_Tiger
Also I just found out Cosmic Avengers and Cabbage Patch Kids weren't available on NES, but they still look like early NES games.
16-bit is a bit of a stretch, but it is certainly better than that prototype for the Colecovision.Quote:
Originally Posted by Black_Tiger
I don't know, but Track N Field 2 came out on the NES in 1988. It's most definitely using a much larger cart ROM to fit all of those levels in. I will say, however, that the original Track N Field on the NES wasn't massively better, and this prototype looks to be mislabeled. I believe that prototype is actually the 1st Track N Field.Quote:
Originally Posted by turboxray
https://www.youtube.com/watch?v=tIjDpOFensY&feature=youtu.be
I was just gonna say, I did post the right Track and Field but its got the wrong name.Quote:
Originally Posted by gamevet
Go to 0:20:
https://www.youtube.com/watch?v=loMp2V8aXZk
Go to 2:34:
https://www.youtube.com/watch?v=gjG7lVZYxlc
NES version seems to have better sound, better parallax scrolling and indeed a ribbon at the end. The ColecoVision version has much better character animation and scoreboard.
It's the MSX version of Track and Field. The NES version combines Hypersports with Track and field, and that is where the skeet shoot level comes from. The MSX/Colecovision version has the timer bar above player 2, which is not present in the NES version. Yeah, the NES version clearly has better sound.
https://www.youtube.com/watch?v=AUh2EeLIv4I&feature=youtu.be
Yeah, that Colecovision version seems to be definitely a port of the first game.
Antartic Adventure was originally a MSX1 game, so ColecoVision should have no trouble with its graphics (literally same video chip). Also I'm still upset about Penguin Adventure not having been ported to the NES.Quote:
Originally Posted by Yharnamresident
That video wasn't too long to watch. Pretty interesting.
So it did get a 2nd gen port, its pretty amazing what they could do with the aging 2600:
https://www.youtube.com/watch?v=jcx71Vr0378
Ok this also explains the ColecoVision version of Track and Field being from the MSX.Quote:
Originally Posted by Sik
Track N' Field is almost a custom fit for the Colecovision hardware as it has minimal sprite requirements and the graphics are so simple that large sections of the background do not need to be scrolled, the few elements that do scroll are repeated for every event, meaning that little memory needs to be wasted on the tile-cycling scroll trick. The Colecovision is maxing out whilst the NES is essentially doing nothing.
Early on the NES was bottle-necked by the price of memory, there's only so much you can do with games that are ~20k odd in size.
This is also what held back 2nd gen games bitd. If you were to try to port many 2nd gen games (especially 2600) to NES using the same sized rom, they would look worse or not be possible at all.Quote:
Originally Posted by Thenewguy
The biggest Intellivision games bitd were 16K, which is a measurement of "Kilo Decles" or words, not kB or KB.
Intellivision games were also held back by Mattel and likely others using 10-bit roms because they were cheaper than 16-bit roms. Similar to what happened to many SFC/SNES launch games.
Roms measured in 10-bit words are smaller than 16-bit word roms and modern Intellivision cart boards use 16-bit rom/ram. Still the largest Intellivision homebrews are still tiny compared to NES roms. Only 256K is supposed to be possible with bank switching.
A good example to put it in perspective is that the first version of Donkey Kong/DKArcade by Carl Mueler Jr is the same size as 16K games from bitd. That's including the sound samples.
It's been estimated that those 16K games are the equivalent of 20kb. Think about what a port of Donkey Kong, even just a port of the Intellivision assets, would look like on NES with only 20kb.
http://youtu.be/8p9XuHPYHeI
You going to get the new Intellivision when it comes out Black Tiger?
Only if the final product gives me a reason to. The last new console I bought was PS3 and I still haven't bought any games for it.Quote:
Originally Posted by gamevet
I like the Amico controller and it actually can produce very unique play experiences. But Tommy's mandate for Amico games to have local multiplayer, be family friendly and misc makes it sound like there won't be a lot of games that interest me. The visual styles in games shown so far also aren't what I'd like.
I don't have as much time as I'd like for classic gaming, which I enjoy much more than everything since. It will take a lot and/or something very special to get to consider any new console.
Thats why the ColecoVision version doesn't have an ounce of flicker or slowdown?Quote:
Originally Posted by Thenewguy
Its not pushing the NES, but its not a noticeably bad looking game either. I get we all grew up with the NES in North America, but that doesn't mean we should jack it off at every opportunity.
You seem to talk a lot about the Intellivision, but never the Intellivision 3. I gotta be honest with you, thats what I'm interested in the most about the Intellivision family. I can imagine an alternate reality where thats another 3rd gen console I grew up with. I definitely didn't grow up with a 7800 and don't think I was missing out on much.Quote:
Originally Posted by Black_Tiger
Well as a millennial, my version of classic gaming is the 6th gen. The reason I enjoy playing games from this generation so much, is theres no many genres that no longer exist today. The most notable one being racing games.Quote:
Originally Posted by Black_Tiger
Well, I'm not as knowledgeable about this stuff as Sik and Kamahl so I may be wrong but lets give this a try -Quote:
Originally Posted by Yharnamresident
Flicker happens when the per line sprite limit is exceeded, which for the Colecovision is four and for the NES is Eight
This game requires one sprite per horizontal line. The Colecovision can use all of its single colour sprites overlaid together to make one "multi-colour sprite", so basically its using its whole sprite capability just to make the player multi-colour. Any game with decent numbers of enemies in it can't do this to this level, it would have to use software sprites made out of the backgrounds for the enemies, which would have coarse movement
The NES is just using one or two of its eight multi-colour sprites per horizontal line, its doing nothing.
------------------
The game only needs to scroll a small area of the screen to give the appearance of movement, the Colecovision developer has made piles of repeated background tiles with the graphics art offset by one pixel, these background tiles are then cycled (so the "scrolling" is essentially working like a flick book).
Any game with detailed backgrounds couldn't do this trick at the time because every element of the background would have to be drawn in multiple positions to flick through, which would waste inordinate amounts of space and make the cartridge too expensive.
The NES is just using its inbuilt hardware scrolling, its doing nothing.
------------------
The Colecovision is just particularly well suited to running Track N' Field.
I'm English, the NES was like the 5th most popular gaming platform here in the 80s, I owned a C64.Quote:
Originally Posted by Yharnamresident
I suppose the biggest problem here is that we're trying to act like the ColecoVision could go against the NES when it was probably never supposed to, really (heck, that was probably supposed to be NEMO's job, but then it got cancelled at last minute due to a spike in VRAM prices and Hasbro chickening out as a result).
[tangent]
…actually looking at dates: ColecoVision came out in 1982. Famicom came out in 1983, though the NES wouldn't come out until 1985 (so regionally ColecoVision still had some advantage… or would have had, if not for the crash). Then again, SG-1000 was basically on par with the ColecoVision and ended up coming out the same day as the Famicom… Yeah, that's a mess.
Also apparently the ControlVision's (i.e. NEMO's) launch year was going to be 1989, despite being a modified ColecoVision genlocked to VHS video? Huh yeah, it'd have been trashed in no time if it came out (ouch).
[/tangent]
Make what you want out of all that.
The Intellivision was released and has software. I grew up playing it. You didn't grow up playing Sega's successor to the Dreamcast, because it was never released, if it ever existed.Quote:
You seem to talk a lot about the Intellivision, but never the Intellivision 3. I gotta be honest with you, thats what I'm interested in the most about the Intellivision family. I can imagine an alternate reality where thats another 3rd gen console I grew up with. I definitely didn't grow up with a 7800 and don't think I was missing out on much.*
This is a 2nd gen console thread. Intellivision III was more 16-bit gen than 8-bit gen.
I enjoy actually playing games and figuring out how they work. The older I get the more that stands out in classic games that I hadn't fully appreciated or understood before.
The Intellivision III has been well documented and video of demos have made it online. There's not much left to discuss.
Maybe start a vapor ware/console thread?
You wouldn’t want to compare an Intellivision to a 16-bit system though, not even to an Atari ST. It certainly couldn’t do a game like the Master System’s R-Type.
The Intellivision also has some strange limit with colors. Kong shouldn’t be Green in Donkey Kong, and Pauline shouldn’t be a solid color either. Then you have green burgers in Burger Time.
The Atari ST isn't a console.Quote:
Originally Posted by gamevet
If you're thinking of the Intv System III, it's a regular Intellivision. Most pcbs are leftover Master Component boards. A small number are various degrees of Tutorvision hardware and are technically superior, but you need Tutorvision software to make use of it.
The Intellivision III is unreleased hardware that actuallly existed. This is what the specs looked like:
Resolution of 320 x 192 pixels (I think that sprites are still higher res).
3.56 MHz cpu.
6 sound channels + built-in Intellivoice.
Wireless controllers.
12-bit master palette.
Multiple types of sprites and tiles.
Improved sprite scaling.
It wouldn't be on par with the released 16-bit consoles, but it also would have shipped in 1984 with Game Gear color, a higher resolution that NES/SMS and plentiful voice samples in most games.
Uh....Famicom.
Seriously, the Atari 520 ST and Amiga 500 were meant for gaming and a lot of early Western Genesis games were ports from those home computers.
Laird's Lair covered the Intellivisin III about 10 days ago and brought up the Intellivisin 4 (68k CPU), that was meant to compete with the likes fo the Atari ST.
https://www.youtube.com/watch?v=km_QmGSWcoA&feature=youtu.be
And back to Draconus yet again!
Nope, it wasn't an Atari original, they just charged more for it, presumably as the Atari user-base was small by this stage.
https://i.ibb.co/GQqj9Tn/draconus1.png
https://i.ibb.co/RzqWyWf/draconus2.png
How much CPU time is used for the interrupts on 5200? None, little, moderate or a lot?
The Atari 8-bit developer of Green Beret seems to have gone to ridiculous amounts of trouble to give the appearance of more colour in that game without using interrupts, he dithered the heck out of that game.
https://i.ibb.co/Hd26MS4/green-beret-4.gif
https://i.ibb.co/xLc10G4/green-beret-3.gif
(The dithering obviously looks better on a CRT as it blends together)
Any reason for this or was he just incompetent? I guess he may not have had any artistic ability to rearrange the graphics to work with interrupts? (I think the foundation art is straight copied from the C64 version, and the new sprites aren't exactly drawn well).
He was definitely rushed as the game seems to have been released unfinished, but is it really that much easier or faster to redraw the graphics with massive amounts of dithering instead of doing one mid screen interrupt?
EDIT: Thinking about it, it takes little artistic skill to make the first level work, all that needs to be done is to have the mountain range set at the same height for the whole level, that means that you don't have to include blue in the bottom half of the screen at least, heck you could do a sunset effect behind the mountain too couldn't you?
Well, making interrupt code is probably harder to get right, so if you're in a rush indeed you probably want to avoid spending time on that. And yeah, a lot of ports were made by a single person, and often from another port that was already downgraded for starters, so that becomes a chain of rushed downgrading.
That said, I recall there being something about vertical blending happening in SECAM, I'm not sure if something similar happened with PAL too? (oh, and the scanlines being closer together in 50Hz probably helped too) If you see that kind of dithering there's a high chance it was made with European systems in mind.
EDIT: also looking more at those screenshots, I'm not sure how interrupts could have helped, it seems it really needs all those colors all across :/ May have been better to change the color of some things (e.g. turn the red arrows into black arrows) and then replace the red with a brown.
An Orange-Brown has actually already been chosen as one of the colours, its just barely used for some reason. Red is required for the earlier part of the level where you're running along on girders so that's kind of needed.
Better to choose a darker brown and use it for the missile carriers with red as highlights maybe IMO.
But yeah, I think the 5200/A8 hardware is poorly suited to Green Beret in general though, its too sprite intensive for one thing.
Actually, correct me if I'm wrong, but this seems to illustrate Kamahl's earlier point. The game is using the tile mode, so it can do 5 colours per line, the Atari has 5 sprites per line so they can either use one single colour sprite for the player and one for each enemy, resulting in fairly crude looking sprites, or they can do what the developer did, which is double them up in two's (with the player seemingly being a green hardware sprite overlaid with a light brown one), but now we only have enough sprites for the player, and one and a half enemies per line (and to be honest they still look quite crappy). Not to mention the flame thrower weapon and its blast.
However, in the bitmap mode we can use most of our hardware sprites for the player, resulting in a nice three or four colour sprite (plus the flamethrower's flame) and use software sprites made out of the background for the enemies, which can, for example now have white faces and hands, brown uniform, and black details, hair and outline. Now we're limited to four colours per line instead of five though.
I think the bitmap route with some background elements removed or simplified would create a more consistent look for the game.
One thing that can also help with the Atari is to run in half-vertical resolution mode. While this does mean that the games become even blockier looking, it allows the CPU to run at full speed (which is nearly twice that of the C64), and you only need to render half the lines for software sprites which is another speedup. All of this extra CPU time also means more time for color changes and such.
Draconus actually runs in this mode, but they don't do anything interesting with it.
If you are willing to have enemies share the same colors, you can also use PMG (sprite) underlays for the background, which gives pretty interesting results and may actually be the best possible use of Atari 800/5200 hardware:
https://www.youtube.com/watch?v=ClOVc_OR5OE
I take it the hardware sprites are being used for the background in that demo, and they are somehow behind the background layer?
So what's left for Mario and the Koopa's? What are the four background colours for the software sprites?
Black, brown and pink, the 3 shared colors on the screen. The greens, blues and whites are made with sprites, so you can't use those for the player or enemies. A game that would work perfectly with this technique is Cybernoid 2, you can do a near perfect port of that game with this technique, image example from José Pereira:
https://atariage.com/forums/uploads/...1322199566.png
In the Atari 800 sprites can also "OR" themselves with the background, so you can actually tint multiple colors with a single sprite, essentially doubling the amount of colors you get out of it.
Another trick that some homebrew games use (I think Pang and Bomb Jack), is to have the game in 5 color tiled mode but arranje the tiles in such a way that they're sort of like a bitmap, with per-scanline changes to have all tiles onscreen be unique.
That gives you sort of the best of both worlds (bitmap screen and 5 colors) and the expense of the overhead from interrupts and a less optimal graphical layout.
The Atari 800 is just like the 2600 and the Amiga in that it is all about using crazy tricks to get the best results.
Why only 3 shared colours?
The brown, pink, and black work reasonably well for Mario and the Goomba's actually.
The underlaid hardware sprites will affect the colors of any software sprites on top of them, so this only works if you massage things a bit.
You can set color priorities such that two colors are always on top of the sprites, these two will not be affected (AFAIU).
I'm not sure what happens in the case of the special 5th color.
ORing sprite colors with the backgrounds seems very poorly documented, so I don't know the exact rules there, but I know white is not affected (it always stays white).
Finally, you can set things up such that there's some "priority" conflicts, which result in the color black.
Whichever way you slice it, you're not getting more than 3 colors for the software sprites.
EDIT: Actually I'm wrong, you can make it such that all background colors appear above the software sprites (not in the weird OR mode), meaning you can use all background colors for software sprites, except for the border/main background color of course. You also cannot use the 5th color because it works at the tile level and you'll get Speccy style color clash if you have software sprites over that, so yeah, it's 3 colors per sprite, whichever way you do it.
EDIT 2: At least for static images, in the hands of top-tier pixel artists, the Atari 800 is unbeatable. Just look at these:
http://gury.atari8.info/pictures/shots/bicorn.png http://gury.atari8.info/pictures/shots/devil_piesiu.png http://gury.atari8.info/pictures/shots/dpwf.png http://gury.atari8.info/pictures/shots/dinner_xex.png http://gury.atari8.info/pictures/shots/i_came.png http://gury.atari8.info/pictures/shots/latarnik.png http://gury.atari8.info/pictures/sho..._in_lichen.png http://gury.atari8.info/pictures/shots/order.png http://gury.atari8.info/pictures/shots/vintage_2077.png
The above is what makes the hardware so... tantalizing. A gorgeous master palette, fast CPU, hardware sprites, hardware scrolling, tiled and bitmap displays, 4 channel sound that's not just crappy square waves.
It should be capable of so much, and yet most games aren't that amazing. I hope someone figures out a way to make the machine do unimaginable things the same way the Speccy scene has done for their machine.
Its certainly the most powerful out of the 2.5 gen consoles I think, but with the development environment of the 80s the system was never going to get close to its full potential in my opinion. It just takes too long to pull off something that the C64 for example can do with little effort, and surpassing the C64 in colour usage just takes too much time and skill for the commercial market of the time. If the 5200 had been a huge hit we probably would've just got more games that looked like Cavernia and Zybex.
On another note I was watching a video on Youtube the other day, it was called something like "every console ever made rated from best to worst", and in the 5200 section the comment was something like (I'm paraphrasing) "of course it failed, the machine was barely better than the 2600, even to the extent they were placed in the same generation" I winced a bit when I heard that, heh.
Hahaha, nice find. Though to be fair, many 5200 games do look barely better than 2600 games. It really struggles to show what it can do.Quote:
Originally Posted by Thenewguy
EDIT: How the color "ORing" works on the Atari 800:
https://atariage.com/forums/uploads/...1208131121.png
The first pair of sprites mix with the first pair of background colors, the second pair of sprites mix with the second pair of background colors. The 5th color (not shown in the pick) is apparently unaffected when it comes to the background but it mixes when it is sprite overlays. This mode requires disabling GPRIOR, which means you can't actually configure background priorities willy nilly, but must use the ones in the picture. How to make software sprites work with this configuration is one hell of a challenge, but that is a lot of extra colors...
EDIT 2: Ok, idea:
PF 0 and PF 1 are set to black and some color that is fitting for the "sky" or such.
PM 0 and PM 1 are set to 4x the size, so each covers 32 px of the screen.
PF 0 and PF 1 have priority over those sprites, so they are used to mask them, i.e. give them a non-blocky shape.
PF 2 and PF 3 are set to colors that never appear on the same tile and BAK to a color that mixes well with those two.
PM 2 and PM 3 are set to colors that "OR" well together with PF 2 and PF 3.
Background wise this gives 5 playfield colors + 2 sprite colors + 4 "ORed" colors.
PM 0 and PM 1 are used for the player sprite and its bullets. The player and bullets are a mix of software sprites and hardware sprites.
The main player sprite and the bullets can use BLACK + two background colors + sprite color + "ORed" colors.
Add in per-scanline color changes and you can probably do something crazy with this. Figuring out which colors "OR" well together is the biggest challenge I would say. Easy if the game uses a lot of greys but otherwise not so easy.
It would have been cool to see the 5200 get better support from Atari. The crappy controller, the power cable connected to the RF box and the same old arcade games kind of killed the console’s chances for the price they were asking.
BTW was there something up with the NES' multi-directional scrolling early on? I'm thinking both Mega Man and Super Mario Bros 2 seem to scroll smoothly one direction, but use burst scrolling on the vertical axis, Metroid does smooth scroll both directions, but there is a burst scroll transition between vertical sections and horizontal sections, and obviously Zelda has to scroll on both axis and that just uses burst scrolling. Then there's Ghosts N' Goblins, which does scroll diagonally but the scrolling is noticeably choppy in that game.
Obviously this went away as later NES games had no problem, but I was thinking the 5200 and C64 rarely seemed to do this even early on.
There's only enough VRAM on the console for two screenfuls, while scrolling in both axes smoothly requires memory for four screenfuls. Games can add more memory, but that wasn't common (because, of course, cost reasons). Many games would just scroll in one direction, but many would also just let garbage show at the sides (or top/bottom) and hope they got hidden away by the overscan.
Another issue is that the arrangement of the two screens (horizontal or vertical) is not a PPU register, but for some reason it's defined by the cartridge wiring. So a lot of games were stuck with a single arrangement for the whole execution. Some mappers would allow changing this on the fly through their own registers instead.
EDIT: the HUD can also be pretty problematic, e.g. Super Mario Bros 3 is stuck with arranging two screenfuls vertically and limiting the height of the maps, because a chunk of the tilemap needs to be reserved for the status bar and it needs to be drawn by changing scroll on the line the status bar starts. And if this seems unlikely because there's no way you'd be able to fit those levels in less than two screenfuls high… yeah, I thought the same, but they indeed did that and just were very good with layout management.
The NES doesn't need additional screen vram to scroll smoothly in multidirectional scrolling. I mean there might be artifact fringing on the edges of the screen, but that doesn't have any effect on if it's smooth or not. I mean you can do it with single screen mirroring if you wanted.
Kamahl, how does Spectrum Robocop get the 3rd colour in the background? is it the same method used to get extra colours on the Apple II? I didn't think this effect worked for Spectrum. EDIT: I'm talking about this blue colour here (unfortunately its difficult to photograph it).
https://i.ibb.co/Tq2Fwks/IMG-20200326-110727.jpg
What third color, I only see two. There's some chroma bleed in the thin vertical bars (which does look blueish) but that's it. Unless you mean the turquoise border around the viewport. That happens to be aligned to tile boundaries, so they just colored those tiles.
For the record, the reason Apple II could get away with it was because it was so high resolution that its pixels were well below the chroma resolution (and hence multiple pixels contributed to one color). This was also abusable on the CGA for a similar reason, though it wasn't as commonly used because you couldn't guarantee that the user had composite output (though lo-res artwork designed to exploit chroma still was a thing, even if it was a bit more restrictive).
Yes this is what I'm talking about, the blue area.Quote:
Originally Posted by Sik
Here's another picture of it I found (from someone who presumably has a lower quality TV than mine) -
https://i.ibb.co/mJP3byY/IMG-20200326-110727.jpg
That last one looks emulated honestly. But yeah, that's just chroma bleed (since RGB to YIQ converters still try to figure out what chroma to use even for monochrome colors and the result isn't perfect).