PDA

View Full Version : Project64 2.0 is now available and open source!


Pages : [1] 2

zilmar
1st April 2013, 05:18 AM
The beta program is now closed. You can now install project64 2.0 and get the clone the source if you want to.

You can download Project64 from:
www.pj64-emu.com

the source can be cloned via git at:
http://www.pj64-emu.com:8090/project64.development

squall_leonhart
1st April 2013, 05:31 AM
if this is legit, good, means someone can fix the crap out of the mess you made of the recompiler.

though im going with april fools joke right now, since fobbing alpha quality emulators as release quality is a nasty joke

Mdkcheatz
1st April 2013, 05:39 AM
Dude, just compile the damn thing and try it.... You know you want to

Kodiack
1st April 2013, 05:52 AM
Delta toolbar? Iminent Minibar? Yay bloatware/adware!

But seriously, this is awesome news, assuming it's not an April Fools' joke. Even if it was an April Fools' joke, I would disgustingly approve because it would be a well-played one. Can't wait to boot over into my non-work partition with all my dev tools and compile it!

Mdkcheatz
1st April 2013, 06:00 AM
There's only one way to find out if it is a joke or not :)

squall_leonhart
1st April 2013, 06:05 AM
The only joke going on here is the cruel release of alpha quality software.

Mdkcheatz
1st April 2013, 06:14 AM
The only joke going on here is the cruel release of alpha quality software.

Alpha quality software can be turned into post-beta quality software in a pinch.

APE
1st April 2013, 06:15 AM
The only joke going on here is the cruel release of alpha quality software.

Rarely does one see such a prime example of a tool bag.

squall_leonhart
1st April 2013, 06:18 AM
Alpha quality software can be turned into post-beta quality software in a pinch.


Yeah, at this point the only good thing here is the source code, i'll toss death-droid a link to it and get it hosted on a decent SVN provider, then rally the troops to work out the bugs in this woeful recompiler.

zilmar
1st April 2013, 06:25 AM
i'll toss death-droid a link to it.

he has had write access to the branch for months already.

dsx_
1st April 2013, 06:29 AM
if this is legit, good, means someone can fix the crap out of the mess you made of the recompiler.

though im going with april fools joke right now, since fobbing alpha quality emulators as release quality is a nasty joke

if its so bad, you fix it

Mr. DOS
1st April 2013, 06:38 AM
I'd say its a crude april fools day joke. Considering that the site was down most of March 31st showing just a "Joomla" CMS logo it does make me wonder if it was legitimate or not.

Maybe, but it's also a functioning copy of the emulator that doesn't require a paid user account to download and use.

I would like to note, though, that:

> git clone git://pj64-emu.com:8090/project64.development/ project64
Cloning into 'project64'...
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

...does not build confidence in ones' open source release.

zilmar
1st April 2013, 06:46 AM
> git clone git://pj64-emu.com:8090/project64.development/ project64
Cloning into 'project64'...
fatal: Could not read from remote repository.


...does not build confidence in ones' open source release.

try
> git clone http://pj64-emu.com:8090/project64.development/ project64

Mr. DOS
1st April 2013, 06:47 AM
try
> git clone http://pj64-emu.com:8090/project64.development/ project64

> git clone http://pj64-emu.com:8090/project64.development/ project64 -v
Cloning into 'project64'...
error: Connection time-out while accessing http://pj64-emu.com:8090/project64.development/info/refs?service=git-upload-pack
fatal: HTTP request failed

I'll try again later. Glad to hear it's just a problem on my end and not the release being a hoax, though :)

zilmar
1st April 2013, 06:56 AM
i found a thread that some one had with a different repository.


You'll need to upgrade your git client to be at least version 1.6.6.

That error is caused by older versions of git not understanding the
Git Smart HTTP protocol

not sure if it applies to you

Mr. DOS
1st April 2013, 07:16 AM
not sure if it applies to you

> git --version
git version 1.8.0.msysgit.0

Doesn't look like it should, but my Git binary comes from GitHub for Windows, so the actual problem may be related not just the Git release but also a library or something.

zilmar
1st April 2013, 07:29 AM
yer I am not sure ....

this is what I get.
D:\bug>git --version
git version 1.7.11.msysgit.1

D:\bug>git clone http://pj64-emu.com:8090/project64.development/ project64
Cloning into 'project64'...
remote: Counting objects: 6211, done.
remote: Compressing objects: 100% (3157/3157), done.
remote: Total 6211 (delta 4879), reused 3995 (delta 3032)
Receiving objects: 100% (6211/6211), 27.28 MiB | 336 KiB/s, done.
Resolving deltas: 100% (4879/4879), done.
Checking out files: 100% (565/565), done.


maybe there is something I have done wrong with the setup. Not Sure

Mr. DOS
1st April 2013, 08:00 AM
Client issue of some sort. I was able to clone the repo just fine from another machine.

And finally on-topic, thanks so much for deciding to release the project source again. I hope it pays off for you in terms of new contributors, but even if it doesn't, the educational benefit of being able to peek inside the guts of an emulator such repute as Project64 is incredible.

zilmar
1st April 2013, 08:28 AM
Client issue of some sort. I was able to clone the repo just fine from another machine.

I am glad you got it working, cause I was not sure how to fix the problem

And finally on-topic, thanks so much for deciding to release the project source again. I hope it pays off for you in terms of new contributors, but even if it doesn't, the educational benefit of being able to peek inside the guts of an emulator such repute as Project64 is incredible.

if you compare the original source of the main emulator to this version you will see the code is very different. A lot more cleaner and easier to manage. Hopefully you able to learn something off it.

MarathonMan
1st April 2013, 01:18 PM
Also managed to clone successfully. Thanks for putting the source out there, Zilmar.

Was this announced? I thought the source was staying closed?

Shookit
1st April 2013, 01:44 PM
I just registered to say, thanks for your contribution to the open source community on this. I was a holdout on donating because I preferred to support open source projects such as Mupen, but now that PJ64 is open sourced, do you have a donation system in place?

Hero
1st April 2013, 01:54 PM
Thank you for including the optional overclocking function, that was a pleasant surprise.

ExtremeDude2
1st April 2013, 02:40 PM
The 7th and current public release of Project64.

seams legit :rolleyes:

Thank you for including the optional overclocking function, that was a pleasant surprise.

orly?

the_randomizer
1st April 2013, 03:08 PM
seams legit :rolleyes:



orly?


Just downloaded it and it does indeed say "PJ64 version 2.0" in the window. Loads games just fine...yup, it's legit, just like how 1.6 was released on April 1st and everyone thought it was fake. :D

Kintaroo
1st April 2013, 03:43 PM
Wow, I didn't expect this ~

Lets see what will happen now ~
~~~~
One Question:
is it the normal V2.0 which the Beta users allready could get too
or is it also with the changes up to 2.014?

and Will you continue to work on it or did uh open it cuz you're tired of N64?

Thanks for your work anyway !!!!!

Because of you I had so many happy hours ^_^

ExtremeDude2
1st April 2013, 09:18 PM
Just downloaded it and it does indeed say "PJ64 version 2.0" in the window. Loads games just fine...yup, it's legit, just like how 1.6 was released on April 1st and everyone thought it was fake. :D

lern 2 read :p

When I said "seems legit" I was referring to 1.6

As for the OC'ing I am sceptical about what he said as I've never seen said option

zilmar
1st April 2013, 09:38 PM
One Question:
is it the normal V2.0 which the Beta users allready could get too
or is it also with the changes up to 2.014?

and Will you continue to work on it or did uh open it cuz you're tired of N64?


it is everything up to 2.0.0.14.

Yes I will still work on it .. tho it will be like the old beta program sometimes I will work on it more than other times. Which means not at all some months :P

I will still most likely release new versions as beta/alpha still, tho the beta program will be via invite only now (any one who previously was a beta still gets to keep that status).

extrahotchilipowder
2nd April 2013, 03:06 AM
This is awesome news! Thanks so much for open sourcing the project! I really hope it pays off, and I really hope someday I could contribute something to the project myself.

Now if I may be a noob for brief moment ... Are there any external dependencies not included in the source?

I've only had the source for few minutes now. Anyone else tried it out yet? I'd be interested to hear if anyone has any tips for getting it to build in VS 2012?

I'll definitely share my experiences if I have anything of use to share.

Mdkcheatz
2nd April 2013, 03:16 AM
seams legit :rolleyes:

oh yeah, Zilmar I see the problem. Under the binary section to download you have "current release" meantioned for both v1.6 and v2.0. That's just a typo because the new one was updated and the old one left as it was accidentally.

Extreme, that wasn't meant to indicate any kind of prank.

I love how people seem so sure that this is a prank, they missed the point of the real prank (how you released the source code when people didn't expect it).

I would say the prank ended up very successful! People that are so paronoid that this is some kind of joke end up missin out on a completely serious release. :D

Mdkcheatz
2nd April 2013, 03:22 AM
Now if I may be a just a normal person asking reasonably for brief moment ... Are there any external dependencies not included in the source?

Yes, there are. The source includes the core application which does depend on external plugin developed by whoever wants to make them. You can use the plugins Zilmar has uploaded for the public releases.

Skorne
2nd April 2013, 03:47 AM
Gauntlet Legends doesn't work :/

RachelB
2nd April 2013, 04:43 AM
What license are you releasing this under? I see no mention of one anywhere.

zilmar
2nd April 2013, 05:10 AM
I never did change the header of the rsp files ..

but the main emu is gpl v2 and the rsp should treated the same

Mdkcheatz
2nd April 2013, 05:12 AM
What license are you releasing this under? I see no mention of one anywhere.

Open sourced, for non-commercial use (what zilmar said) ^

RachelB
2nd April 2013, 05:43 AM
I never did change the header of the rsp files ..

but the main emu is gpl v2 and the rsp should treated the same

Excellent! Thank you.

squall_leonhart
2nd April 2013, 07:32 AM
it is everything up to 2.0.0.14.

Yes I will still work on it .. tho it will be like the old beta program sometimes I will work on it more than other times. Which means not at all some months :P

I will still most likely release new versions as beta/alpha still, tho the beta program will be via invite only now (any one who previously was a beta still gets to keep that status).


I honestly think much of the current 2.0 stuff should be scrapped and work should be started from where it left off with 1.7.51 alpha.

The way memory is managed has to go as well, there are modern ways to do much of it that won't have the same cache aliasing issues that the current code has.

With what Marathonman and Iconoclast are contributing, more accurate recompilers can be made given time - and now that the source is opened to allow developers to contribute frequent fixes, it won't be so impossible to remove the audio timing hackery that went into 2.0 and replace it with properly calculated timings.

Mr.64
2nd April 2013, 08:10 AM
I've done some testing
advanced block linking breaks Tonic Trouble, John Romero's Daikatana and Pocket Monsters Stadium

squall_leonhart
2nd April 2013, 08:19 AM
its not enabled for those games in the first place.

replace the rdb!

Mdkcheatz
2nd April 2013, 10:23 AM
Pocket Monsters Stadium

I didn't know you spoke Japanese. (ポケモンスタジア o-o

Mr.64
2nd April 2013, 11:11 AM
I'm using the rdb that came with the installer
also Linking=0 seems to do nothing in the rdb, it only gets applied in the cfg file but maybe I am doing it wrong :\

I didn't know you spoke Japanese. (ポケモンスタジア o-oI can't speak Japanese but I have some Japanese games

squall_leonhart
2nd April 2013, 11:25 AM
Thats odd

anyway, NekoKabu has a newer rdb on the emutalk forum, you should use that instead.

the_randomizer
2nd April 2013, 03:04 PM
Tried the 1.7.0.x versions and they all crashed to hell, but 2.0.14, games that ran on that didn't run properly on the 1.7.x betas and the audio had issues, but not anymore.

zilmar
2nd April 2013, 03:58 PM
I'm using the rdb that came with the installer
also Linking=0 seems to do nothing in the rdb, it only gets applied in the cfg file but maybe I am doing it wrong :\

I can't speak Japanese but I have some Japanese games

the rdb matches the 1.6 format, so it should be Linking=No

(tho I hate adding those to the rdb because it is only needed because of a bug, maybe it should be there but I personally try to fix any bug that needs that there)

Mr.64
2nd April 2013, 08:03 PM
advanced block linking also breaks Golden Nugget 64
will you make a bugfix release?

eclenaeu
2nd April 2013, 09:26 PM
advanced block linking also breaks Pokemon Stadium - Kiosk (U) , Fighting Force 64 is very fast, how fix?

mistamontiel
2nd April 2013, 09:44 PM
Wow lol.. why bloat installers.. for what purpose.. archive that shit

Archive alllllllllllll and thanks

Mdkcheatz
2nd April 2013, 11:05 PM
I'm using the rdb that came with the installer
also Linking=0 seems to do nothing in the rdb, it only gets applied in the cfg file but maybe I am doing it wrong :\

I can't speak Japanese but I have some Japanese games

In the bit world, 0 represents off. 1 represents on. Linking=0 by definition signifies nothing. Linking=1 on the other hand opens the door it represents. Except obviously as Zilmar said his formatting spells out something else.

I can't speak Japanese either, I was just messing with you because Pokemon is only called Pocket Monsters in Japan.

mistamontiel
2nd April 2013, 11:14 PM
What's up with all the input plugins in the list ? There's only one in the Plugin\Input directory

The default crap is not remembering my controls.. every time I close rom then load again or any other my controls just vanish and I have to load every. single. time.

the_randomizer
2nd April 2013, 11:18 PM
The audio issues in Killer Instinct Gold have returned, but were nonexistent in 2.0.14 alpha.

What's up with all the input plugins in the list ? There's only one in the Plugin\Input directory

The default crap is not remembering my controls.. every time I close rom then load again or any other my controls just vanish and I have to load every. single. time.

Use N-Rage V2 1.80a instead.

Mdkcheatz
2nd April 2013, 11:19 PM
Wow lol.. why bloat installers.. for what purpose.. archive that *jit*

Archive alllllllllllll and thanks

Why? Because we all have to realize at the end of the day Zilmar is a real person with a real life. Life is precious and time spent is valuable. He put effort into making the source code so he deserves some kick back. He's open sourced the project for the most part so the only way to effectively gain kick back is by the little revenue he'll get from adware.

The adware is not a virus. Just a little token of appreciation to years of hard work to the developer. So it's this or closing the source and implementing a paid beta system as the only legit means of keeping up to date with the newest releases. Personally, this current option is fair in more ways than not. You feel me bro?

mistamontiel
2nd April 2013, 11:24 PM
Even the gfx plugin hardly remembers anything.. only res. I set Aspect display to Stretch, I check the two texture boxes and those settings vanish every time I load rom.

Thank you Zilmar and all the devs

EDIT: Is this because every blasted rom needs setting ?

bryc
3rd April 2013, 06:09 AM
Oh awesome! I finally get to fiddle around with the lovely debugger features. :)

the_randomizer
3rd April 2013, 06:45 AM
Even the gfx plugin hardly remembers anything.. only res. I set Aspect display to Stretch, I check the two texture boxes and those settings vanish every time I load rom.

Thank you Zilmar and all the devs

EDIT: Is this because every blasted rom needs setting ?

There is per ROM configuration, yes.

Melchior
3rd April 2013, 08:19 PM
Wow O_o ^_^

Predator82
4th April 2013, 07:31 PM
Is this coming to googlecode?

zilmar
4th April 2013, 07:44 PM
Is this coming to googlecode?

If I was going to change it off the server I would move it to github

Predator82
5th April 2013, 06:46 AM
Donīt like git but itīs ok

squall_leonhart
5th April 2013, 07:58 AM
github you can download master zips atleast

with gcode though, you can maintain a git and svn clone at once.

squall_leonhart
5th April 2013, 09:05 AM
@ Zilmar

is there any way to set the RSP Method per game?

Rogue Squadron will only work if

[RSP]
CPU Method=0

is set in the Pj64 core settings.

Seting the CPU Core Style in rom settings does not get the game started.

simke85
5th April 2013, 04:23 PM
Zimlar and Jabo, thank you vary much for this excellent emulator! I played many excellent Nintendo 64 games with Project 64 1.6 thanks to you!

One question: is it now better to switch to 2.0 version or to stay with 1.6 when playing Nintendo 64 games, I have old computer (1.7 GHz, 512MB RAM, ATI 9600Pro,...)?

squall_leonhart
5th April 2013, 04:50 PM
stick to 1.6, your computer is not up to running 2.0.

dsx_
6th April 2013, 07:26 AM
stick to 1.6, your computer is not up to running 2.0.

http://dsxcorner.com/emulation/pj6420014.jpg

HatCat
6th April 2013, 05:06 PM
If people can afford a $1500 gaming PC, they can afford a $50 N64...

Mdkcheatz
6th April 2013, 05:53 PM
If people can afford a $1500 gaming PC, they can afford a $50 N64...

You can't assume this. Maybe their $1,500 gaming PC was a gift? How do you know they paid for it?

HatCat
6th April 2013, 06:49 PM
He said "afford", lardass.

Hero
6th April 2013, 08:17 PM
He said "afford", lardass.
You can't assume everyone knows what that means.
FOR GOODNESS SAKE FATCAT

HatCat
6th April 2013, 08:23 PM
*purring*


edit: heh, well you assumed that I assumed he knew what it meant :D
Maybe I didn't care

edit befire edit: o wait I assumed that you assumed

Hero
6th April 2013, 08:29 PM
http://3.bp.blogspot.com/_FJKP4nNYgQ4/SpybjX-TJkI/AAAAAAAACXk/j7RYrhzgedE/s400/Confused_dog.jpg

HatCat
6th April 2013, 08:31 PM
http://25.media.tumblr.com/tumblr_mdymzsbnjo1r88n60o1_500.jpg

Mdkcheatz
7th April 2013, 03:50 AM
He said "afford", lardass.


af·ford**
/əˈfôrd/
Verb
Have enough money to pay for.
Have (a certain amount of something, esp. money or time) available or to spare.


I can see that...

And I said you can't assume that someone has "afforded" the computer they are using. Which CLEARLY is what it was an implication of an assumption based on reading someone's computer specs.


Edit: just in case you falsely interpret my comment AGAIN, I'm not saying you can't assume in general. You just can't assume that someone has afforded something. "Afford" does not mean you didn't assume, and in most cases is actually assumed, ESPECIALLY online.

HatCat
7th April 2013, 03:57 AM
Never saw the word "if" in dsx!'s post?


How is that making an assumption, saying if you can afford a $1500 PC?

I don't even give a shit about his signature. :D
I just felt like blatantly copy-pasting his signature when he challenged squall's insight on computer specs.

too long, don't read :)

Mdkcheatz
7th April 2013, 04:05 AM
Never saw the word "if" in dsx!'s post?


How is that making an assumption, saying if you can afford a $1500 PC?

I don't even give a shit about his signature. :D
I just felt like blatantly copy-pasting his signature when he challenged squall's insight on computer specs.

too long, don't read :)

"if" doesn't negate an assumption. Regardless, You clearly don't want me talking to you, your actions are pretty clear. For a reason I have no clue. So stop pretending like you care by communicating with me...

HatCat
7th April 2013, 04:11 AM
"if" doesn't negate an assumption.

So? You quoted an "if" inquiry, saying, "You can't assume that"; there was no negation, assumption, or subjectivity to negation.
There was only tl;dr, copy-pasta, an "if" clause that stated nothing and therefore can't assume, and your hallucinations.

Now be a good boy and stop pretending like you care to communicate even if it means arguing something you know is wrong. :D

Mdkcheatz
7th April 2013, 04:17 AM
Now be a good boy and stop pretending like you care to communicate even if it means arguing something you know is wrong. :D

I'm not pretending. I tried every effort of anything reasonable to get through to you. All attempts were either ignored and/or intercepted by technical failure. I care - you don't. Simple.

Edit: I care because someone I thought was my friend decided to erase connection to me based on some unknown misconception.

HatCat
7th April 2013, 04:59 AM
non-controversial signature

dsx_
7th April 2013, 05:01 AM
that was quick :P

HatCat
7th April 2013, 05:02 AM
non-controversial signature

Don't assume things, lardass!

Now get back on-topic!

dsx_
7th April 2013, 05:05 AM
Now get back on-topic!

Project64 2.0 is now available and open source!

Mdkcheatz
7th April 2013, 05:13 AM
It would be nice to eventually work on getting all the plugins open source too. Seems to really help out when times seem slow.

HatCat
7th April 2013, 05:15 AM
Project64 2.0 is now available and open source!

if its so bad, you fucking fix it


Heh Now let's see, where was that page talking about how to clone it in Git for n00bs like muah...

try
> git clone http://pj64-emu.com:8090/project64.development/project64

WOOOO! It's working.

Anybody who doesn't know jack crap about Git, read this.
It worked even for me.

[edit to reply to mdk]

It would be nice to eventually work on getting all the plugins open source too. Seems to really help out when times seem slow.

Perhaps.
There is not a necessity for every single thing to be open-source although that could be of help.

Intelligence is the most important thing.
The ability to teach ourselves, in the absence of all the information being immediately given to us.

But, you could argue that point.

Mdkcheatz
7th April 2013, 05:23 AM
Perhaps.
There is not a necessity for every single thing to be open-source although that could be of help.

Intelligence is the most important thing.
The ability to teach ourselves, in the absence of all the information being immediately given to us.

But, you could argue that point.


Yeah not a priority. At least not at the moment. Itelligence helps, sometimes you just need that missing link though to articulate results :D

HatCat
7th April 2013, 03:34 PM
So how many people here can honestly say that they downloaded the source code, before installing Project64 2.0 off the site?

Because I honestly have yet to install Project64 2.0 off of the public downloads.
Not an intentional delay, just absent-minded procrastination.

Yeah not a priority. At least not at the moment. Itelligence helps, sometimes you just need that missing link though to articulate results :D

I think of open-source as a personal benefit more often than a global benefit.

Inspires you to take notes, jot down your thoughts everywhere, debate with yourself in your programs, have conversations with yourself.

It's literally as easy with closed-source except you're not as inclined to keep comments and make everything presentable and readable.

I usually like programming as an art.
It looks beautiful, sometimes.

I even took a long break from emulation and made a few trigonometry/geometry self-teaching JavaScript programs, to get computers to think of math like humans, because math stuff in high-level languages is artistic.

If programming was meant to be ugly I might not tend to just open-source things by default.

Sometimes knowing the official names, the intended meanings, things reversing might not explain, helps lead us to conceptual, concrete conclusions, though it's probably way funner to reverse the stuff (assuming success).

robinhood2013
7th April 2013, 04:30 PM
So far I've tried two ROMs (FIFA 98 and NHL 99) on the new Project64 2.0, and I regret to inform you that with both Jabo's (the default) and Aristotle's Mudlord and Rice Video plugins, the video emulation is completely wrong. Now, I am pleased that the new version will start and run with Windows 7 -- version 1.6 was refusing to start at all -- but unfortunately, I've found the plugins that come with this new version, as well as those I download from the Internet, are horrifyingly obsolete.

What's the deal here?

HatCat
7th April 2013, 04:41 PM
meh


Thread is becoming another case of Plugin64-Dev.

So far I've tried two ROMs (FIFA 98 and NHL 99) on the new Project64 2.0, and I regret to inform you that with both Jabo's (the default) and Aristotle's Mudlord and Rice Video plugins, the video emulation is completely wrong. Now, I am pleased that the new version will start and run with Windows 7 -- version 1.6 was refusing to start at all -- but unfortunately, I've found the plugins that come with this new version, as well as those I download from the Internet, are horrifyingly obsolete.

What's the deal here?

One of those two had a ucode support issue last I checked.

Either way you should try Glide64 or a LLE graphics plugin.

Mdkcheatz
7th April 2013, 07:08 PM
Hm, this Windows 7 problem raises some questions. For me and many, Windows XP and Windows 2000 is the preferred option, but here I can't assume everyone is capable of installing those OS accurately. What to do about this?

MILAD_786
7th April 2013, 08:33 PM
Hi everyone! im new to N64 emulation and I installed Project64 2.0 today I am playing Pokemon Stadium and it is running fine. However I would like to use a plugin to use my Gameboy save files BUT for some reason I wont be able to because I dont have any subdirectories for Project64! There is no saves, 3rd party plugins etc folders in my Project64 folders! Can someone please help me?
:(

I am running on Vista if that helps

HatCat
7th April 2013, 09:23 PM
Look. I don't own this thread, or this forum.
But, can we keep progress-, source- or development-oriented discussion here, or basic feedback about the 2.0 system?

I don't like being forced to ignore people, but I would rather relevant discussions not become disorganized (never mind the fact that I just finished fucking around on the previous page :D).

So, last indication.
Try to use the 2.0 forums zilmar just made. Those are for program questions.
How to play Pokemon goes in the 2.0 support forums.

That being said, new thread or avoid posts.

Hi everyone! im new to N64 emulation and I installed Project64 2.0 today I am playing Pokemon Stadium and it is running fine. However I would like to use a plugin to use my Gameboy save files BUT for some reason I wont be able to because I dont have any subdirectories for Project64! There is no saves, 3rd party plugins etc folders in my Project64 folders! Can someone please help me?
:(

I am running on Vista if that helps

If you have no subdirectories in the install path, you may be running Windows Vista, Windows 7, maybe 8, as an administrator of your machine.

A typical cause for the VirtualStore directory re-mapping.
The actual saves, files, etc. for PJ64 data will be elsewhere on your hard disk, what, C:\Users (or C:\Documents and Settings\) your username, app data, local, virtualstore, it was posted online somewhere tl;dr.

I'm not discussing it further within this exact thread, sorry.

MILAD_786
7th April 2013, 09:35 PM
Thanks for replying FatCat. Im new here and it wont make me a thread but I still dont know what to do :( I'll go onto a different page :)

MILAD_786
7th April 2013, 09:38 PM
Eureka! Thanks FatCat I found the files it was in my C Drive in the PJ64 folder but not in my all programs sections :) Thanks!

HatCat
7th April 2013, 10:31 PM
Cool, nice topic.

Nice enough to gets its own thread.

Thanks for replying FatCat. Im new here and it wont make me a thread but I still dont know what to do :( I'll go onto a different page :)

No, no, not the Site News forum.

You have to be cool like me to make new threads there.
(Either that, or a moderator like zilmar. But preferably cool like me.)

http://forum.pj64-emu.com/forumdisplay.php?f=2
Try going there next time and clicking "New Thread" up the top.

Mdkcheatz
8th April 2013, 12:37 AM
No, no, not the Site News forum.

You have to be cool like me to make new threads there.
(Either that, or a moderator like zilmar. But preferably cool like me.)

Lmao, it's all in the name. Which yours has evolved over the years. Anyway, aside from the frustration of derailing the intended topic, I just realized that there's a forum specific for version 1.6, 1.7, alpha (not viewable by regular members, cheat support (also hidden to regular members) and open discussion, but none for the 2.0 release (besides the alpha forum but this 2.0 is a public release not an alpha. (I'm combining forums for 1.7, and I know there's a site news forum, just figured I'd mention before I get torched)

ExtremeDude2
8th April 2013, 02:06 AM
But they say 2.0...:eek:

Also why is 1.6 under beta forums? :p

HatCat
8th April 2013, 03:28 AM
But they say 2.0...:eek:

Also why is 1.6 under beta forums? :p

Is it under Beta Forums?

It looks to me like the Beta Forums category is empty/null.

http://ft.trillian.im/785abe041074fd64135ab3318aff1ec8767ab03d/6fIt1IyvxGb5ej2nWOs0tw7knAnqn.jpg

robinhood2013
8th April 2013, 04:24 AM
Glide64 is no help to me at all -- Project64 doesn't even recognize that the plugin exists in the "Plugins\GFX" subfolder. Am I doing something wrong here?

Mdkcheatz
8th April 2013, 04:51 AM
But they say 2.0...:eek:

Also why is 1.6 under beta forums? :p

Yeah now they do. Zilmar must have updated the forums' titles.

Now there's nothing under beta section.

Mdkcheatz
8th April 2013, 04:54 AM
Glide64 is no help to me at all -- Project64 doesn't even recognize that the plugin exists in the "Plugins\GFX" subfolder. Am I doing something wrong here?

So you're saying that the option to use glide64 doesn't even appear in the options?

robinhood2013
8th April 2013, 05:45 AM
Yes. That is exactly what I said. Even with the glide64 plugin installed in the proper folder, and after stopping and restarting Project64, returning to Options > Settings > Plugins, and clicking the Video (graphics) plugin drop-down list, I don't see the glide64 plugin as an available option.

Mdkcheatz
8th April 2013, 06:18 AM
Yes. That is exactly what I said. Even with the glide64 plugin installed in the proper folder, and after stopping and restarting Project64, returning to Options > Settings > Plugins, and clicking the Video (graphics) plugin drop-down list, I don't see the glide64 plugin as an available option.

What version of glide? What os are you using?


Edit:

Try THIS (https://glidehqplusglitch64.googlecode.com/files/Glide64_Final.zip) Glide64, it's the latest one. The glidewapper should work for it as well (included)

robinhood2013
8th April 2013, 07:26 AM
Yes, that's the version of Glide64 I just tried. I'm using Windows 7, the same operating system on which Project64 1.6 wouldn't work at all (thanks to zilmar, by the way, for at least building version 2.0 which starts and runs okay on Windows 7 -- except for the graphics, of course).

Am I to gather I need to set a compatibility mode on Project64?

squall_leonhart
8th April 2013, 02:53 PM
you need the frickin glide3x file in the root directory of the emulator.

chumbalumba
8th April 2013, 03:23 PM
This version can be ported to Linux?

HatCat
8th April 2013, 03:31 PM
This version can be ported to Linux?

Sure can.

It will just take a bit of API experience, but if it's open-source you can do whatever you like with that respect. :p

Glide64 is no help to me at all -- Project64 doesn't even recognize that the plugin exists in the "Plugins\GFX" subfolder. Am I doing something wrong here?

Yes, participating in a project discussion with information about one of the plugins zilmar can't control.

Preferable to keep that to its own thread, but what squall said is almost certainly correct (see previous page).

HatCat
8th April 2013, 04:03 PM
Hmmm.

I'm not finding the source to zilmar's zilmar's Audio Plugin DLL.

It's identical to his open-source Basic Audio Plugin provided on Emu64, except he added a prebuffer control and fixed an initialization fault with CloseDLL.

It may be yet another DirectSound plugin (we need a plugin that isn't DirectSound/WaveOut at least once!) but it's the only audio plugin, closed-source or not, to control prebuffering for testing with games unless you count Nemu audio.

Unless someone else is finding it?

Mdkcheatz
8th April 2013, 07:46 PM
Sure can.

It will just take a bit of API experience, but if it's open-source you can do whatever you like with that respect. :P

Yep, you can port to linux, mac, iOS, PSP custom firmware, android OS (Fat Jelly Belly), anything is possible you just need to find a solution.

squall_leonhart
8th April 2013, 08:10 PM
you'll just have to rewrite 99% of the emulator so it doesn't rely on various windows functions.

nobody did it with 1.4, i don't see it happening now.

Mdkcheatz
8th April 2013, 08:49 PM
you'll just have to rewrite 99% of the emulator so it doesn't rely on various windows functions.

nobody did it with 1.4, i don't see it happening now.

Because 1.4 was hard to understand compared to the current version which was rewritten in C++ (easier porting in itself). But by then, someone already ported mupen64 to iOS. The guy called it something else but when I used my Granny Smith powers to sifen through this N64 app I could see it was just a mupen64 port. Theoretically, if I knew anything about objective-c I would see how mupen64 was ported and make the same changes for PJ64.

HatCat
8th April 2013, 09:15 PM
C is more portable than C++.


I had no problems understanding 1.4 source code.

Mdkcheatz
8th April 2013, 09:23 PM
C is more portable than C++.


I had no problems understanding 1.4 source code.

I guess I misunderstood some things. Anyway I know for iOS c++ is good for porting (maybe less so for other OS) because you can code apps using objective-C/C++

HatCat
8th April 2013, 09:25 PM
The idea was that you should sometimes use functional templates, polymorphism, blah blah, bunch of rudimentary programming terminology I never read up on.

Even so, I like even JavaScript more than C++, as far as function-oriented, mathematical algorithms go.
The structure and added syntax are far from unreadable in C++, just weird IMO.

robinhood2013
9th April 2013, 04:46 AM
Finally got the Glide64 plugin to work... it doesn't work any better than Jabo's old plugin. I think the fault may be in the emulator itself.

Mdkcheatz
9th April 2013, 05:31 PM
Finally got the Glide64 plugin to work... it doesn't work any better than Jabo's old plugin. I think the fault may be in the emulator itself.

Support has changed in favor of Glide64, not because it works better (it works equally as good), because Jabo has discontinued his plugin work and has decided to not open source his plugin. Where as glide64 is open source so work can proceed as scheduled.

HatCat
9th April 2013, 07:16 PM
And what better way to defy the events of the past while not also seeming like a hypocrite, than to open-source a product.

But me, personally I don't know that I would have made the same decision.
Too many demanding people. :p

the_randomizer
9th April 2013, 11:31 PM
And what better way to defy the events of the past while not also seeming like a hypocrite, than to open-source a product.

But me, personally I don't know that I would have made the same decision.
Too many demanding people. :p

It's the internet, it was bound to happen.

HatCat
9th April 2013, 11:41 PM
Well.


They lost their source access because zilmar didn't like open letters.

So, naturally, why transverse the fixations of time, when you could become crazy than you ever were and trust everyone equally to control the direction of Project64?

Internet or not, it does make some sense. Everything happens for a reason.

And besides, it sounds like fun.

squall_leonhart
10th April 2013, 12:05 AM
who open lettered zilmar now?

HatCat
10th April 2013, 12:15 AM
Bah.


Why is it that every time I try to be polite/concealing of the blabbermouth truth, somebody asks me a question and uses my ego against me and causes me to elaborate on the specifics? :D

Well, trying to be polite.
I'm not strictly familiar with how to define an open letter.

It wasn't in any of the public forums, just in a private group. Even though the opposition was most likely lead by Gent, I could tell that nobody agreed with the continuum of time that was passing by under zilmar's leadership. So, against their expectations, he shut off their source access to Project64 1.6, so then they left the team.

But they all agreed on at least one thing.
How little do us noisy kids mature. :D


Back to thread now. :3

squall_leonhart
10th April 2013, 04:20 AM
found another bug in 2.0 (and 1.7b50)

All games are starting with the wrong Emulated Height/Width (Set to 0 instead of Default)

don't think this was an issue back in b49.

daaceking
10th April 2013, 12:02 PM
shitstain64 2.0.0.14 gave me a BSOD as soon as i booted up the first ROM, which was PD. What's with the (optional) adverts all of a sudden?!? keep working on it, i'm using 1.6.

deathdroid
10th April 2013, 12:25 PM
shitstain64 2.0.0.14 gave me a BSOD as soon as i booted up the first ROM, which was PD. What's with the (optional) adverts all of a sudden?!? keep working on it, i'm using 1.6.

BSOD is more than likely to be caused by a dodgy driver than pj64...

squall_leonhart
10th April 2013, 03:16 PM
the bsod in pj64 is caused by a bug in the version of windows you are using (if vista) or a faulty RDP Mirror driver.

HatCat
10th April 2013, 04:13 PM
/************ Functions ***********/
DWORD AsciiToHex (char * HexValue) {
DWORD Count, Finish, Value = 0;

Finish = strlen(HexValue);
if (Finish > 8 ) { Finish = 8; }

for (Count = 0; Count < Finish; Count++){
Value = (Value << 4);
switch( HexValue[Count] ) {
case '0': break;
case '1': Value += 1; break;
case '2': Value += 2; break;
case '3': Value += 3; break;
case '4': Value += 4; break;
case '5': Value += 5; break;
case '6': Value += 6; break;
case '7': Value += 7; break;
case '8': Value += 8; break;
case '9': Value += 9; break;
case 'A': Value += 10; break;
case 'a': Value += 10; break;
case 'B': Value += 11; break;
case 'b': Value += 11; break;
case 'C': Value += 12; break;
case 'c': Value += 12; break;
case 'D': Value += 13; break;
case 'd': Value += 13; break;
case 'E': Value += 14; break;
case 'e': Value += 14; break;
case 'F': Value += 15; break;
case 'f': Value += 15; break;
default:
Value = (Value >> 4);
Count = Finish;
}
}
return Value;
}



Even though this is not really relevant to RSP emulation, it was one of the very first things I ever touched about the zilmar RSP source.

It's that kind of thing, that led me to believe, maybe I should contribute to the rest of the project, if inefficiencies like this frequent throughout the rest of the emulator.

Or somebody interested should in the meantime.

Or do people not find benefits to an update of algorithms like that, such as:


const char digits[128] = {
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
0, 1, 2, 3, 4, 5, 6, 7, 8, 9, -1, -1, -1, -1, -1, -1,
-1, 10, 11, 12, 13, 14, 15, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, 10, 11, 12, 13, 14, 15, -1, -1, -1, -1, -1, -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 };



unsigned long int AsciiToHex(char *ASCII)
{
register unsigned long int hexadecimal = 0x00000000;
register unsigned int i = 0x0000;

while (digits[ASCII[i]] != -1)
{
hexadecimal <<= 4;
hexadecimal |= digits[ASCII[i]];
}
return (hexadecimal);
}


Even without any knowledge of emulation it is possible for someone to contribute.

BunieLuv
12th April 2013, 06:44 AM
So is this fake? Because it seems to be weird, and a lot more buggy than my old 1.7 Beta build.

dsx_
12th April 2013, 12:28 PM
no its not fake, zilmar just doesn't give a shit about his userbase

zilmar
12th April 2013, 12:44 PM
no its not fake, zilmar just doesn't give a shit about his userbase

what makes you think I do not care about the userbase, you think I should not have released.

BunieLuv
12th April 2013, 03:38 PM
what makes you think I do not care about the userbase, you think I should not have released.

I think a public release was long overdue, 1.6 Was more than a bit dated lol. it's just that i had a build of 1.7b50 or 55 or something like that and it felt better, and i can't figure out why. For example, override aspect ratio on "Ocarina of Time (U) 1.2" on 1.7 worked in 2D Areas but on 2.0 it streaches the 2D zones, making it unplayable widescreen.

EDIT: Just to throw it out there, ive also had an issue with gamepad settings not saving, do i need to run as Admin or something?
EDIT2: Or maybe theyre game specific now? Lol~
EDIT3: Maybe it's only streached in certain areas. Maybe im just crazy and its the same video plugin. Maybe you should ignore this post completely. ♥

the_randomizer
12th April 2013, 03:58 PM
no its not fake, zilmar just doesn't give a shit about his userbase

And you're basing that on what exactly? If anything, he actually cares, and how do I know that? Because he took time out of his own schedule to rewrite 90% of the code without the help of Jabo, he released the source code and publicly released 2.0, despite people's bitching about it not being perfect blah, blah, blah. Back your arguments up before making such baldfaced accusations.

Good day.

squall_leonhart
12th April 2013, 07:29 PM
I think a public release was long overdue, 1.6 Was more than a bit dated lol. it's just that i had a build of 1.7b50 or 55 or something like that and it felt better, and i can't figure out why. For example, override aspect ratio on "Ocarina of Time (U) 1.2" on 1.7 worked in 2D Areas but on 2.0 it streaches the 2D zones, making it unplayable widescreen.

EDIT: Just to throw it out there, ive also had an issue with gamepad settings not saving, do i need to run as Admin or something?
EDIT2: Or maybe theyre game specific now? Lol~
EDIT3: Maybe it's only streached in certain areas. Maybe im just crazy and its the same video plugin. Maybe you should ignore this post completely. ♥

Build Pj64 50 broke the Emulated Height/Width settings in Jabo's 1.7 plugins.

They default to 0 instead of -1(Default) resulting in stretched images and the likes.

dsx_
13th April 2013, 01:52 AM
And you're basing that on what exactly? If anything, he actually cares, and how do I know that? Because he took time out of his own schedule to rewrite 90% of the code without the help of Jabo, he released the source code and publicly released 2.0, despite people's bitching about it not being perfect blah, blah, blah. Back your arguments up before making such baldfaced accusations.

Good day.

Seems like 2.0 is worse than 1.6 and 1.7, based on a LOT of problems, and squall said the recompiler is broken, so

HatCat
13th April 2013, 02:24 AM
squall said the recompiler is broken, so

...so .....

http://forum.pj64-emu.com/showthread.php?t=3577

Changed his mind about the recompiler start-up issue.




Seems like 2.0 is worse than 1.6 and 1.7, based on a LOT of problems

At the same time, you believe:

if this is legit, good, means someone can fix the crap out of the mess you made of the recompiler.

though im going with april fools joke right now, since fobbing alpha quality emulators as release quality is a nasty jokeif its so bad, you fucking fix it

Mood swings.

Probably just some personality grudge.

squall_leonhart
13th April 2013, 02:32 AM
didn't change my mind so much as i learned wtf was going on that is new to the 2.0 compiler (a hell of a lot more logging!)

HatCat
13th April 2013, 03:06 AM
I wrote a logger, too. I figured it was a bit more organizable than WinUI/interactive data display.


RCP Communications Register Display

SP_MEM_ADDR: 000004E0 CMD_START: 00158010
SP_DRAM_ADDR: 8021BC70 CMD_END: 00158010
SP_DMA_RD_LEN: 0000007F CMD_CURRENT: 00158010
SP_DMA_WR_LEN: 0000017F CMD_STATUS: 00000000
SP_STATUS: 00000040 CMD_CLOCK: 00000000
SP_DMA_FULL: 00000000 CMD_BUSY: 00000000
SP_DMA_BUSY: 00000000 CMD_PIPE_BUSY: 00000000
SP_SEMAPHORE: 00000000 CMD_TMEM_BUSY: 00000000
SP_PC_REG: 04001690

zero 00000000, s0: 000E45B0,
$at: 00000000, s1: 00005200,
v0: 00000000, s2: 0000000A,
v1: 8021C5E8, s3: 0000007F,
a0: 00000600, s4: 000004E0,
a1: 00000020, s5: 00000040,
a2: 00000000, s6: 00000F08,
a3: 00000000, s7: 00000E28,
t0: 00000560, t8: 8021BC70,
t1: 00000000, t9: 01008010,
t2: FFFF8800, k0: 8021C4C8,
t3: 00000000, k1: FFFFFF70,
t4: 00000001, gp: 000003BF,
t5: 00000180, $sp: 00000F00,
t6: 00000540, $fp: 000001C0,
t7: 00000560, $ra: 00000590

$v0: [0000][0000][0000][0000][0000][0000][0000][0000]
$v1: [0001][0001][0001][0001][0001][0001][0001][0001]
$v2: [0000][EF6B][0000][0000][0000][0000][0000][0000]
$v3: [0000][0000][0000][0000][0158][0104][03E9][7D74]
$v4: [0000][8000][0000][0001][0000][0000][0000][0001]
$v5: [0000][0000][0000][F07C][0000][0000][0000][C872]
$v6: [FE35][0105][01E4][0207][FE92][0227][0212][0235]
$v7: [1CE0][3A0E][EB98][E654][8280][023E][FA28][7FE4]
$v8: [0000][0002][0000][0000][0000][0002][0000][0000]
$v9: [0000][0000][FFFF][FFFF][0000][0000][FFFF][FFFF]
$v10: [0001][FFFF][FFFF][FFFF][0001][FFFF][FFFF][FFFF]
$v11: [0001][0003][015F][016F][0001][0003][015F][016F]
$v12: [A60A][032B][51E1][5111][A60A][032B][51E1][5111]
$v13: [0000][C9E4][0CFA][0F65][0000][C9E4][0CFA][0F65]
$v14: [9B18][2FED][DEED][DF42][9B18][2FED][DEED][DF42]
$v15: [0EF0][92A0][39AD][A278][0EF0][92A0][39AD][A278]
$v16: [0280][FE20][01FF][3E80][0280][FE20][01FF][3E80]
$v17: [0280][01E0][01FF][C280][0280][01E0][01FF][C280]
$v18: [1670][1430][0000][0000][0041][0002][0000][0000]
$v19: [0000][0000][0000][0001][0000][0000][0000][0001]
$v20: [FFEF][FF31][012C][013D][0024][0078][FF7F][0000]
$v21: [0000][8000][0000][7FFF][0000][0000][0000][7FFF]
$v22: [0000][0000][0000][0000][0000][0000][0000][0000]
$v23: [8E70][9D07][75CC][75CC][4140][811F][7D14][7D14]
$v24: [FF1A][0082][00F2][0103][FF49][0113][0109][011A]
$v25: [0004][4256][0004][0002][0004][0004][0004][0002]
$v26: [0000][0000][0000][0004][0000][0000][0000][0004]
$v27: [7F00][7F00][7F00][7F00][7F00][7F00][7F00][7F00]
$v28: [0000][0000][0000][0000][0000][0000][0000][0000]
$v29: [0004][0004][0004][0004][0004][0004][0004][0004]
$v30: [7FFC][1400][01CC][0200][FFF0][0010][0020][0100]
$v31: [FFFF][0004][0008][7F00][FFFC][4000][0420][7FFF]

$vco: [00][00]
$vcc: [00][EE]
$vce: 00

VACC[0]: 000000040000
VACC[1]: 000042560000
VACC[2]: 000000040000
VACC[3]: 000000020004
VACC[4]: 000000040000
VACC[5]: 000000040000
VACC[6]: 000000040000
VACC[7]: 000000020004

DivIn: 0
DivOut: 116850
DPH: true

the_randomizer
13th April 2013, 03:07 AM
Seems like 2.0 is worse than 1.6 and 1.7, based on a LOT of problems, and squall said the recompiler is broken, so

Konami games have improved audio with default plugin
Killer Instinct Gold has near-perfect audio
Kirby 64 has a working HUD
007 Goldeneye works also with perfect audio
ROMs and plugins are configured individually into profiles and not being forced to use three plugins for all games
Games like World Driver Championship now boot up
Donkey Kong 64 functions properly
Star Wars Shadows of the Empire also boots up

Yep. Seems broken to me.

squall_leonhart
13th April 2013, 05:49 AM
kirby64 has broken enemies (http://forum.pj64-emu.com/showthread.php?t=2143)

the_randomizer
13th April 2013, 06:02 AM
And that's why I use Glide 64. It does what Jabo's plugin doesn't.

Besides, I doubt Jabo will ever have the balls to want to come back.

squall_leonhart
13th April 2013, 06:46 AM
please don't insult Jabo, hes a good man that simply couldn't stomach the taste of what n64 emulation is these days.

dsx_
13th April 2013, 09:31 AM


Hero
13th April 2013, 03:18 PM
Besides, I doubt Jabo will ever have the balls to want to come back.
That's extremely insulting to someone who contributed more than you could ever hope to.
What have you done besides come on these forums to bitch and overreact?

HatCat
13th April 2013, 03:18 PM
lulz, ninja'd by Hero

And that's why I use Glide 64. It does what Jabo's plugin doesn't.

Besides, I doubt Jabo will ever have the balls to want to come back.

Is everything so one-sided?

I've known the other way to be true.
Lots of things Jabo's plugin does that Glide64 doesn't.

As far as microcode simulation, though, no not really. Glide64 seems to do everything that Jabo's plugin does + more as far as I can tell. But, simulation doesn't necessarily have anything to do with emulation accuracy. Hence, Jabo's plugin will be more accurate in some ways.

Jabo had been in a position to do more than just plugins, but he got fired with everyone else instead, so try not twisting the story and cut everyone some slack, even Gent and some of those other meanies he was friends with.

pretty much :/

sorry zilmar and sorry everyone

You're still cool and whatnot.
Just annoying from time-to-time.

Everyone's evil inside, not just you or zilmar.

I was thinking about sending a monumentally fucked up birthday cake to your inbox, but I found out I was forced to log on and be active on the site that posted it just to get the URL for it again which made me mad and want to stay inactive on that site even longer :D plus I started getting mad anyway like you. :p

BunieLuv
13th April 2013, 05:10 PM
My cats breath smells like cat food.

HatCat
13th April 2013, 05:56 PM
If you engage me in a sumo-wrestling contest and lose and feed me a mouse it might smell better.


*mrow* :(

*needs to be pet* T_T

the_randomizer
13th April 2013, 08:02 PM
lulz, ninja'd by Hero



Is everything so one-sided?

I've known the other way to be true.
Lots of things Jabo's plugin does that Glide64 doesn't.

As far as microcode simulation, though, no not really. Glide64 seems to do everything that Jabo's plugin does + more as far as I can tell. But, simulation doesn't necessarily have anything to do with emulation accuracy. Hence, Jabo's plugin will be more accurate in some ways.

Jabo had been in a position to do more than just plugins, but he got fired with everyone else instead, so try not twisting the story and cut everyone some slack, even Gent and some of those other meanies he was friends with.



You're still cool and whatnot.
Just annoying from time-to-time.

Everyone's evil inside, not just you or zilmar.

Who said anything about being one-sided. Jabo quit the scene and doesn't have the balls to return. I was thinking about sending a monumentally fucked up birthday cake to your inbox, but I found out I was forced to log on and be active on the site that posted it just to get the URL for it again which made me mad and want to stay inactive on that site even longer :D plus I started getting mad anyway like you. :p


Jabo doesn't emulate those alpha dithering effects in Mario 64, Mystical Ninja 64, Mario Kart, etc (Mario had the invisible Mario effect, Hybrid Heaven showed the effect when robots blew up, Mystical Ninja 64 had laser beams from the first boss that showed the effect. Neither of those does Jabo emulate). If Jabo didn't go silent and implemented those effects, my argument would be different. Only Direct 64 and Glide 64 get it right. Then there are the missing skies in Killer Instinct Gold and 007 Goldeneye; in Jabo's they're either grey or missing, but in Glide, they show up normally like on real hardware.

I'd be more than happy to show anyone a side by side comparison.

I'd love to know in what respect Jabo is more accurate then Glide. Oh yeah, and Mystical Ninja 64 works well on Glide but horribly on Jabo.

HatCat
13th April 2013, 08:43 PM
Because a game looks good, or looks better in another plugin, doesn't mean it's emulated more accurately. Never heard of a hack?

It's the reason Rice's Video Plugin renders Gauntlet Legends HUD render-to-texture, much better than Glide64 does, but you don't see me showing off about how much more accurate RiceVideo is than Glide64 just because of that.

Because, it's called, a hack.
Glide64 admittedly has its own share of hacks, just so much less than Rice plugins.

Jabo doesn't emulate those alpha dithering effects in Mario 64, Mystical Ninja 64, Mario Kart, etc (Mario had the invisible Mario effect, Hybrid Heaven showed the effect when robots blew up, Mystical Ninja 64 had laser beams from the first boss that showed the effect. Neither of those does Jabo emulate).

Uh where does Mario Kart 64 use dithered alpha?

So just because of dithered alpha in various games, + missing sky, = 2 reasons proving Glide64 is all-around more accurate?

Because I know way more than just 2 things Jabo's plugin supports that Glide64 doesn't.
2 is the best you come up with, seriously? :rolleyes:

If Jabo didn't go silent and implemented those effects, my argument would be different.

Effects are different from accuracy.

Glitch64 (running under Glide64) uses OpenGL techniques for dissolve effect.
Direct64 doesn't use OpenGL, or GBI software that N64 RCP uses, but gets the effect right anyway.

Effects are the end result of something.
Drawing eye-candy up on the screen, to show the "effect" of using another API to simulate separate hardware, doesn't imply accuracy.

Then there are the missing skies in Killer Instinct Gold and 007 Goldeneye; in Jabo's they're either grey or missing, but in Glide, they show up normally like on real hardware.

I used to have a couple discussions with Jabo about this a while back.

He wouldn't directly admit to it, but ever since z64gl / MAME upgrades / Glide64 implementation of LLE findings, Jabo's D3D8 1.7 had the exact same results for GoldenEye skies as any of the other plugins. Last I checked, the sky for the Dam level worked just fine. :) It was broken for Frigate though.

Again, he wouldn't admit it, but he almost certainly had help from mame/z64 regarding lle.

zilmar
13th April 2013, 08:46 PM
Jabo's Plugin is also a lot faster as well ... started playing a bit more with glide64 now and noticed how slow it it.

last I looked the sky in golden eye does work in jabo plugin.

My only real issue with jabo plugin is that it cause some users to get a blue screen (not really his fault).

He may come back on work on it one day, when your studying it is a lot easier to have time for this kind of thing, when you have work and family a lot harder.

HatCat
13th April 2013, 08:51 PM
Who said anything about being one-sided. Jabo quit the scene and doesn't have the balls to return.

Being one-sided requires no mention of one-sided-ness.

Jabo "left" because zilmar let everyone go, if not, fired him, like I said.

But, instead of acknowledging my having already said that, I guess you'd rather talk about Jabo's balls, hoping for a man with balls to come back, how nice it would be if more men had the balls to do what you want, etc. all that other romantic stuff, instead of RTFM and getting it through your thick skull:
He was dismissed because everyone had an argument with zilmar; he didn't pussy out, rather, he was more like kicked out.

You're just upset to the point of blaming him regardless, just because you didn't get everything you want out of his work.

Next time you get emo and leave, do yourself a favor and make it for good.

the_randomizer
13th April 2013, 08:54 PM
Because a game looks good, or looks better in another plugin, doesn't mean it's emulated more accurately. Never heard of a hack?

It's the reason Rice's Video Plugin renders Gauntlet Legends HUD render-to-texture, much better than Glide64 does, but you don't see me showing off about how much more accurate RiceVideo is than Glide64 just because of that.

Because, it's called, a hack.
Glide64 admittedly has its own share of hacks, just so much less than Rice plugins.



Uh where does Mario Kart 64 use dithered alpha?

So just because of dithered alpha in various games, + missing sky, = 2 reasons proving Glide64 is all-around more accurate?

Because I know way more than just 2 things Jabo's plugin supports that Glide64 doesn't.
2 is the best you come up with, seriously? :rolleyes:



Effects are different from accuracy.

Glitch64 (running under Glide64) uses OpenGL techniques for dissolve effect.
Direct64 doesn't use OpenGL, or GBI software that N64 RCP uses, but gets the effect right anyway.

Effects are the end result of something.
Drawing eye-candy up on the screen, to show the "effect" of using another API to simulate separate hardware, doesn't imply accuracy.



I used to have a couple discussions with Jabo about this a while back.

He wouldn't directly admit to it, but ever since z64gl / MAME upgrades / Glide64 implementation of LLE findings, Jabo's D3D8 1.7 had the exact same results for GoldenEye skies as any of the other plugins. Last I checked, the sky for the Dam level worked just fine. :) It was broken for Frigate though.

Again, he wouldn't admit it, but he almost certainly had help from mame/z64 regarding lle.

And why can't those be implemented into the current plugin? Why can't there be newer versions of Jabo's plugin, same with Glide, why were they abandoned?

Mario Kart 64 uses dithering right here

http://i.imgur.com/Kj04Uej.png

And missing effects implies higher accuracy? What makes Jabo's more accurate? You still didn't elaborate as to what makes Jabo superior and Glide inferior. Does it implement hard-to-emulate microcode like Star Wars Battle for Naboo and custom microcode Rare used for Conker's Bad Fur Day? I may have only used two examples, but I can sure as hell come up with more. Mystical Ninja 64 for example doesn't run full speed on Jabo's D3D, in fact, when it renders the camera (and rotates) the framerate drops, but in Glide 64, it never slows down during camera rotation. Even back on PJ64 1.6 it worked fine, so it's not emulator-dependent but plugin-dependent.

Glide 64
===========
+Better emulated effects such as alpha dithering
+Mystical Ninja 64 has no issues with camera rotation
+Goemon's Great Adventure shows underwater levels and not a black screen
+HUDs are properly filtered with forced bilinear mod
+Missing skies are no longer an issue
+Force 16:9 mode
+Games like Ogre Battle have properly emulated prerendered JPEG backgrounds
-Can be annoying to configure properly

Jabo's D3D
========
+Less resource intensive
+Easy to configure
+Force 16:9 mode
-Cannot emulate underwater levels in Goemon's Great Adventure
-Cannot have camera rotation without severe speed reduction in Mystical Ninja 64
-HUDs in games are often unfiltered
-Ogre Battle 64 does not look correct due to prerendered JPEG code not being properly implemented.

I'm not questioning anyone's programming skills, but I wonder why Jabo couldn't implement the code to fix these issues since they're not dependent on the API used. Glide uses OpenGL, Jabo uses D3D.

HatCat
13th April 2013, 08:57 PM
Jabo's Plugin is also a lot faster as well ... started playing a bit more with glide64 now and noticed how slow it it.

last I looked the sky in golden eye does work in jabo plugin.

My only real issue with jabo plugin is that it cause some users to get a blue screen (not really his fault).

He may come back on work on it one day, when your studying it is a lot easier to have time for this kind of thing, when you have work and family a lot harder.

It should be very much faster than Glide64 running with the wrapper, but...once you get it going with OpenGL integration without a wrapper requirement that should change?

I just find it a bit surprising it should be that much slower, once the interposition of the wrapper is removed.

And yeah, it's also worth noting he just doesn't have as much time for it anymore; that's also true.
He used to tell how he would be trying to interchange work much on Jnes vs. Project64, also losing a little faith in doing so while you weren't able to work on the core in unison to his activity.

ps sorry about other posts usual anger problems :p delete as needed

HatCat
13th April 2013, 09:02 PM
Mario Kart 64 uses dithering right here

http://i.imgur.com/Kj04Uej.png

Good to know, cool. Wasn't paying attention I guess.

And why can't those be implemented into the current plugin? Why can't there be newer versions of Jabo's plugin, same with Glide, why were they abandoned?

According to mudlord, dithering manipulations are much easier with OpenGL, than with Direct3D.
OpenGL is also closer to the internal schematics off which the RCP GBI software was running.

Glide wasn't abandoned; Jabo d3d wasn't abandoned.
Abandonding is leaving with tl;dr; it's possible to finish plugin projects while leaving them far from perfect.

*other questions, hypothetical posts etc. that might arise from this point*

tl;dr, feel like going back to work now, have fun / figure it out

zilmar
13th April 2013, 09:03 PM
Again, he wouldn't admit it, but he almost certainly had help from mame/z64 regarding lle.

No actually he didn't, they did get it working first which annoyed him, so he decided to dedicate the time to work out why it did not work and fix it.

HatCat
13th April 2013, 09:08 PM
No actually he didn't, they did get it working first which annoyed him, so he decided to dedicate the time to work out why it did not work and fix it.

I assumed in the absence of his details it was the most likely thing, but, I guess, if what you're saying is true, it sounds like there was somewhat of a race. Not like, some intense competition, but like, they just happened to both be working towards finishing it at the same time?

I just figured, some common news had to have alerted both of them to start implementing it.
The findings / resources of someone else.

There is certainly the chance that they just both started working on LLE and backporting to HLE things like ge007 etc. ucode at nearly the exact same time, coincidentally though.

squall_leonhart
13th April 2013, 09:10 PM
My only real issue with jabo plugin is that it cause some users to get a blue screen (not really his fault).



I'm looking into this, thus far i can only find instances of Dell machines having the specific error win32k!xxxSendMenuDrawItemMessage+d3 bsod.

It might be something unique to Dell recovery disks, but i also have a lead on one of the Broadcom drivers used by Dell having a version of the Wifi utility that breaks the RDP driver.

HatCat
13th April 2013, 09:34 PM
Hmm I think I get it now.

Some of the newly leaked parts and manuals must have initiated both mamedev and jabo. They were both racing towards a goal, but dependent off of a separate entity entirely, not off one another.

The results however were so similar, including the bugs. They must have interpreted the doc similarly enough for that.

the_randomizer
13th April 2013, 09:49 PM
I'm looking into this, thus far i can only find instances of Dell machines having the specific error win32k!xxxSendMenuDrawItemMessage+d3 bsod.

It might be something unique to Dell recovery disks, but i also have a lead on one of the Broadcom drivers used by Dell having a version of the Wifi utility that breaks the RDP driver.

I knew I had a reason for not liking Dell ;)

Still, the vast numbers of people reporting all these BSODs can't be the emulator, but on their machine. The fact they have the balls to even accuse Zilmar or his work to be the problem is ludicrous at best.

HatCat
13th April 2013, 09:57 PM
And now having balls is a crime.


My computer crashed a few days ago, for the first time in years.
It wasn't a blue screen.
It was a rainbow screen :D full of funny pixels, had to hard reboot.

I think it's partly how Jabo's plugins use the drivers, but it makes sense to guess that maybe something zilmar did to pj64 could also have something to do with it.
Permanently assuming it without asking is another thing though.

btw, I have a Dell :)

Natch
14th April 2013, 12:04 AM
It was a rainbow screen :D full of funny pixels, had to hard reboot.

Wtf? How on earth do you explain th-

btw, I have a Dell :)

ah

squall_leonhart
14th April 2013, 12:22 AM
Fatcat

is broadcom wifi utility installed?

the_randomizer
14th April 2013, 01:38 AM
And now having balls is a crime.


My computer crashed a few days ago, for the first time in years.
It wasn't a blue screen.
It was a rainbow screen :D full of funny pixels, had to hard reboot.

I think it's partly how Jabo's plugins use the drivers, but it makes sense to guess that maybe something zilmar did to pj64 could also have something to do with it.
Permanently assuming it without asking is another thing though.

btw, I have a Dell :)

No, but accusing Zilmar of making a "faulty" emulator without solid proof is, since a lot of end users don't fully troubleshoot the issue at hand.

HatCat
14th April 2013, 02:40 AM
Wtf? How on earth do you explain th-


ah

Yaaaaay :D a fellow victim of dissociative personality disorder who like me needs to change his user name etc. every so often. :cool:

Fatcat

is broadcom wifi utility installed?

idk wtf that is lmao, I'm lucky I barely managed to get any wireless Internet at all at this shitty inn

No, but accusing Zilmar of making a "faulty" emulator without solid proof is, since a lot of end users don't fully troubleshoot the issue at hand.

dsx! isn't a noob (at least as far as end user / testing / etc. goes); he just like so many others has eyewitness experience of zilmar disregarding various things, usually but not necessarily as he fancies.
The old man may be smart, but it doesn't mean that he can't enjoy mind games XD

Either way, it's true that with new software comes both positive and negative changes, every time.

The objective is that each time the positive should outweigh just minor negative changes, e.g. minimized new bugs (because there are new bugs introduced in pj64 2.0 as well if you haven't noticed).

daaceking
14th April 2013, 07:15 PM
Come on guys, all this swearing and getting hot under the collar is unproductive and unnecessary. One step at a time, the project is ongoing with no deadline. Those who code and test, their work is appreciated.

My system is not dell and my wifi is edimax. No broadcom soft or drivers.

My gpu drivers are fine and I won't bother replying to anyone accusing the gpu drivers. Updating may fix it but it's more of an issue in pj64. If you tweak it I'm sure it will fix it.

It's nice to see it open source. We just need pro code recruits.

And forum moderators... :)

HatCat
14th April 2013, 07:31 PM
Come on guys, all this swearing and getting hot under the collar is unproductive and unnecessary.

hell, damn, ass, ...


Oh, look at me. I'm hot under the collar. :D
Almost as much as that one time you called Nate a "numbnut".

One step at a time, the project is ongoing with no deadline. Those who code and test, their work is appreciated.

Though it doesn't have to have anything to do with project x, just anything of academic of benefit.

But pj64 source I'm sure will make several differences regardless.

My gpu drivers are fine and I won't bother replying to anyone accusing the gpu drivers.

Cool, but jealousy is off-topic.

And forum moderators... :)

Only one forum moderator here and I think zilmar has done a surprisingly very good job of sanity-checking the forum every 15-25 minutes or so (uhh just random numbers forget I said that) and making sure weird posts don't make it through (heh, except some of mine). I don't understand why everybody has the desire for more moderators except me, oops off-topic I'm getting hot under the collar again.

daaceking
14th April 2013, 07:57 PM
nate a numbnut? wow you have a good memory. [or really like that word]

do i know you? what was your old display name?

btw hell damn ass aren't swears. :p maybe ass..

Edit - according to our encounters on Previous threads. You are ...iconoclast. Right? Hmmm living under a new name and picture. Hmmm...you must hate your old life :p

HatCat
14th April 2013, 08:43 PM
Obviously you remember me, or you would not be taking advantage of my forced instincts to reply to questions, answer things etc. even if it makes me go off-topic the forum XD

do i know you? what was your old display name?

How should I pick?

btw hell damn ass aren't swears. :p maybe ass..

Hell and Damn surely are swears, but IDK about ass, since a few bibles use that word from time to time.

Edit - according to our encounters on Previous threads. You are ...iconoclast. Right?

Whoever that is, it sure wasn't the name I had when we were socializing.

Where did you find that? Google Maps?

Hmmm living under a new name and picture. Hmmm...you must hate your old life :p

1, 2, 3, 4, 5, 6, 7, 8, 9, ... hm I probably changed my name on this forum about fifteen times, most likely a little more than that.

Though that pales in comparison to the number of times I changed my forum picture here.
(Edit, according to my avatar entry in the db I changed my avatar 70 times on this board lmao)

And you think I had only 1 old life? :D
Don't take the Internet so serious! We're not reborn when we change pictures/names, just lacking in self-entertainment.


Merge double posts.
Move all the threads to the correct forum.
Make a rule thread in every forum.
Sticky several help threads nobody reads.
etc.

That was the kind of shit that was going on when zilmar was not the only moderator here.
It stirred up drama like crazy. :)

Now that zilmar is the only moderator here, the forum seems much more relaxed.
People who think every forum needs the lead of a social chain of moderators, take the Internet way too serious.

daaceking
14th April 2013, 08:54 PM
the things you say are very different from what you used to say. you used to be cool. i hate you now. :D

so... you're supposed to be a pro coder. what comercial projects you working on? you going to be credited on assassin's creed 4? :)

HatCat
14th April 2013, 09:13 PM
No commercial projects.
I have never before been paid to program anything, except my very first job when I had just turned 14.

But, being paid by someone, doesn't necessarily mean people know what they really want.
My dad gets paid to program stuff every time, and he has to deal with way more shit than I do as far as personal problems go.


I basically make all the things nobody likes.
* teacher-student finite geometry teaching multimedia
* a triangle solver that teaches itself to think like a human and use arcs, segments, other measures
* iterative solver to play perfect games of Nim every time (you get 15 objects, whoever has to take away the last one loses)
* chess notations parser and transliteration
* deliberate, inconveniently interfaced console apps that most people won't figure out
* I could go on listing all the academic stuff that benefit me and nobody else making it. :p

daaceking
14th April 2013, 09:33 PM
Just as I suspected. I have no idea what you just said :D

Anyway it was nice to catchup (even though you claim you ain't icono and have met in a parallel universe)

Unlike you who has way too much forum time, I have to watch wreck it Ralph for the 10th time. That thing is awesome. Who knew Disney could make great movies?!? :D

HatCat
14th April 2013, 09:46 PM
http://ft.trillian.im/785abe041074fd64135ab3318aff1ec8767ab03d/6fSKzpPO89EtZTe1i5lwBODQM52S7.jpg

lulz

on-topic +1

Anyway it was nice to catchup (even though you claim you ain't icono and have met in a parallel universe)

Eh, some people call it a "lie by omission", even though it's not really a lie, but I think it's more like just being an ass. :D

daaceking
15th April 2013, 12:13 PM
and take the toolbar trash off. when did the project stoop so low? i'm ashamed of being part of a project that tricks the dumb into installing garbage.

edit - how do you decipher minidumps with wordpad/notepad?

my last bsod, was simple.

this one says ati/hd audio/norton/bowser.sys/usb etc

i've created a mario.sys to tackle bowser.sys just in case that's the culprit. :p

squall_leonhart
15th April 2013, 09:54 PM
this one says ati/hd audio/norton/bowser.sys/usb etc

Faulty hardware,

the jabo 1.7 bsod is specific to win32k.sys

the_randomizer
15th April 2013, 10:35 PM
and take the toolbar trash off. when did the project stoop so low? i'm ashamed of being part of a project that tricks the dumb into installing garbage.

edit - how do you decipher minidumps with wordpad/notepad?

my last bsod, was simple.

this one says ati/hd audio/norton/bowser.sys/usb etc

i've created a mario.sys to tackle bowser.sys just in case that's the culprit. :p

No toolbar was installed when I ran it, so....

ExtremeDude2
16th April 2013, 02:41 AM
No toolbar was installed when I ran it, so....

That's because you actually told it not to install unlike him XD

Scootaloo
19th April 2013, 12:28 PM
No commercial projects.
I have never before been paid to program anything, except my very first job when I had just turned 14.

But, being paid by someone, doesn't necessarily mean people know what they really want.
My dad gets paid to program stuff every time, and he has to deal with way more shit than I do as far as personal problems go.

I basically make all the things nobody likes.
* teacher-student finite geometry teaching multimedia
* a triangle solver that teaches itself to think like a human and use arcs, segments, other measures
* iterative solver to play perfect games of Nim every time (you get 15 objects, whoever has to take away the last one loses)
* chess notations parser and transliteration
* deliberate, inconveniently interfaced console apps that most people won't figure out
* I could go on listing all the academic stuff that benefit me and nobody else making it. :p
I feel bad for you Mr. Cat :"(.

V1del
20th April 2013, 05:19 PM
This version can be ported to Linux?

And whyever this would have to happen, mupen64plus is a thing you know. And as of hg and the Glide64-Port I can't think of anything that doesn't work which wouldn't require extra rsp fiddling in PJ64 as well.

Inb4 squall, there are pretty useable interfaces around with m64py and wxmupen so the "but its command-line only!!" argument is also kind of moot.

Enough off-topic:

Thanks zilmar for an awesome release, and even though i don't have the drive to test it extensively since switching over to linux, I really appreciate the hard work you and everyone involved in the emulation scene are doing. Keep the awesoming coming, you dudes!

Jorchking
21st April 2013, 05:14 AM
Someone can tell me what's new in this version, and which bugs was fixed?

GreenBanana
21st April 2013, 03:14 PM
One of the new bugs introduced was the inability to read Hat Switch (Directional Pad) input presses on the controller plugins.

the_randomizer
21st April 2013, 03:47 PM
One of the new bugs introduced was the inability to read Hat Switch (Directional Pad) input presses on the controller plugins.

Use the NRage plugin instead. It works just fine.

squall_leonhart
22nd April 2013, 02:20 AM
POV Hats work fine with Jabo input 1.7.0.12

Predator82
22nd April 2013, 03:02 PM
Zilmar, do you now take updates to the git or make you bins sometimes?

zilmar
22nd April 2013, 07:11 PM
I am playing with glide64 at the moment trying to get it better integrated in to pj64.

I have a couple other things on my todo list that I want to test (easy fixes).

Once I have those I will make a 2.1 release.

People can sumbit patches which I can update the source with, death droid has write access as well.

If someone is making any real improvements most likely I will give them write access as well.

et500
22nd April 2013, 08:10 PM
Looks really promising, EmuCR already offers regular unstable builds.

Have you ever thought about moving the main development source code to Google Code, Sourceforge or GitHub, making it easier to find and contribute for a wider audience and allowing the use of an issue tracking system?

Melchior
22nd April 2013, 10:13 PM
I am playing with glide64 at the moment trying to get it better integrated in to pj64.

I have a couple other things on my todo list that I want to test (easy fixes).

Once I have those I will make a 2.1 release.

People can sumbit patches which I can update the source with, death droid has write access as well.

If someone is making any real improvements most likely I will give them write access as well.
Zilmar are you still updating your Beta page? so the existing Testers can try stuff out?


ps: is its possible aside from a archive of standalone files (ie. no Installer) on the beta downloads page could you do that on the main download page if your not updating the beta Downloads anymore? Thx.

zilmar
22nd April 2013, 11:25 PM
before I release 2.1 I will put it up through the beta file system

Scootaloo
22nd April 2013, 11:28 PM
before I release 2.1 I will put it up through the beta file system

I am curious. What more does PJ64 need to be done?

I mean aside from some issues it is very good.

zilmar
22nd April 2013, 11:30 PM
Looks really promising, EmuCR already offers regular unstable builds.

Have you ever thought about moving the main development source code to Google Code, Sourceforge or GitHub, making it easier to find and contribute for a wider audience and allowing the use of an issue tracking system?

maybe something like github could work ... tho any one should be able to clone it now and upload a version to one of those sites if they choose to start playing with it.

For the moment I am happy with it is .. it is working fine, when things stop working or some one wanting to contribute is finding it hard then I might speed the time to change it. I just do not have the time at the moment.

the_randomizer
22nd April 2013, 11:36 PM
Looks really promising, EmuCR already offers regular unstable builds.

Have you ever thought about moving the main development source code to Google Code, Sourceforge or GitHub, making it easier to find and contribute for a wider audience and allowing the use of an issue tracking system?

Who wouldn't want one of EmuCR's unstable builds that don't have clear change logs?

In all seriousness, glad the work continues :p

HatCat
23rd April 2013, 02:22 AM
I am curious. What more does PJ64 need to be done?

I mean aside from some issues it is very good.

Arguably nothing, though the same could be said of the other emulators.
The hybrids of HLE and LLE have promoted a leisure gaming experience.

A lot of what needs work is the RCP and the timing issues in the core (some threads you will read complaining about this), and I see that the interpreter core to the CPU host has also maintained some faults which break many ROMs that almost nobody on this forum has.

But it was made so that testing/making changes would be done as-needed by the commercial N64 games. I would rather just make an accurate engine that weighs the balance of algorithm and speed against it so that everybody could use a truly optimized emulator, so a lot of people are constructing the components from scratch rather than asking themselves that very same question of yours. :)

Melchior
23rd April 2013, 10:03 PM
before I release 2.1 I will put it up through the beta file system
good news thx ^_^ :D

would it be possible to get the Standalone files for the full releases(ie. non-installer based)?

I drag and drop into a custom Emulation Directory system I use. so I drag and drop overwriting as needed

root\EmulatorRoms\{Folders for each console}\{subdirectories for ROMS, PLugins, etc}

et500
24th April 2013, 04:49 PM
Are there any plans to bring back the 'Edit game settings' right click menu from 1.7? Still using 1.7.0.50 because of this, I really like this version.

ExtremeDude2
24th April 2013, 05:40 PM
It....never left >.>

zilmar
24th April 2013, 07:50 PM
Are there any plans to bring back the 'Edit game settings' right click menu from 1.7? Still using 1.7.0.50 because of this, I really like this version.

just turn on show advanced settings

TheLegend
27th April 2013, 02:38 AM
I missed shell integration thing that was included in Pj64 1.6... What happened to it in later versions? While I can do similar things with regedit (.reg file for lazy people), but for more convenient, it's better to include in Pj64 settings. Will you plan to put it back in maybe 2.1? I would really like to know.

zilmar
27th April 2013, 05:46 AM
I missed shell integration thing that was included in Pj64 1.6... What happened to it in later versions? While I can do similar things with regedit (.reg file for lazy people), but for more convenient, it's better to include in Pj64 settings. Will you plan to put it back in maybe 2.1? I would really like to know.

2.1 is mostly glide64 being added .. some more bug fixes .. Would like it mostly tested and stabilizing it soon. So not really going to be adding that many features.

Will probably be releasing it in the next few weeks once things get stabilized.

the_randomizer
27th April 2013, 06:07 AM
2.1 is mostly glide64 being added .. some more bug fixes .. Would like it mostly tested and stabilizing it soon. So not really going to be adding that many features.

Will probably be releasing it in the next few weeks once things get stabilized.

Anything in particular that you want tested more thoroughly?

zilmar
27th April 2013, 07:02 AM
Anything in particular that you want tested more thoroughly?

I am not sure, I need to know what I do not know :P

at the moment I am going over texture load location, the running over some of the settings of more games.

Will look at the game specific rsp plugin problem

I might look at dynamic changing of plugins/settings or that might be in 2.2

squall_leonhart
27th April 2013, 07:15 AM
i've dropped koolsmoky a pm to see if he remembers what causes the glidehq issues.

Ichinisan
11th May 2013, 02:38 PM
Why does the site still show 1.4 source code if 2.x source is released?

[edit]
OK. I bet it's an April Fool's joke if you compile the source from the OP.

Natch
11th May 2013, 03:23 PM
Why does the site still show 1.4 source code if 2.x source is released?

[edit]
OK. I bet it's an April Fool's joke if you compile the source from the OP.

Yeah, there's a link to the source in the OP. And zilly's always released on April Fool's for some reason.

HatCat
11th May 2013, 05:14 PM
And zilly's always released on April Fool's for some reason.

...heh
Is that right XD

Just about every release of Project64 happens barely less than 1 day before younger brother's birthday. :S


Well I usually worry about the time of day, like making it divisible by 5 minutes or something, just to be an ass.

Why does the site still show 1.4 source code if 2.x source is released?

Who cares; both are useful.
But if that's one of the bigger issues you see with project/site then I guess you are enjoying it here. :D

[edit]
OK. I bet it's an April Fool's joke if you compile the source from the OP.

lol,

*runs the Git clone command off pj64-emu.com*

Message from Git server: "APRIL FOOLS!"

or
*successfully clones off the Git repository off pj64-emu.com*
*goes into the source code release*
*sees only one file and it's just an ASCII text render of a giant middle finger* :D

But yeah seriously I guess I'm not in that great of a mood today. :)

Anyway I need to update my clone of the updated pj64 source with the Glide stuff in it when I get a chance.

p_025
15th June 2013, 08:13 AM
The beta program is now closed. You can now install project64 2.0 and get the clone the source if you want to.

Holy fuck. I tune in for the first time in six months and come across this. I love they've released the current source and I hope this sees the same explosion in development as Dolphin-emu has, since the authors up to this point probably won't be contributing much anymore, or am I wrong about that?

MarathonMan
18th June 2013, 11:21 PM
Holy fuck. I tune in for the first time in six months and come across this. I love they've released the current source and I hope this sees the same explosion in development as Dolphin-emu has, since the authors up to this point probably won't be contributing much anymore, or am I wrong about that?

zilmar is the only one that really works on the PJ64 core AFAIK, but there's a fair amount of development in the plugin sector.

HatCat
19th June 2013, 12:45 AM
Yeah except the input plugin, which zilmar intends to use N-Rage source to re-model Jabo's DirectInput.
[Erstwhile, squall indirectly has advised me into making a SDL input plugin over a RawInput one. :D]

Some people do their independent stuff to the core and I guess zilmar hears critique on that from time to time.

Btw, wish for Iconoclast to have a happy birthday, cause it looks like upgraded vBulletin board on EmuTalk omits it this year under the condition that his fat ass is still banned. :D

MarathonMan
19th June 2013, 01:52 AM
Btw, wish for Iconoclast to have a happy birthday, cause it looks like upgraded vBulletin board on EmuTalk omits it this year under the condition that his fat ass is still banned. :D

:D (thumbsup)

MMredux
25th December 2013, 07:09 PM
Seems like i have more issues using rice video with the newer versions im stuck using 1.6 for retexturing.

et500
3rd January 2014, 12:41 PM
Is this the official github project page? https://github.com/twostars/project64/commits/master

In order to attract new talented developers, contributing to project64 should be made as easy and convenient as possible by using google code or github to advertise the project. There is still a lot of work to be done.

HatCat
3rd January 2014, 07:07 PM
There is no official GitHub page, but I think you already could see that from the OP of this thread, which has the necessary instructions.

the_randomizer
5th January 2014, 02:03 AM
Still in better shape than Zsnes 2.0

HatCat
5th January 2014, 02:31 AM
You can flaunt around infinite Git repositories with [deviant] forks of Project64; it will contribute nothing to emulation by itself.

There is nobody on this entire forum who is going to be able to directly fix Project64, without first obtaining the level of skill concerned with closed-source challenges. You must learn to think independently; desire with arrogance depend on too many things.

The only people who even have any interest of contributing to Project64 themselves are either too caught up in the sheer desire of the result to pursue the necessary experience, or are already too busy familiarizing themselves with smaller building-block projects.

If you really like the Nintendo 64 that much, and see nothing coming to life just by being one of 99% of the planet's population to list ideas of how other people can do the work for you, you would have thought of some different behavior for a change.

the_randomizer
5th January 2014, 08:16 PM
Who the black hell was that directed to? I hope it wasn't me because I didn't even mention the N64, just that fixing up PJ64 is more viable than seeing Zsnes 2.0.

HatCat
5th January 2014, 09:03 PM
I get many afterthoughts. :p
Sometimes I'm in the mood to clarify things; other times I would rather hurry up and post so I can get back to work.

If you're not interested in persuading open-source people to take over the scene for you, then my post had nothing to do with you.

Since we're on the subject though, I thought ZSNES was pretty cool.

the_randomizer
5th January 2014, 10:34 PM
I get many afterthoughts. :p
Sometimes I'm in the mood to clarify things; other times I would rather hurry up and post so I can get back to work.

If you're not interested in persuading open-source people to take over the scene for you, then my post had nothing to do with you.

Since we're on the subject though, I thought ZSNES was pretty cool.

Zsnes was for the time, but then Snes9x came along and used Blargg's S-SMP and left Zsnes in the dust lol. I'd never want to recommend it unless someone was running Windows 98 on a toaster :D What irks me is how bad the sound emulation is compared to Snes9x 1.53, it's nigh-on identical to real hardware, so yeah, cycle-accurate audio emulation (I think). I would suggest Bsnes, but for many reasons, I don't (long story).

As for emulation, I don't know what's going to happen with the N64 in all honesty. The first problem is yeah, I'd love to contribute, the problem is I wouldn't know where to even begin, as my programming knowledge is crappy at best ROFL :D So in essence, my contributions, if you can call them that, wouldn't amount to jack squat. :confused:

HatCat
6th January 2014, 02:32 AM
You could probably do all the controller/joystick stuff that some of us (like myself) have neither the hardware nor the interest to design, learn or test. (I only use keyboards.)

Maybe some XInput plugin; I read there was some guy at EmuTalk who allegedly had crap to nothing experience with programming but pulled off a basic XInput controller plugin.

If it is one good thing about this plugin spec, it divides so much of the "emulation" away from what really is anything core to N64 emulation, such that you can know next to nothing about either emulation or programming yet still pull off something useful.
(I'm the exact opposite tho; I still suck with APIs even after all this time. :p)

RPGMaster
6th January 2014, 05:34 AM
I decided I wanted to play around with the pj 1.6 source since that version seems to have the best performance for me. I ran into a few issues. One is that the rom list is messed up and won't display any names. Another issue is that when I compile with RELEASE_EXTERNAL, the emulator doesn't even work at all, so i use release which seems to have debug code in it.

My goals are to get better at programming, contribute what I can, and also improve the quality of whatever I decide to work on (either emulator or gfx plugin). I'd appreciate any advice/tips :) . Ima study up on algorithms.

HatCat
6th January 2014, 07:48 PM
I decided I wanted to play around with the pj 1.6 source since that version seems to have the best performance for me. I ran into a few issues. One is that the rom list is messed up and won't display any names. Another issue is that when I compile with RELEASE_EXTERNAL, the emulator doesn't even work at all, so i use release which seems to have debug code in it.

My goals are to get better at programming, contribute what I can, and also improve the quality of whatever I decide to work on (either emulator or gfx plugin). I'd appreciate any advice/tips :) . Ima study up on algorithms.

If you are compiling with Visual Studio then you can usually disregard the configurations manager and just fixate everything to your consistent needs.

Somewhere in VS project settings are options like "Generate Debug Info" (the one you want to look for to evade builds with debug info linked into them), "Buffer Security Check", warning level...those are things I usually find myself changing when I open a VS project.

RPGMaster
6th January 2014, 09:48 PM
Ya I'm using Visual Studio. I went ahead and changed the settings like you suggested. I was looking through the code and saw a lot of things like #ifndef EXTERNAL_RELEASE
default:
DisplayError("Does %s effect Delay slot at %X?",R4300iOpcodeName(Command.Hex,PC+4), PC);
#endif
so I'm confused why External release doesn't even work lol. Yesterday I learned how #ifndef works, so I know that this code will be removed when you switch to external release mode. I guess I'll have to manually test each one to see where the problem lies. Also do you know how I can fix the rom list? Every game says "Bad ROM? Use GoodN64 to check for Updated RDB".
Lol this looks like a lot of fun though. One last thing I need assistance with is profiling. Any advice on that would be nice.

HatCat
6th January 2014, 10:19 PM
dunno , to say the truth I never once attempted to build source to pj64.


Compiling massive emulator project never was my investment, but there probably are some beginners here who got it to compile.

About profiling, there is no unbiased way to do it, so I'm primitive enough to just write my own wall-clock benchmark.

RPGMaster
7th January 2014, 12:10 AM
Seriously idk why more people don't do this. I have no idea what I'll be able to do, yet I'm legitly excited LOL. For the time being, I've just been using loops and system clock to compare 2 pieces of code. I just wanted to figure out how to find bottlenecks so I can focus on those. I guess I'll do more reading on profiling and optimization techniques. I think I'm going to also work with the rice video plugin. It's open source right? I've been wanting to learn Direct X and eventually open gl.

HatCat
7th January 2014, 12:53 AM
I'm not interested usually in either profilers or benchmarks (or loops).
The best way to understand bottlenecks is to do so through your own experience, not what the profiler tells you.

For example 99% of my analysis while developing RSP plugin was by checking the assembly output file generated by the compiler per every change I made for which I was not certain whether it was for the better or for the worse. When you're not sure or it isn't clear, prefer smaller code size over larger code size in the x86 output for more cache space. Don't waste too much time being analytic over microperformance appearances in what the profiler tells you to think; just judge for yourself.

I only wrote my own wall-clock benchmark implementation in the RSP emulator because it made it easier for one exact thing that was getting to be complex. For simple projects it's best to just learn to trust in yourself.

RPGMaster
9th January 2014, 12:29 AM
Lol I guess I was overdoing it with the optimization. I already look at the ASM output, so I'm good in that aspect. Right now I'm learning SSE instructions :) . Now I got to figure out the best compiler to use and the best settings as well. I'm guessing it will be Intel's, since I'm using an intel processor and I want the code to work well specifically for my pc. I'm also debating whether to upgrade visual studio 2010 to 2012.

Where can I get your latest version of your rsp plugin?

HatCat
9th January 2014, 02:58 AM
I have never thought to buy Intel's compiler.
A lot of people just use Visual Studio, but I hate that it won't let me weigh my own branches.

Regardless, if you're going to develop on platforms other than Microsoft Windows, you'll need to get familiar with the GNU tool chain.

I think RSP plugin got posted about here http://forum.pj64-emu.com/showthread.php?t=3618

RPGMaster
9th January 2014, 04:22 AM
I have never thought to buy Intel's compiler.
A lot of people just use Visual Studio, but I hate that it won't let me weigh my own branches.
Thanks for the link. What do you mean by it won't let you weigh your own branches?

HatCat
9th January 2014, 05:00 AM
Let's say we want to do this in Visual Studio:


if (A & B & C & D & E & F & G & H)
{
massive_function_of_loads_of_things_to_do();
}
else
{
very_small_task_to_do();
}


Conceptually, the massive function will be WAY more code to execute (and use up more of the x86 instruction cache or risk a cache miss), so ordinarily we'd want to set up the if-else branch statement so that the x86 BRANCH operation is to jump to the VERY SMALL task to do. We jump to the smaller code because jumps take more time than not doing a jump, and we balance out (or average) the execution time by making the smaller code take longer and the massive code go faster without ever having to jump.

This is Microsoft's logic.
But it's wrong!
A & B & C & D & E & F & G (bit-wise AND of 8 0/1 bits) has a 1/256 probability of being TRUE.
It is VERY unlikely that the if() block will be branched to.

So PROPER logical branch prediction should let the user decide, that what's under the if { } is the code that the x86 code gen should generate a jump TO. But instead, Microsoft Visual Studio gives you no say or credibility in the matter, and assumes that since the if { } code is massive, the slow jump operation should point to the faster code to balance fast code with slow code.

Again, this is NORMALLY good logic to apply, but they've failed to factor in the extreme lack of likelihood, or probability, of the condition in question. If this code were in a N64 emulation loop that got executed 60,000 times, it would be that much slower when compiled by Microsoft compilers than GCC: 60,000 times worse. Branch prediction is very important, and Microsoft gives you no control over it because, as is their philosophy with Windows, all end users are idiots (even programmers).

RPGMaster
9th January 2014, 07:39 AM
Is there no manual way to fix that in MSVC? I remember learning that you should put the more likely to be true statements first.

In terms of assembly output, what would good branch prediction look like for this scenario? When I tried the pseudo code you gave and looked at the assembly, it moved A into a register and did a bitwise & with the other 7 variables then does a jump if zero to the small task.

HatCat
9th January 2014, 04:48 PM
Is there no manual way to fix that in MSVC? I remember learning that you should put the more likely to be true statements first.

I've tried everything next to inline assembly, but I've never found a manual way to fix it in MSVC.

Even goto (label) statements in C or jumping to some isolated or otherwise unreachable block of code (like a label put in some while (0 != 0) loop) don't fix this: Visual Studio will ALWAYS and unconditionally generate jump instructions pointing to the faster code, to avoid having to jump to the larger/slower code.

All you can really do is, if you ever have to do this in MSVC:


if (condition) {
f(x);
} else {
g(x);
}


a) Try rewriting the function f(x) to be faster than g(x), so Visual Studio will implicitly recognize correct prediction.
b) Try inverting the if-else statement manually yourself:

if (!condition) {
g(x);
} else {
f(x);
}

... if you can be sure that it MUST be g(x) that is faster, so that you will adjust your statements to the way Visual Studio will implicitly force them anyway and that other compilers like GCC will just use it cause you wrote it that way.
c) Use inline assembly using the non-ANSI __asm keyword (not recommended because not portable).
d) Hope that Visual Studio's incorrect branch prediction amounts to no virtuous impact in performance/speed (the code you are writing is not the performance critical part).
e) Get a better compiler. :p I know firsthand GCC/MinGW will let you force it in ANSI C.

In terms of assembly output, what would good branch prediction look like for this scenario? When I tried the pseudo code you gave and looked at the assembly, it moved A into a register and did a bitwise & with the other 7 variables then does a jump if zero to the small task.

Just as I feared.

Like you said, it did this register math:

dx = (A & B & C & D & E & F & G & H);

and you said it did a JUMP IF ZERO, meaning A & ... & H is FALSE.

So Visual Studio INTERNALLY, just as I said it would, inverted the if-else pseudocode I gave you from:


if (A & B & C & D & E & F & G & H)
{
massive_function_of_loads_of_things_to_do();
}
else
{
very_small_task_to_do();
}

... to ...

if ((A & B & C & D & E & F & G & H) == 0)
{
very_small_task_to_do();
}
else
{
massive_function_of_loads_of_things_to_do();
}


Sure, looks good because slow jump operations are only applied to very_small_task....
But does Visual Studio have any idea how extremely likely that A & ... & H condition WILL almost always be 0? It's a waste of time.

And besides, theoretically speaking I'm not sure there is any true algorithm for a compiler to detect preferred branch prediction...I think there are cases where it really just depends what the programmer intends, and it should be left to him.

HatCat
9th January 2014, 05:03 PM
As an example, let's use debugging.

Say we want to throw an error if a conditional expression is true.


if (A | B | C | D | E | F | G | H)
MessageBoxA(NULL, "Error", NULL, 0x00000010);
else
even_larger_and_slow_function();


Microsoft's method -- based on code size balancing -- is correct. We have no intention of optimizing error-tracing or debugging code because the purpose of our program is not to throw error messages. It is more of a rare thing a branch weigh should target to jump to.

My method (well the particular one I just talked about) -- based on conditional probability -- is incorrect. With the method I just gave against Microsoft's, it fails here because A | B | C | D | ... | H is VERY likely to be true, not false (as opposed to of course "AND-ing" them). So with my method, it generates a jump to the code which has an actual probability of not being reached as often (even_larger_and_slow_function) HOWEVER, if this code were in a massive loop repeated 65,000+ times (and we do not expect to call WIN32 MessageBox error tracing nearly half that many times), my method would be that much worse and slower, 65,000+ times, than Microsoft's method because we really do not care to optimize branch weighing for error-tracing or special code functions.

So it really depends.
My point is that there is no one unanimous algorithm to weighing them properly.
You just need to look at those two factors yourself and decide on your own which is better overall.

In fact, MANY times you can eliminate if-else branches:

if ((INT32)(x) < 0)
y = 5;
else
y = 1;


Here, the result of `y` is a function of 32-bit register variable `x`.

We don't need to do any branch weighing here because we get to do branch-folding.

y = 4*((unsigned long)(x) >> 31) + 1;
... using the most-significant (sign) bit's set value in register `x` as the input.

This is one of the things I see just about any N64 emulation code fail to adopt for performance-critical things.
For example it gave a noticeable speed boost to MTC0 SP_STATUS conditional bits in the RSP interpreter (or even a recompiler would be affected this well)

HatCat
9th January 2014, 05:15 PM
And besides, theoretically speaking I'm not sure there is any true algorithm for a compiler to detect preferred branch prediction...I think there are cases where it really just depends what the programmer intends, and it should be left to him.

One good example of this btw is file I/O.

Say you are writing a FLASHRAM N64 save file editor for Zelda Majora's Mask.

You are reading a sort of EEPROM-ish "magic number" from the FLASHRAM save file.

You compare the number stored in Zelda MM save file .fla to see if it matches what proper Zelda64 save files use.

How can Microsoft Visual Studio, or any C compiler in existence for that matter, possibly know for certain which branch prediction model is correct?

Yes, the unanimously best if-else branch weigh should be one such that the x86 jump instruction jumps to the error code, where there is a magic number mismatch against what Zelda64 save file should really contain, but, how does any C compiler know what byte/word/DWORD/??? is *supposed* to exist, more likely than not, in some stdio-streamed save file?

There are just cases where the compiler CAN'T know.
That's why it should give you the option of forcing the if() expression to be the x86 jump, but Visual Studio does not.

et500
10th January 2014, 12:52 PM
While visiting EmuCR, I just stumbled on Jario64, which claims to be a Project64 based N64 emulator written in Java...

https://code.google.com/p/jario/

HatCat
10th January 2014, 03:33 PM
yep read about it sometime on EmuTalk a few years (months?) back, don't remember a whole lot really

Only one memorable thing I liked about my Java class:
myCard.getFace();
so maybe in Java emus can get an upgrade to sock the user in the face.

RPGMaster
13th January 2014, 07:28 AM
Sigh, I'm struggling to compile a bunch of stuff. I've been trying different compilers and stuff now, to see what I should do for future programs. I can see why people advise against inline ASM now. Switching compiler settings alone can break a program lol. I'll have to be more careful from now on :) .

Anyway, is the GCC compiler for windows any good? I heard it's worse than it's linux version. I'm trying to see what different compilers do differently in terms of x86 output.

HatCat
13th January 2014, 05:36 PM
If you're just trying to compile Project64, don't worry about "using the best compiler". The easiest way is to just adapt to the way they did it, which was in Visual Studio. If your changes are dedicated and/or rigorous enough, the choice of compiler may change later, but generally for Win32 applications Visual Studio does the best link-time job and such (even if not optimized code).

GCC (the GNU compiler collection) ported to Windows is called MinGW ("minimalist GNU for Windows"), enabling you to compile with GCC on Microsoft Windows platforms. It probably is the most unorthodox compiler, at least that I've ever encountered, but it is very optimized concrete output. I needed it for my RSP emulator since Microsoft Visual Studio has no auto-vectorization and also generated some other code poorly for the kinds of problems I was solving.

RPGMaster
13th January 2014, 09:26 PM
Good to hear about gcc. I will start testing it out, not for pj64 of course. I fixed some of the problems I had with Visual Studio. I don't even know what I did, but at least now PJ64 runs fine with the exception of the rom list still being messed up. All I did was delete the project and start over again lol... My problem with rice video is that idk how to include Direct x, but I'll give it another try today. I did download the Direct X SDK already, I just don't know how to set it up.

Also, is there a way with visual studio for the compiler to ignore inline assembly code? It gets annoying when I write pieces of assembly code, and the compiler ends up changing other code. I understand why the compiler does it, but sometimes it's just counter productive. It's very fun learning from the compiler, because it pulls out magic numbers and comes up with some interesting algorithms.

HatCat
13th January 2014, 11:22 PM
I have no experience writing inline assembly code into C source. (I've worked with it before; I just usually end up removing such facilities because they're not portable at all.) Not only do most normal C compilers out there *not* have any support for inline assembly, but there is different syntax for doing so. Microsoft Visual Studio uses Intel syntax (which I personally prefer at least for the Intel architecture's machine code :rolleyes:), whereas GCC uses AT&T syntax (which MarathonMan undoubtedly prefers).

If you want your code to work on any standards-compliant compiler, then avoid inline assembly. C its self is low-level enough that you generally already have enough power to avoid it. Having said that, I'd answer your question if I knew what you were talking about insofar as the "ignore inline assembly code" bit. (I think commenting code pretty much makes it get ignored?)

--------

About setting up DirectX, I wouldn't, because it's more of Microsoft's problem than mine, but I have had to work with it before in some basic plugins. From the DirectX SDK you just need to add dxguid.lib (unless you resort to the infamous #define INITGUIT alternative which MSFT doesn't recommend but does remove some crap code from the linked module) and whatever other libs corresponding to the layers of DirectX you're using (DirectDraw, DirectSound, Direct3D, whatever). The other part is what you'd expect: Have all the *.h header API files in the include directories so you can #include them. :p

RPGMaster
14th January 2014, 12:00 AM
Lol I ended up following your advice before you even replied :) . Turns out I was able to do what I wanted in C. I guess I should read up on C because it seems like some things are just easier to do in assembly. I'm sure some of them are easier for me to do in assembly simply because I haven't learned how to do it in C. I just figured out how to treat a variable any way I want. What I mean is do things like set the 3rd bit of an int to a value or set 4 bytes of a c-string to a specific value. I was just confused how things like *(int*)&variable works. I think I got the hang of it now though. I definitely prefer intel syntax over AT&T. I can't stand looking at assembly code if it's not Intel syntax. Honestly if it weren't for google, I'd be much worse at coding. I keep learning useful things that I don't see in any of the books I've read. Is there a manual or book where I can learn more about things like *(int*)&?

Lol I'm bad at explaining things. My problem with inline assembly is that sometimes when I mix ASM code with C code, the compiler changes code outside of my inline code, which is annoying because it defeats the purpose for what I am try to do. So my solution in those situations where the compiler messes things up, is to either convert more C code into assembly or write all of it in C. What I meant by ignoring is making the compiler not change other areas of code because of my inline assembly. I don't think there is a way to fix it. Funny thing is, I tried using the emit macro, and that made the compiler do different things.

Alright, I'll try to do what you said for Direct X.

HatCat
14th January 2014, 12:17 AM
Lol I ended up following your advice before you even replied :) . Turns out I was able to do what I wanted in C. I guess I should read up on C because it seems like some things are just easier to do in assembly. I'm sure some of them are easier for me to do in assembly simply because I haven't learned how to do it in C.

I got that feeling.

I learned assembly languages before I learned C.
Never did read up any books/texts to learn C (aside from the occasional inquiries here and there), just read the official processor manuals to jot down what I needed to know about assembly and, once you get used to the somewhat arbitrary syntax, you'll teach yourself C just as well.

I just figured out how to treat a variable any way I want. What I mean is do things like set the 3rd bit of an int to a value or set 4 bytes of a c-string to a specific value. I was just confused how things like *(int*)&variable works. I think I got the hang of it now though.

The former: (expression >> shift_amount) & 1;
... will obviously extract the 3rd bit of an int to a Boolean value, if shift_amount is set = 3.

The latter, you could do it that way.
I think you've figured it out already.

Instead of: /* char string[9] */
string[4] = 'A';
string[5] = 'B';
string[6] = 'C';
string[7] = 'D';

... you'd probably do:
*(int *)(string + 4) = "ABCD" (except obviously this is not valid syntax, the ASCII string needs to be rewritten as a 32-bit hexadecimal).

But, the former is probably readable enough that the compiler would figure it out for you and generate 1 32-bit write of the 4 characters without you having to explicitly code that. Another advantage C has over many assembly languages.

I definitely prefer intel syntax over AT&T. I can't stand looking at assembly code if it's not Intel syntax. Honestly if it weren't for google, I'd be much worse at coding. I keep learning useful things that I don't see in any of the books I've read. Is there a manual or book where I can learn more about things like *(int*)&?

lmao, agreed, AT&T syntax is just fugly to me.
I think MarathonMan likes it cause it's more explicit with data types than Intel syntax.

Still, whether I generate assembly output using GCC (AT&T) or Microsoft compilers (Intel syntax), as far as I'm concerned for any specific debugging purposes they're about the same readability to me, with the major difference being that semi-retarded right-to-left principle. (Then again it's probably good practice for Hebrews.)

& just means take the address of a variable.
&(expression) will resolve to the memory address of where something is stored.

Since char array[4]; actually, on the low-level, declares an ADDRESS (called "array") where 4 bytes are stored, you don't need to say *(int *)&array (that's taking the address of an address and you can't do that); it's just *(int *)array.

Pointers are the last thing I stopped hating with C, I tell ya.
But when they finally make sense, you'll find the '&' operator isn't as frequently used as you might suspect.

Lol I'm bad at explaining things. My problem with inline assembly is that sometimes when I mix ASM code with C code, the compiler changes code outside of my inline code, which is annoying because it defeats the purpose for what I am try to do. So my solution in those situations where the compiler messes things up, is to either convert more C code into assembly or write all of it in C. What I meant by ignoring is making the compiler not change other areas of code because of my inline assembly. I don't think there is a way to fix it. Funny thing is, I tried using the emit macro, and that made the compiler do different things.

The compiler probably does that because it is an optimizing compiler.
If the compiler sees the inline assembly code you wrote, it might try to maintain legal, non-program-breaking changes on the exterior of the inline assembly you wrote if it means even MORE optimization. It's just trying to do its job; that's all.

And yeah, I would just try to write it all in C. Have never needed to use inline assembly yet.

RPGMaster
14th January 2014, 01:04 AM
Rofl, I really do need to try out different compilers. The reason I wanted to try out different compilers is because I keep getting conflicting information when I google things. Some people say MSVC is the best for windows, some say GCC is the best, and others say Intel. Now I bet Intel is probably the best (at least for intel cpu's), but I really got to try GCC now. Part of the reason I got into inline assembly is because the compiler I use (MSVC2010) seems pretty inefficient sometimes. When I do string[0] = 'A';
string[1] = 'B';
string[2] = 'C';
string[3] = 'D'; the assembly output looks like this mov byte ptr [_string],41h
mov byte ptr [_string+1],42h
mov byte ptr [_string+2],43h
mov byte ptr [_string+3],44h
. I also happen to enjoy writing code in assembly, so i do it for fun sometimes. My issue earlier was that I didn't understand how to do arrays with the *(int*). I initially knew that if I wanted to deal with just the 2nd byte of an int, I'd do ((char*)variable)[1]. The number in the [ ] would be multiplied by the size of the variable in the ( *). My problem was, I didn't want to size of that number based on the variable type inside ( *), then I just randomly tried *(char*)variable[i] and that worked. I also barely learned today, that you can do *(int*)(variable +2) to start at a different location. The reason I put & is that I was getting errors sometimes, and I never got errors when I put the &. I think it has to do with what language I compile as in MSVC. If that's not the case, then I'm just confused lol.

Ya I understand that it tries to optimize and reads the inline code as well. I was just getting frustrated that it keeps switching the registers it uses. For readability I just comment my code although it would still be a pain to write out the ASCII values in hex lol. I'm starting to use Macros now, which to me is amazing.

Edit: I just tried *(int*)(string+4) = 'ABCD' and it actually compiled. Only problem was that it stored the letters in reverse since I'm using a little endian PC. I made a macro that puts it in order for me :) . Now i don't have to write hex for certain things anymore lol.

HatCat
14th January 2014, 04:20 PM
I'd actually like to try out Intel compiler myself someday.
No reason not to, just that me I haven't gotten around to it. (Edit: I do have to pay for it, right?)

Rofl, I really do need to try out different compilers. The reason I wanted to try out different compilers is because I keep getting conflicting information when I google things. Some people say MSVC is the best for windows, some say GCC is the best, and others say Intel.

Yeah, well, essentially every programmer has opinions. It can get pretty religious at times. -.-

Fact is they're all good at different things. I'd say it depends what kind of project you're trying to do. Most of the time though GCC usually gives much more optimized output, but, there are again exceptions (like with bit-field decodes :D as some of us seem to have discovered).

When I do string[0] = 'A';
string[1] = 'B';
string[2] = 'C';
string[3] = 'D'; the assembly output looks like this mov byte ptr [_string],41h
mov byte ptr [_string+1],42h
mov byte ptr [_string+2],43h
mov byte ptr [_string+3],44h
.

Ah, guess I was partly wrong.
VS should be capable of figuring this out, but I guess it doesn't want to.

It could be also cause MSFT expects you to use an intrinsic of some sort to accomplish this, based on strcpy (the string copy function).
http://www.cplusplus.com/reference/cstring/strncpy/


strncpy(string, "ABCD", 4);

... should do the job more readably and maintainably. See what that outputs?

I personally have never tried strncpy before, but this I believe is correct. (I usually work with the plain strcpy() since all strings in C tend to use "null termination" as a safeguard for the rest of the C stdio.)

Ideally, it should actually be string[5], not string[4].
string[0,1,2,3] hold ABCD, and string[4] is the terminating null byte '\0' character you might read about.

But, that's not as clear of an example, because:

char string[5];
strcpy(string, "ABCD"); /* This writes FIVE bytes, not four. */

...is probably uglier output for the sake of this example, as it can't copy 5 bytes with a 32-bit write.

I also happen to enjoy writing code in assembly, so i do it for fun sometimes.

I'm curious.

This isn't impossible (as it applied to me too), but, you're new to C, yet you're more familiar with sticking to an assembly language often.

Are there any other languages in your programming history besides assembly?

oddMLan
14th January 2014, 05:41 PM
I'd actually like to try out Intel compiler myself someday.
No reason not to, just that me I haven't gotten around to it. (Edit: I do have to crack it, right?) (unless you want to shell out $700 bucks only for the C/C++ compiler)
:D

RPGMaster
14th January 2014, 11:25 PM
I'd actually like to try out Intel compiler myself someday.
No reason not to, just that me I haven't gotten around to it. (Edit: I do have to pay for it, right?)

Yeah, well, essentially every programmer has opinions. It can get pretty religious at times. -.-
Intel has a 30 day trial. My problem with the Intel compiler is that I heard they purposely make the performance worse for AMD computers, so I don't think it would be good for releasing public binary files, unless you have separate versions. I tried out gcc and I must say, the output seems to be a lot more efficient, at least when it comes to number crunching. I can see why people stick with MSVC though. I think MSVC is a great IDE and I liked it's features better. The only thing I really am not too happy with is the compiler itself. Maybe I'm a noob, but MSVC seems a lot easier to use than GCC. I'm glad to know that now I can learn from multiple compilers!


Ah, guess I was partly wrong.
VS should be capable of figuring this out, but I guess it doesn't want to.
I tried the string[0] = 'A' code in GCC and it also did 1 byte at a time. I'll check out that strncpy function.


I'm curious.

This isn't impossible (as it applied to me too), but, you're new to C, yet you're more familiar with sticking to an assembly language often.

Are there any other languages in your programming history besides assembly?
Sadly I have almost 3 years of experience with C++. I wasn't a serious programmer until a year ago though. Also I didn't do much practicing outside of school until I started getting serious. I also took 1 semester of C# and 2 semesters of Visual Basic. I suck at C# and VB lol. This goes to show how little you should rely on school to learn stuff. I learned a lot more on my own than I did in school when it comes to programming. I started teaching myself C a few months ago and Assembly about a year ago. For some reason the lower level languages just feel more natural to me (C and Assembly) compared to Java, C#, VB, etc. I used to think C++ was cool, until I started doing C. Now I don't even like C++ that much anymore. When I say I don't like C++ much, I just mean the libraries, not the syntax of the language. I much rather prefer using stdio over iostream.

I really wish I didn't listen to brainwashed people. In school I didn't even learn about bitwise operations (like OR, XOR, AND) or debugging until I took an assembly class (sadly it was some simulator language called PEP8). I should have been studying on my own from day 1 instead of just relying on school to teach me. Also, learning assembly really helped me get better at C/C++. Lately I've just been focusing a lot more on assembly, but I've also been learning stdio and winapi. I will probably start learning intrinsics soon, so that I can rely less on inline assembly. I would say my best language is C/C++, because I could write more complex algorithms easier, but when it comes to writing efficient code, sometimes I only know how to efficiently do it in assembly. One thing I could never find out how to do in C was branching off of a variable. What I mean is, lets say I had a variable named num which had the value of 401030, I can't just write goto num, to jump to 401030. Lol I know this might seem obscure, but I wanted to see how it's done because it's like that in Super Smash Bros 64, where the game jumps to a specific address, based on the value of a variable.

I finally started getting the hang of compiling PJ64. I still don't know why I had some of the problems I had earlier, but now everything works fine :) . The reason the display list was messed up was because I didn't put the rdb file in the same folder as my new pj64.exe lol. So now I'm just trying to see what good changes I can make.

HatCat
15th January 2014, 12:52 AM
Intel has a 30 day trial. My problem with the Intel compiler is that I heard they purposely make the performance worse for AMD computers, so I don't think it would be good for releasing public binary files, unless you have separate versions.

Somehow I don't feel the blame on them for that.
AMD does screw up a few things with conformance to the modern-day benefits of the Intel architecture, and code would have to get optimized in a different way for Athlon CPUs than Intel ones in some cases, like SSE.


I tried the string[0] = 'A' code in GCC and it also did 1 byte at a time. I'll check out that strncpy function.

Well that's surprising. Neither compiler did it?

Have you tried passing -O3 to GCC for full optimization?
I thought Visual Studio did 32-bit-write conversions from separate char writes I did in some of my basic plugins...maybe you're not using the optimized project settings like /O3 or /Ox in Visual Studio (I think it was). It's somewhere in the Code Generation settings.

Still, strncpy should do it.


Sadly I have almost 3 years of experience with C++. I wasn't a serious programmer until a year ago though. Also I didn't do much practicing outside of school until I started getting serious. I also took 1 semester of C# and 2 semesters of Visual Basic. I suck at C# and VB lol. This goes to show how little you should rely on school to learn stuff. I learned a lot more on my own than I did in school when it comes to programming. I started teaching myself C a few months ago and Assembly about a year ago. For some reason the lower level languages just feel more natural to me (C and Assembly) compared to Java, C#, VB, etc. I used to think C++ was cool, until I started doing C. Now I don't even like C++ that much anymore. When I say I don't like C++ much, I just mean the libraries, not the syntax of the language. I much rather prefer using stdio over iostream.

Oh yeah I only took one programming class in school, and it was about Java.
I probably learned less than I ended up teaching. -_-

I tried learning C++ I think *before?* C? I downloaded some books for both, but, I got really impatient learning by reading. I gave it up for a couple maybe 3 years, then through a spontaneous series of events started following my own example.

I don't know a thing about C# or VB though, lol.

I used to think the stdio in C was more annoying than the iostream in C++.
But after I taught myself all that jazz, I'm like, WUT?
C++ is frikkin' hideous to me now. (It's probably the best choice for people who plain and simple are way better at science/math than they'll ever be at computer science. But, nah, stick to HTML. :rolleyes: )

I really wish I didn't listen to brainwashed people. In school I didn't even learn about bitwise operations (like OR, XOR, AND) or debugging until I took an assembly class (sadly it was some simulator language called PEP8). I should have been studying on my own from day 1 instead of just relying on school to teach me. Also, learning assembly really helped me get better at C/C++. Lately I've just been focusing a lot more on assembly, but I've also been learning stdio and winapi. I will probably start learning intrinsics soon, so that I can rely less on inline assembly. I would say my best language is C/C++, because I could write more complex algorithms easier, but when it comes to writing efficient code, sometimes I only know how to efficiently do it in assembly. One thing I could never find out how to do in C was branching off of a variable. What I mean is, lets say I had a variable named num which had the value of 401030, I can't just write goto num, to jump to 401030. Lol I know this might seem obscure, but I wanted to see how it's done because it's like that in Super Smash Bros 64, where the game jumps to a specific address, based on the value of a variable.

If you learn stdio, then you probably learn everything I know about APIs, haha.
I never did get into WINAPI stuff. Microsoft mostly supports the C++ world of things.

Do you mean like a switch statement?


if (x == 0)
do_case0();
else if (x == 1)
do_case1();
else if (x == 2)
do_case2();
else if (x == 3)
do_case3();


... being replaced with:

switch (x)
{
case 0:
do_case0();
break;
case 1:
do_case1();
break;
case 2:
do_case2();
break;
case 3:
do_case3();
break;
}


Here modern compiler theory will convert the logical if/elseif/elseif nature into an unconditional, "indexed" branch using a hash table or jump table.

It might convert the value (x) into an instruction memory offset, and use that offset to create the new location in code memory where the program jumps to, to avoid the problem of going through too many if'ss/else's to eventually find the code to jump to.

But, if you're trying to jump to a numeric address in C (not referenced by label of a function or other symbol), then, you can't. C doesn't really let you pick the numbers and exact numeric addresses where code begins because the compiler handles those matters for us.

I finally started getting the hang of compiling PJ64. I still don't know why I had some of the problems I had earlier, but now everything works fine :) . The reason the display list was messed up was because I didn't put the rdb file in the same folder as my new pj64.exe lol. So now I'm just trying to see what good changes I can make.

oh lol, sorry to hear actually because I was *thinking* maybe your ROM browser issue might have just been a newb issue with hte placement of the RDB file, but, I kind of felt bad bringing that up. Glad you figured it out though. :D

It's possible zilmar might really appreciate your help, but he's too busy dealing with the usual transitional channels in his career to log on here for months sometimes. So if you think you might be able to make a difference, you've got plenty of time to figure out how.

RPGMaster
15th January 2014, 02:40 AM
Well about Intel, ya I understand that AMD doesn't support all of the Intel instructions, but I have heard of people tricking the CPUID thing and improve performance on AMD cpu's. Maybe Agner's blog is outdated, but I was still disappointed when I read about it.

For the string thing, I did max speed for MSVC, but I did highest optimization for GCC. Funny thing is, I saw a piece of code like that in pj64 1.6 PIF_Ram[36] = 0x00;
PIF_Ram[37] = 0x06;
PIF_Ram[38] = 0x3F;
PIF_Ram[39] = 0x3F; I know about switch statements, but I was curious about that method I described because I was wondering how they did it in Super Smash Bros 64. They have a structure of data that contains the addresses for the player states of each action. The game then jumps to the address loaded from the data structure. I guess I should learn more about compiler theory. I'm interested in this stuff is because I may make a game one day, and I heard that finite state is an efficient way to make games. So I guess the compiler is did all that fancy work for them. It just sounds impressive considering that I heard compilers were bad back then.

My problem with pj64, was that it somehow was very buggy when I first compiled it. So I assumed that the problem for the display had to do with the compiler issue, rather than files/settings. I still don't get how erasing the project and starting fresh fixed the bugs I was getting and then finally yesterday while I was debugging, it just hit me that I didn't put the rdb file in the folder. Lol that would also explain why it says bad rom for my patched roms since I never updated the file.

Right now, I don't know what I can do to contribute. You think it's best that I work with 1.6 instead of 2.x? All I can do right now is read through the code and try to understand it. For me, it's hard to work with other people's code, especially when there's so much to read. I'd say my best bet is to find the most important things to work on and go from there. It will take a while for me to learn enough to do anything significant. I have too little knowledge about emulators at this point in time.

HatCat
15th January 2014, 04:59 AM
Funny thing is, I saw a piece of code like that in pj64 1.6 PIF_Ram[36] = 0x00;
PIF_Ram[37] = 0x06;
PIF_Ram[38] = 0x3F;
PIF_Ram[39] = 0x3F;

Right. This sort of code, while "algorithmically" unoptimized, is meant for maintainability and stability.

It's written like that in PJ64 source code because, you can change the bytes easier, and the byte addresses with 8-bit precision.

Sure, zilmar could have written it as *(int *)(PIF_Ram + 36) = 0x00063F3F; instead of those 4 1-byte write lines, but then it wouldn't be as..."flexible". His intention was probably to let the compiler figure out the 32-bit write for him. (I'm rather surprised that so far you haven't been able to reproduce this easy compiler strategy though.)

I know about switch statements, but I was curious about that method I described because I was wondering how they did it in Super Smash Bros 64. They have a structure of data that contains the addresses for the player states of each action. The game then jumps to the address loaded from the data structure. I guess I should learn more about compiler theory. I'm interested in this stuff is because I may make a game one day, and I heard that finite state is an efficient way to make games. So I guess the compiler is did all that fancy work for them. It just sounds impressive considering that I heard compilers were bad back then.

Indeed so. Compilers today are much better than what people had to explicitly lay out for compilers in the 90s.

(One very simple example of this is bit shifts. I'm sure you're aware of shifting integers like the x86 SHL instruction. Multiplying ax * 2 is slower than doing a SHL ax, 1, but, if you type out * 2 in C source code today, compilers will convert it to shifts for you. This is something you could not so easily count on compilers to do for you in the 90s.)

And what you described about the table of jump addresses in Super Mario 64 is exactly what I meant to model by the switch.

Whenever you type a huge switch statement with loads of cases, the optimizing compiler will not (or should not) generate thousands of conditional jumps. In the x86 output you should see it create a "look-up table" of addresses to jump to. (GCC will show this better I think...I'm not sure if you can see this just as well in Visual Studio output.)


const unsigned long table_of_addresses[4] = {
0x3FC496,
0x3E1298,
0x101101,
0x543210
};

... is an example of a look-up table containing addresses to jump to.

A switch() statement with 4 cases (case 0:, 1:, 2: and 3:) could get compiled to the assembly code where the assembler after that is able to generate the absolute addresses and created table like the one above. (Except this can't be managed on the C level since you can't force start addresses in C.)

Right now, I don't know what I can do to contribute. You think it's best that I work with 1.6 instead of 2.x? All I can do right now is read through the code and try to understand it. For me, it's hard to work with other people's code, especially when there's so much to read. I'd say my best bet is to find the most important things to work on and go from there. It will take a while for me to learn enough to do anything significant. I have too little knowledge about emulators at this point in time.

I think you should read through the code that makes most sense to you.

You think Project64 source code is most sensible to you? Practice with that.
You prefer Mupen64 or 1964 source code? Try experimenting with those.
1.6 source to PJ64 looks cleaner to you than 2.1? Check that out (or the older 1.4 source code).

The point is, at least in my experience, it is challenging sometimes to not let our ambitions get the better of our plans. If we start out right away with the "best" code, or the project we really want to improve (in your case PJ64), we might be over-encumbered by new programming experiences that will constantly distract us while working with huge, colossal code bases (especially a systems critical thing like an emulator).

So while 2.1 or 1.6 or even 1.4 PJ64 source code might be best, sometimes it's the smallest (even most incomplete and not finished) [emulator] source code bases that we learn the most out of experimenting with. But then again, we all have different methods of learning. I can't pretend to know what's best for most people.


I will say this much.
I'd rather evade talking about 1964/Mupen64 source code in this thread because it's kind of disrespectful to this topic and this forum (which is about PJ64 source). Sure I'd like an imaginative way to get banned, but there are better ways than that.

RPGMaster
15th January 2014, 05:49 AM
Well with the current compiler settings I was using (SSE2 enabled), it just ended up using the xmm0 register to transfer the values, so it wasn't as bad in this case. Another advantage to doing each byte separate is letting the compiler deal with endianess.

What I will do is just learn how to get the compiler to recognize exactly what I want to do. When I first started debugging n64 games, I was really impressed with the formulas they were using. Then after studying some more assembly, I decided to debug my C code and compare the difference between things like num *= 2 and num <<= 1. With MSVC, I saw that sometimes it would switch the num *= 2 to num += num instead of switching to num <<= 1. I feel silly, all this time I've been underestimating the compiler considering I've been using MSVC which has some obvious flaws. I honestly don't know how anyone can say MSVC produces faster code... It didn't even generate efficient loops (especially if you use global variables). I guess compilers generally make code less efficient when you use global variables? I will say, I love how compilers generate magic numbers when doing math with constant values (like num *= 7). I used to laugh at people who said "you can't beat compilers", but now it makes a little more sense after seeing the performance difference between MSVC and GCC.

Alright, I guess I'll stick with 1.6 but maybe look at 1.4 as well. Now I just need to find the hotspots so that I can see what I'm capable of doing.

Edit: I was looking at some code in the dma.c file. Is there any reason why they wrote mov edx,0 with inline assembly? I thought it was better to do xor edx,edx? Also I just went ahead and installed MSVC2013 since 2010 kept crashing anytime I right clicked a variable or register while debugging. I noticed it optimized the strings a lot better :) . I hate how they made the disassembly view look worse while debugging in 2013. It no longer shows variable names, and it only tells you the address that it pushes and not the variable. Lol either I initially had the wrong settings enabled or installing MSVC 2013 changed the compiler for 2010 as well, because I don't remember seeing the optimized string [0] = 'A', but now I see it even in 2010.

HatCat
15th January 2014, 06:07 PM
I'm really not sure how MSVC works with different memory types in that regard.

I figure it might possibly be doing ...
add ax, ax;
... instead of ...
shl ax, 1;
... because they aren't really all that different performance-wise. (Though if anything I'd say the SHL by 1 is preferable.)

Or it could do a LEA instruction, where it handles both writing the function of the source memory operand (multiplying it by 2 with an internal shift of the source operand) TO a destination memory operand which effectively kills two birds with one stone (multiply and store in one instruction).

No doubt about it, though: There are cases where the compiler just never figures out some of the shit you're really trying to do. I wouldn't blame you for sticking to assembly code anyway, but even so, I'd keep such resorts for only the performance-critical code, those within the main bottlenecks.
Compilers will also continue to improve over time, over years and over decades, so other times all you have to do to fix it is keep upgrading till it works. :D

Edit: I was looking at some code in the dma.c file. Is there any reason why they wrote mov edx,0 with inline assembly?

Heh. It is, actually, but a few people out there are rebellious against the Intel optimization manual.

I didn't know zilmar might be one of them.
Many people say XOR reg,reg is full of shit, and that it should just be MOV reg,0.
After all the latter is more readable, natural and somewhat maintainable.
(The other optimized way to say it is SUB reg,reg instead of XOR reg,reg.)

Of course, if this is the worst case of non-conformance with PJ64 inline assembly code, I doubt the performance degradation from solely this amounts to much.

RPGMaster
15th January 2014, 11:51 PM
I just wanted to make sure before I made changes lol. What I am going to do is use #if #else so that I can quickly test my changes vs the original code.

For compiling, would enabling SSE mess with the accuracy of the emulator? Also enabling inline functions increase the code size by quite a bit. I wonder if it's worth turning on.

HatCat
16th January 2014, 12:08 AM
I don't think enabling SSE(n) code generation would affect much of anything in Visual Studio, even for a project like Project64. MSVC is very skeptical about processing ANY C code as SSE1 or SSE2. The only time I've ever seen MSVC convert anything to SSE code generation was stuff you did through memset or strcpy, maybe memcpy.

By contrast, if you write a loop like this in C under MinGW/GCC compiler:

INT16 vd[8], vs[8], vt[8];

void do_SSE2_XOR(void)
{
register int i;

for (i = 0; i < 8; i++)
vd[i] = vs[i] ^ vt[i];
return;
}

...then GCC should actually generate the SSE2 PXOR instruction (which is the _mm_xor_si128 compiler intrinsic) since all 3 vectors are 8 * 16-bits to correspond to the elements of 128-bit SSE2 vectors. Visual Studio is not so adventurous.


> Also enabling inline functions increase the code size by quite a bit. I wonder if it's worth turning on.

Check the speed and performance of the emulator at run-time.
If games seem to all play at the same speed, then I'd say leave it off for small size.

RPGMaster
16th January 2014, 04:38 AM
Well, that's good to know about sse.
Lol sigh, I fail at optimizing. It looks like the important parts of the emulator are already well written. I'm guessing I should focus on working with graphics plugins instead. I'm convinced I won't be able to see a noticeable difference from tweaking the emulator itself. Please correct me if I'm wrong though.

HatCat
16th January 2014, 05:05 AM
I don't know.
I have not had a good look at Project64 source code, let alone tried to build it.

Since zilmar wrote both PJ64 *and* RSP interpreters, I can only presume that he styled neither for purity and directness.
But, many programmers do change styles over the course of so many years. He might have thought differently then.

I've had a couple peeks at it to find out certain answers, and from what I can tell 2.1 source is some of the most complicated tree...I really have no interest in it. It's simple-engineered and small, where possible, projects that interest me.

I really can't stand C++, so as much as I might be able to speed up or even fix some things about the PJ64 interpreter (that aren't broken in others), I'm really not interested personally and especially not in an audience of attention from worldly human being noobs who know nothing more than how to use the program.
But I really don't intend that to discourage you.
By all means, if you do have any interests/fascinations with PJ64 source code, don't let what I say change your mind. Practice around with it.

But yes, generally smaller projects (or at least things in your field of interest or specialization) would make for a good starting experience in most cases. The graphics plugin is quite a bit more complicated than audio and controller plugins, but also in need of the most optimization probably (not for HLE though I think).

RPGMaster
16th January 2014, 05:41 AM
I'll admit I'm pretty discouraged right now. Unfortunately I'll have to take things at a slower pace, because right now I have no clue on how to even progress. I will just have to be more patient. Beginner books were helpful, but now idk where to go for more advanced topics. I'll have to find a way to strengthen my main weakness (algorithms).

For now I will just try to read as much as I can, to increase my knowledge. I need to learn Direct X and Open GL anyway, so gfx plugins will be a good thing for me to work on.

I agree with you that many programmers change styles over time. I used to prefer iostream to stdio, when I was a noob at C++ and didn't know C. Now that I'm more experienced and understand programming a lot more, C just feels a lot more natural to me. I don't like reading C++ code either.

HatCat
16th January 2014, 03:40 PM
By the way, you don't have to learn DirectX. There's a cross-platform solution for everything. (OpenGL would be the primary one for graphics.) If you happen to end up liking OpenGL, you could learn the fairly synonymous OpenAL language for cross-platform audio.

Even easier to learn yet is SDL. That gives you enough basic and straightforward functions to just blit pixels onto the screen in a sample program, though it seems to operate a little more slowly than DirectDraw (the equivalent layer under DirectX) or OpenGL. A very small graphics plugin with only the basics implemented you could look at is the source to zilmar's Basic CFB Plugin.

RPGMaster
16th January 2014, 09:23 PM
The reason I want to learn Direct X is because from what I've seen and heard, it has better performance than anything else on windows. I prefer learning the more powerful API's rather than using an API that's a wrapper to something else. That's why I don't use MFC or even WTL and would just prefer winapi. Of course I haven't worked on any large projects, but honestly I don't see a real advantage in using MFC or WTL. It seems like once you know how to do something, you don't need that extra help lol. Despite what I've said, I still think SDL is cool and might be worth learning.

Between Direct X and Open GL, which one do you think is harder? Also, I'll check out that CFB plugin. If possible I want to learn both Direct X and Open GL. I'll just have to see how difficult they are to learn. I'd say I'm good at learning API's because I understand concepts quickly. My only issue is memorizing things, so I have to read previous examples sometimes, because I forget things.

HatCat
16th January 2014, 10:35 PM
First off, let's break it down.
The key to "DirectX", is that the "X" can be different things.

DirectDraw, Direct3D, DirectSound, DirectInput, even XInput and XAudio are all layers under the DirectX API.

DirectX is essentially Microsoft's biggest reason for success. (Edit: Windows' biggest reason.)
Windows 3.1 wasn't selling well over just plain MS-DOS or other operating systems which had OpenGL to begin with, so Microsoft needed to come up with their own thing that only worked on Windows.

If you only want to do 2-D pixel stuff, DirectDraw has rectangle-precision and is easy to learn.
Direct3D is for the 3-D triangles in DirectX and is what most N64 graphics plugins use. Its competitor is OpenGL.

I have no experience with either one (except indirectly OpenGL since I've brushed up on the OpenAL programming guide and specifications), but from what I've read all over, Direct3D is more suited to C++ programmers and OpenGL is for C programmers. (After all DirectX makes you go through that Component Object Model stuff, where the syntax varies inflexibly between C and C++, and Microsoft barely acknowledges the existence of the C language anymore.) So I would rather avoid it if this were me.

Also, Silicon Graphics adopted OpenGL for some things, and even used it to test their own pixel-accurate implementation of the N64 graphics. Its speed, performance and features are certainly on par with Microsoft's Direct3D, so I don't see any direct benefit to DirectX except maybe for C++ people who only care about Windows.

I'm not the credible person on this subject, though. I was never a gfx person with code.
But I doubt any graphics plugin developers would have intervened on this forum anyway, so this is just what I think.

RPGMaster
16th January 2014, 10:57 PM
Lol I have a habit of just saying Direct X. I know it's multiple things.
I was dissapointed when I found out Direct X is more OO than Open GL. I hate OO programming lol. My problem is that I like windows the most so I'm more interested in the performance of things for windows OS. That's why I'm learning WinApi instead of using wrappers. Now after doing some reading, I'm seeing conflicting information. The truth is probably mixed, but some say Direct3D is better on windows, some say they are about even, and some say OpenGL has better performance.

From my personal experience, Open GL applications usually performed worse on every computer I've used. What I'll do is try to learn both and write programs for both and see which one performs better. I stress performance a lot, because it's frustrating when I can't play a game I enjoy because my computer can't handle it. I hate the idea of programmers becoming lazier and expecting the users to upgrade hardware in order to run their software.

I've heard some people say that Open GL programmers are just doing a bad job, so I can't completely judge something based on the performance of other people's software.

Also, if I were to do Open GL, what input API should I use?

HatCat
17th January 2014, 12:20 AM
Sadly there isn't a very wide variety of option for input APIs.

Microsoft of course, as usual, has their own solution: The DirectInput, XInput layers of DirectX.

The only widely known multi-OS solution for handling joystick/non-keyboard controller input is SDL I think.

I've seen MarathonMan (who hates SDL and probably has every right to do so) use GLFW for joystick/controller input, so that might be another option.

I haven't really heard of anything else.


Good idea about writing basic 3-D demos in both Direct3D and OpenGL to see which one performs better on your machine.
That's probably what I would do. Honestly the idea of learning OpenGL excites me; I've just been putting it off because of emulation.