3 ms·

I'm guessing this app looks cool; you might like to know that older systems remix it into glitch art like this: http://imgur.com/a/o3YVy http://imgur.com/a/o3YV

by i336_ 11y ago

I'm guessing this app looks cool; you might like to know that older systems remix it into glitch art like this: http://imgur.com/a/o3YVy http://imgur.com/a/o3YVy I thought I'd give it a whirl on the old ThinkPad T43 I'm using at the moment. I never really expect much from its tiny Mobility Radeon X300, but this was especially hilarious, and a most unexpected, refreshing change from the usual "oh, the disk LED is solid... again..." that I usually get. :P FWIW, the http://aframe.io/ http://aframe.io/ examples all work perfectly - I was actually slightly gobsmacked when I saw them, I can tell you with a fair amount of confidence that the simpler demos run on my system as fast as yours - so this GPU isn't a total lost cause with WebGL, and if it's moderately trivial to fix this, you'll net a small extra niche in your userbase (along with mobile users in 3rd-world countries using really entry-level smartphones and tablets). If the fault lies with Phaser.io, and you feel like poking their ticket thingy, I'm fine with you passing the screenshots along. I'm also fine with testing potential fixes, if there's any room to explore there. If your build environment can split out 32-bit Linux binaries without too much effort, I'd be happy to test that too.

nacs 11y ago
That "glitch art" looks like a video-card driver problem to me. It's also possible that the solitaire site uses more texture space than your card/driver can handle causing issues. The Aframe examples you linked seem to be simple geometric shapes with no textures so you may just be getting lucky there. Also, Phaser, the library GP is using uses Pixi.js for the webGL drawing code if I remember correctly and Pixi is supposed to fall-back to plain canvas rendering if webGL isn't supported -- so disabling WebGL for the site may make the solitaire site work.
- i336_ 11y ago
  Looks like you're right, the author responded saying exactly the same thing :) I tried killing webGL, which technically worked - I see a card deck! - but it didn't practically work: said card deck interacted at about 0.75-0.9fps. XD
kyle_u 11y ago
Linux 32-bit Build: https://s3.amazonaws.com/solitaire.gg/linux/Solitaire.gg.x32.zip https://s3.amazonaws.com/solitaire.gg/linux/Solitaire.gg.x32... It looks like I exceeded your texture memory. I use pretty high resolutions (targeting 4K displays), and dynamically build the card textures at runtime based on your screen size. Let me know if the native app improves the situation.
- i336_ 11y ago
  Another commenter said exactly the same thing about texture size, so I think you've pretty much nailed it. The native build sadly didn't fix much; Electron === Chrome at this level of the stack pretty much. Thanks for taking the time to build it though :) Incidentally, I tested the 32-bit build on my T43, and also tried the x64 build on my ever so slightly newer T60; both seem to have exactly the same issue: I'm getting pages and pages of r300: CS space validation failed. (not enough memory?) Skipping rendering. on both machines' stdouts when I run ./solitaire. One uses (as I mentioned) an ATI X300, the other an X1400. Behold what 2005-2007 had to offer...! xD The T43 says: radeon 0000:01:00.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (64M used) radeon 0000:01:00.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 440758 kiB [TTM] Zone highmem: Available graphics memory: 509818 kiB [drm] radeon: 64M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000). And the T60 says: radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used) radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0x0000000027FFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 1534580 kiB [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). Can confirm, am firmly entrenched in old-hardware club. Ah well. I'll try and check back here to see if you've thought of anything else; my email's in my profile. For a few years now Google has had a little canvas benchmark in search results pages to figure out whether to enable endless scrolling. The game might springboard off of a technique like that to decide whether or not to use lower-resolution textures. (IMO, I'd target the detected screen resolution myself, I think that'd work...?)

by i336_ 11y ago

nacs 11y ago

That "glitch art" looks like a video-card driver problem to me. It's also possible that the solitaire site uses more texture space than your card/driver can handle causing issues. The Aframe examples you linked seem to be simple geometric shapes with no textures so you may just be getting lucky there. Also, Phaser, the library GP is using uses Pixi.js for the webGL drawing code if I remember correctly and Pixi is supposed to fall-back to plain canvas rendering if webGL isn't supported -- so disabling WebGL for the site may make the solitaire site work.

i336_ 11y ago
Looks like you're right, the author responded saying exactly the same thing :) I tried killing webGL, which technically worked - I see a card deck! - but it didn't practically work: said card deck interacted at about 0.75-0.9fps. XD

kyle_u 11y ago

Linux 32-bit Build: https://s3.amazonaws.com/solitaire.gg/linux/Solitaire.gg.x32.zip https://s3.amazonaws.com/solitaire.gg/linux/Solitaire.gg.x32... It looks like I exceeded your texture memory. I use pretty high resolutions (targeting 4K displays), and dynamically build the card textures at runtime based on your screen size. Let me know if the native app improves the situation.

i336_ 11y ago
Another commenter said exactly the same thing about texture size, so I think you've pretty much nailed it. The native build sadly didn't fix much; Electron === Chrome at this level of the stack pretty much. Thanks for taking the time to build it though :) Incidentally, I tested the 32-bit build on my T43, and also tried the x64 build on my ever so slightly newer T60; both seem to have exactly the same issue: I'm getting pages and pages of r300: CS space validation failed. (not enough memory?) Skipping rendering. on both machines' stdouts when I run ./solitaire. One uses (as I mentioned) an ATI X300, the other an X1400. Behold what 2005-2007 had to offer...! xD The T43 says: radeon 0000:01:00.0: VRAM: 128M 0x00000000C0000000 - 0x00000000C7FFFFFF (64M used) radeon 0000:01:00.0: GTT: 512M 0x00000000A0000000 - 0x00000000BFFFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 64bits DDR [TTM] Zone kernel: Available graphics memory: 440758 kiB [TTM] Zone highmem: Available graphics memory: 509818 kiB [drm] radeon: 64M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] PCIE GART of 512M enabled (table at 0x00000000C0040000). And the T60 says: radeon 0000:01:00.0: VRAM: 128M 0x0000000000000000 - 0x0000000007FFFFFF (128M used) radeon 0000:01:00.0: GTT: 512M 0x0000000008000000 - 0x0000000027FFFFFF [drm] Detected VRAM RAM=128M, BAR=128M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 1534580 kiB [drm] radeon: 128M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. [drm] PCIE GART of 512M enabled (table at 0x0000000000040000). Can confirm, am firmly entrenched in old-hardware club. Ah well. I'll try and check back here to see if you've thought of anything else; my email's in my profile. For a few years now Google has had a little canvas benchmark in search results pages to figure out whether to enable endless scrolling. The game might springboard off of a technique like that to decide whether or not to use lower-resolution textures. (IMO, I'd target the detected screen resolution myself, I think that'd work...?)