SpritesMind.Net

One of the better things the Atari ST had was the ability to DMA the palette during the horizontal blank. So while you had only 16 colors, you could use a different set of 16 colors for every line. You might look for ST graphics tools designed to generate 16 color images along with palette entries for each line.

By the way Chilly Willy have you tried the interlace mode to make the resolution 320x448 and make the rgb lines less visible for better quality?
If it works it promises the moon to us.

I made few tests but sgdk seems to be not "interlace-ready" yet.
I added a partial support to sgdk but it works bad.
I couldn't make per line horizontal scroll (which the rgb lines so need).
It moves 2 pixel lines minimum after my "interlace improvements".

greatkreator wrote:By the way Chilly Willy have you tried the interlace mode to make the resolution 320x448 and make the rgb lines less visible for better quality?
If it works it promises the moon to us.

I made few tests but sgdk seems to be not "interlace-ready" yet.
I added a partial support to sgdk but it works bad.
I couldn't make per line horizontal scroll (which the rgb lines so need).
It moves 2 pixel lines minimum after my "interlace improvements".

Hmm - that should reduce the vertical artifacts... I'll have to give it a try. Remember there are two interlace modes: one where it simply repeats the same lines in each field, and one that doubles the lines per cell and shows half in each field.

The double height cells would make for a more detailed display, but would take twice the ram for a bitmap.

Actually doubled RAM is not a problem.
You can use not full screen.
For example border-lines in the top and the bottom is OK.
But you get almost 512 colors per each 1.5 pixels with satisfactory quality.
It would be really impressive and useful.
If it works I will definitely use it in my games.

greatkreator wrote:Actually doubled RAM is not a problem.
You can use not full screen.
For example border-lines in the top and the bottom is OK.
But you get almost 512 colors per each 1.5 pixels with satisfactory quality.
It would be really impressive and useful.
If it works I will definitely use it in my games.

Reducing the size of the display reduces the memory usage, and many games don't use the full display, but you're still using twice the memory you would have otherwise used. That means half the speed drawing the same size display. but if it improves the display enough to be useful, that may be what it takes. I'm considering using this type of display myself, which is why I did the demo.

I am looking forward to see your results Chilly Willy using the interlace mode. Will it be bmpdemo number five?

When you will have done it tell me please. It is very interesting.
As for me even to have only a static image with 512 colors almost per each pixel moves everything to the "next level".

Your previous rgb-lined and rgb-dotted demos are almost satisfactory for usage. If the interlace mode reduces the visible lines/dots as I said I will use it to amaze people who will play my games. At least as static images. It would be enough as for me.

greatkreator wrote:I am looking forward to see your results Chilly Willy using the interlace mode. Will it be bmpdemo number five?

When you will have done it tell me please. It is very interesting.
As for me even to have only a static image with 512 colors almost per each pixel moves everything to the "next level".

Your previous rgb-lined and rgb-dotted demos are almost satisfactory for usage. If the interlace mode reduces the visible lines/dots as I said I will use it to amaze people who will play my games. At least as static images. It would be enough as for me.

It IS number five... and here it is: http://www.mediafire.com/?l43jp39v1683wdb

The results look REALLY good... on real hardware. On my LCD display, the picture is a little dim and the interlace flicker is fairly noticeable. On my CRT, the picture is brighter and the interlace not as bad. The resolution is noticeably sharper and the colors noticeably better.

The problem is emulators - the even field shows the r/b pixels, and the odd field shows the b/g pixels. If your machine isn't fast enough to do 100% speed, the frame skip will give you random cycling through the colors. It's not stable on slow systems... like mine. If I force the frame skip to 1, it's stable, but with just two of the three colors.

The demo works like this:
The display mode is set for 320x448 interlace mode 2 (cells are 8x16). I use a 288x192 bitmap (actually 384 lines tall, but every other line is only part of the colors) stored in the vram at $0000 to $D7FF (36x24 cells). The Sprite Attribute Table is at $D800, the Horizontal Scroll Table is at $DC00, and all the layer name tables are at $E000. The scroll layer size is 128x32, with the first 40 columns being the r/b palette pattern numbers for the bitmap in layer B, the next 40 being the b/g palette pattern numbers, and the next 40 are for layer A in case we want to use layer A. The horizontal scroll for layer B is changed in the vertical blank between 0 and 320 pixels, based on whether the field is even or odd. The layer A hscroll is always 640.

The routine goes through the BMP and draws all the r/b pixels into the even field, and then goes through the BMP again drawing b/g pixels into the odd field. Interlace virtually overlaps the two fields, making for better color, and twice the vertical resolution. As I mentioned, on real hardware on a CRT, it really looks good.

If you have a suggestion on making emulators look better, I'd be happy to hear it. I'll also think about this a bit more as well. Maybe I'll come up with something better.

You did it. It is very impressive.
Sega has never shown such a picture before the day you have done it.

I think it is very likely that emulator won't be fixed ever for the problem.
The only likely way to "fix" demo to modify emulator to meet your demo needs.

Thank you very much Chilly Willy you did a great work.

greatkreator wrote:You did it. It is very impressive.
Sega has never shown such a picture before the day you have done it.

I think it is very likely that emulator won't be fixed ever for the problem.
The only likely way to "fix" demo to modify emulator to meet your demo needs.

Thank you very much Chilly Willy you did a great work.

You're welcome.

The issue is that the different colors are in different fields. In the older demos, the different colors were in different lines of the same field. That made them farther apart for worse resolution and color, but stable in emulators regardless of how slow they were since it was all in one field/frame. For this new method to work well in an emulator, it would need to deal with one whole frame (2 fields, or 30 Hz) as the fundamental unit of the emulated machine rather than one field (60 Hz) when interlace is enabled. That would make the effect stable regardless of speed or frame skip.

Anywho, some thoughts on this method of display:
For games that use vertical rendering (raycast 2.5D and voxels), the bitmap should probably use vertically oriented columns of tiles instead of horizontal rows. If you look at my code, the patterns go like this:

0 1 2 3 4 5 ... 35
36 37 38 ... 71
...

The problem there is a slowdown every time you move from one row of tiles to the next as you need to add enough to move across a line of tiles. It would be MUCH quicker (on a column based game) to do it like this:

0 24 48 ...
1 25 49 ...
2 ...
3 ...
...

Then as you draw your columns, you never need worry about crossing tiles. The horizontal orientation would be faster for polygon based games where polys fill/texture across lines instead of columns. So you want to tailor how you orient the bitmap tiles based on the primary method used to render the display.

If you put the screen in H32 mode, make the display 192 tall, and use an HINT to turn off the display after the last line, you can transfer enough tiles via DMA to update the display at 20 Hz (on NTSC). I'd make the main part of the display 256x160 (effectively 128x160 with this display mode), and use a 32 line status bar which could use "normal" tile display instead of being a bitmap. 128x160x2 = 40960 bytes. If you switch off the display at line 192, the cycles available for DMA = 192*16 + (262-192)*161 = 14342, which x 3 = 43026. So three fields to update the display. Hmm, might look better if it were updated every four fields to avoid color artifacts. That would also not use all the CPU time on the MD for DMA.

It looks acceptable only in NTSC composhit.
In RGB it is a flickery mess, and in PAL composhit you get funky color artifacts, like blue lines 5 pixels apart from each other.

Yes you are right TmEE it does work acceptable only in NTSC through composite.

It seems mega drive tries hard to reject any each pixel graphics.

By the way Chilly Willy have you been able to make each pixel horizontal scroll or not?
I see that you made it with r/b g/b lines. Isn't it possible just to use 3 rgb lines as in the first demo?

greatkreator wrote:Yes you are right TmEE it does work acceptable only in NTSC through composite.

It seems mega drive tries hard to reject any each pixel graphics.

By the way Chilly Willy have you been able to make each pixel horizontal scroll or not?
I see that you made it with r/b g/b lines. Isn't it possible just to use 3 rgb lines as in the first demo?

Using 3 lines for r/g/b would again reduce vertical resolution. Interlaced wouldn't be as bad as the non-laced version of three line r/g/b, but not as good as two line. I wonder if that would look better in PAL and RGB... I'll make (yet another) demo so we can see how that looks.

Please make it and I will test it on different hardware that I have.

By the way Chilly Willy you could try to show r/g/b values not as 0x000->0x008->0x00f, 0x000->0x080->0x0f0, 0x000->0x800->0xf00.
but
0x000->0x008->0x00f->0x88f->0xfff,
0x000->0x080->0x0f0->0x8f8->0xfff,
0x000->0x800->0xf00->0xf88->0xfff.
It could make the image brighter.

Why you don't use dithered images? It should remove the uniform areas of the same colors.

greatkreator wrote:Please make it and I will test it on different hardware that I have.

By the way Chilly Willy you could try to show r/g/b values not as 0x000->0x008->0x00f, 0x000->0x080->0x0f0, 0x000->0x800->0xf00.
but
0x000->0x008->0x00f->0x88f->0xfff,
0x000->0x080->0x0f0->0x8f8->0xfff,
0x000->0x800->0xf00->0xf88->0xfff.
It could make the image brighter.

Why you don't use dithered images? It should remove the uniform areas of the same colors.

Both the palette values and the use of dithering has nothing at all to do with my demos. I merely provide the framework, and if you think changing something will make it look better, it's something you can change. I HAVE thought of changing the palette to improve the look, but I'm not going to spend days tweaking colors for a demo. Dithering actually works against the method as dithering is all about trading spacial resolution for color fidelity. Not to mention there are several different dithering methods... I leave that as well to someone else.