Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - gdark100

Pages: [1] 2
1
General Discussion / Re: GLideN64 Android port
« on: May 25, 2015, 10:48:38 PM »
Textures working here on Mali 400MP, just with minor glitches. performance is not too bad, but a bit slow. Will test on PVR when I have time.

@littleguy - I get those random pixels at the startup, but they disappear and the actual game start playing after 2-3 seconds.

2
General Discussion / Re: GLideN64 Android port
« on: May 23, 2015, 09:22:50 PM »
@gdark100: Could you tell me if the textures are ALL black on glN64 with the same games you tested with GLideN64?

@gdark100: Please,do tell us the results with glN64,if you have textures where they are black in GLideN64,then it will help Gonetz to fix the Mali issue by utilizing the Android glN64 source code.
On Mali400MP, textures works perfect on all plugins, except glideN64, on the tested games (on glideN64 all textures are black like show in the screenshots a few posts back). On PVR 540, textures looks OK, but it runs at less than 1 fps I think, very slow. All other plugins have acceptable speeds (at least on SM64).

3
General Discussion / Re: GLideN64 Android port
« on: May 23, 2015, 05:20:55 PM »
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.
Come on, don't be that a$$hole, the dev team are working hard fixing things, they have real jobs and lifes, i am a rookie developer and i know  that some things needs time to debug and fix them
Im not being an asshole. Sorry if I sound like that. Totally agree with what you said, but gonetz made the development of this plugin his full time job (with Indiegogo campaign money). Also he have a very tight time to work on the plugin, like he said a few posts ago, so it would be better to fix critical problems first (like the plugin barely working on kinda a lot of GLES2 devices). Of course, is up to him to decide what is priority...

4
General Discussion / Re: GLideN64 Android port
« on: May 23, 2015, 03:13:03 PM »
I've pushed commit which fixes paths for texture library. It uses the same path for hires pack texture, as Rice video. It does not have much sense until problem with boost exists. But if boost problem will be fixed, texture library should be fully functional.
Texture pack library is kinda irrelevant when you have a plugin that doesnt even display the textures in the first place.

5
General Discussion / Re: GLideN64 Android port
« on: May 19, 2015, 11:38:36 AM »
So besides making the GLES2 version render correctly and position stuff correctly,should it be primarily optimized for performance and non-crashing/non-freezing?

All about the GLES2 version:
And is it possible to bring code from Glide64 to it to fix some of the issues?
Or would you like to take a different approach and perfect the Glide64 plugin by placing as much of GLideN64 code as you can into it to apply most of the missing framebuffer effects and improve performance?

Just trying to stretch out the options here.
if I was gonetz, I would focus on speed. From what I understood, the main focus of this plugin was emulation accuracy and some neat features. GLES2 doesnt support those features through, and also doesnt support some of the necessary stuff to run some effects correct. So, to avoid it being just another Glide64 for GLES2, he could work on speed. A bunch of games work slow on older devices, and be able to play those would be awesome  ;D (Conker's BFD and Mario Tennis are two of those games that i can't play on my phone cause its too slow)

6
General Discussion / Re: GLideN64 Android port
« on: May 18, 2015, 04:01:25 PM »
Here the PowerVR SGX 540 compatible build:
https://drive.google.com/file/d/0B0YqMPjGo3B2YUZ5dzk3RmdHWHc/view?usp=sharing

I had to disable fog blend modes to make shader program compiled for this GPU.
Works very slow with and without FB emulation.
No changes on Mali400 MP device, and it is now working on PVR SGX 540 at slideshow speed. Recorded a video because whynot: https://youtu.be/NSpWc1PzuMM (swtiched to gln64 at middle-to-end for speed comparasion)
Didnt see any major graphical issue on SGX 540 tho.

7
General Discussion / Re: GLideN64 Android port
« on: May 18, 2015, 01:52:27 PM »
Just tried to run GLideN64 on Samsung Galaxy 2. Not sure which GPU it uses. No errors in logs. Textures do not load at all.
Cant you port the functions that deal with textures from gln64 for GLES2 to your plugin until you "fix" the problem? So Ill know what is wrong and will have a possible solution.

8
General Discussion / Re: GLideN64 Android port
« on: May 17, 2015, 12:38:52 PM »
I tried to record a video showing some games, but it didnt ended very well, cause I recorded with one hand and played with the other... but well, here it is: https://youtu.be/rGE_endTjcI

9
General Discussion / Re: GLideN64 Android port
« on: May 16, 2015, 09:23:25 PM »
Well, just a note to gonetz. The problem is not the polygon themselves, but the textures. All textures are black. So only the polygons with colors (not textures) are visible.

10
General Discussion / Re: GLideN64 Android port
« on: May 16, 2015, 01:01:14 PM »
@gdark100 - from which of your devices these screenshots? As I know, my Note 2 is powered by Mali400, and I have almost no glitches or speed issues. Some games crashes, but those which work run pretty well.

@retroben GLES2 does not support glblitFrameBuffer.
Galaxy S2 Lite (Samsung Janice).
Ill test on the Xoom

Edit: On the Xoom it doesnt show anything. I can only hear the sound.

11
General Discussion / Re: GLideN64 Android port
« on: May 16, 2015, 12:03:57 PM »
Yesterday I managed to run GLES2 build of my plugin on NVidia Shield tablet. I rewrote large part of code to get that result. Today I had been porting my work on true GLES2 device and found that my yesterday struggle was just a warm-up before the real battle. I forgot how limited GLES2 is. Lots of things which I considered as basic just do not present here. I feel myself as returning back to stone age. I rewrote all " switch case" with "if else". I replaced "texture" with "texture2D". And so on. Lots of plugin's functionality is disabled because I don't know how to implement it with GLES2 functionality. For example, my mip-mapping code requires textureLod function, which is not supported here. My code is all perforated by "#ifdef #endif" because GLES2 can't do this and requires special code for that. It looks ugly.

Nevertheless, I finally got it working on my Note 2. The work is not finished and I will not push it to repo yet. However, I built an apk with current code. You may try it on your device. I was afraid that GLES2 will run slow, but speed is ok despite of plenty of debug output. Download link:
https://drive.google.com/file/d/0B0YqMPjGo3B2WmZON0ZkdXRNZWs/view?usp=sharing
Tested it here, heavy graphical glitches and poor speed, but it is probably expected since youre rewriting lots of code...

Here are  some screenshots:
First this appeared:

then:

This is Super Mario 64. Only a few polygons actually appears on the screen, the rest is black.
I will test other games and let you know how they perform.

Also, good luck with your indiegogo campaign  ;D

12
General Discussion / Re: 3.0 Alpha Testing
« on: May 08, 2015, 07:41:02 AM »
On the lastest Alpha, everytime I try to re-scan ROMs at the root of my sd card, the emulator crashes. If I try to scan inside my ROMs directory, it works. Below is the log inside the "CrashLogs" folder.

Spoiler: show

Code: [Select]
Uncaught exception in package org.mupen64plusae.v3.alpha

****MESSAGE****
An error occured while executing doInBackground()

****STACK TRACE****
java.lang.RuntimeException: An error occured while executing doInBackground()
at android.os.AsyncTask$3.done(AsyncTask.java:299)
at java.util.concurrent.FutureTask$Sync.innerSetException(FutureTask.java:273)
at java.util.concurrent.FutureTask.setException(FutureTask.java:124)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:307)
at java.util.concurrent.FutureTask.run(FutureTask.java:137)
at android.os.AsyncTask$SerialExecutor$1.run(AsyncTask.java:230)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1076)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:569)
at java.lang.Thread.run(Thread.java:856)
Caused by: java.lang.NullPointerException
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.getAllFiles(CacheRomInfoTask.java:215)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.getAllFiles(CacheRomInfoTask.java:218)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.doInBackground(CacheRomInfoTask.java:118)
at paulscode.android.mupen64plusae.task.CacheRomInfoTask.doInBackground(CacheRomInfoTask.java:52)
at android.os.AsyncTask$2.call(AsyncTask.java:287)
at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:305)
... 5 more

****LOGCAT****


****DEVICE****
Processor : ARMv7 Processor rev 1 (v7l)
processor : 0
BogoMIPS : 4.80

processor : 1
BogoMIPS : 4.80

Features : swp half thumb fastmult vfp edsp thumbee neon vfpv3 tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x2
CPU part : 0xc09
CPU revision : 1

Hardware : SAMSUNG JANICE
Revision : 000e
Serial : XXXX

Board: montblanc
Brand: samsung
Device: GT-I9070
Display: JZO54K.I9070VJLPD
Host: SEP-119
ID: JZO54K
Manufacturer: samsung
Model: GT-I9070
Product: GT-I9070


****PERIPHERALS****

Device: Virtual
Id: -1
Descriptor: a718a782d34bc767f4689c232d64d527998ea7fd
Class: BUTTON

Device: sec_jack
Id: 1
Descriptor: bda7e7374aba7c80dee4f7f0d239c94d5609e45a
Class: BUTTON

Device: gpio-keys
Id: 7
Descriptor: 485d69228e24f5e46da1598745890b214130dbc4
Class: BUTTON

Device: sec_touchkey
Id: 8
Descriptor: af4d26ea4cdc857cc0f1ed1ed51996db77be1e4d
Class: BUTTON

Device: AB8500 POn(PowerOn) Key
Id: 11
Descriptor: 6ecc9411d15f2f29cc10f7afdeaaacc1773c3bfc
Class: BUTTON

13
General Discussion / Re: GLideN64 Android port
« on: May 07, 2015, 05:58:00 PM »
What we need is improved performance on the emulator's side itself because in reality,it is a tad slow.
Tis' the sad truth. :(
Must agree with you, yesterday I tried to play the old n64 version of Spiderman, that I used to play on computer when I was younger, for the nostalgia, and it was lagging a bit. It was not too slow, but the lag was annoying, so I started to play around with settings, and the only plugin that worked smooth was gln64, with the enhancements disabled, but the polygons started to glitch out with this plugin, and that was even more annoying. So I had to play the PS1 version, since it have a weaker hardware compared to the n64, it worked smooth as butter :)

But the worst is that Conker's Bad fur Day doesn't work well in any plugin, it is always below 30fps, and that is unplayable. I remember playing it well on may old Pentium III with a GeForce FX 5200 video card (it have some lag sometimes, but it was pretty smooth and very playable). Is that old Single Core x86 833mhz CPU better than the 1.2 ghz Dual Core ARM CPU my tab have? What about the over 10 years old GPU?

Well, point is. I already saw some people saying the plugin was a bit slow on some games even on high end machines (some "issues" on github), add that to the fact that the plugins mupen ae already have runs pretty slow on some games, and with lag on others, so thats the reason I said that I believe this one will only have full speed on recent, high end devices, and some games will probably still have issues with speed. But of course, I really, really hope to be wrong.

14
General Discussion / Re: GLideN64 Android port
« on: May 07, 2015, 03:34:10 PM »
13 fps looks pretty bad, if you consider the fact that SM64 is one of the simplest Nintendo 64 games, and the Shield is a very powerful device.  This plugin looks really nice, especially the widescreen feature, also stuff that never worked right before is now looking nice (like Mario Tennis, it was a glitch party on old plugins, now it is nearly perfect on gliden64!). I really want to play my favorite n64 titles in widescreen on my TV using my old tablet (it got an HDMI output), it only have OpenGL ES 2.0 through, and Im affraid that the speed will render the games unplayable, since some games already lag A LOT with plugins like gln64 (Conker's Bad Fur Day and Mario Tennis being some title that goes below 30fps).

15
General Discussion / Re: 3.0 Alpha Testing
« on: December 09, 2014, 09:40:52 AM »
Very good to see Paul is back, and the project is progressing again! Tested the Alpha 3 yesterday, and the only problem I noticed was the lack of compressed roms support, also the cover art for zipped roms doesn't appear, but they are recognized and added to the list. Also Conker's Bad Fur Day still slow as ever here :P

Also would be good to add the new strings to Transifex, so we can start working on translation, and it would be already done in the release date.

Pages: [1] 2