"Smach Z is Back!" ...?

[fusion_power]

It already runs an 3D benchmark, that's technically more than the Pyra is able to do right now if we are honest. ^^"
We all know how long it can take to develop a device like that. And if you are patient with the pyra development, you also should be patient with other comparable devices.

 

[Nintendo]

^ The difference is, Pyra is being handled by good-trustworthy and intelligent people.
SMACH Z project is, well, being run by idiots.

 

[second exodous]

I watched the video and eh, he wasn't actually in the room. I know they're idiots but something like that could be faked, like in a virtual machine.

 

[CommanderB]

Nah, I think that they really have a prototype, but I do not know, how good it will be in the end

Gesendet von meinem SM-N9005 mit Tapatalk

 

[vcoleiro1]

In about 2 weeks , a Spanish person I know has arranged to see it in person.

 

[EvilDragon]

It already runs an 3D benchmark, that's technically more than the Pyra is able to do right now if we are honest. ^^"

We have 3D running for years...? It's just not compatible with TILER yet (zmatt needs to fix a few things), but 3D works fine without it on any Pyra
[doublepost=1540422205,1540422161][/doublepost]

In about 2 weeks , a Spanish person I know has arranged to see it in person.

That will be interesting, as so far, the SmachZ team is known to fake almost everything they show... would be neat if they actually have something this time.

 

[Nintendo]

I watched the video and eh, he wasn't actually in the room. I know they're idiots but something like that could be faked, like in a virtual machine.

Remote access can be faked?

 

[pmprog]

Remote access can be faked?

Not the remote access, but you can still fake the prototype. Let me explain how I would do their set up if I was trying to fake it.

1. Buy a laptop with the specs of the prototype I'm pretending to have. Install Windows 10 and a VNC Server.
2. Cobble my "prototype" with a big board, hidden underneath is a Raspberry Pi Zero W, linked to one of the batteries, and use the HDMI out to the monitor
3. VNC the Pi to the laptop, so now you will get a mirror of the laptop on your "prototype" without any wires (other than the HDMI)
4. Let my target "reviewer" remote onto the laptop whilst videoing my "prototype" with it's HDMI screen

I'm not saying this is what they've done, but it's pretty easy to do

 

[second exodous]

Remote access can be faked?

Uh, yeah, well, like pmprog said it really is remote access but remote access to what? Even with the guy filming you can't be 100% sure, especially with all the crap they have pulled in the past. The only reason they picked The Phawx is he has a huge following bench marking their competition. If they picked someone closer it would look more legit.

 

[Nintendo]

@pmprog & @second exodous

Ah, I see. I understand now. Thanks for the explanation to both you.

 

[fusion_power]

We have 3D running for years...? It's just not compatible with TILER yet (zmatt needs to fix a few things), but 3D works fine without it on any Pyra

Uhm, do we talk about hardware accelerated 3D functions?

 

[Grench]

We have 3D running for years...? It's just not compatible with TILER yet (zmatt needs to fix a few things), but 3D works fine without it on any Pyra

So - does this mean turning it 90* to the right or the left for 3D in portrait mode?

Someone needs to make a game to take advantage of that... Maybe a vertical scrolling driving game or shooter controlled by one hand and one nub?

Seriously though - that doesn't sound like the 3D drivers are in as bad of shape as many of us had likely thought (including me).

Does Zmatt have one of the now working units to make the modifications on?

 

[EvilDragon]

Uhm, do we talk about hardware accelerated 3D functions?

Yes, of course.

Uh, yeah, well, like pmprog said it really is remote access but remote access to what? Even with the guy filming you can't be 100% sure, especially with all the crap they have pulled in the past. The only reason they picked The Phawx is he has a huge following bench marking their competition. If they picked someone closer it would look more legit.

The prototype they had at the Gamescom years ago was working but even way slower than the GPD Win 1 (even simple games or the OS was sluggish).
They could even use this prototype and do the remote session on that one to any laptop or PC with the specs the SmachZ is supposed to have.

I'm kinda puzzled why they even needed that remote access. If what he had in his hands was a working prototype which can do a remote session, there's no reason you even NEED the remote session as you could simply show off the prototype.

So the only real reason to do a remote session would be because you want to hide something.

So - does this mean turning it 90* to the right or the left for 3D in portrait mode?

No, 3D could easily handle it's own rotation. But the normal system doesn't run in 3D.
So right now, we either have an unrotated OS with working hardware 3D (which can rotate the games), a rotated but awfully slow OS (software rotation) with working hardware 3D or a rotated OS with hardware accelerated (TILER) rotation but without 3D.

According to zmatt, this should be an easy fix. AFAIR TILER simply locks the framebuffer and therefore 3D can't use it. So TILER would need to unlock it so the 3D can use it.

Does Zmatt have one of the now working units to make the modifications on?

The unit he has can already be used for that fix, and he hasn't replied to my offering of the final prototype yet (he's probably pretty busy).

 

[levi]

According to zmatt, this should be an easy fix. AFAIR TILER simply locks the framebuffer and therefore 3D can't use it. So TILER would need to unlock it so the 3D can use it.

Oof. That seems to me like it would hit a lot of code that does its own framebuffer stuff, but I've already seen prototypes apparently running Hydra Castle Labyrinth. That probably runs under SDL or something though, so it's only really low level stuff like Mame and other old code that was written before SDL matured.

Still, I have every trust that zmatt knows his onions, and the fix will be easy and relatively speedy.

 

[ptitSeb]

HydraCastleLabyrinth use SDL (1.2) so, it doesn't use 3D.
For the 3D driver, if I understood correctly, the issue is that the driver tries to get the size of the Framebuffer (it gets the rotated one 1280x720) , then tries to allocate a framebuffer surface and fail here, because FB is really 720x1280. When rendering in offscreen buffer (with LIBGL_FB=3 using gl4es), the 3D is running fine on my Pyra (but slowly as I had to disable fbturbo on my prototype, making every blit a bit slow).

 

[vcoleiro1]

Smach had already released videos showing the Smach Z board running windows and GTAV. The reason Phawx had gotten to do this video is becuase he had been asking to do so and they finally felt it was at a stage where he could have remote access. There is always going to be doubt unless someone is right there checking it out. This is why one of my online freinds in Spain has arranged to see it live .

 

[Grench]

HydraCastleLabyrinth use SDL (1.2) so, it doesn't use 3D.
For the 3D driver, if I understood correctly, the issue is that the driver tries to get the size of the Framebuffer (it gets the rotated one 1280x720) , then tries to allocate a framebuffer surface and fail here, because FB is really 720x1280. When rendering in offscreen buffer (with LIBGL_FB=3 using gl4es), the 3D is running fine on my Pyra (but slowly as I had to disable fbturbo on my prototype, making every blit a bit slow).

Complete novice - more educated people have probably already gone there. Is there a way to hard-code what the system responds to the driver's framebuffer call? I.e. man-in-the-middle style. If -this- driver calls for -this value-, return it -this other value-. ?
[doublepost=1540505498,1540505446][/doublepost]Oh, and if a mod feels inclined, this non-smach-Z discussion could probably move it's way back into Pyra General discussions...

 

[vcoleiro1]

Also, Phawx has not finished , he will be doing more sessions with the Smach Z and releasing more videos on it soon that try to address questions raised by people in his last video

 

[EvilDragon]

HydraCastleLabyrinth use SDL (1.2) so, it doesn't use 3D.
For the 3D driver, if I understood correctly, the issue is that the driver tries to get the size of the Framebuffer (it gets the rotated one 1280x720) , then tries to allocate a framebuffer surface and fail here, because FB is really 720x1280. When rendering in offscreen buffer (with LIBGL_FB=3 using gl4es), the 3D is running fine on my Pyra (but slowly as I had to disable fbturbo on my prototype, making every blit a bit slow).

Ah, thanks for the info. That means the fix should be even more trivial and work with everything once it's applied.

 

[levi]

Complete novice - more educated people have probably already gone there. Is there a way to hard-code what the system responds to the driver's framebuffer call? I.e. man-in-the-middle style. If -this- driver calls for -this value-, return it -this other value-. ?

The call that asks for the screen resolution, I guess you mean. Yes, that's always possible, but the question remains on how easy it is to do, and whether it's even the right way to square this rotated rectangle. Even if everything's still closed source, the API should still be public and you can shim that out, although reimplementing and passing all those other calls on is a chunk of boilerplate someone needs to write. In practice, there should be an open source interface file to be built as a kernel module and that can be tweaked as you suggest, if that turns out to be the right thing to do.