Messages

1

General Discussion / Re: How to backup ROMs from N64 cartridges

« on: May 10, 2017, 09:32:10 PM »

Recently came across an old Netmos MP9835 dual serial/parallel PCI card and I have successfully dumped an N64 ROM using this.
I tried first in Ubuntu but I could not get GSCC to pick up the port correctly. For some reason Ubuntu thought I had two parallel ports.

I ended up using this card with Windows 7. Amazingly, this chip has actively updated drivers even for Windows 10.
I just spun up a Windows 98 VM in VMware, gave it LPT1, and GSCC worked out of the box and even autodetected the settings correctly.

I will try this in a Windows XP VM later, but this appears to be another viable way to dump ROMs and use all the features of GSCC on more modern computers.

2

General Discussion / Re: Backtrace on segfault in NDK code

« on: August 01, 2015, 10:46:43 PM »

I don't know much about OpenGL programming but it seems a bit odd to check extensions in a compiler macro. I would think they should be checked dynamically on the device that's running the GL code.

3

General Discussion / Re: Backtrace on segfault in NDK code

« on: July 16, 2015, 12:15:43 AM »

No crash for me and I tried every GLide variant. Only issue I had was the Peach-Bowser painting transition at the end of the hallway doesn't work with the GLES2 version

4

General Discussion / Re: Brainstorming Version 3.0

« on: June 22, 2015, 08:05:06 PM »

I implemented the cheat dynamic backend as best I could. See the latest commit of my new branch. I used two separate int arrays instead of 1 2D int array. I added a single cheat and I dynamically toggled that cheat, and both worked. Yet another thing that needs a GUI I guess

I've also found that we should be more strict with mandating unique names for cheat codes because the CheatEnabled command takes a cheat name as an argument.

Here is an APK intended for use with Super Mario 64. Open the menu and tap add cheat, and it will apply the cheat I hardcoded. Tap toggle cheat to toggle the added cheat: https://db.tt/zBoGVaa1

5

General Discussion / Re: Brainstorming Version 3.0

« on: June 21, 2015, 09:22:46 PM »

I made a new branch that makes sure the xperia-touchpad lib only builds on armv7, and it contains some setup for a dynamic cheat interface (@littleguy I think I'm getting better at this committing thing, but I'll let you be the judge).

6

General Discussion / Re: 3.0 Alpha Testing

« on: May 29, 2015, 09:24:54 AM »

Glide64mk2: http://i.imgur.com/mqGCVep.png

I think I remember some dithering on my older adreno devices like the xperia play.

7

General Discussion / Re: 3.0 Alpha Testing

« on: May 28, 2015, 05:50:59 PM »

That dithering appears to be done by your device's GPU, not the app. Nothing like that on my Shield Tab. Using GlideN64-3.0.

8

General Discussion / Re: 3.0 Alpha Testing

« on: May 27, 2015, 06:12:25 PM »

That would be the dithering. It's used more in older games, especially on the PSX. I don't know how feasible it would be to disable it.

9

General Discussion / Re: GLideN64 Android port

« on: May 24, 2015, 10:17:44 AM »

I know you've mentioned some of this already, but could you summarize the fundamental differences between the three variants?  In particular I'd like to know how much is lost going from GLES 3.1 to GLES 3.0.  Unless I can resolve the binary backward-incompatibility of APP_PLATFORM 21, we will not be able to get the GLES 3.1 variant into the master branch and on Google Play.

Also, if you could list which subset of settings should be displayed for each variant, I can go ahead and update that as well.

It'd be a nuisance, but if it comes down to that, it's possible to post multiple APK versions on Google Play under the same listing. Alternatively, it'd probably make the APK huge, but 2 sets of libraries could be included for armeabi-v7a and x86 (I don't see armeabi getting platform 21 or having GLES 3.X )

10

Support / Re: Please Add Rom Shortcuts

« on: May 20, 2015, 12:53:48 PM »

I think this is a reasonable feature since most other emulators have it. Something to automatically just run a game without selecting options when tapped on the home screen.

11

General Discussion / Re: GLideN64 Android port

« on: May 16, 2015, 12:40:36 PM »

@Paul I mirrored GLideN64 into the mupen64plus-ae repository and we are getting our first auto-builds of the gliden64-integration branch.  Unfortunately it looks like the native stuff isn't getting compiled.  Would you mind checking the build logs on your server?  Perhaps you might need to install additional Android SDK levels?

The ndk-build is failing with the following output:

Code: [Select]

jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::_addTexture(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:539:13: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'CachedTexture* TextureCache::addFrameBufferTexture()':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:559:15: error: 'TextureCache::Textures' has no member named 'emplace'
jni/./mupen64plus-video-gliden64/src/Textures.cpp: In member function 'void TextureCache::update(u32)':
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1277:10: error: 'std::this_thread' has not been declared
jni/./mupen64plus-video-gliden64/src/Textures.cpp:1281:10: error: 'std::this_thread' has not been declared
make: *** [obj/local/armeabi-v7a/objs/mupen64plus-video-gliden64/./mupen64plus-video-gliden64/src/Textures.o] Error 1
make: *** Waiting for unfinished jobs....
I'll grab the latest ndk version and see if that makes a difference.

You either need the latest ndk version or force GCC 4.8 or higher. I'm still on ndk r9d and forcing gcc 4.8 got it to build after experiencing that error.

12

Your Projects / A DOS etch a sketch program

« on: May 14, 2015, 09:53:52 PM »

Last summer I learned DOS 8086 assembly for some reason, and over the past few months I've been resurrecting an original 1982 compaq. I decided to port my VGA sketch program to CGA and improve it. Here is the basically finished source written for TASM: http://pastebin.com/LtYHUW2d

I might post an exe later

There are probably ways to make it more efficient, but it gets the job done, and it's nice to see it run on real hardware.

13

General Discussion / Re: GLideN64 Android port

« on: May 09, 2015, 10:45:13 PM »

My LG G3 also appears to accept the GLES3.0 commands.

14

General Discussion / Re: GLideN64 Android port

« on: May 04, 2015, 05:10:34 PM »

http://m.imgur.com/BXB9WbZ

15

General Discussion / Re: GLideN64 Android port

« on: May 04, 2015, 03:18:04 PM »

I have a build at the ready. (GLES3.0)

It's pretty slow, but fairly accurate. The puzzle piece effect in Banjo-Kazooie works fine.
I know this is an early build, but just wanted to note that Animal Forest has issues with 2D elements being nonexistant. However, the pause menu is already better in my opinion as the player character is displayed properly and the read from framebuffer effect in the background works, as opposed to random colors being displayed.

And there's this unsettling issue in CBFD: http://imgur.com/XHoK4WA,g6haqiy

(Building this version in eclipse is a bit of a pain. I had to mess around with the jar files and library dependencies).