Demo: Tall Pixel
Moderator: Moderators
Demo: Tall Pixel
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
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/)
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/)
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?
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?
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.tokumaru wrote:I don't know if many people are having enough CHR space problems to justify a complex solution like this.
As I wrote in the README, I don't have a 50 Hz NES to test with.Complex because it doesn't look as good with refresh rates other than 60 Hz
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.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's sprite 0.What's up with the top half of the "l" in "Pixel"? Why's it pink?
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
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.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.
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...As I wrote in the README, I don't have a 50 Hz NES to test with.
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?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
U R FUNEH!
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?In a real game, the pink part would be drawn either with the behind bit turned on or in a color matching the backdrop.
Re: Demo: Tall Pixel
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.
Re: Demo: Tall Pixel
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!
https://www.patreon.com/bitinkstudios <- Support me on Patreon!
Re: Demo: Tall Pixel
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.