All of this code was made during the Full Tilt road engine. It doesn't support it yet, but the design is to allow plugging in your own functions from which the animation system will call. This way the game can control it however it wants.
@@Xonatron Looking at the Thunder Blade play throughs, I see the Sega Genesis version shows all characters zoom in at the same in sync Z distance, at the end of each stage. The arcade just prints the text, but shows the high scores at the end with zooming letters that each appear one at a time (like mine do) except in a curved pattern -- this would be a neat example function to inject into the system.
@@Xonatron That reminds me -- Thunder Blade had the spinning disc of letters in 3D, that I stole for Full Tilt VGA -- so perhaps the font rendering could be given a resultant zoom value outside of any animation.
Thanks for the kind words. Because these are pixel fonts, they are stored as basic PNG files, which are non-lossy (exactly / accurately stored). The visible pixels are RGBA = 255, 255,255,255 and the empty pixels are 0,0,0,0. This way I can load them directly in my texture system in my engine (Xona System 8, which is based on the MonoGame framework, based on XNA), and render them exactly as is. This also allows me to make anti-aliased fonts simply by drawing see-through pixels, like RGBA = 255,255,255,127, for 50% alpha (127/255).
Just watching this again with Myke. It's super cool. One idea I'd like to add is when a font is drawn and its drawn with random characters before settling into the proper character. This is not really an animation in the sense of movement, scaling, and alpha.
I added this and it showcases in my next video. It's not trivial to do, since you have to change what is being drawn, instead of just moving it. Also the idea of animation is that it starts then ends... where in this case they all start from the beginning and then end at different times. It can all be done, but I want some kind of consistent API for them all.
I tried just randomization and also deterministic settling into the ASCII character desired, and the latter just never felt right. Either too fast to notice or if slowed, it ruins the desired random character effect.
Another thing is fixed width vs variable width. It turns out it works well for both. Only because the entire thing is a random mess so variable width jumping isn't bad. But I did notice it's better to only randomize letters and numbers with themselves. Leave spaces as spaces.
@@JDoucette I wondered if there was any value in easing in close as measured by the ASCII value. For "A" it could climb down from D, to C, to B, to A. I had a feeling it would make no sense, and better would be to have characters that were closer to it. It would require analyzing each font to see the "visual distance" of every other character. It could be a cool effect. Similar to using fonts to render graphics as if each character is a graphic element of some sort bigger than a pixel.
@@Xonatron Yeah, this is exactly what I was trying... for the letter A, it would start higher, and then get closer to A.... E, D, C, B, A... in a slow-down fashion, but it just seemed random (too fast), and then too slow (you can see the C, B, then A). I'm sure there's some variable setting that makes it best, but I didn't like the idea that it was so finnicky -- an animation shouldn't rely on exact settings to even look good at all.
No. I don't think SDF fonts would look good with large pixels. This screen is 3x3 pixel size in 1920x1080 and it's the smallest I would go for my low resolution pixel rendering. I feel 4x4 is the actual smallest but I wanted to showcase more letters in these larger fonts. This is pixelmania! I'm going to keep making my own fonts and control the pixels myself.
@@JDoucette They would help immensely at 1:09 But you bring up a good point -- at what native font size does an SDF font fall off in quality? 6x6? 5x5? 4x4? 3x3?
@@MichaelPohoreski Oh I get it now -- you mean when the font is zooming, and the central characters are right in your face. Currently, the zoom factor is 8x through to 1x, using correct 3D perspective, but the font fades in over the first 12.5% of the animation (essentially from 8x to 7x zoom, the zoom factor is LERP). I actually don't mind the extreme pixelation, since this is part of the charm of the Sega "Super Scalar" sprite scaling technology.
@@MichaelPohoreski And yes, once the font settles into its 1x zoom -- how well will SDF work? This could be tested in your SDF demo on ShaderToy - shadertoy.com/view/llK3Wm (I wonder if UA-cam will erase this comment because it has a link?)
I think SDF fonts may backfire psychologically as you would lose font quality as they zoom out, giving the user more at first and taking away as time goes on. This is in context of the engine being geared towards low resolution, pixel art games, of course.
Very cool work.
All of this code was made during the Full Tilt road engine. It doesn't support it yet, but the design is to allow plugging in your own functions from which the animation system will call. This way the game can control it however it wants.
Oh that's really cool. @@JDoucette
@@Xonatron Looking at the Thunder Blade play throughs, I see the Sega Genesis version shows all characters zoom in at the same in sync Z distance, at the end of each stage. The arcade just prints the text, but shows the high scores at the end with zooming letters that each appear one at a time (like mine do) except in a curved pattern -- this would be a neat example function to inject into the system.
@@Xonatron That reminds me -- Thunder Blade had the spinning disc of letters in 3D, that I stole for Full Tilt VGA -- so perhaps the font rendering could be given a resultant zoom value outside of any animation.
You and your bro are kings
That's a wickedly nice comment. Thank you so much for sharing. Curious if you do any game/graphics/retro development yourself?
Ha, wow, amazing compliment!
That's some great variety of typefaces. What format you're using for the fonts?
Thanks for the kind words. Because these are pixel fonts, they are stored as basic PNG files, which are non-lossy (exactly / accurately stored). The visible pixels are RGBA = 255, 255,255,255 and the empty pixels are 0,0,0,0. This way I can load them directly in my texture system in my engine (Xona System 8, which is based on the MonoGame framework, based on XNA), and render them exactly as is. This also allows me to make anti-aliased fonts simply by drawing see-through pixels, like RGBA = 255,255,255,127, for 50% alpha (127/255).
Just watching this again with Myke. It's super cool. One idea I'd like to add is when a font is drawn and its drawn with random characters before settling into the proper character. This is not really an animation in the sense of movement, scaling, and alpha.
I added this and it showcases in my next video. It's not trivial to do, since you have to change what is being drawn, instead of just moving it. Also the idea of animation is that it starts then ends... where in this case they all start from the beginning and then end at different times. It can all be done, but I want some kind of consistent API for them all.
I tried just randomization and also deterministic settling into the ASCII character desired, and the latter just never felt right. Either too fast to notice or if slowed, it ruins the desired random character effect.
Another thing is fixed width vs variable width. It turns out it works well for both. Only because the entire thing is a random mess so variable width jumping isn't bad. But I did notice it's better to only randomize letters and numbers with themselves. Leave spaces as spaces.
@@JDoucette I wondered if there was any value in easing in close as measured by the ASCII value. For "A" it could climb down from D, to C, to B, to A. I had a feeling it would make no sense, and better would be to have characters that were closer to it. It would require analyzing each font to see the "visual distance" of every other character. It could be a cool effect. Similar to using fonts to render graphics as if each character is a graphic element of some sort bigger than a pixel.
@@Xonatron Yeah, this is exactly what I was trying... for the letter A, it would start higher, and then get closer to A.... E, D, C, B, A... in a slow-down fashion, but it just seemed random (too fast), and then too slow (you can see the C, B, then A). I'm sure there's some variable setting that makes it best, but I didn't like the idea that it was so finnicky -- an animation shouldn't rely on exact settings to even look good at all.
You going to switch to SDF fonts?
No. I don't think SDF fonts would look good with large pixels. This screen is 3x3 pixel size in 1920x1080 and it's the smallest I would go for my low resolution pixel rendering. I feel 4x4 is the actual smallest but I wanted to showcase more letters in these larger fonts. This is pixelmania! I'm going to keep making my own fonts and control the pixels myself.
@@JDoucette They would help immensely at 1:09
But you bring up a good point -- at what native font size does an SDF font fall off in quality? 6x6? 5x5? 4x4? 3x3?
@@MichaelPohoreski Oh I get it now -- you mean when the font is zooming, and the central characters are right in your face. Currently, the zoom factor is 8x through to 1x, using correct 3D perspective, but the font fades in over the first 12.5% of the animation (essentially from 8x to 7x zoom, the zoom factor is LERP). I actually don't mind the extreme pixelation, since this is part of the charm of the Sega "Super Scalar" sprite scaling technology.
@@MichaelPohoreski And yes, once the font settles into its 1x zoom -- how well will SDF work? This could be tested in your SDF demo on ShaderToy - shadertoy.com/view/llK3Wm (I wonder if UA-cam will erase this comment because it has a link?)
I think SDF fonts may backfire psychologically as you would lose font quality as they zoom out, giving the user more at first and taking away as time goes on. This is in context of the engine being geared towards low resolution, pixel art games, of course.