Yeah I loved that episode, great gimmick and nice story arch with a great new character in Chevy's brother. Although the gameplay was spoof I thought it had promise compared to Fable and other so called free form games. I thought all the sprites captured and distilled the actors well except for the Brita sprite which looked like a linebacker imo.

I thought I'd use them to test my double wide (C64/Atari) pixeling skills. Some things changed but I managed to get most of the details into half horizontal resolution.


Great transposing from the episode btw, I know what a pain it can be to draw things with weak source materials.

Well I'm not done looking into text related rendering but I can at least discuss the basics to begin with.

The majority of text rendering on the 2600 is Player object based or to be more specific heavy multiplexing of Player0 & Player1 and the application of what is called the Venetian Blind display kernel. So its fair to say you're looking at a very prerendered setup for text display like single words, 2X1 letter clusters, and tile constructed fonts.
The Venetian blind methods primary element in function is the memory nybble that exists in the 2 Player objects which have an upper and lower nybble for every 4 bits wide. Basically it shifts both 4 bit wide segments of the Player object up & down per scanline with some flicker, it has the benefit of being fast to render but also that even with flicker it keeps a solid consistent appearance. The main drawback of this is that a 1-line render will look like a 2 line-render or losing half your visible height resolution despite the benefits.
Also this method has a higher cycle cost than a normal display kernel so those costs have to be considered. How much cycle cost really depends on the design of the game you intend but one thing is certain is that you should really decide upon a maximum character amount as the more you push for more characters the less you can do overall in terms of effects and other display trimmings.

Here's a neat kernel that managed 32 characters with a 3 pixel wide font at 2 characters per Player object. That's the big thing to get the maximum number of characters to display.
http://www.atariage.com/forums/topic/180632-32-character-text-display/page__st__25

I've been aiming for less characters but larger character fonts for better legibility but no one seems to interested in that yet. Mostly I've been pursuing what I would call the standardized CRT to text approach which is best described in this article. I can't see the images in the page but maybe you can.
http://www.gamasutra.com/view/feature/130498/crossplatform_user_interface_.php?print=1
I subscribe to the standards set in this article when it comes to retro gaming as we went through many games with fancy fonts that were hard to read on our game consoles over the years. I was actually quite pleased when I started seeing DS games with big letters that compensated for the distance I hold the unit away from myself and I feel the same way about font to CRT clarity issues.

*Actually that issue with Dead Rising on a SD-TV being unreadable is inexcusable since the level of memory and HUD to font scale options possible today allow not just SD support but also help for people with varying levels of eyesight quality. I don't want to rant but for crying out loud don't neglect the deaf or people with poor eyesight who play video games ijs.

Format:

Its not too difficult to produce content at this standard as you just use a 1:1 pixel unit to compose the image, strip out every second horizontal line, and then offset 50% of the width either up or down the for every Player object sprite block.

I mention 1-line kernel rendering that looks like 2-line but this also progresses lower as well with 2-line rendering looking like 4-line rendering which is what I'd consider the limit of this technique except for large screen filling text or a coarse resolution bitmap.

Now this halving of the vertical resolution is not default since you can actually use the venetian blind rendering with 1-line rendering which people have applied to game sprites, its mostly that in large doses of sprite multiplexing the skipping of lines helps overall with timing and CPU demands of pushing beyond 2 Player objects. So if you were doing a 1 on 1 competitive game 2 sprites with 1-line venetian blind rendering would be mostly practical while a sports game with teams of players or in the case of text with its multiple characters would more the likely need to skip lines or even thicken the scanlines to cope.

For a little background on this here's an interview with the inventor of Venetian Blind rendering.
http://www.digitpress.com/library/interviews/interview_bob_whitehead.html

@BladeJunker: Today, I pixeled your concept canvas of the SMW3 mockup (including all test tiles ) into MINIPAINT. Some elements had to be re-arranged horizontally (160 pixels horizontal resolution in MP instead of 176 pixels in the concept canvas). It took me roughly 2 hours:


(download)

Very cool and authentic to the original. Yeah I get lazy and leave a lot of construction and guide lines all over the place. Using the updated colors has been challenging but I'm finding some good compromises. I'm familiar with sprite color limits but I've never worked under a shared color limit however its interesting in the results I get.

I tried MINIPAINT through Vice since I don't have means to transfer the program onto my VIC yet. Under your download page do you think you could add a Help text file with the controls listed as I'm kind of poking keys to find functions and I want to load the PRG file but I don't know how?

I guess there isn't a mouse for the VIC as far as what I read here? I have done joystick drawing on my C64 so its not completely foreign to me.
http://sleepingelephant.com/ipw-web/bulletin/bb/viewtopic.php?t=4626&sid=87ecec713b47d3affcb4e1dc40454d56

Quote from: BladeJunker

Do you think the 3:2 pixel unit is a fairly accurate representation of a VIC-20 display, it was as close as I could get for a hardware external concept canvas?

It's about right for NTSC. On a PAL VIC-20, the pixels are slightly more elongated, 5:3 was the best approximation I could find as ratio of small integers. The 'standard' setting of VICE, 2:1, is totally off.

That's what I thought too that 2:1 was just not reflecting what I was seeing on an actual VIC-20. I'll make some adjustments to my PAL canvases to 5:3, I'm not in a PAL region so I couldn't even guess at shape accuracy, although at AtariAge one helpful person did mention a shorter pixel height and another mentioned the Denial forum as the best place to ask.

One other point about the palette in your mock-up of the Colour Test program: Light Red is too dark, it should have a similar brightness as its upper neighbour, Light Orange. On an NTSC VIC-20, Light Orange, Light Red and Light Purple are quite difficult to tell from each other, on a PAL VIC-20 they are easier differentiated.

These are two exemplary palettes we came up with after a longer discussion in Denial:

-- NTSC (darkatx's VIC-20) ------- PAL (tokra's VC-20) ----


I used digital camera shots from CRTs with the VIC-20 running the Colour Test program. Then I took the averages of all RGB values of the bigger colour patches in the middle of the display, and finally stretched the result for maximum contrast. In both cases, only little to no clipping of RGB values occured in the end result - the saturation setting of the monitor/camera combination was just about right.

Of course, the viewers output device will also lead to a different result again, but that's the way it is.

Yeah I have not been happy with the color palette I found through Wikipedia at all, so thank you for this post of colors that are much, much closer to the real thing. Been meaning to sign up with Denial and ask around but I've been catch up with other things. Perhaps the Wiki source tried to average the 2 palettes out to one inaccurate result? 

Looks like PAL users got the better color palette, nicer saturation and separation of colors. This reminds me of 2600 PAL to NTSC color differences as this will require color conversion for graphics as a simple swap won't cut it for most graphics. Damn I really like the PAL version, I keep gravitating towards it and want to use it despite being in a NTSC region.

Oh sure the display used will effect the look of the colors and any settings it offers but this palette is much closer and is exactly what I was looking for.

Thanks again for your input as I want to get this guide as accurate as possible.  Well I guess I'll get started making adjustments.