bmcnett
-
Content Count
131 -
Joined
-
Last visited
-
Days Won
3
Posts posted by bmcnett
-
-
You know what's lewd, guys?
When you're playing Smurf Rescue and you deliberately retreat from the final screen, knowing that it will cause Smurfette's dress to disappear for a few video frames.
-
3
-
-
While I agree, there isn't a lot of money to be made from the homebrewers, but if you work on getting them out of the picture, and getting a fan site out of the picture that has almost five times the amount of followers that your corporate page has, then you win back a bit more "control" AND you can focus on where the spending from retro gaming fans goes. Or at least maybe this is the thought process by Coleco Holdings LLC?
Coleco Holdings LLC have made it pretty clear they are releasing some new products this year. New mini-arcades, new ColecoVision games, possibly even a new system, right?
And here we are a fan site, and we are featuring Opcode's games, CollectorVision's games, AtariAge's games and more to our 25,000+ people who have chosen to like our page. But what if we weren't around anymore? When you search "Coleco" or "ColecoVision" on Facebook, our page is the first result to appear. The official Coleco site is 2nd. Maybe the end goal for them is to push the fan sites and the homebrewers a little more out of the way by making it difficult for them to produce their games, so that more focus, and thus more money would be spent going directly to Coleco Holdings LLC.?
Your theory makes more sense now that you've gone into more detail. This does assume that Coleco has a poor understanding of the retro computing scene, which is possible.
Historically, a commercial platform holder's ability to control brand perception flows from their power to block distribution of games.
Colecovision was the last major game platform to implement no hardware controls to lock out unauthorized games, and this is cited as one of the reasons it eventually failed.
The pico8 homebrew platform holder manages to block distribution of lewd / infringing games without hardware controls,
but he does this by maintaining the free BBS and free game download system that are convenient for people to use.
If Coleco is a homebrew platform (it is right now) it would probably have to work more like the pico8 model, since there's no money involved.
-
3
-
-
"Strong arm the community into making you more money"
this, I don't buy. the kind of money thrown around on coleco homebrew, as i understand it, amounts to probably a few grand a year, total? i have no idea really, but this seems like a reasonable first guess.
so an attempt to horn in on that money would net you what, a few hundred a year tops?
it just doesn't make sense to me that this is a move to squeeze money from the homebrewers - unless the scale of their operation is much, much larger than it appears to an outsider like me.
-
1
-
-
Heh, I didn't know it had sold this well.
-
1
-
-
Hi Bryan,
I don't think you will get any argument that trademark owners should protect their IP. I think the big issue is the way they went about it and who they went after.
*Should* the Coleco owner have gone after this fan page, in this way? Well no, probably not, because of the Streisand effect: those who attempt to forcefully cover things up on the Internet tend to achieve the opposite result.
If a person under the age of 30 who knows how the Internet works had been consulted before action was taken, things could have gone a lot more smoothly, probably...
My imagination can still imagine that somewhere, a businessperson is considering releasing a say, Raspberry Pi powered microconsole for $40, that comes preloaded with official Coleco, but which could also run NES favorites, etc.
If the price were lower than NES Classic Edition and if it did multiple consoles more smoothly, I know people who would buy such a product.
-
People who seem irrational often simply have poor information about the decisions they are making.
The chameleon affair tells me that there is a lack of tech and product design savvy in play.
People have succeeded without them before, but unfortunately the videogame market is already fairly mature for that sort of thing to fly.
-
It already exists.
And the reviews were not exactly "glowing" either....
While technically, yes, Colecovision Flashback already is the Coleco equivalent of NES Classic Edition, it went on sale in 2014 when there hadn't yet been a runaway success in the retro console market.
A business-minded person could argue that NES Classic Edition sold well partially because the platform is so beloved, and partially because a higher degree of polish went into the product itself.
Personally I am not the market for any of these products, but I can't think of any other reason why the owner of Coleco would suddenly see fan-pages as a threat, where no threat had been perceived before.
-
Hello all,
Ok so here's my view from 30,000 feet. In 2016, Nintendo's "NES Classic Edition" console was a smashing success and sold out everywhere. One of its pack-in titles is "Donkey Kong."
http://www.nintendo.com/nes-classic/
This fact can't be lost on the person who currently owns the rights to Colecovision - the favored game console immediately before the original NES, which had the *exact same* "Donkey Kong" pack-in title.
If I were them, I'd be thinking about attracting investors to a "Colecovision Classic Edition" product, but first I'd want to ensure that when people search for "Colecovision" on Facebook and Google, nothing sketchy appears.
The crucial flaw with any such plan is that the vast majority of nostalgia-inducing Colecovision titles have always belonged to third parties, and never to the owner of the Coleco brand.
Sega and Nintendo own the rights to most of those games, and would likely not participate in anything Coleco-related ever again.
Anyway, this is what I think is going on here. I don't get the impression that the "homebrew community" is of any concern to the rights-holder particularly, other than it should not get in the way of business.
Who am I? My dad was an Art Director at Coleco during the Colecovision and ADAM years, and I am a game industry veteran with dozens of credits on AAA titles.
Bryan
-
7
-
-
AWESOME!
-
after reading all this i think I was wrong to say that no randomization entered the mainstream.
-
No, see, matthew has been talking about (eventually) offering scrolling in his enhanced 9918A but the implementation remains an unsolved problem. I happen to be working on that problem in my fake 9918A. So this is relevant to at least matthew's 9918A project. Do you have any technical opinions to offer, or are you satisfied quoting mine and replying "So what, I don't care because you're nerdy McGurdy."
-
I've been working on scrolling again in my VDP emulator. I'm going to have to take back my recommendation for a Game Boy-like fixed "tile window" inside of which the screen scrolls and wraps. With sadness in my heart I have concluded that Atari 400-like "display list" scrolling is ideal. That is to say, there is a data structure in VRAM that says for each scanline where to start reading tiles. I am sad because the Atari 400 way is prone to fiddly-piddly hacks - it is possible to get lost in there doing scanline breakdancing. All I want is scrolling.
However a "display list" is capable of expressing all existing VDP modes OR something almost the same but with the required extra two rows and columns for scrolling without special cases for either, plus some other useful interesting scrolling methodologies, which is more than I can say about a fixed scrolling window a la Game Boy.
-
randomization would complicate testing because there would be far more variations than any user is likely to encounter. also the artwork and programming would be more complicated than otherwise necessary. there have been games that do things like you mention ( did black and white set game time from the net connection? ) but none so far have become mainstream because the perceived cost/benefit is too high.
famous games with randomization include nethack and dwarf fortress, both quite far from mainstream gaming.
-
i remember my family had the 2600 w/launch titles, so that was 1977? i was five years old.
most of the games required two people. my brother and i played a lot of indy 500 and combat...
it didn't occur to me until years later that games could look any better than that.
-
There's no way Dad was responsible for Coleco's top level business decisions, he was nominally in charge of "preliminary design" or prototyping. I remember him having pride in the toys and TV shows he helped make over the years, but never games. He got his degree in industrial design in the early 60s and videogames were simply beyond his ken.
Since he had no mastery of the videogame making process he simply ignored it, far as I can remember. That couldn't have helped Coleco, but in retrospect it's unclear what would.
-
Does anyone have any idea who might have been in charge of game dev at coleco? It would be fun to see the reaction of the person who originally conceptualized having this game in the Coleco arsenal.
Great work, RK! Great, I say!
My Dad was in charge of design at Coleco during those years. When I bumped into one of Coleco's game artists at a sushi restaurant many years later, he told me that Dad's nickname at Coleco was "Mr. Drummond." I guess this was because Dad was very "square" and looked like the television character.
Dad expressed zero interest in computers or videogames until his death in 2009. I sometimes wonder if his attitude may have contributed to the collapse? Guess we'll never know.
-
Make that 2! For me, this is an option I'd love to have available. For fancier graphics options, software/registers is the way to go, but for legacy software, such as any ColecoVision game that flickers, it'd be great to be able to switch between 4 and 32 sprites per scanline. I can't/won't be reprogramming any of the old (or newer) games that use flicker.
What do most of the flickery ColecoVision games do at boot time? Call the BIOS routine that uploads the system logo and copyright screen to the 9918A. That could be the software switch that enables 32-sprite mode
-
That's an interesting one.. expensive to do in hardware though (you need to fetch the whole pattern, and compare every byte). Also, the technique works with invisible sprites (color 0) -- although that would be easier to test for, hehe. Finally, not all titles used non-visible sprites to induce flicker. For my own part, I actually defined the lower indexed sprites as part of the scenery, so they were visible (rather than wasting four sprites!
)This raises an interesting issue - if I'm not mistaken the 9918A and its contemporaries did all sprite work afresh with each scanline. They did not, if I understand correctly, use the VBLANK to do things like scanline-sort or otherwise process the sprite table in anticipation of scanlines to come. This made possible scanline tricks on many platforms, but also as you say would have made it expensive in hardware to do things like examine sprite patterns.
I've seen MSX demos that have what look like scanline tricks, but I've never seen one on ColecoVision or ADAM, and don't know about TI-99/4A. My software VDP forbids such tricks, which enables a bunch of per-frame work to get done efficiently during VBLANK and during the frame itself. For example, batches of four scanlines are sometimes rendered in parallel ahead of the beam, which makes it possible to load fewer bits per pixel.
-
Funny we talk about multicolor mode - I forgot that someone uploaded a nice little multicolor Tetris game to my forums for me to look at - I just did and it's rather well done. http://www.harmlesslion.com/hl4m/viewtopic.php?f=3&t=519&p=1820 (scroll to my reply where I post the fixed files). So we have two multicolor games for the TI now, hehe.
bmcnett... your color scheme reminds me a lot of the Atari Jaguar's CRY mode. CRY was a 16-bit mode that used the top 8 bits for luminence, and the bottom 8 bits selected a color from a table. The table selection did limit the colors available, though, IMO too much (but many people liked it.) A full HSV system as you list is probably better, the Jag just didn't have the bandwidth to pull it off.
Yeah, that sounds exactly like my 16-bit HSV. It ended up having 32 hues and 8 saturations or 16 hues and 16 saturations, neither of which was enough to encode the 9918A's default palette IMO. I also don't have the bandwidth for full HSV, so I have both HSV and RGB palette registers, and do HSV->RGB only just after the CPU updates an HSV palette register.
Multicolor mode is actually pretty cool IMO because there are so few bytes to update that an old CPU can handle it. I may keep it as a 64x48, 256 color mode which could be "faster" than the original mode, because then at least the CPU wouldn't have to deal with masking and shifting nybbles all the time.
-
I dunno that uploading partial sprite bitmaps is JUST AS well. First, you need to upload the patterns. If you want single pixel occlusion you need up to 31 additional frames loaded (magnify 4 sprite), that's up to 1k per sprite pattern (and you only have 16k to start with), though a more realistic case would be 16x16 sprites at up to 512 bytes each. Second, you can't use automotion at all, because you need to change the pattern based on the scanline. Thirdly, you need to devote CPU cycles on a machine that's usually CPU bound to checking for and changing the patterns on the fly. This is all impossible to do realtime in Extended BASIC due to the low speed of the language. Or you can just drop four unused sprites there and let the hardware do it for free.
I had to deal with the issues of pre-rendering partial sprites to fake occlusion for Mario Bros, since there was no way to do it horizontally. Anyway, nobody is taking away your flicker-free system. Matthew doesn't like flicker either, and IF he puts it in you will be able to turn it off. So why raise such a fuss?
Ah, I hadn't considered that people were using BASIC still. That case is SO cpu-bound that the four-sprite limitation is clearly superior to bit-twiddling the sprite patterns. Sorry if I'm raising a fuss - I guess I come from a different culture. I'm a ColecoVision and ADAM user, and on those platforms a no-flicker default setting is an obvious win for everyone. ColecoVision is an interesting case for homebrew because, while as a game console it was mainstream in North America, due to licensing issues and its short life there are huge gaps in its catalog that are easy to fill by amateurs (e.g. Space Invaders) and its chipset is very conventional.
I thought of a flicker compromise that might or might not be useful: If on a scanline there is any sprite with all zeroes in its entire 16x16 bit pattern, then the four-sprite limitation applies to that scanline. If no such sprite is on that scanline, then the limitation is lifted.
-
I have a few propeller microcontrollers. I was going to go that route before I decided on the FPGA. I'm sure a propeller could emulate a 9918A. It runs at 80MHz and has 8 parallel RISC processors they call "cogs". Hopefully I'll have time to mess with them before I die...
To a PS3 programmer like me, this sounds suspiciously like an SPU but at 1/40 the speed and probably without floating-point. If I had one of these things, I could knock out emulators for old chips left and right, but I'm totally clueless about how to deal with the electrical connections to the host computer. Any pointers about what a person like me should read or experiment with, in order to reduce the cluelessness?
-
re: matthew's color space
Yeah I'm using RGB internally like you. I do the HSV to RGB conversion only when a palette register is set, and keep an HSV copy lying around in the imaginary chip, for color key, recoloring and CPU palette readbacks.
Sounds like doing this in a real FPGA is pretty hard! I admire your work ethic.
I've been hearing about this "propeller" processor that can be programmed to output an analog RGB or NTSC signal from binary data comparable in density to an 8/16 bit home computer from the past. Someone got a "spectrum" emulator working, I hear. Wonder if it could do a 9918.
-
I am considering 24-bit color, but only to be able to accurately reproduce the original colors. Currently I have 9-bit color and I can only get close. I don't think, however, that I would ever make a version that would allow 24-bits per pixel, tile, or sprite. However, the palette registers (or memory) may be 24-bit.
Since there aren't any backwards compatibility issues to consider, other than the one you just mentioned, this is where I've been doing the most radical work in my (fake) VDP. I don't understand why you would consider 9-bit colors, but I guess it has something to do with the FPGA, and I'd love to hear the story behind that one.
Currently my colors are HSV (hue, saturation, value) and not RGB. Historically, HSV was used instead of RGB on older systems like 2600 because it more closely matches how an analog TV signal works. I don't care about analog TV, but I like HSV for other reasons:
1. Sprite transparency is typically done via a dedicated bit pattern (like a 0 bit in a VDP sprite.) This however consumes a proportion of colors equal to 1/(2**N) where N is the number of bits per pixel. That seems to be a reasonable tradeoff when you have four bits per pixel, because then you lose only 1/16 of your colors and you probably weren't using that color anyway. But for two bit imagery, you lose one of four colors, which is pretty horrible IMO! Therefore I would like to use "color key" for transparency in sprites. I want each sprite definition to have, in addition to X, Y, etc. a "transparent color" which is to say, a HUE which will be transparent. So a color space where HUE is a primary is convenient for that purpose.
2. The app developer sometimes desires to "recolor" imagery cheaply, which is to say for example have one sprite definition for a soccer player with a red shirt, and somehow cheaply get him to show up with a blue shirt instead. Historically this has been done with palettes, but these are usually a limited resource (e.g. Genesis had only four in the whole system) and moreover if you just want to change one color, you end up storing copies of all the other colors in each palette, which is wasteful. So I would like ANOTHER two values in the sprite definition that gives two HUES: the hue of the color you want to change, and the hue of the color you'd like to change it to. So again, a color space with HUE as a primary is convenient.
3. Sometimes the app developer wants to do something programmatically to a color on the CPU, and in my experience this is typically a change in value (brightness), hue, or saturation. If they get these as color primaries, no need for them to deal with conversions to and from a linear space like RGB, which a really old CPU is bad at anyway, because it might not even have a MUL instruction
So right now, I'm considering either a 16-bit HSV color space, or a 32-bit HSV color space. Leaning towards the 32-bit because 16 isn't enough to reproduce the VDP's original hardware palette. So that would be:
16 bits: luminance, with the same nonlinearity as sRGB.
8 bits: hue. the "angle" of the color as rotated around the luminance vector.
8 bits: saturation. the "distance" of the color from the luminance vector.
A 16 bit nonlinear luminance has a few things going for it:
1. You can set just the top byte and it's still sRGB so you don't lose all your dark values even though you're poking only eight bits of precision
2. If you poke all 16 bits, You won't get "banding" on any display device I've ever encountered (unlike 24 bit color!)
-
Perhaps before your next post denigrating the old hardware you should remind yourself of an old adage.... It's a poor carpenter who blames the tools.
Whoa there cowboy, who's denigrating old hardware? The original VDP is one of my all-time favorites, and I you won't catch me saying an unkind word about it, unlike some people who can't get over the lack of hardware scrolling...
The VDP mode where 8x1 pixel chunks can pick two of sixteen colors is remarkably modern if you consider how "texture compression" works on a GPU. I see a lot of hate for these modes with "attribute clash" but they are really an excellent compromise, which is why all the new graphics modes in my fictional VDP upgrade have "attribute clash!"
If imitation is the most sincere form of flattery, then count me as a VDP fanboy.
Like us on Facebook
Follow us on Twitter
AtariAge on Instagram
Watch us on YouTube
Chat on Discord
Coleco strong-arming homebrew publishers and fan sites
in ColecoVision / Adam
Posted
Actual Colecovision compatibility is a technical liability if your goal is to make and sell microgames to a mass market.
The cheapest hardware worth mass producing in 2017 is somewhere between PS2 and PS3 in terms of capability,
and it is far, far easier to pump out Coleco-era-looking games that target this actual hardware,
because there is no need to fit everything into Colecovision's extreme technical limitations:
no scrolling background
32 16x16 pixel sprites with 1 color each, only 4 per scanline
16 total colors
2 colors per 8x1 background pixels
1KB RAM
Z80 ASM is the only programming language
There is no mass market business value in producing Colecovision games in 2017, because the cost of dealing with the above limitations vastly exceeds whatever profit could be recouped.
So anyone who wants to make big money from the Coleco name these days, wouldn't be interested in Colecovision games per se.
They'd be more interested in a fantasy platform like pico-8 that provided the same nostalgia feel, but which didn't have expensive technical limitations.