Time for PC version release is come. All project supporters with perk "Early Release" will get link to archive with the plugin.
The archive contains the following builds:
- Win32 build for Mupen64Plus emulator. Put the dll file to emulator's folder and setup the emulator to use GLideN64 as graphics plugin. Run any rom. On the first run plugin creates settings section in emulator's configuration file. You may either edit it in text editor, or use one of Mupen64Plus frontends.
- Win32 build for Zilmar specs emulators: 1964, Mupen64, Project64 and others. Copy dll and ini files to emulator's plugin folder and setup the plugin to use GLideN64 as graphics plugin. Open video settigs configuration dialog and setup it for your taste. Read tooltips for options explanations.
- Ubuntu64 build for Mupen64Plus emulator. Making working binary distributive for Linux is tricky, so there is no warranty that it will work. Public release of the plugin will be open-source, and then you will be able to build the plugin from sources.
During development I solved literally hundreds of issues. More than hundred is still not fixed. If you want to open new bug report, please check already open issues first.
Public release will be two weeks after the "Early Release", stay tuned. I'm planing to spend these two weeks on code cleanup and preparations to Android port works.
Update: last minute optimization causes problem with saving hires-textures cache files. Hotfix will be uploaded soon. Sorry for inconvenience.
Congrats on the awesome work. Any idea if the Linux file will work for mac os? Having issues running mupen on a virtual machine. CheersReplyDelete
No, it will not. Mac OS X has strict reqs for creating GL 3.3 context. GLideN64 does not met them yet. I'm planing to work on it in parallel with Android port.Delete
Please please comment the code during cleanup. :)ReplyDelete
I'm maybe the only one but I've backed to read it. :D
All the code is in my local Git repository. Each commit has detailed description why it is made like this. I could not work on the code myself without it.Delete
The code itself is "self-documented" :) i'm too lazy to write comments.
Amazing work. Those screenshots look unreal. So glad I backed this.ReplyDelete
I'm happy that I worked on it. Best few months in my life.Delete
How to get texture packs working when using the new revisions of Project64? I think I have everything in the right place and have texture pack checked but it doesn't seem to be loading the texture pack.ReplyDelete
GLideN64 supports only texture packs in Rice format.ReplyDelete
Open Textures tab and check "Use texture pack" option. You may also select path to the folder with texture packs.
I did that and it wont work. Works in Project64 1.6 though but not in the new Project64 2.2 revisions.ReplyDelete
Nevermind, got it. Had to manually select location even though I thought it was already set to that location and it worked.ReplyDelete
I received my email but when I go to download the file its telling me I need to request access to the Google drive ! I have a Google account logged in but the email from you is on my hotmail account ?ReplyDelete
Please try again.Delete
Thanks I got it :)Delete
Great work man! Just curious, what's your plan after releasing glideN64? Do you plan on continuing your work as a hobby or do you consider it as finished and leave it as is?ReplyDelete
Can't say for sure. Family man has little time for hobbies. Remaining issues require hours of investigations. Even if I will have some free time, the things which I currently can do for a week will take half a year.Delete
Glad to hear! i think it's more then enough if you ocassionally take a look at the source and point people in the right direction and stuff.Delete
Wish you all the best with your new job and your family. Thx for everything you've done so far!
Great work. So much progress has been made. There's not much left from old glN64. Just playing Mario Tennis :)ReplyDelete
General architecture, texture loading code, most of gSP and gDP functions - in fact half of core code inherited from glN64. Core bugs were inherited too and caused lot of troubles.Delete
From user’s point of view there’s not much left. Orkin rewrote his plugin many times. Plugin architecture was important for him. I think he wanted to keep everything as simple as possible. I looked at the source a bit and everything looked clean and straightforward compared to other plugins like rice video (I think so but I haven’t done much with the code). But every rewrite introduces new bugs. I think some of them got fixed later in Direct64. But unfortunately there’s no source for it.Delete
Yes, clean and straightforward. That's why I choose it as a basis.Delete
What license is GLideN64 going to be released under?ReplyDelete
GLideN64 uses code from projects, which under GPL 2 and 3. So, it will be GPLDelete
I can't wait to try this out, awesome work! :3ReplyDelete
Better wait a bit when it will be even more awesome and stable. The "Early Release" was tested only for a week, and few serious issues left unnoticed.ReplyDelete
I must inform you of the state of android mupen64plus ae all development has come to a halt because Paul lamb has dissapeared he hasnt been online since December littleguy has tried to contact him but there has been no responce so a few of us at paulcode have been wondering if you would be interested in developmentReplyDelete
It's disturbing news. I tried to contact him this winter, but he did not answer. Paul is one of the main contributes of this project and I counted on his help with Android port. Who is in charge for Mupen64Plus AE atm?Delete
Hey,retroben here... I checked his user profile,and Paul was last on the site at March 27 2015,and the last thing he said in chat was about fixing the auto build issue related to the new branch.Delete
Because the lack of support for those few weeks,there has not been a single commit for that long while. :(
After your done with the android port of courseReplyDelete
Gonetz is there still any chance for a shader support and could you update xBRZ to 1.3?ReplyDelete
What do you mean by " shader support"?Delete
Post-processing shaders like DolphinFX or those shaders linked in the post above.Delete
Yes, I'd like to add support for this wonderful library of shaders. Unfortunately, it's already out-of-funds. Remaining funds are barely enough for Android port. Then I'll retire for search of new full time job. There is an option to open new campaign. I'd like to implement that feature and emulate N64 coverage feature. However, it is another few month of work, thus it needs several thousands of funds. I doubt that it is possible.Delete
What is that coverage feature doing and which games are using it? Pity about shaders. Is xBRZ update possible?Delete
Pixel coverage is a feature of N64 hardware. Additional per-pixel bits, which show how much of a pixel is covered by polygon. It's used mostly for anti-aliasing, but also required for correct depth compare and some games do not work correctly without it, e.g. https://github.com/gonetz/GLideN64/issues/141Delete
Regarding xBRZ: I used latest C++ implementation I could find. If you know more fresh C++ (not shaders!) variant, give me a link.
if your xBRZ implementation is already at 1.3 then that's okay. I thought it may be outdated because the 1.3 version come out a few days ago.Delete
Then my version is outdated. I added xBRZ filter several month ago. It works fine though.Delete
By the way I think the most urgent fixes needed are for Pokemon Snap , Body Harvest, Gauntlet Legends , Pokemon Stadium., Resident Evil 2 and Conker.Delete
The newest version of xBRZ is 45% faster and has support for images with alpha channel, improved color analysis and fixed alpha channel gradient bug.Delete
Like "SeanyP Plays Something" I'm also getting the page telling me to request access to download the file. I received the e-mail on my yahoo account.ReplyDelete
The Release is sent to indiegogo contributors, using their emails on indiegogo. If you can't download the file with that email, please send me a message on my email address with your indiegogo email and your google email.Delete
Where is the link to download the plugin?ReplyDelete
The Release is sent to indiegogo contributors. Check your email for download link.Delete
Gonetz, I have a question. Due to somebody leaking a few builds of your plugin, I now have a copy. I'm not a backer. And while I'm not really happy with how one or more backers have chosen to leak your unfinished plugin, I feel it's my responsibility to report the bugs and regressions I've found after a few hours of tinkering, and was wondering whether you would be okay with me filing some issue reports over on Github. Ordinarily, I'd wait until you release the public version, but you have said you won't have much free time to fix bugs then. Some are super obvious, like Toy Story 2 rendering coin and shadow sprites through walls and floors. Others are more subtle, like a lighting regression in Perfect Dark, a problem with Quake II when underwater, among other things.ReplyDelete
However, I'm willing to wait until public release if you only want to take bug feedback from backers.
Bugtracker has 100+ open issues. It's already too much. New reports just bring new chaos because it distract my attention.Delete
Okay, then, Gonetz. I'll wait until public. Best of luck over the coming week or so.Delete
First of all - congratz on getting closer to an official release :)
I must say I have one concern though. You said before you based your plugin on GPL'ed code - which means (as you said) your plugin would be licensed via the GPL too. This probably means all the binaries which you distributed so far are licensed like this. However, nowhere so far I have seen references to the source code - which is against the term of the license in fact.
I know you said you were going to clean up the source code and stuff, but the GPL says that people could request the source code of a particular binary build (such as the ones which have been "leaked" - i.e. legally redistributed by the terms of your license ;) ). That's actually one of the main points of choosing that license in the first place.
Unless I'm seeing something wrong, you should hence upload the sources of those binaries right now. I know it's besides your original intentions, but it'd be unfair to everyone to base your project on GPL'ed code, yet not actually follow that license properly. It won't do any harm anyway - so what do you think? :)
I think that source code will be release along with the public release. Not earlier.Delete
I understand you feel uncomfortable about releasing the source code now. Do you understand that you're strongly violating the GPL terms, though?Delete
You distributed GPL-licensed builds to your backers. Some of those backers legally redistributed those builds on reddit. Hence, I (and others) are able to (legally) acquire a copy of your plugin, and have a right to take a look at the source code. If you feel unhappy about publicly distributing the source, would you at least be kind enough to give the source code to the people who explicitly ask for it? That's the very least you're required to do by the license, and anything else is a blatant violation.
If I was an author of any of the code you wrote, I'd be pretty pissed off to see people ignore the license like this. It's actually happened quite often to me before, so I'm trying to educate software authors about this. Also: Why publish binaries of your plugin in the first place if you're not willing to provide the source?
 they have to be GPL-licensed if you based your work on GPLed code, which is the case as you said above
 redistribution is explicitly allowed by the GPL (that license very much encourages this, in fact)
 To be more explicit: Please send me a copy of the source code.
 Please don't ever chose to use GPL-code if you're unhappy with this.
Don't worry, the code will be available. The project has GitHub repository:Delete
You may download the sources from here.
Read carefully project roadmap:
Source code is for Public Release.
If you unhappy with that source code policy, please stop using my builds.
And stop provoke me.
It wasn't my intention to offend you, so sorry if it came across like that. My sole interest is in getting proper acknowledgement of the GPL terms.Delete
I was aware that you were going to eventually release the source code. It doesn't matter though, since you're distributing binaries right now. By the GPL you're *required* to release the source *now*, and not in a few weeks or so. That's what you chose to go for when you based your plugin around GPLed code, so please don't blame my well-meant explanation for the consequences of your choices.
You made the choice to use the GPL and now are not following the rules implied by that. I could understand that someone wouldn't release the source by lack of knowledge about the GPL, but seeing you choosing not to comply to the license terms even after being pointed out the violation is hugely disappointing.
Ohh... I expected that. Every time I'm trying to make people happy copyright purists are trying to f.k my brain. Please read project roadmap again : "the project ready for public release if the following conditions are met: ... Source code is clean, free and open-source, licensed under the GPL" Currently source code is not clean, not open source and not licensed under GPL. Thus, there is no public release yet. There is no public binary distribution. Nothing to discuss. Sorry for disappointing you. I'm working in accordance with the project plan.Delete
Just for the record, this has nothing to do with purism, but with someone lacking understanding of a license and using it regardless.Delete
Either way, thanks for replying to my comments. That's still better than silently ignoring people criticizing your work.
"Every time I'm trying to make people happy copyright purists are trying to f.k my brain. "Delete
He is right though and you aren't being entirely reasonable here. As soon as you release public binaries of GPL-derived works, source must also be released.
I don't see what you have to lose in just complying with the GPL license. At best it will get a tiny but vocal minority of people off your back that want to see the terms and stipulations of the GPL license followed to the letter, at worst the world gets to see some slightly messy code. But nobody ever complained about id Software's codebases being full of messy legacy code when their source got released and it isn't as if that deters people from making sense of the code.
Honestly I think by not complying with the license from Day One it just makes you look bad and it also makes that $8K paywall look more and more suspect. I don't think it is worth to be flushing goodwill down the toilet like this and I think you should consider because the entire N64 community loses face by your actions. "Just slightly better than Shunyuan/Pokefan" is not what you should be aiming for here in terms of moral conduct.
After further discussion elsewhere, this matter has been resolved:
I just want to say thank you to gonetz for this.Delete
I won't be using or looking at the source code until after the official release, but I'm still glad that this happened and is resolved.
Hey, neobrain, Daniel.Delete
Stop being asshats. He gave you this link in his second response: https://github.com/gonetz/GLideN64
All you had to do was click the releases tab, and you would have arrived at the link you posted: https://github.com/gonetz/GLideN64/releases
All I see is a bunch of whiner-baby complainers. Did you help with the code? No. Did you back the project? Unless it was anonymously, then no. In which case you haven't received any of the prior releases and haven't helped debug either. So why don't you get the fuck out of here with that shit and let Gonetz continue his awesome work and take suggestions from the backers first? You'll get your chance to complain later after the official release.
Gonetz, mad work! I haven't been in the N64 emulation scene in years. Between PJ64 2.2, HatCat's RSP, Azimer's Audio and your new GLideN64 graphics plugins, I'm having some high hopes that games will run just a little bit smoother. Back when I was into things, I had trouble running Banjo-Kazooie. So I'm excited! Thanks!
*sigh* the source is available at that link only because we asked gonetz to put it there.Delete
Cody Brant, thanks for the words of support! It really helps.Delete
The problem with source code is settled. All arguments already said, Thus, I suggest to not touch that problem anymore even with ten feet long stick.
The idea to postpone complains until the official release is the right one :)
It's not so long to wait.
You're alright gonetz! I hope your indiegogo campaign picks up again so you can work on this more, if it doesn't, its cool. Either I thank you for all your hardwork.ReplyDelete
I zoomed into those pics and I have no clue how you made Zelda look like that - (and maybe I'll be needing a monster computer to just render at that quality), so to me, this is all magic! I hope the 100+ remaining bugs will be fixed by other people when the plugin goes public and I wish you well on finding a Job you enjoy doing and bringing up your family! Take Care!
Regarding the screen shots: it's djipi's texture pack + widescreen hack + fsaa. Any modern PC is capable to perform that magic.
Thanks gonetz, as for settings options in the GLideN64.custom.iniReplyDelete
Is it possible to add option (forgive me if it already exists) to define game aspect ratio?
For the handful of games that natively work with widescreen I'd like to set that automatically, the games that work acceptable with your widescreen hack set that, otherwise default to 4:3
Love your work, playing with texture packs at the moment, had a few issues but all textures seem to be loading fine now I've increased the memory to 800MB and disabled cache compression
General and custom sections of the ini files are loaded by the same code. That is you may add any setting to the custom section of the game. Official custom ini includes only settings, which are essential for correct work of the game. You may add anything you need including the aspect ratio. I also plan to split the custom ini on 2 files: the official custom ini with only necessary settings and user ini, which user can modify using the GUI.ReplyDelete
First of all. A very big thank you to all of your work and efforts.ReplyDelete
It's incredible what you have done.
But I have also a question.
I am using m64py and the newest build of mupen64plus.
Can I use the custom.ini there as well? What do I have to do in order to configure mupen64plus to use gliden64? The section in the cfg file is created but it's empty.
Thanks you so much for this great plugin. :-)
Custom ini section for mupen64plus is not implemented yet. Currently plugin keeps all its settings in emulator's main configuration file. That set of settings is static. Custom ini is dynamic. It can't be hardcoded and stored in the main config. Thus, I need to write special code to load external custom config file and parser for it. It is currently low-priority task, because I'm overloaded with other stuff, sorry.
You don't need to be sorry, these things happen and you're doing amazing work.Delete
This comment has been removed by the author.ReplyDelete
Cant wait to play zelda and paper mario with this next day:D public release babyReplyDelete
We are working hard to make it worth your expectations.Delete
I hope the texture corruption issues in Mystical Ninja64 I've seen on the Github get fixed soon ;) Just saying ^_^ReplyDelete
Unfortunately, not sooner than the first release. Too much hot problems.Delete