Options (Click to show):
Change Topic Title: Delete Topic: Restrict Topic:
Posted: 09 Jan, 2017 02:49
Wow, that sounds really great though, but that sure was a ton of work that went into it. XD Well good luck with the integration if it goes through then, will be very interesting to see where it goes from there.
Posted: 09 Jan, 2017 05:11
Last Edit: 09 Jan, 2017 05:15
Well I'd say the next order of business is to make a custom lib of libpng, zlib is already taken care of. libpng on NuGet only supports v120 and v140 toolset but both projects are set to use the v140_xp toolset.
There are a shitload of warnings in the older version of Snes9x but not the new one, I don't feel like fixing them so I'm turning them off.
3rd party libs/APIs should never be altered, that's why I'm using NuGet. W/ RA_Integration alone, there are no dependency projects or submodules (so much pain). It makes life easier. Unless it's a .net project there is no need to organize separate projects for the same purpose.
Posted: 10 Jan, 2017 00:18
Last Edit: 10 Jan, 2017 00:36
Ok ran into a giant snag and it has to do with RA_Interface. I never touched that area because it's purpose seemed ambiguous but I guess the "exports" are for the emus.
It might take me awhile to figure out what's wrong unless someone knows it well.
From what I've noticed so far it's a bunch of bad coding practices. I think I'll need to remove some includes from Snes9x and use conditional macros to make friend classes in RA_Integration. Snes9x 1.54.1 did a complete refactor and doesn't have these issues but I need to test with current versions.
There are also undefined/undeclared functions in RA_Interface (how in god's name did this compile before)?
Posted: 10 Jan, 2017 00:58
Last Edit: 10 Jan, 2017 01:33
There's two solution I think may work, one is more drastic but too bad.
The first one is to make all the "externs" static, redefinition is killing me. Extern is normally when your calling a function outside the scope of the project such as from a dll/lib. It makes absolutely no sense to call something extern in the same project unless you aren't using classes.
The second idea is to make it a class library with C linkage, it seems like it would solve a lot of things but I'll try that later.
Edit: I'm used to Object Oriented Programming, it'll be easier for me to just make it a class library as a C interface.
Posted: 10 Jan, 2017 05:43
OK, I "think" I might be getting somewhere.
I went ahead and made RA_Interface into a class, there's a few linker errors now with libpng and xaudio2. Some static functions defined in RA_Integration have unresolved externals as well.
Well I have class starting tomorrow so I might not have much time to work on this.
Posted: 10 Jan, 2017 23:16
Last Edit: 10 Jan, 2017 23:32
I'm having a really tough time working with globals so another "rehaul" will be required. What I'm saying is that everything in RA_Integration will be under the namespace "RA". The split files will have a namespace of the original filename filenames without RA. For example ComparisonType, ComparisonVariableSize, ComparisonVariableType, CompVariable, Condition, ConditionSet, and ConditionType will be under the namespace "RA::_Condition". Sub namespace names will be shortened if too long and be aliased where needed. This will allow us to use usings like C#.
RA_Core and RA_Implementation will now be classes as well with C linkage. Any class that does not have complex STL containers like vector, stack, queue, list, etc will not have C linkage as C does not support templates. All structs have been converted to classes as well.
This will make pointer to members and function calls from other classes a lot more efficient with less hassle. I've been sick and tired (not mad at anyone) with errors saying redeclared/redefined and all that garbage. Object-Oriented style is truly the best from a Software Engineering and Design standpoint. You can still export functions as C from C++ classes so the project will not break.
I'm still worried about RA_Keys.dll. If I can't figure it out I'll post an issue on the official repo.
I'm taking advantage of the friendship concept to ensure only specific classes can use protected/private members from another class. There were TONS of cases where memory leaks could happen that were obvious so that's why I made this decision. This makes it possible for most of the stuff I wanted to do early with relative ease.
I'm just doing this in my free time since it helps me out from a learning standpoint. Just posting updates when I believe it's important or just for reference.
@Scott (if you read this)
There were some parts of the code I didn't quite understand. In RA_Core there's a code block that goes like this:
#define API __cdeclspec(dllexports)
I've never really worked with drivers or whatever you use that for but I added another part but I'm not sure if I'm supposed to. Following Microsoft's example I made it like this.
#define API __cdeclspec(dllexports)
#define API __cdeclspec(dllimports)
I think the above makes more sense because RA_EXPORTS is not defined in "RASnes9x". Like RA_Integration is the exporter and Snes9x is the importer. I'd really appreciate some input if possible.
Posted: 13 Jan, 2017 03:23
Last Edit: 13 Jan, 2017 20:54
Edit: The below will apply if my proposed solutions don't work, this edit will be removed if that's the case. (see the second post for more details)
I'm just gonna tell you guys I'm gonna take a long ass break from this. The biggest problem now are to function pointers and will need to be rehauled (again...). RA_Integration still builds by itself but I'm have some trouble integrating it. I don't have time because of school.
If anyone is interested or just wants to read the below.
Main areas that need work (I'm not gonna push my recent changes because it won't build)
The function I'm having trouble with is InstallSharedFuncs (or something like that), I never using function pointers personally so it would take me too long (not that I would mind if I could spare the time)
I'm guessing RA_Implementation needs to stay global and not be wrapped in any namespaces or classes (because the namespace mangling probably messed it up so everything else can stay as a class with namespaces except RA_Implemenation).
I can just Merge changes later. Good luck to you all.
Posted: 16 Jan, 2017 06:09
Well std::function seems work exactly like a function pointer. It stores functions, binds calls, etc. The best thing is that you don't need to repeat the calling convention (__cdecl) inside it. It seems it has to be initialized to store a function or it will be considered redefined.
I think I'm getting somewhere, RA_Interface is gonna have the function pointers replaced. It also helps me find erroneous function pointers (like having int instead of void).
Posted: 20 Jan, 2017 22:44
Last Edit: 20 Jan, 2017 23:18
I've been extremely sick recently but today I've been feeling better. On the note of RASnes9x, there's another problem I ran into that I don't have any experience with. So like before, since we're using C++ I decided to use function objects instead of function pointers, ~function automatically gets called when the program terminates so the majority of RA_Shutdown has barely any use (I remember a discussion on that before).
So since it's an object and not a pointer or reference to an object I need another approach. So far I've been looking at here (didn't try it yet) http://stackoverflow.com/questions/15249465/c-dynamically-load-arbitrary-function-from-dll-into-stdfunction. and seems to be the solution. I don't know how Scott even got it to work before, void* and function pointers in general don't exist in C++ and won't even build with current compilers like G++ or VC++. void* and function pointers have been replaced by templates because eliminates memory leaks caused by them.
Well RA_Integration "builds" by itself but the implementation/interface stuff needed and still needs some changing. If you have any questions please ask, I can't promise that I'll know the answer but will try.
Edit: Reading this page https://msdn.microsoft.com/en-us/library/7h0a8139.aspx is giving me a better understanding of what this project is supposed to be. It seems that RA_Integration.dll is an MFC Extension dll and there's actually a wizard for that. And plus there's a wizard for dll exports/imports. I'm gonna look in to those, having free functions in an object-oriented language seems wrong to me.
Edit2: While the project does look like it uses MFC extension I reviewed Scott's repo and doesn't look like all the emus use MFC. I'm making a test just to utilize the wizard and there's three choices:
- Regular DLL using shared MFC DLL
- Regular DLL with MFC statically linked
- MFC extension DLL
Reviewing the repo, it seems RAVBA uses the second option so I think that's the best call for now.
Posted: 21 Jan, 2017 01:56
Last Edit: 21 Jan, 2017 01:58
I'm gonna go on a limb here and use the RA_Keys.dll that comes with the emus because that's where a dll initialization takes place. If something goes wrong I'll post an issue on RA's repo. It seems to import functions from it.
It really SHOULD be included as code if it's supposed to GPL, I've studied all that crap in my Senior Project/Ethics class.
Posted: 21 Jan, 2017 07:32
Last Edit: 21 Jan, 2017 07:40
I finally got this shit to build with RA's current version of Snes9x. I had to take some lazy shortcuts because I could not for the life of me resolve this linker error with the function's widen.
I'm guessing widen needs to exported but it's not. I made it inline instead of extern/static. I don't really care, I'm gonna try to merge this in the main repo. Still needs testing.
It would take too much effort to use functors now, I put back the function pointers, figured out how they work here they just needed tweaking to work.
Guess first thing I need to do is make a pull request between my two repos, I really didn't want to mess anything up.
Edit: scratch that, I just gotta copy and paste directly and resolve conflicts.
Posted: 21 Jan, 2017 15:14
Last Edit: 21 Jan, 2017 15:14
Ok craps ready for forking if anyone else wants to test https://github.com/SyrianBallaS/RASuite
It says it in the readme but you'll Windows 7.1A SDK, DirectX SDK (June 2010), NVIDIA Cg Toolkit. Also you can optionally get the FMOD audio API. Crap like zlib, libpng, missing directx stuff, etc. have already been taken care of. I did not work on any other emus except snes9x.
Posted: 21 Jan, 2017 18:53
Hmm, well, I probably won't be able to do much, but I'll dig out the Win10 laptop and attempt to get all those together if ONLY just to take a look at it. If I can get the time to anyway...but I'm really curious to see how it all works even if I can't do anything with it. Thanks for all the hard work!
Posted: 21 Jan, 2017 22:00
Last Edit: 21 Jan, 2017 22:05
Yeah no problem. Right now I'm having issues with RapidJSON. According to the documentation a "Document" is supposed to contain a json, either from string or stream. But it doesn't seem be done anywhere. I fixed that xstring assertion failure awhile back what
How on earth can an empty document, that's not even parsed do anything?
P.S: I should probably post the RA API documentation even though most of it is incomplete. It just makes it easier to read, if a method had a comment on it already then it's just wrapped in XML.
Posted: 21 Jan, 2017 23:59
I got somewhat of a help file put together. It's pretty useful for finding things. Gonna put it in the OP.
login to retroachievements.org:
or create a new account
or create a new account