Jump to content
IGNORED

My try for a 96x128 bitmap with 4 colors...


DrWho198

Recommended Posts

I just wanted to share this to hear what you guys think of this code. After seeing the 'Dark Mage' game I had an idea of adapting the kernel to be able to show Multi-color images with a resolution of 96x128. The kernel had a few problems, one of which was the fact that the sprites did not connect perfectly. I tried fixing this using the HMOVE timing anomalies. But the second problem is that the sprites are already interleaved to create a monochrome image. This causes the need of 4 frames to show a 4 color image... The result? A lot of flickering.

I don't have the needed hardware to test the code on a real a2600. Maybe someone else can give it a try and tell me how it looks, or ideally show me a picture or movie :) .

I wouldn't be surprised if it doesn't work at all since I'm an inexperienced programmer.

Anyway, here is the rom, any comments or suggestions are welcome.

 

PS: I did not optimize the code or try to center te image yet... maybe later.

And like all games who use flickering I advice to turn on Phosphoring in Stella by pressing 'ALT-P'

post-37130-0-37434700-1435831423_thumb.png

 

Small update:

I made a small change in the order that the frames are shown. This makes the flickering softer to the eyes. It might even make it acceptable on real hardware!

96x128x4b.BIN

 

Old binaries:

 

 

Edited by DrWho198
  • Like 2
Link to comment
Share on other sites

Thanks, I didn't optimize the picture much. I think I could have gotten more detail in Elliot with some work.

When I choose the picture I thought I could do better than this:

 

s_ET_1.png

 

I wanted my first demo to be a titlescreen mock-up.

And what better titlescreen to improve than the most famous atari game. But the flickering in the first binary that i send was demotivating me. So I threw it on here as it is to see if someone could give me pointers to what could be done to make it acceptable to the magority of people. A lot can be done with 4 colors if chosen correctly. And it fits easaly in a 4k rom with space to spare.

Edited by DrWho198
Link to comment
Share on other sites

Not wishing to bump my thread for no reason.

But does anyone know how many frames chetiry uses to build up the title image?

And looking at images of the titlescreen it seems like they were able to push out a full 96 pixel line of sprites within 1 frame, am I right?

If so, then I have a very long way to go! :-D

Link to comment
Share on other sites

@thomas: thanks for the pointers. I'm probably going to look at it again in a few days. You tell me to alternate the color line. But that would not give me the liberty to set every pixel to one if the 4 mixed colors does it? Unless there is a way to plot out a full 96pixel line in 1 frame.

 

I don't know code is out there. But I hafe yet to see a rom that can do this. Or am I wrong?

 

Sent from my MEDION X4701 using Tapatalk

Link to comment
Share on other sites

The ROM you posted only has two colors. And it already flickers a lot.

 

Your current pattern for a 2x2 pixel matrix over 4 frames is

 

#1  #2  #3  #4
A.  B.  .A  .B
.A  .B  A.  B.

I suggest:

#1  #2  #3  #4
A.  .B  B.  .A  
.B  A.  .A  B.
or

#1  #2  #3  #4
A.  .A  B.  .B
.B  B.  .A  A.
So you always alternate the pixel displayed. This should reduce flicker.

 

Alternatively, you could combine two vertical pixel. Then you could really mix 4 colors at the cost of less vertical resolution.

 

There are lot of threads about flickering colors. Search for e.g. "chronocolor" or "chronocolour"

Link to comment
Share on other sites

@Thomas: I had a quick look at the files again, as far as I can see your suggested sequence equals the first rom I posted. Check the spoiler box in the first post. I can't test it on real hardware but in stella if flickers a lot more. The Lines are more continues in that sequence, but the colors flicker harder. You could compare them.

 

Here is one in which I offer up vertical resolution... But it only uses 2 frames so it will not give a visible flicker when displayed with phosphoring.

The file: 96x128x4c.BIN

the question is, what would be best?

You can easaly see some loss of detail. Although in this mock-up the loss of detail isn't that important to the global image. But I'm still wondering what it would look like on a CRT.

 

Here is a gif that shows the difference. its not fast enough to show reality, but it does give you a good idea:

post-37130-0-18575100-1436180821_thumb.gif

without phosphoring:

post-37130-0-55189500-1436183265_thumb.gif

 

And here it is slowed down:

post-37130-0-47067800-1436183270_thumb.gif

Edited by DrWho198
Link to comment
Share on other sites

Here's a 48x128 using Chronocolour with 8 colours, so to speak. Dithered and changing R/G/B every scanline.

This is still one of the best demos using large colour sprite, IMHO!

 

 

Here's a search of the [stella] list for some of the discussions on this.

http://www.biglist.com/cgi-bin/wilma/wilma_glimpse/stella?query=chronocolour&Search=Search&errors=0&maxfiles=50&maxlines=10&.cgifields=lineonly&.cgifields=filelist&.cgifields=case&.cgifields=partial&.cgifields=restricttofiles

Also attached, my effort (from over a decade ago now - gosh how time flies) of an ICC 96x128 image.

 

mario2.bin

genius.bin

  • Like 2
Link to comment
Share on other sites

@Andrew:

The image that you wanted to show used 3 channels. I don't think the refresh rate would be fast enough to get the 3 channels shown with a width of 96 pixels.

The problem is that you can not show a line of 96 pixels within 1 frame. At least not as far as I know. Because of this you already create black area's in 1 out of 2 frames.

The Original 48x128 demo used 3 frames to shift the channels in each others place. But if you multiply the 3 frames by the 2 frames you needed to double the size, then it stretches the frames too far away to visually mix the colors. Resulting in flicker.

That's why I only want to use 2 channels. This would result in 2(channels) * 2(48pixels*2) equaling in a 4 frame total. Which would only be 1 frame more then the 3 frames used in the 48x128 demo.

What Thomas suggests seems logical to switch the color of the frame every scanline. Because like in the 48x128 demo, your eyes will mix the 2 colors which are close together. But personally I expect it to fail in this case. Since the 2 colors are not close together because of the way the sprites are ordered. But I'll give it a try and see the result. Part of this thread is a quest for the best way to show a 2 channel 96x128 image and to see how far you can go.

 

The chetiry game is a bit of a riddle to me. I think that the footage that you see online is rendered with phosphoring settings. Since they don't shift the colors it would create a seemingly stable picture. But since the rom is not available, there is no way for me to know for sure. I like the effect, but I'm not a fan of it since you will always see banding and you don't have perfect control over what pixel color occupies which pixel.

Edited by DrWho198
Link to comment
Share on other sites

@Andrew:

The image that you wanted to show used 3 channels. I don't think the refresh rate would be fast enough to get the 3 channels shown with a width of 96 pixels.

The problem is that you can not show a line of 96 pixels within 1 frame. At least not as far as I know. Because of this you already create black area's in 1 out of 2 frames.

The Original 48x128 demo used 3 frames to shift the channels in each others place. But if you multiply the 3 frames by the 2 frames you needed to double the size, then it stretches the frames too far away to visually mix the colors. Resulting in flicker.

That's why I only want to use 2 channels. This would result in 2(channels) * 2(48pixels*2) equaling in a 4 frame total. Which would only be 1 frame more then the 3 frames used in the 48x128 demo.

What Thomas suggests seems logical to switch the color of the frame every scanline. Because like in the 48x128 demo, your eyes will mix the 2 colors which are close together. But personally I expect it to fail in this case. Since the 2 colors are not close together because of the way the sprites are ordered. But I'll give it a try and see the result. Part of this thread is a quest for the best way to show a 2 channel 96x128 image and to see how far you can go.

 

The chetiry game is a bit of a riddle to me. I think that the footage that you see online is rendered with phosphoring settings. Since they don't shift the colors it would create a seemingly stable picture. But since the rom is not available, there is no way for me to know for sure. I like the effect, but I'm not a fan of it since you will always see banding and you don't have perfect control over what pixel color occupies which pixel.

 

You are right in your analysis of the "black areas" with a 96 x 128 image, and so this particular format poses challenges. However, I think the 3-frame 'rolling' colour 48x128 image is beautiful. I just put two side-by side and yes it flickers terribly. I did some experiments with 'full-screen' colour images using PF graphics, so only 40 pixels wide. This did work, but with terribly low resolution. Finally, a bit of advice - if you are using just 4 colours (2 channels) then the dithering you use will be important (IMHO). I found it made a huge difference to the 3 channel results. From memory (not totally sure) I first separated each channel, and then individually floyd-steinberg dithered these, then recombined ABCABC format and then BCABCA and then CABCAB to give 3 frames containing merged RGB data which, when displayed one after the other, "rolled" the colours. So to do the same thing, a bit more difficult because you can't individually separate out the R/G/B planes first, and then dither. So you have to dither/colour reduce in one operation. That is, reduce original to 4-colour and select the dither as a part of that process. Whereas I first separated each plane (8-bits each) and then dithered each down to a single colour. Is that how I did it? I think so, but wouldn't swear on it. So long ago.

 

As an experiment, which wouldn't work for real stuff, but just an idea -- separate an image to 3 planes (R/G/B) then discard one of the planes (OR combine with one of the others), giving two 8-bit planes (R and B or R and G or B and G or RB and G or R and BG or RG and B). Then colour-reduce to single-colour with floyd-steinberg dithering giving two 1-colour planes, then combine those together using alternate scaliness from each giving two merged colour planes in the format ABABAB and BABABA and finally when you're displaying, vary the colours on alternate scaliness, and on successive frames.

 

Happy coding!

Link to comment
Share on other sites

I'm just a beginner when it comes to atari programming. So right now I'm having trouble with updating the sprites at just the right time. The code I started from didn't allow me to add color changing code in between scanlines. So I'm now working on new code... But sadly this means I'll have to figure out the right timings myself. It might take a while.

I agree that the 48x128 image looks beautiful, but I doubt this will work with my sprite ordering since in a single frame my sprites are not located above each other. But that's just my guess, I will know for sure if I manage to write code that can do this. In other words, replicate the chetiry code. I think they used the same sprite ordering as I am trying to use, but they might as well used the ordering you did in your attempt to make a 96x128 3 channel image.

Link to comment
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.
Note: Your post will require moderator approval before it will be visible.

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...