Help

[sir_eot]

Lawfull Reverse Engineering

Can anyone tell me what tools I would need to make my own N64 emulator
and plugins ?

Please keep in mind I don't care to much about starting from scratch
if there is a way to directly manipulate things I would like to take the
fast path=1

with emphasis on video plugins

I think I know what I would need but I would like to hear a veteran speak
on the matter.

Also keep in mind I wish to legaly and lawfully reverse engineer my own
emulator and plugins.

I'm an enthusiast who desires to own the hardware being emulated.

:bouncy:

 

[dogdogwoof]

well C++ for your emulator, Asm for reverse engineering side of it. For graphics plugins, then you'd need to focus on OpenGl/DirectX

 

[sir_eot]

Response

1. I just happen to have C++ and VB6
2. Know a little about how to use ASM and TASM32 and T-Linker
3. I feel this is a job for DirectX

One small catch about the directx 9.0c SDK
I can't get hands on that due to a problem with
verification of authenticity of my OS

That should be cleared up in about two months

So if you know where I can fetch the DirectX SDK for 9.0c
I could move things along.

Thanks for the Hard Coded Tips :term:

 

[smcd]

You don't have to validate - click continue & then opt-out and it works just fine.

 

[sir_eot]

Belated Response

Thank you so much for your help.

I had no idea their was a bypass method to aquire DX9.0c SDK ,

By the By , do I need a hex editor for anything ?

My experience with a hex editor has been observation of
file structure and file content , I've no experience in useing it beyond that.

1. I DO have the ability to convert base 10 to other things like ocx and binary
I may be slow at doing this in my head but I can get the job done.

2. My experience with VB6 has been dissasterous seems the very first thing
one needs to do in VB6 is import the windows kernel into the project
and as you might have guessed knowing all the functions of the
windows xp kernel is not something average joe is going to want to
hasstle with.

all things considered , and especialy ( the fact that the source for rice beta 10 ) has not been released at the time of this writting ...

I would still like to engage in learning how to program for video plugins
that can be used in project 64

by the way , I seem to be gods gift to the universe when it comes to
visualizing a video plugin GUI

Again many thanks for the information.

arty:

 

[Trotterwatch]

VB6; You can't seriously be considering writing a video plugin in this can you?

 

[Gent]

by the way , I seem to be gods gift to the universe when it comes to visualizing a video plugin GUI Again many thanks for the information.
arty:

lol Just remember. It aint whats on the box that makes it rock, its the goods that deliver the shiver.

 

[sir_eot]

Response

Hey there trotter glad your lookin in on me ,,,

Yes I'm considering doing anything I can possibly do to satisfy a need here
and in this particular case I don't care about any recognition I just want to
get a job done.

More to the point , it's just not wise to do more work than one has to
and your right trotter this is a very technical area and I thank the people
who put their hard work into it and time.

what I am zeroing in on is that I seem to want to add a 2x texture size
and smooth filter to the already 100% functional Jaobo D3D8 1.6 default
video plugin that comes with project 64

For me being more of an electronics engineer codeing is indeed a bit
of a challenge but only because the parameters haven't been well defined
in short I don't have my scooby doo decoder ring yet lol

once I discover what tha parameters are when it comes to a video
plugin , and here's an admition for the record trotter my experience with
VB6 and C++ ended when I became upset over having to import the windows
xp kernel into my projects , because all the functions of the windows kernel
are not something thats just put out there in the open , or lets just say
I had difficulty aquireing information I needed about the windows kernel.

I'm not a big time programmer or anything and I may seem to have
an ego when it comes to what I know about thing but I'm sure your aware
that the bottom line is life is to short to be concerned over emotionalism
when it comes to getting a job done.

I think it wiser from what you've all tried hard to explain to me
to target specific code and ask more directly what I need to do
to inject the code I desire into the source code and do a quick recompile

I realize my terminology may be lacking here and that may
be another reason why I'm treated with a little contempt
but I urge you to bear with me and help me get this done..

Quite simply I want to add a 2x texture size and smooth filter
to the default jabo D3D8 1.6 video plugin

does that seem like a more reasonable approach ?

and what do I need to do to accomplish that is my question.

j64:

 

[Clements]

You can't really add stuff to Jabo's plugin without the source (which Jabo alone has access and will not grant to people). Since Jabo has added Super 2xSAI to his plugin, adding other 2x filters will not be as difficult for him. Perhaps Jabo can fix the 'Force Filtered Rendering' option so that when used it creates fewer artifacts and looks a little better like the smooth options of Rice's.

Anyway, I suggest you look at the Open Source plugins first (Glide64, glN64() etc.), look at their source and probe around. Grab Mupen's source as well, along with the tech docs from dextrose and see what you can do. If you can fix anything then you can help the plugin developers.

 

[ScottJC]

I've already said about the source, seriously sir_eot you need to listen as people have told you things and you have took no notice of them. If you want to alter Jabo's plugin you need the source, otherwise you can do nothing about it.

Because of this fact you couldn't recompile the phrase "hello world" into jabo's plugins even if you wanted to.

Unless of course you are able to alter compiled dll code [hex editing], which is basicly hacking and incredibly harder than Programming - I doubt Jabo would approve of that and we tend to agree.

You need to work on plugins that have released the source, those are the ones you can make a difference in, such as Rice's Video Plugin.

This is how all programs work, they are compiled into machine code from their programming source code, Project 1.6 is no different, nothing can be done directly to it without the source code.

 

[sir_eot]

Response

Thank you all for your suggestions

I have a condition wich requires medication
and makes it's difficult for me to understand
the suttle nuances and social dynamics
that could lead to better relations.

Also makeing it very difficult to handel group situations.

So if anyone feels I've purposly or intentionaly ment to
block them out or ignore them I feel bad for that ...

Your very right , I did see what was said about source and
I seem to have blocked that out and stayed in my own world
but I assure you that was not on purpose I was scared and I'm sorry

:blush:

 

[ScottJC]

Oh, I didn't know about that, I apologize. Don't worry about it at least your in the right attitude, wanting to update things and make things better.

 

[sir_eot]

Rapid Response

You folkes are great !

about 4 posts and were already down to business !

I'm going to say stop at this point because clements is absolutely right
I can't really do anything if the authors haven't relased the source.

Perhaps in the future authors of plugins will trust the user enough
to allow them to have full access to all the functions of DX9 in their
plugin ... example allow user to select functions requardless wether
or not it will cause failure , perhaps some instructions beside each
function could help. wich makes rice beta 10 the ideal interface

I somehow see Rice fixing the problems before the end of the year.

In my mind I feel like a simple INI with no interface would be more ideal
sinse thats the method for most FPS-First Person Shooters like quake all versions , hexin , doom 3 , the list goes on.

It's going to be interesting watching the whole show ...
I feel things are darn near close to perfect ...
in fact I didn't expect things to even get passed UltraHLE but they sure did.

It really blew my mind when project 64 came out.

sadly two of my favorite tittles , Dragon's Lair 3d , and Zelda:TP
are slated for game cube so I wonder if I'm going to have another
hissy fit if the game cube emulator isn't working to well for Nvidia lol

Cheers to all you 3dfx owners , I still have my voodoo3500
but I'm glad about the Nvidia 3dfx merger ... 3dfx needed 32bit color
to really make it worth it they could have stood up more against Nvidia.

I know for sure I'm an enthusiast because I like all this stuff for it's own sake.

I did get hands on the DX9 SDK ... thanks to you all helping me.

I'll say one thing , it's damn good toilet reading material :evil:

Trotter wins the debate on wether or not I can make my own
emulator because quite simply he's right , I think he means
he believes I could do it , just not under the present circumstances
wich would make his ( year theorem ) correct ...

The best I'm hopeing for at this point is patch for jabo or rice gets fixed.

so meanwhile back at EOT labs here in amarillo , I'll be watching with extream interest.

PS. I sure will get on those other plugin source files and check them out.
I've already looked at Rice released source 1.5 there's lots of stuff
in it relating to drawing functions and pointers to the BMGlib.dll
everything seems modular before it's compiled into a singel file.
did anyone notice that Rice plugin changes it's GUI when used
with 1964 vs. Project 64 ?

just a passing though I'll bet BMGlib.dll is the problem

 

[Doomulation]

Perhaps in the future authors of plugins will trust the user enough
to allow them to have full access to all the functions of DX9 in their
plugin ... example allow user to select functions requardless wether
or not it will cause failure , perhaps some instructions beside each
function could help. wich makes rice beta 10 the ideal interface

Trust their users enough? There's more to it than that. Did it ever occour to you that a) they simply don't want users to mess with it b) they don't believe it's necessary or c) they don't want to go through the hassle to make it changeable? Each author has their own reasons, probably, but I might think that one of those might be the answer to as why they're not included.

And I keep complaining about users about ini files... they're outdated. Settings should not be messed with in ini files, and settings can be stored in the registry unless you're planning on doing it portable.

Btw, you don't need to do manual line breaking. Just enter your post and it will be wrapped automatically. Well, use it if you feel like it...

 

[sir_eot]

Response

Yes , very difficult to say exactly whats going through an authors mind
when it comes to GUI.

1. protecting from user tampering
2. INI files may indeed be an outdated method of parameter alteration
3. Trust factor.

any of those reasons are valid ...

I tend to want to view things from the programmers perspective
because I build my own computer wich is nothing more than
( insert tab A into slot B ) in my humble opinion , then I setup the software
again no big deal ...

so my thinking is why not take the next leap and learn about code
and whats under the hood ... no harm I suppose
doesn't it make sense to want to add that new carberator to a vehicle
you own ?

Anyway , I thank you all for your time and information.

It's a pleasure to be among the informed.