Go Back   Project64 Forums > General Discussion > Site News

Reply
 
Thread Tools Display Modes
  #241  
Old 15th January 2014, 11:51 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.
Reply With Quote
  #242  
Old 16th January 2014, 12:08 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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:
Code:
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.
Reply With Quote
  #243  
Old 16th January 2014, 04:38 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.
Reply With Quote
  #244  
Old 16th January 2014, 05:05 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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).
Reply With Quote
  #245  
Old 16th January 2014, 05:41 AM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.
Reply With Quote
  #246  
Old 16th January 2014, 03:40 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.
Reply With Quote
  #247  
Old 16th January 2014, 09:23 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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.
Reply With Quote
  #248  
Old 16th January 2014, 10:35 PM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.

Last edited by HatCat; 16th January 2014 at 10:38 PM.
Reply With Quote
  #249  
Old 16th January 2014, 10:57 PM
RPGMaster's Avatar
RPGMaster RPGMaster is offline
Alpha Tester
Project Supporter
Super Moderator
 
Join Date: Dec 2013
Posts: 2,008
Default

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?
Reply With Quote
  #250  
Old 17th January 2014, 12:20 AM
HatCat's Avatar
HatCat HatCat is offline
Alpha Tester
Project Supporter
Senior Member
 
Join Date: Feb 2007
Location: In my hat.
Posts: 16,236
Default

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.
Reply With Quote
Reply
Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Forum Jump


All times are GMT. The time now is 01:21 PM.


Powered by vBulletin® Version 3.7.3
Copyright ©2000 - 2023, Jelsoft Enterprises Ltd.