Demo: Tall Pixel

Discuss technical or other issues relating to programming the Nintendo Entertainment System, Famicom, or compatible systems. See the NESdev wiki for more information.

Moderator: Moderators

Post Reply
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Demo: Tall Pixel

Post by tepples »

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
Last edited by tepples on Thu Jan 26, 2023 10:25 am, edited 1 time in total.
Reason: Change scheme of download link to reflect a change in behavior in Firefox 93 (https://blog.mozilla.org/security/2021/10/05/firefox-93-protects-against-insecure-downloads/)
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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?
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

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.
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.
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.
What's up with the top half of the "l" in "Pixel"? Why's it pink?
That's sprite 0.
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.

EDIT: fix broken image link
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
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...
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?
Image
U R FUNEH!
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?
User avatar
Memblers
Site Admin
Posts: 4044
Joined: Mon Sep 20, 2004 6:04 am
Location: Indianapolis
Contact:

Post by Memblers »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Post by tepples »

Image
should look like
Image
User avatar
Bregalad
Posts: 8056
Joined: Fri Nov 12, 2004 2:49 pm
Location: Divonne-les-bains, France

Post by Bregalad »

Cool idea, looks great with my notebook's LCD screen, but will probably look crappy flickering on a real TV like Batman's intro.
Useless, lumbering half-wits don't scare us.
User avatar
tokumaru
Posts: 12427
Joined: Sat Feb 12, 2005 9:43 pm
Location: Rio de Janeiro - Brazil

Post by tokumaru »

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.
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Demo: Tall Pixel

Post by tepples »

Tall Pixel for Super NES is also available. This uses the S-PPU's interlaced mode to make 1-and-2 vs. 2-and-1 more stable.
User avatar
nesrocks
Posts: 563
Joined: Thu Aug 13, 2015 4:40 pm
Location: Rio de Janeiro - Brazil
Contact:

Re: Demo: Tall Pixel

Post by nesrocks »

The original NES version's link doesn't seem to work for me right now.
https://twitter.com/bitinkstudios <- Follow me on twitter! Thanks!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
tepples
Posts: 22708
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Demo: Tall Pixel

Post by tepples »

When I posted the original topic, the forum was at http://nesdev.parodius.com/bbs, under the scheme HTTP, not HTTPS. Since then, the forum has moved to https://forums.nesdev.org, under the scheme HTTPS, and Firefox 93 released in October 2021 changed download behavior to add a roadblock when a document on HTTPS links to a downloadable file delivered through HTTP.
Post Reply