Jump to content
BladeJunker

Questions about Coleco graphics capacity?

Recommended Posts

Sprites can be layered if you're careful. But you can layer 2 or 3 or 4 sprites at a time. There is a rule that you can have at most 4 visible sprites on each scanline.

How are the sprites addressed exactly, is it just 4 slots per scanline like the 2600s limit of 2 before flicker is required? Can you reduce flicker more so with just increasing vertical misalignment or is it just a matter of intruding on the same scanlines in question for a constant rate of flicker needed? I came across a homebrew called the Mating Game that mentioned staggering sprites rather than aligning the layers perfectly to each other but it didn't say much about flicker matters since they seemed to just avoid it completely in their setup? All I know about flicker is its software based rather than something that happens automatically.

Share this post


Link to post
Share on other sites

How are the sprites addressed exactly, is it just 4 slots per scanline like the 2600s limit of 2 before flicker is required? Can you reduce flicker more so with just increasing vertical misalignment or is it just a matter of intruding on the same scanlines in question for a constant rate of flicker needed? I came across a homebrew called the Mating Game that mentioned staggering sprites rather than aligning the layers perfectly to each other but it didn't say much about flicker matters since they seemed to just avoid it completely in their setup? All I know about flicker is its software based rather than something that happens automatically.

 

Flicker is software based. All of the sprites for the trees -4 down the slots of 20 sprite per frame. If the slot hit 0 in that frame then value 20 is loaded to reinsert the tree x,y,color, pattern information. You can see that the trees are solid. Once they are overlay or 5 or more on a scanline, then you will see flicker. NES flicker is also written in software. There's different flicker technique.

 

The rate of flicker is different for each games. If side scroller, there may be 12 sprites possible on one scanline, then you have to make a game engine that change sprite priorities just in case there would be 12 sprites on a line. If there would be 12 sprites on a line, then the player can see those 12 sprites oppose to 4 sprites if there was no flicker. Of course there's a flag flips if there's a 5th illegal sprites on that line and give the sprite number for the code to catch that if developer prefer to use a routine to change that sprite priority.

 

I'm unsure why the 5th sprite drops technically. But for 2600, there's only 2 8-bit register per line for sprites image. There's different way that the TIA handle sprites like fixed space cloning, or stretch sprite 2x 4x 8x size.

 

How many Char Sets can Multicolor mode use, since it is unpopular people sort of gloss over it?

From the TI book, it only uses the pattern table to store the data, and the name table. So it reads 4 bit of a byte to determine what color that block is, so 0x1f would be 4x4 pixel black, next to it will be 4x4 pixel white. I haven't played with multi-color mode. You can store multiple state of screen data and write to the vdp register to change the pattern table pointer else where in memory. Smurf Paint n Play uses multicolor mode. As for Charset, none. You can have color data prepared on ROM to upload right to the pattern table.

 

 

 

Thanks, yeah I've seen your mockups and your topic thread, all great stuff. What do you use to make the ROM, flash cart?

 

So only the Char set can do 2 colors per line in Graphics Mode 2 but not the sprites which are only one color always?

 

I use SDCC development kit to make the ROM. I made the tileset and made the screen data with ICVGM. It output the data in C for me to put in my project. I use rle2vram command to put the charset, colorset, and name table. The sprites were done last since I reposition by hand since I used CVSPRITE 2 and didn't know how to use the generated data and place them in VRAM.

 

Yes, the sprites each are 1 colors. 32 sprites display on screen is possible.

  • Like 1

Share this post


Link to post
Share on other sites

The rate of flicker is different for each games. If side scroller, there may be 12 sprites possible on one scanline, then you have to make a game engine that change sprite priorities just in case there would be 12 sprites on a line. If there would be 12 sprites on a line, then the player can see those 12 sprites oppose to 4 sprites if there was no flicker. Of course there's a flag flips if there's a 5th illegal sprites on that line and give the sprite number for the code to catch that if developer prefer to use a routine to change that sprite priority.

Would the memory and CPU savings of Multicolor mode help with flicker matters, like towards a better rate of flicker?

 

From the TI book, it only uses the pattern table to store the data, and the name table. So it reads 4 bit of a byte to determine what color that block is, so 0x1f would be 4x4 pixel black, next to it will be 4x4 pixel white. I haven't played with multi-color mode. You can store multiple state of screen data and write to the vdp register to change the pattern table pointer else where in memory. Smurf Paint n Play uses multicolor mode. As for Charset, none. You can have color data prepared on ROM to upload right to the pattern table.

I thought that was the case, makes sense. Not sure why I fixated on Multicolor mode, I guess I wanted to see what it was good for, multi-cart games maybe? I find it works best with magnified sprites, matches the background better and gives 8X8 sprites something to do. Visually it creates graphics that look like the Bally Astrocade games.

post-29395-0-44756800-1391374448_thumb.png

post-29395-0-30993200-1391374467_thumb.png

post-29395-0-55724200-1391374480_thumb.png

post-29395-0-42379400-1391374500_thumb.png

Share this post


Link to post
Share on other sites

Would the memory and CPU savings of Multicolor mode help with flicker matters, like towards a better rate of flicker?

Your question tells me that you don't seem to have a very good grasp of the ColecoVision's graphic chip and its capabilities and limitations... Not judging, just saying...

Share this post


Link to post
Share on other sites

Your question tells me that you don't seem to have a very good grasp of the ColecoVision's graphic chip and its capabilities and limitations... Not judging, just saying...

Lol, yep, that's what I'm here for, to learn. ^_^ Actually got to ask if you're pissed at me, just curious? It's a cute statement you made but it doesn't really help when I think about it, I would think the fact I'm a novice would be obvious by now.

Edited by BladeJunker

Share this post


Link to post
Share on other sites

Lol, yep, that's what I'm here for, to learn. ^_^

Okay then, allow me to take it from the top and give you a quick crash course about the CV's graphic chip. I'm not an absolute expert on the matter, but I know enough about it to give you valid information to get you properly started.

 

Where graphics are concerned, there are three components to consider under the hood of a ColecoVision console:

 

- The CPU (i.e. the main Z80 processor)

- The VDP (video display processor, a.k.a. the CV graphics chip)

- The video RAM (a.k.a. VRAM)

 

The first thing you need to understand about these three components is that they are somewhat independent from each other and operate almost asynchronously.

 

The VDP's only function is to take the contents of the VRAM and output it to the TV screen, and it performs this job at an endless regular pace, regardless of what the CPU is doing. The only way the programmer can control the VDP's behavior is by setting its registers (which are write-only, if I remember correctly). Aside from setting registers, the CPU has no real control over what the VDP does, and that's what makes programming for the ColecoVision a sort of balancing act, because as the programmer, you want to try to synchronize your game program with what the VDP is doing, to avoid graphic glitches while the game is running.

 

With this said, there are several graphic modes available, namely text mode, graphic mode 1, graphic mode 2 and multi-color mode. The main technical difference between these graphic modes is how the VDP interprets the contents of the VRAM, and nothing more.

 

Keep in mind that VRAM is really just 16K of "external" RAM that you can write to and read from any way you like. Some programmers even store game data in unused portions of VRAM. I say it's "external" RAM because the CPU can only read/write one byte at a time from VRAM, and as such, accessing VRAM is particularly slow, so the programmer has to minimize VRAM access as much as possible. The ColecoVision's 1K of native RAM (which the CPU can work with much faster) is completly distinct from VRAM.

 

I'm not going to go into details about the different graphic modes because it has been discussed at length in this thread already, but you just need to keep in mind that sprites are handled via two areas of VRAM: Sprite patterns and the sprite attribute table. The VDP uses these areas of VRAM to display sprites on the TV screen, over the background tiles. Sprite patterns are really just bytes where 1=solid color and 0=transparent. That's why sprites can only be of one color. However, the sprite attribute table allows you to change the X/Y position, pattern and color of a sprite at any time, and the table can handle up to 32 different sprites simultaneously, which means you can display 32 different sprites on the screen.

 

Sprites can be 8x8 pixels, 16x16 pixels, or 16x16 pixels magnified (they appear as 32x32 on the TV screen). All graphic modes allow sprites to be displayed except for text mode. For any graphic mode, the VDP always works the same way: It reads the data in the sprite attribute table and the sprite patterns and displays the referenced sprites on the screen.

 

Aside from reading/writing to VRAM, the programmer doesn't have any control over what the VDP does with sprites. That's why the 4-sprites-per-scanline limit is such a bummer: On any particular scanline of the TV screen, the VDP will only display the first four sprites defined for that scanline by the sprite attribute table, and will refuse to display the fifth (or sixth, etc.) sprite. That's why the programmer needs to define flicker algorithms, to display large numbers of sprites on the same scanlines in groups of 4 at a time.

 

I hope you now understand the CV's graphic chip a little better, and perhaps you will better understand the previous responses in this thread. :)

  • Like 2

Share this post


Link to post
Share on other sites

Okay then, allow me to take it from the top and give you a quick crash course about the CV's graphic chip. I'm not an absolute expert on the matter, but I know enough about it to give you valid information to get you properly started.

Thanks very much. :)

 

Where graphics are concerned, there are three components to consider under the hood of a ColecoVision console:

 

- The CPU (i.e. the main Z80 processor)

- The VDP (video display processor, a.k.a. the CV graphics chip)

- The video RAM (a.k.a. VRAM)

 

The first thing you need to understand about these three components is that they are somewhat independent from each other and operate almost asynchronously.

 

The VDP's only function is to take the contents of the VRAM and output it to the TV screen, and it performs this job at an endless regular pace, regardless of what the CPU is doing. The only way the programmer can control the VDP's behavior is by setting its registers (which are write-only, if I remember correctly). Aside from setting registers, the CPU has no real control over what the VDP does, and that's what makes programming for the ColecoVision a sort of balancing act, because as the programmer, you want to try to synchronize your game program with what the VDP is doing, to avoid graphic glitches while the game is running.

 

With this said, there are several graphic modes available, namely text mode, graphic mode 1, graphic mode 2 and multi-color mode. The main technical difference between these graphic modes is how the VDP interprets the contents of the VRAM, and nothing more.

 

Keep in mind that VRAM is really just 16K of "external" RAM that you can write to and read from any way you like. Some programmers even store game data in unused portions of VRAM. I say it's "external" RAM because the CPU can only read/write one byte at a time from VRAM, and as such, accessing VRAM is particularly slow, so the programmer has to minimize VRAM access as much as possible. The ColecoVision's 1K of native RAM (which the CPU can work with much faster) is completly distinct from VRAM.

I appreciate the description here, it helped a lot, I am far from a programmer but I get this. Of coarse you could have saved yourself some typing and just said "No, saving VRAM doesn't aid flicker in any way, VRAM is slow so use the 1K of system RAM for flicker matters which is faster" or "The VDP just displays things, its not really an extra CPU.

 

I'm not going to go into details about the different graphic modes because it has been discussed at length in this thread already, but you just need to keep in mind that sprites are handled via two areas of VRAM: Sprite patterns and the sprite attribute table. The VDP uses these areas of VRAM to display sprites on the TV screen, over the background tiles. Sprite patterns are really just bytes where 1=solid color and 0=transparent. That's why sprites can only be of one color. However, the sprite attribute table allows you to change the X/Y position, pattern and color of a sprite at any time, and the table can handle up to 32 different sprites simultaneously, which means you can display 32 different sprites on the screen.

Yeah I think I grasp the numbers, been trying to work out a way to describe how to layer sprites effectively in games to pixel artists. Best analogy so far was cut out shapes of colored paper that don't align or touch vertically.

 

One thing that threw me off is the book description of Multicolor mode, it says its a 64X48 color 'square' display and each square has 4X4 pixels. It's a terminology difference mostly but Square means Tile right? So isn't that more like an effective pixel resolution of 128X96 in practice.

I know its technically described correct as far as display divisions but I think it "under sells" Multicolor mode some since I thought it was 64X48 pixels. So you can see how someone as stupid as me can get confused. ^_^

 

Sprites can be 8x8 pixels, 16x16 pixels, or 16x16 pixels magnified (they appear as 32x32 on the TV screen). All graphic modes allow sprites to be displayed except for text mode. For any graphic mode, the VDP always works the same way: It reads the data in the sprite attribute table and the sprite patterns and displays the referenced sprites on the screen.

 

Aside from reading/writing to VRAM, the programmer doesn't have any control over what the VDP does with sprites. That's why the 4-sprites-per-scanline limit is such a bummer: On any particular scanline of the TV screen, the VDP will only display the first four sprites defined for that scanline by the sprite attribute table, and will refuse to display the fifth (or sixth, etc.) sprite. That's why the programmer needs to define flicker algorithms, to display large numbers of sprites on the same scanlines in groups of 4 at a time.

Yeah I understand the 'all' magnified or not option. I noticed the 4 sprite limit bugs people, Newcoleco called it The Stupid 4 Sprite Limit lol. So pretty much flicker is flicker and it doesn't change no matter what you do, got it. :)

 

I hope you now understand the CV's graphic chip a little better, and perhaps you will better understand the previous responses in this thread. :)

Oh yes it all helps, thank you and to everyone posting. I appreciate all the help. I guess I was just underwhelmed by your idle statement, not trying to be snarky.

Share this post


Link to post
Share on other sites

I appreciate the description here, it helped a lot, I am far from a programmer but I get this. Of course you could have saved yourself some typing and just said "No, saving VRAM doesn't aid flicker in any way, VRAM is slow so use the 1K of system RAM for flicker matters which is faster" or "The VDP just displays things, its not really an extra CPU.

Actually, in a certain way, it IS somewhat like an extra CPU, one that runs in parallel to the main CPU, and is specialized in what it does. You should look at it like a robotic bureaucrat working non-stop in his little corner: The game program initializes the VDP to the desired graphic mode, and from there, the VDP just chugs along, updating the TV screen 60 times per second, and the game program applies subtle changes to VRAM between each screen update. That's essentially the foundation of programming for the ColecoVision.

 

 

Yeah I think I grasp the numbers, been trying to work out a way to describe how to layer sprites effectively in games to pixel artists. Best analogy so far was cut out shapes of colored paper that don't align or touch vertically.

Why shouldn't they touch vertically? I'm not sure I follow...

 

 

One thing that threw me off is the book description of Multicolor mode, it says its a 64X48 color 'square' display and each square has 4X4 pixels. It's a terminology difference mostly but Square means Tile right? So isn't that more like an effective pixel resolution of 128X96 in practice.

I know its technically described correct as far as display divisions but I think it "under sells" Multicolor mode some since I thought it was 64X48 pixels. So you can see how someone as stupid as me can get confused. ^_^

The total resolution offered by the CV is 256 x 192 pixels in graphic modes 1 and 2. Divide both 256 and 192 by 4, and what do you get? ;)

 

Also, a tile is 8x8 pixels in graphic modes 1 and 2, so you could say that a single tile contains 4 "big pixels" in Multicolor mode. But really, that's just confusing for no good reason. The whole point of Multicolor mode is that there is no concept of tiles at all. All you have are 64 x 48 big pixels (1 big pixel = 4x4 TV pixels) and you can set the individual color of each of those big pixels. You can also place sprites over the big pixels. There are two reasons why homebrew programmers don't use Multicolor mode:

 

1) Big pixels don't look very good compared to the crips graphics of graphic modes 1 and 2.

2) The way the big pixels are represented in VRAM is really weird and hard to work with.

 

 

Yeah I understand the 'all' magnified or not option. I noticed the 4 sprite limit bugs people, Newcoleco called it The Stupid 4 Sprite Limit lol. So pretty much flicker is flicker and it doesn't change no matter what you do, got it. :)

The programmer has to code his own flicker algorithm, which is a tedious task, and what makes it even more bothersome is that this algorithm tends to change for each game: You want to optimize the flicker routine as much as possible, and this optimization really depends on what's happening on the screen.

 

 

Oh yes it all helps, thank you and to everyone posting. I appreciate all the help. I guess I was just underwhelmed by your idle statement, not trying to be snarky.

Actually, through my initial remark, I was just setting myself up to deliver my "quick crash course". ;)

  • Like 1

Share this post


Link to post
Share on other sites

Actually, in a certain way, it IS somewhat like an extra CPU, one that runs in parallel to the main CPU, and is specialized in what it does. You should look at it like a robotic bureaucrat working non-stop in his little corner: The game program initializes the VDP to the desired graphic mode, and from there, the VDP just chugs along, updating the TV screen 60 times per second, and the game program applies subtle changes to VRAM between each screen update. That's essentially the foundation of programming for the ColecoVision.

Oh yeah I understood that the VDP processor is a good bit of hardware but I was thinking more along the lines of like you say, its too busy to ask it to do anything else except what it does specifically. Its a shame it isn't more addressable or controllable.

 

Why shouldn't they touch vertically? I'm not sure I follow...

I'm mostly just referring to the balance of layering sprites and the 4 sprites per scanline limit, trying to stagger them from each other so fewer occur per scanline. They can touch for sure but as soon as they pass over each other they occupy there respective scanlines, I guess I was just trying indicate that too much like they were gasoline and fire or something lol. Carefully wording my description on layered sprite construction, it's different than sprites with mutliple colors built in already.

 

It's tricky to describe retro hardware to artists when it comes to limitations, you want them to know its importance but you also don't want to scare them away. For example something that occurs many times with the Nes is pixel art with 4 color graphics popping up because 2-bit color is 4 colors but what is missed over and over again is that one is background or transparent always, I could try to educate them but its just easier if we say "Nes is 3 color graphics, here's how you draw with a 3 color palette. Maybe I'm cynical but ignorance is more dependable than knowledge, I have my limits though, you spell it out completely into the simplest terms for people and they still can't or won't do it, then I hit them with bats. ^_^

 

The total resolution offered by the CV is 256 x 192 pixels in graphic modes 1 and 2. Divide both 256 and 192 by 4, and what do you get? ;)

 

Also, a tile is 8x8 pixels in graphic modes 1 and 2, so you could say that a single tile contains 4 "big pixels" in Multicolor mode. But really, that's just confusing for no good reason. The whole point of Multicolor mode is that there is no concept of tiles at all. All you have are 64 x 48 big pixels (1 big pixel = 4x4 TV pixels) and you can set the individual color of each of those big pixels. You can also place sprites over the big pixels. There are two reasons why homebrew programmers don't use Multicolor mode:

 

1) Big pixels don't look very good compared to the crips graphics of graphic modes 1 and 2.

2) The way the big pixels are represented in VRAM is really weird and hard to work with.

I can appreciate that Squares are not Tiles technically but all an artist wants to know is how many pixels(squares) they can use, so the more simplified or distilled way I can describe a a video mode the better. For example I did my best to distill the Atari 2600 into pixel art terms but still some that read it found it too long even though I treated every word like it was being tattooed onto my back IE. trying to make descriptions shorter.

 

Actually I'm getting confused now. Does each Square contain a 2X2 grid of pixels or 1X1, is it visually 64X48 squares or 128X96 squares? In the Smurf paint game the big pixels look like 4x4 pixels in scale to non-magnified sprite pixels.

 

I can appreciate that Multicolor mode is harder to program for, I will add that to my art guide specifically as a warning. To me its just a canvas to draw on so the scale of pixels don't concern me much, even on a TRS-80 or ZX81 I just try to make graphics as attractive as possible within technical limits. Beyond the tricky VRAM matters I can appreciate how no one likes that mode since its not as crisp but I'm exploring the Coleco as an art medium at the moment so even Text mode interests from an art standpoint, not as varied as the C64 but quite a few options.

 

The programmer has to code his own flicker algorithm, which is a tedious task, and what makes it even more bothersome is that this algorithm tends to change for each game: You want to optimize the flicker routine as much as possible, and this optimization really depends on what's happening on the screen.

Another good point I'll add to my guide. Yeah thought it might be contextual and custom in nature but I guess that is true of flicker on all other platforms. I'll try to emphasize that as an optimization chore hard for the programmer where optimal well planned layouts would be appreciated, for example some idea of how sprites per scanline at one time IE. a Maximum a particular game uses as part of any design document. :)

 

Actually, through my initial remark, I was just setting myself up to deliver my "quick crash course". ;)

Sorry I didn't get that, so many internet comments, some very confusing at times. ;)

Share this post


Link to post
Share on other sites

 

I'm mostly just referring to the balance of layering sprites and the 4 sprites per scanline limit, trying to stagger them from each other so fewer occur per scanline. They can touch for sure but as soon as they pass over each other they occupy there respective scanlines, I guess I was just trying indicate that too much like they were gasoline and fire or something lol. Carefully wording my description on layered sprite construction, it's different than sprites with mutliple colors built in already.

Okay, I get it now. :)

 

 

Actually I'm getting confused now. Does each Square contain a 2X2 grid of pixels or 1X1, is it visually 64X48 squares or 128X96 squares? In the Smurf paint game the big pixels look like 4x4 pixels in scale to non-magnified sprite pixels.

I really don't understand where you get that 128x96 thing, but here's a way to understand what Multicolor mode is:

 

1) Open Microsoft Paint (under Windows).

2) Create a new image.

3) Set the dimensions of the image to 64x48 pixels.

4) Draw anything you like within this canvas using the ColecoVision's 15 colors.

5) Stretch the image by 400% in both directions.

 

The result you get after the stretch is what you get on the TV screen.

Share this post


Link to post
Share on other sites

I really don't understand where you get that 128x96 thing, but here's a way to understand what Multicolor mode is:

It's the description in the TI PDF I was reading, the sentence didn't make sense to me the way it described it. Your term of 1 big pixel = 4 X 4 TV Pixels clinched it for me making the diagram make sense finally. Eureka!

 

It also occurs to me what made my last 4 mockups look so confusing, I had the pixel scales wrong, so very sorry about that. Boy is my face red. The thing is I had scale right before on page 1 but I got all turned around some how, I think I was all focused on the discussion of the particulars and reading the TI VDP guide that I didn't double check my drawings so that was confusing me and the topic at hand. I was at 32x24 and couldn't figure out where my resolution went and why it wasn't lining up with the PDF description of Multicolor mode.

 

Thanks for the varying terms, eventually it gets into my head with some particular terms more so than others. Hope this looks more accurate?

post-29395-0-69276500-1391502460_thumb.png

Share this post


Link to post
Share on other sites

Thanks for the varying terms, eventually it gets into my head with some particular terms more so than others. Hope this looks more accurate?

Yep, that looks correct. :)

 

EDIT: No, wait, it's not correct. You're still using 2x2 pixels for your little characters and objects. Unless those are done with sprites? If those are sprites, you're going over the 4-sprite-per-scanline limit.

 

EDIT #2: I fixed your picture (see below) although I didn't fix the Mario/Luigi lookalikes. I think you get the idea anyway. :)

post-7743-0-32511000-1391521226_thumb.png

Share this post


Link to post
Share on other sites

Personally, I wouldn't bother with the 64X48 mode... although I used it for my YPbPr test program. ;)

You can find it right here: http://atariage.com/forums/topic/153635-component-video-mod-for-colecovision/page-3?do=findComment&comment=1897217

Your own crappy drawing program right on the CV (or emulator).

 

Edit: fixed the linking.

 

Edited by 5-11under

Share this post


Link to post
Share on other sites

Yep, that looks correct. :)

 

EDIT: No, wait, it's not correct. You're still using 2x2 pixels for your little characters and objects. Unless those are done with sprites? If those are sprites, you're going over the 4-sprite-per-scanline limit.

 

EDIT #2: I fixed your picture (see below) although I didn't fix the Mario/Luigi lookalikes. I think you get the idea anyway. :)

Yeah those are sprites, early shot so hadn't really balanced number of sprites per line yet.

 

I like the Multicolor versions you drew(coins especially :) ) but I thought some of the spacing might have worked like the Sun with the background coloring behind it is up high so only a jump would reach, the treasure chest is one black sprite over some background blocks, the enemy sprite would probably be one per floor ideally, the happy hill could be taller I admit so it was as tall as the 2nd floor platform where only a ladder climb would put the player on the same elevation, and the status bar characters are more than 4 sprites but I could make them single color instead.

Still I did go overboard on the character sprites, if I go further with them I'll explode the layers and analize how they line up vertically and try for more staggering, probably 1 player at a time too. Do they look like Mario/Luigi, I was going for more of a Burgertime chef and a busty Princess? ^_^

Share this post


Link to post
Share on other sites

 

Yeah those are sprites, early shot so hadn't really balanced number of sprites per line yet.

 

I like the Multicolor versions you drew(coins especially :) ) but I thought some of the spacing might have worked like the Sun with the background coloring behind it is up high so only a jump would reach, the treasure chest is one black sprite over some background blocks, the enemy sprite would probably be one per floor ideally, the happy hill could be taller I admit so it was as tall as the 2nd floor platform where only a ladder climb would put the player on the same elevation, and the status bar characters are more than 4 sprites but I could make them single color instead.

Well, whatever works for you. :)

 

 

Do they look like Mario/Luigi, I was going for more of a Burgertime chef and a busty Princess? ^_^

I dunno, your princess looks like a guy in a white cloaked tux wearing Mickey Mouse ears. :D

  • Like 3

Share this post


Link to post
Share on other sites

Personally, I wouldn't bother with the 64X48 mode... although I used it for my YPbPr test program. ;)

You can find it right here: http://atariage.com/forums/topic/153635-component-video-mod-for-colecovision/page-3?do=findComment&comment=1897217

Your own crappy drawing program right on the CV (or emulator).

 

Edit: fixed the linking.

 

Heh, people keep saying that but I just keep ignoring them, seriously though it's just testing of graphics, since no one uses Multicolor mode I had to make my own test images in regards to what it looks like and the Smurf game wasn't cutting it being more of an application program. Just seeing what visual potential it holds. Still I can't force anyone to like big pixels, for me whether I'm looking at screen shots of PS4 or Bally Astrocade games I just judge it on its own merits, does this look good for what it is. And I know it looks like I haven't tried Graphic Mode 1 and 2 out based on my postings here but I actually have but I'm still working out the whole 4 sprites per scanline limit and how to balance that requirement without any or much flicker needed.

http://videogamecritic.com/astro.htm

http://videogamecritic.com/channelf.htm

 

My own crappy drawing, I hope you mean that as a general statement lol? Cool thread though, I'd like to get a Atarimax cart and see my artwork on a real Coleco someday but emulation will do for now. I've been looking into some AV modding, right now my Coleco needs a switch rebuild since my picture and sound have gone to shit. Looks like Component has more variables(tuning) than Composite but still very sharp. How goes that venture, is it hard to keep up with orders?

post-29395-0-70888800-1391535832_thumb.png

  • Like 1

Share this post


Link to post
Share on other sites

Does anyone know the games that specifically used 8X8 pixel sprites a lot and or one that used smaller sprites well? Seems like more often one just goes straight to 16x16 to get more pixel resolution and avoid the 4 sprite limit with the added divisions of 8X8 sprites.

 

Fixed up the scale problem I had in the earlier mockups of Multicolor game graphics. Won't help with flicker but I guess games at this res would be smaller at least in the amount of VRAM used at one time and smaller Rom storage needs. I would think the added VRAM complications of Multicolor mode and the use of dynamic background graphics for HUDs wouldn't be an easy task. Is there anyway to break up the scanline zones vertically on the Coleco like they do on the 2600 to optimize background graphics that change in real time?

post-29395-0-60870800-1391712317_thumb.png

post-29395-0-23457200-1391712339_thumb.png

post-29395-0-70925600-1391712357_thumb.png

post-29395-0-45261800-1391712374_thumb.png

  • Like 1

Share this post


Link to post
Share on other sites

Trying Text mode graphics today and I had a few questions about it.

 

I read you can have 256 patterns at 6X8 pixels, so that's a 192x64 pixel Char Set?

 

Does the Colecovision have a built in system character table or do you have to make your own to put into VRAM?

 

It says it stretches 240 to fill the screen width, is that default or can you just center it without stretching?

post-29395-0-94066500-1391818547_thumb.png

post-29395-0-17128200-1391818556_thumb.png

Share this post


Link to post
Share on other sites

8x8 (total, including any "white" space).

There's a built-in font, in case you're not fussy.

Read the tutorial... .

Ah right, sorry, was looking at the wrong PDF. Thanks.

Share this post


Link to post
Share on other sites

In text mode, the last two columns of pixels of every tile is not displayed, which allows the CV to display 40 columns of tiles instead of just 32.

Share this post


Link to post
Share on other sites

In text mode, the last two columns of pixels of every tile is not displayed, which allows the CV to display 40 columns of tiles instead of just 32.

 

Oh, text mode... not 8x8, I guess. Perhaps I'll read the tutorial, then. ;)

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Loading...

  • Recently Browsing   0 members

    No registered users viewing this page.

×
×
  • Create New...