144p Test Suite (was: STN torture test)

Discussion of programming and development for the original Game Boy and Game Boy Color.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

144p Test Suite (was: STN torture test)

Post by tepples »

This ROM was produced during early development of a Game Boy port of Artemio Urbina's 240p Test Suite, which I'd previously ported to NES. Techniques demonstrated:
  • Fading out the IPL logo
  • Drawing text in a variable width font (VWF), also called proportional font
  • Copying tile data to VRAM during horizontal blanking
  • Bank switching background tiles at line 72 using a STAT IRQ
  • Drawing half of a character as background and the other as flipped sprites
  • Ease-in, ease-out, and overscroll bounce for window
  • Making an excuse to skip leg day
  • No exceptions in BGB
The effect looks great on a Super Game Boy, Game Boy Color, or PC based emulator. On GBC or GBA, press Left+B to hide miscoloration of flipped sprites. But it's a smearfest on a Game Boy Pocket, with these analog artifacts:
  • Vertical smearing proportional to each pixel column's average gray level. This appears to be inherent in passive matrix super-twisted nematic (STN) displays.
  • Darkening of gray areas when large white area present. I'm not sure whether this is the fault of the Game Boy Pocket, which supplies less power than other models, or of the EverDrive GB X5, which draws more power than a single-game cart.
Attachments
menu_slide_opt.gif
menu_slide_opt.gif (20.02 KiB) Viewed 19019 times
gb240p-smeartest.zip
(30.41 KiB) Downloaded 900 times
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: STN torture test

Post by calima »

Wasn't that bounce patented by Apple? ;)
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

It's the same effect as a CSS transition using a curve similar to "easeOutBack" when showing and the "easeInBack" when hiding. Using cubic-bezier.com, I eyeballed it as similar in effect to cubic-bezier(.6,1.3,.8,1) when sliding in and cubic-bezier(.2,0,.4,-0.3) when sliding out.

According to the browser compatibility table for CSS transition timing functions, the free web browser Firefox added experimental support for CSS transitions in version 4 (2010) and unprefixed it in version 16 (2012), and the free web browser Chromium added support for CSS transitions in version 1 (2008) and unprefixed it in version 26 (2013). Apple WebKit gained specific support for overshooting transitions when the bug 45761 fix landed in September 2011, and WebKit is free software (LGPLv2) as well. If Apple were interested in asserting this patent for overshoot in ease-out for discrete show/hide transitions, as opposed to reaching the end of a continuous scroll range, we probably would have heard about it sometime in the past six years. More generally, it follows from two of Disney's basic principles of animation: squash and stretch and ease-in and ease-out. These have been around since the 1940s, as described in The Illusion of Life (F. Thomas and O. Johnston, 1981).
Oziphantom
Posts: 1565
Joined: Tue Feb 07, 2017 2:03 am

Re: STN torture test

Post by Oziphantom »

Apple patented showing a texture or surface or material behind the item when it over scrolled. It's some super dupper design thing that makes it feel more real and less like a slab of glass or something... see also "Material design" by android ; So tepples is safe for now ;)
Shonumi
Posts: 342
Joined: Sun Jan 26, 2014 9:31 am

Re: STN torture test

Post by Shonumi »

I don't really have much to say besides that it looks pretty good. This is your first attempt at seriously diving into Game Boy (DMG) homebrew right? Very nice so far.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

I took the hint and lightened the background for the help and menu screens of this first preview of the 144p Test Suite.

0.01 (2018-04-10)
  • initial release with Grid, Linearity, Gray ramp, Solid screen, Sharpness, Grid scroll, Full screen stripes, About, Credits
Who would need something like this?
  1. Someone owns a Super NES console, Super Game Boy accessory, and EverDrive GB, but no Super EverDrive or SNES PowerPak.
  2. Someone owns a Nintendo GameCube console, Game Boy Player accessory, and EverDrive GB, but no GameCube homebrew device.
  3. Someone wants to see exactly how much a Game Boy (DMG) or Game Boy Pocket suffers from motion blur and STN smear artifacts.
Attachments
gb240p-0.01.zip
(78.04 KiB) Downloaded 814 times
promo1.jpg
promo2.jpg
promo2.jpg (23.07 KiB) Viewed 18722 times
promo3.jpg
calima
Posts: 1745
Joined: Tue Oct 06, 2015 10:16 am

Re: STN torture test

Post by calima »

If you can keep it at 32kb with no mapper required, you could sell them through Catskull Games. Likely not a huge seller, but another income stream is always worth it.

edit: I imagine the main use will be testing screens for dead or damaged pixels, so gearing tests towards that could be useful. Maybe color support for GBCs?
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

The "Solid screen" pattern can toggle across all four gray levels. Thank you for the suggestion to add dead pixels to its description.

I'll do my best, but I'm not certain I'll be able to fit a full Game Boy Color suite in 32K. I've used 23.5K of 32K already, and for a benchmark, the NES port uses 52K out of 64K. Mitigating that are a few factors:
  • A lot of tests don't apply to monochrome Game Boy systems, allowing me to leave out their CHR data. The planned GB-exclusive tests (Motion blur and STN smearing) aren't expected to use much CHR data.
  • Tile data for Linearity, Shadow sprite, and the Sonic/Kiki Kaikai wannabe scroll tests will be smaller on Game Boy due to the smaller screen with square pixels. This means that for (say) Linearity, I store one variant and calculate its grid at runtime, not four like I have to on NES (NTSC grid, PAL grid, NTSC no grid, PAL no grid).
  • I've already included CHR data for some unfinished tests (Vertical scroll test, Manual lag test, and part of Shadow sprite) but not others (Stopwatch, Hill zone scroll test).
  • I left my hello world demo accessible by choosing any test that I haven't started on. Once no tests are marked "NYA", its 2K of code and CHR data can be cut out.
  • Unlike the NES port, where I reused the PB53 tech I had built for Action 53 and RHDE, I haven't done anything with compression yet. Game Boy has more RAM for more compression, and I'll have fun figuring out how to make better use of it.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: STN torture test

Post by nitro2k01 »

tepples on gbdev forum wrote:But not everybody can run 240p Test Suite.

A. Someone owns a Super NES console, Super Game Boy accessory, and EverDrive GB, but no Super EverDrive or SNES PowerPak.
It is not strictly true. The SGB contains facilities for downloading code into SNES RAM and running it. This should be enough to run a special version of the suite using only the hardware listed in A. This would also be a good idea if you want to display effects at the framerate of the SNES rather than the output rate of the onboard GB CPU. Even if you don't go full SNES on it, you could use SGB functionality to provide color to tests where this is relevant and fill the whole screen using the border.

One minor nitpick about the interface would be that I'd like to be able to read the about text for an individual test without first entering that test. As it is now, pressing start at the menu always shows the about screen for the whole ROM.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

tl;dr: SGB/GBC patches are welcome.
nitro2k01 wrote:The SGB contains facilities for downloading code into SNES RAM and running it.
The official Super NES port of the 240p Test Suite was 512K last I checked, and the Super Game Boy allowed downloading only up to 64K last I checked. Is there source code for a Super NES program sending requests back to the Game Boy CPU so that it can request 4K of data at a time through the DATA_TRN mechanism? Is there public source code for loading and running native code on a Super NES through Super Game Boy at all? Or would I end up having to become the only developer other than the Taito devs who made Space Invaders to actually use DATA_TRN and JUMP?
nitro2k01 wrote:This would also be a good idea if you want to display effects at the framerate of the SNES rather than the output rate of the onboard GB CPU. Even if you don't go full SNES on it, you could use SGB functionality to provide color to tests where this is relevant and fill the whole screen using the border.
As calima suggested above, one goal of this project is to fit it in 32768 bytes, the size of Catskull's $10 MBC-less flash cart. As a precedent for the practicality of producing Super Game Boy enhanced software small enough to fit in such a cartridge, which licensed Super Game Boy enhanced or Game Boy Color enhanced games are 32K? No-Intro's DAT-o-MATIC doesn't appear to have a way to filter by size, even if we assume that filtering by title "SGB Enhanced" is reliable. If no such games exist, then who manufactures production cartridges larger than that?

In addition, with my obligations to my employers (plural), I may not be able to produce a Super Game Boy enhancement patch, a Game Boy Color enhancement patch, and a Game Boy Advance port (which someone on Shmups Forum requested after I announced this there) on my own any time soon. Once I complete the mono version, I am willing to review such patches provided by you, calima, or anyone else.
nitro2k01 wrote:One minor nitpick about the interface would be that I'd like to be able to read the about text for an individual test without first entering that test.
In this post, I have passed along this nitpick to the maintainer. I think the main sticking point is what button binding would be used to show each test's help page on each supported platform.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: STN torture test

Post by nitro2k01 »

tepples wrote:The official Super NES port of the 240p Test Suite was 512K last I checked, and the Super Game Boy allowed downloading only up to 64K last I checked. Is there source code for a Super NES program sending requests back to the Game Boy CPU so that it can request 4K of data at a time through the DATA_TRN mechanism? Is there public source code for loading and running native code on a Super NES through Super Game Boy at all? Or would I end up having to become the only developer other than the Taito devs who made Space Invaders to actually use DATA_TRN and JUMP?
No such source code exists publicly to my knowledge. What does exist is documentation of the hardware used for communicating through the SGB cartridge. With that info, I think the limiting factors (other than time of course) is one's knowledge of the SNES architecture, as well as access to debug tools. At least Higan emulates SGB.
tepples wrote:As calima suggested above, one goal of this project is to fit it in 32768 bytes, the size of Catskull's $10 MBC-less flash cart. As a precedent for the practicality of producing Super Game Boy enhanced software small enough to fit in such a cartridge, which licensed Super Game Boy enhanced or Game Boy Color enhanced games are 32K? No-Intro's DAT-o-MATIC doesn't appear to have a way to filter by size, even if we assume that filtering by title "SGB Enhanced" is reliable.
If the query is games licensed by Nintendo, I'm fairly certain there are no examples. But I can mention my own port of Flappy Bird. Even though it's a simple game, there's quite a lot of graphics in it. Including an as mentioned, SGB border graphics, intro screen, multiple animation frames for the bird, certain graphics that are different in GB and GBC mode as well as multiple easter eggs. But there you have an example a 32k game that is both SGB and GBC enhanced, and it was sold on cartridge. Attached is the ROM and a screenshot of it SGB border.

Some size stats about the game:
(Almost) all graphical assets are compressed using my shoddy homebrew compression algorithm. To take the SGB border as an example:

Uncompressed size
Tile data: 8192 bytes
Attribute map: 2048 bytes
GB map data used for the data transfer: 448 bytes
Total: 10688

Compressed size
Tile data: 5185 bytes
Attribute map: 742 bytes
GB map data used for the data transfer: 21 bytes (That data is mostly sequentially incrementing tile numbers so it compresses extremely well in my compression encoding. But that's one of the things it was optimized for.)
Total: 5948 bytes

A tally of all graphical assets (uncompressed) comes out to 28200 bytes, whereas the complete ROM (code+compressed graphics) is 27785 without slack.
flap_sgb.png
With that said, what takes up the most space in any game is likely graphics as well as level data. The test suite will have no level data and could cut down the data considerably by restricting itself to the more utilitarian tests and skip for example the Sonic screen. The graphics used in the more utilitarian tests would compress well, owing to their mostly repetitive nature. There's nothing intrinsic about SGB that would make the ROM big, other than actual size of the graphics. I realize, though, that at that point we're discussing a whole new product.
tepples wrote:If no such games exist, then who manufactures production cartridges larger than that?
There's nothing special about a SGB cart, so if all you want is a physical cartridge for a release, there are various ways. Just let people run it on their own flashcarts. You could buy the cheap knock-off games from eBay or Aliexpress, which are often reflashable. That could be a cheap way of getting something out, although those carts often a bit flaky.
tepples wrote:In addition, with my obligations to my employers (plural), I may not be able to produce a Super Game Boy enhancement patch, a Game Boy Color enhancement patch, and a Game Boy Advance port (which someone on Shmups Forum requested after I announced this there) on my own any time soon. Once I complete the mono version, I am willing to review such patches provided by you, calima, or anyone else.
That, I totally get. What could theoretically be done, and what one person could do on their own given their available time are different things. I'll put it on the todo list.
tepples wrote:In this post, I have passed along this nitpick to the maintainer. I think the main sticking point is what button binding would be used to show each test's help page on each supported platform.
My counter-nitpick would be that it's not that it would be needed per se, it's just what I expected the button to do. Why have a dedicated button for showing the about screen, when there's a menu item for it. Remove that keybinding and reuse it and there should be no problem with any lack of buttons. Although that's just my stupid opinion.
Attachments
flappy.gb
(32 KiB) Downloaded 621 times
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

nitro2k01 wrote:What does exist is documentation of the hardware used for communicating through the SGB cartridge. With that info, I think the limiting factors (other than time of course) is one's knowledge of the SNES architecture, as well as access to debug tools. At least Higan emulates SGB.
How would I set that up? There appears not to be HLE for the SGB firmware, and I'm told Game Boy boot ROM is hard to dump.
nitro2k01 wrote:My counter-nitpick would be that it's not that it would be needed per se, it's just what I expected the button to do. Why have a dedicated button for showing the about screen, when there's a menu item for it. Remove that keybinding and reuse it and there should be no problem with any lack of buttons.
I'll pass that along. I'm looking to keep buttons as consistent with the Super NES version as possible, so whatever Artemio does with that one, I'll probably end up doing with the GB and NES versions.
nitro2k01
Posts: 252
Joined: Sat Aug 28, 2010 9:01 am

Re: STN torture test

Post by nitro2k01 »

tepples wrote:How would I set that up? There appears not to be HLE for the SGB firmware, and I'm told Game Boy boot ROM is hard to dump.
Thankfully, I host the various boot ROMs.

Todo: Add a hash list to that page for discoverability for people who may be looking for those files. Add the GBC boot ROM.

Edit: Added the aforementioned things and an expanded readme.
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

I came up with a GB/SNES counterpart to PB8, a CHR data codec used in the new version of the Who's Cuter demo and the Haunted games. (PB8 is LZSS with a fixed distance and length of 1, or equivalently RLE with unary-coded run lengths. PB53, used in Action 53, is PB8 with a couple ad hoc optimizations for NES tiles.) To make RLE effective on GB, you need to change the fixed distance to 2. I was inspired by the RLE tile codecs used in Master System games, which store the data bitplane-major before compression (like NES tiles) rather than row-major (like Master System and Game Boy tiles) and then reinterleave the data when copying it to VRAM.

I also dug up the text coder that I had for made for my NES port of robotfindskitten. Byte pair encoding (BPE), also called digram coding or (in the ROM hacking community) dual tile encoding (DTE), is a way of compressing text by mapping otherwise unused high-numbered code units to pairs of characters. For example, code units $20-$87 might be your ASCII code plus a few accented glyphs, and $88-$FF would represent pairs of characters. Recursive BPE, or digram tree encoding (DTE), also allows one or both of the pairs to refer to another (lower-numbered) pair.

0.02 (2018-04-14)
  • Solid screen: Mention dead pixel test (requested by calima)
  • Compress most tile graphics with PB16, saving about 1.25K
  • Compress help text with DTE, saving about 3.5K
  • Add tests: Shadow sprite, Hill zone scroll, Vertical scroll, and Stopwatch
These tests remain: Overscan, Manual lag test, Motion blur, STN smearing, Sound test, Audio sync
Attachments
gb240p-0.02.zip
(99.63 KiB) Downloaded 786 times
darryl.revok's portrait of Gus, 128 tiles
darryl.revok's portrait of Gus, 128 tiles
Gus_portrait.png (1.36 KiB) Viewed 18456 times
Smaller version of mikejmoffitt's Green Hill Zone-alike, 109 tiles
Smaller version of mikejmoffitt's Green Hill Zone-alike, 109 tiles
greenhillzone.png (2.05 KiB) Viewed 18456 times
tepples
Posts: 22705
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: STN torture test

Post by tepples »

Stick a fork in it 'cause I think it's done, unless someone wants to contribute a patch for SGB or GBC support. There's about 6K left without having to step up to an MBC.

0.03 (2018-04-17)
  • Add Overscan, working around a mono hardware bug with WX=166
  • Add Audio sync, Manual lag, Sound test, and Motion blur
  • Help: When displaying the same page as last time, don't move the window out and back in
Attachments
gb240p-0.03.zip
(120.75 KiB) Downloaded 912 times
Post Reply