This page is a mirror of Tepples' nesdev forum mirror (URL TBD).
Last updated on Oct-18-2019 Download

Demo: Tall Pixel

Demo: Tall Pixel
by on (#53808)
In the process of developing a card-matching game, I have come up with several proof-of-concept demos. This one is called Tall Pixel. It demonstrates a way to stretch still images vertically by a factor of 3/2, using mixed $2006/$2005 writes and timed code, so that the CHR data for your cut scenes takes 33% less space. Tested on FCEU Karmic and on an NTSC NES + PowerPak.

Tall Pixel (NTSC version)
Download NROM binary and CC65+Python source

by on (#53809)
Interesting. It probably looks really good on hardware (with my monitor's refresh rate the frame blending isn't perfect).

I don't know if many people are having enough CHR space problems to justify a complex solution like this. Complex because it doesn't look as good with refresh rates other than 60 Hz, and uses timed code specific to NTSC consoles. If it was possible to make it work in PAL or NTSC automatically it would be great.

It is an interesting concept though, and the test screen looks very good. The frame blending created a very pleasing anti-aliasing effect (I know the font itself is anti-aliased, I'm not talking about this).

What's up with the top half of the "l" in "Pixel"? Why's it pink? I know it's a sprite, but why did you make it that color?

by on (#53810)
tokumaru wrote:
I don't know if many people are having enough CHR space problems to justify a complex solution like this.

I am. The game's deluxe version will have an opening cut scene, but the CHR RAM on its SNROM board has only 6.5 KiB of CHR RAM left after subtracting 96 tiles for text glyphs. I can possibly get it down to 4 or 5 KiB in the ROM using something like the Codemasters codec, but I still need to decompress it for display.

Quote:
Complex because it doesn't look as good with refresh rates other than 60 Hz

As I wrote in the README, I don't have a 50 Hz NES to test with.

Quote:
and uses timed code specific to NTSC consoles. If it was possible to make it work in PAL or NTSC automatically it would be great.

That would be a matter of detecting the PAL NES at boot time and switch to the loops designed for 341/3.2 cycle operation. I can remember Dwedit saying Codemasters games do that, but they fail on Dendy which has the same CPU:PPU ratio as NTSC but more scanlines per frame. So to be compatible with all three variants in one program, we'd need to check for the frame period being close to 312*341/3.2, that is, 33200 to 33300 CPU cycles. This way both 262*341/3 (NTSC) and 312*341/3 (Dendy) are detected as 341/3 systems.

Quote:
What's up with the top half of the "l" in "Pixel"? Why's it pink?

Image
In a real game, the pink part would be drawn either with the behind bit turned on or in a color matching the backdrop.

by on (#53816)
tepples wrote:
I can possibly get it down to 4 or 5 KiB in the ROM using something like the Codemasters codec, but I still need to decompress it for display.

You know, I tried to implement the variant of it we talked about (more compact color definitions, avoiding some redundant bits, etc). Both encoder (C) and decoder (6502) work fine, but I wasn't able to make the encoder find the optimal block lengths. I used a set of tiles from Bee52 and the result of my encoder was always larger than what their encoder managed to do. I you want to help me out with the encoder we might be able to come up with a good tile compression everyone can use. This is a subject for another thread though, I don't wanna ruin this one.

Quote:
As I wrote in the README, I don't have a 50 Hz NES to test with.

I meant emulators running on computers whose monitors refresh at frequencies other than 60 Hz. In these cases the effect doesn't look so good, and many people use 75 or 85 Hz as their refresh rate, and many people play NES games on their computers. I'm just saying, as I do believe that if we have to favor the console or emulators we should definitely pick the console. We should avoid having to make that choice, but if there's no other way...

Quote:
That would be a matter of detecting the PAL NES at boot time and switch to the loops designed for 341/3.2 cycle operation. I can remember Dwedit saying Codemasters games do that, but they fail on Dendy

Isn't supporting the Dendy like worrying about how the plethora of Famiclones will handle your software? I'm not sure if the Dendy is so noteworthy for us to care specially about it or if it should be considered just another Famiclone which is inaccurate and we don't care about. Do many rusians still have their Dendy's? Wouldn't retro gamers be interested in getting real NES consoles now?

Quote:
Image

U R FUNEH!

Quote:
In a real game, the pink part would be drawn either with the behind bit turned on or in a color matching the backdrop.

Yeah, I was asking why it isn't so in the demo. I'll assume you were using a flashy color for debug purposes and ended up not changing that before releasing this demo and I'll not ask about it again, OK?

by on (#53861)
It's a neat idea. I've tried something similar, by repeating each line X times. Even stretching it a lot looks pretty good with fonts, but a 1/3rd scaling like this would be interesting to see with some detailed graphics.

by on (#53869)
Image
should look like
Image

by on (#53879)
Cool idea, looks great with my notebook's LCD screen, but will probably look crappy flickering on a real TV like Batman's intro.

by on (#53895)
Bregalad wrote:
will probably look crappy flickering on a real TV like Batman's intro.

I haven't checked, but this effect is much more subtle than the title screen in Batman. I expect it to look good, even if you can notice it's flickering a bit.