Author Topic: 3.0 Alpha Testing  (Read 295488 times)

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #750 on: July 05, 2015, 10:07:11 PM »
Just submit a pull request on github.  Sorry I'm on vacation and away from my computer right now.
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #751 on: July 05, 2015, 11:39:00 PM »
Should I be able to push my change to master before creating the pull request? I'm not too familiar with how things are done in this project.

By the way, I tested the fix and it seems to work ok. No more crashing in TV mode and the screenshot functionality in TV mode works now.

Offline Gillou68310

  • Developer
  • long
  • *****
  • Posts: 112
    • View Profile
Re: 3.0 Alpha Testing
« Reply #752 on: July 06, 2015, 12:33:03 AM »
You need to fork the repo first, then push your change to the fork (master or a new branch) and finally open the pull request from there ;)

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #753 on: July 06, 2015, 09:47:16 PM »
Ok, that took me a bit to figure out, but I think I got it. Git is very new to me, we use all SVN where I work.

Offline littleguy

  • Moderator
  • double
  • *****
  • Posts: 1945
    • View Profile
Re: 3.0 Alpha Testing
« Reply #754 on: July 06, 2015, 11:08:45 PM »
Thanks fzurita!   :D
2012 Nexus 7, rooted stock Lollipop
Samsung Galaxy Victory, rooted stock Jelly Bean
Xperia PLAY, stock Gingerbread
OUYA, retail version

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #755 on: July 14, 2015, 12:42:18 AM »
After the recent post about Yabause AE and the async feature,I have come to a harsh realization in light of slow performance on Android Shield TV running my mentioned Banjo-Tooie 60fps test,the emulator is actually what is slow,not the box.
I say this because I just saw a comparison video using Yabause with normal sync and the new async,and the results of the slower sync method show it running a game at 39-49fps/60fps on an Nvidia Android Shield TV while async runs at full 60/60fps.

https://www.youtube.com/watch?v=Og11R6-b_T4

Now obviously,we sadly can't get improved N64 emu speed using async with CPU and GPU via asynchronous because of how the real N64 hardware is designed,or am I wrong?
(If so,then awesome if async can be done for a really great speed boost!)

And yes,I probably should of said this upstream instead of here,just getting desperate since the excessive lack of activity on the forums lately.

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #756 on: July 14, 2015, 09:27:06 AM »
Retroben, the new 3.0 auto build has an x86 workaround. Can you see if that works for you? It allows the GlideN64 plugin to start, but it's not really a true fix.
« Last Edit: July 14, 2015, 09:28:59 AM by fzurita »

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #757 on: July 14, 2015, 12:27:39 PM »
Thanks.

Possibly the part making them run is causing slowdown.
The GLES 3.0 variant is indeed slower while the GLES2 variant is really good.
I can run Super Smash Bros. with four DKs on Hyrule VS. Mode at a full smooth 60fps the entire time on it.
Yet I get the same exact frame-dip problems on the intro sequence for some split-second moments.

Also a mention about noise,the locked character slots in SSB use it too,so another thing for Gonetz to be able to look at easily for proof of working noise emulation on GLES2.

Offline OnijJoku

  • byte
  • *
  • Posts: 38
    • View Profile
Re: 3.0 Alpha Testing
« Reply #758 on: August 02, 2015, 01:46:39 AM »
It appears gles2 is buggy on my myTouch 4G (4.1.1). When it was Jellybean, it was just black screen. Now that it's gingerbread (2.3.5), it displays the game the first time, but the second time I load the same rom I get a black screen from then. I just brought this up for compatibility reasons. It works great on my Note 3 and this device called a Rockchip rk31sdk. Thanks for these great updates.
Device: T-Mobile MyTouch 4G
Resolution: 480 x 800
Chipset: Qualcomm MSM8255 Snapdragon
CPU: 1 GHz Scorpion
GPU: Adreno 205 245 MHz
RAM: 768 MB RAM

Device: Samsung Galaxy Note 3
Resolution: 1080 x 1920
Chipset: Qualcomm Snapdragon 800
CPU: Quad-core 2.3 GHz Krait 400
GPU: Adreno 330
RAM: 3 GB RAM

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #759 on: August 02, 2015, 10:40:54 PM »
I think the performance issues in OpenGL ES 3.0/3.1 are GLSL related. The more shader code gets added the slower it seems to get. Also, each a shader is compiled, games end up stuttering. From logging I added, it seems that shader re-compilation is happening a lot in Android.
« Last Edit: August 03, 2015, 08:35:34 AM by fzurita »

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #760 on: August 11, 2015, 02:01:21 PM »
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #761 on: August 11, 2015, 10:15:47 PM »
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.

The 16:9 mode sounds like a difficult thing to do. I think it would have to be done on a plugin by plugin basis.

Offline grayman

  • bit
  • Posts: 1
    • View Profile
Re: 3.0 Alpha Testing
« Reply #762 on: August 12, 2015, 01:54:03 AM »
Now that it's gingerbread (2.3.5), it displays the game the first time, but the second time I load the same rom I get a black screen from then.
I've got the same problem with gilden64 3.1 on my galaxy s6. When I play a game the first time it works perfectly, but when i play it the second time the picture is just static. all else works but except for that.
note that the problem happened both on 5.1 and 5.1.1 android versions so I'm  not sure if it's that that's causing the problem. I've  also got opengl es 3.1 exactly as specified so I'm  stumped as nothing I've tried (basic fidgeting with available options on the 2.1 alpha build and trying some methods that were said on the forum) has allowed me to open a game the second time
If this is resolved,  well conker's bad fur day does play on 30fps as does majora and banjo kazooie. And I've seen no notable glitches if any at all.
Played games all perfect:
banjo kazooie
majora
smash
conker 28-34 fps (rare 43fps)
yoshi story
paper mario (it was perfect on this and i played it before on n64oid on 25 fps on my galaxy s4 with glitches and crashes so major improvement.)
and i just tried banjo tooie which doesn't  seem to show it at all on gliden64 3.1 which is odd.

Offline fzurita

  • Moderator
  • double
  • *****
  • Posts: 560
    • View Profile
Re: 3.0 Alpha Testing
« Reply #763 on: August 12, 2015, 10:49:11 PM »
Something I think should have immediate attention.
Can an option be added to use aspect ratios so we can actually use 16:9 widescreen for the correct filled screen size on widescreen capable games?
I can't stand how useless it is for Banjo-Tooie and DK64 with widescreen enabled,as it has the large black bars on the left and right.

Additionally,I must again mention that GLideN64 has scaling glitches when you use stretch,it has glitched edges instead of scaling to the stretched width like it is supposed to,which kinda sucks when you want to see the beauty of native resolution on a 1080P screen combined with stretch (or pending 16:9 mode) to fill in the black border space.

The 16:9 mode sounds like a difficult thing to do. I think it would have to be done on a plugin by plugin basis.

Ok, so apparently you can already do this. It doesn't work with GLideN64 though, but it does work with other plugins. Just set the "Rendered Resolution" to native and the "Screen Scaling" to stretch.

Offline retroben

  • float
  • ****
  • Posts: 432
    • View Profile
Re: 3.0 Alpha Testing
« Reply #764 on: August 12, 2015, 11:45:47 PM »
Is "stretch" just a confusing scale-type name for the 16:9 aspect?
I wouldn't think so since it is only stretching it instead of squeezing and stretching it,I dunno.
Unless that is what 16:9 is,I can't help but get confused about this... :-\

Okay,I think I figured it out.
Normally,on a TV with the actual console,the game fills the entire screen in both modes,but when enabling the widescreen mode on it,you see it become squished to fit completely,revealing the missing part of the game visual.

I'd really like to see that GLideN64 issue fixed though. ;)