So, Netrix, can we download the one you're working one? or not?
No. I am not "working" on it. I wanted to see how well it worked and give suggestions about it if I could. I am not going to be trying to make it playable, so there is no use for users to get the one that I have. I will only give it to other programmers if they do not want to go through the trouble of fixing the things that I did.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
After fixing several problems, I have it (Tiptup300's version) working (kind of). I only get 4-5 frames per second (with the VideoProcessor.cs modification), but it does load ROMs, and it seems to display them correctly. I have not actually waited long enough for it to go through all of the screens and get to the title, so I do not know if the controls work or not.
Unfortunately, I can not really be of much help because I do not have any experience with creating emulators. I did try to port SharpNES (as did several other people), and the only real problem was the frame rate, because the emulator's engine is taking up all of the CPU power. Some people were saying that the drawing methods needed to be redone to fix the frame rate, but from what I saw, the drawing itself had little impact on the frame rate. When I commented out the drawing entirely, the frame rate increased less than 2 frames per second. The emulator engine itself is what needs to be optimized.
The same thing should theoretically apply to this emulator. You both might already be aware of what I have just said, but I figured I would try to help a little anyways.
The only real problem with this emulator and the zune is the Timer class which I'm not sure how I could make such an exact timer... I'll see what I can do.
The only real problem with this emulator and the zune is the Timer class which I'm not sure how I could make such an exact timer... I'll see what I can do.
Can you tell me what exactly is the problem with the timer, or are you not sure? I might be able to help with that.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
I've been testing the following code for the PC version:
Code:
public void Update( double TimePassed )
{
Time += TimePassed;// Timer.GetInterval( this );
TMR.Update();
while( Time >= 0.0001 )
{
VideoProcessor.Run( 0.0001 );
Processor.Run( 0.0001 );
Time -= 0.0001;
}
return;
}
This is to help with synchronization between both processors(especially for large TimePassed values), and it has helped eliminate flickering. Unfortunately it might be too slow for the Zune, but I plan on making it optional.
I've also been doing some profiling and the Tile.Draw function is a major bottleneck. I think it should be about two times faster now. I've also added a frame skipping option to the VideoProcessor so only some frames are processed, but the system runs at normal speed.
There should be an update within the next few days. Some new changes are(other then the above):
- Different timer model
- IConfigFile is now IOptions, plus it can now be null if you don't fell like implementing it.
- Console object is now only created once, each cartridge load only creates a Cartridge object and not an entirely new system.
Oh and I've split/renamed some parts of the project. Now all the executables should be able to coexist in the same folder. Before my XNA and DirectX versions overwrote eachother.
So Tiptup300 you might want to hold off working on anything until the next update.
Has anyone created a Zune program using the C# 3.0 compiler? Having automatic properties would really help clean up some of the code. I assume it would work since I'd still be targetting .NET 2.0 and the bytecode is the same, but I want to make sure before I spend any time on it.
Also after seeing what you guys have to go through just to open files, I'm going to remove all the System.IO stuff from the emulator, though I'm still trying to figure out how.
Has anyone created a Zune program using the C# 3.0 compiler? Having automatic properties would really help clean up some of the code. I assume it would work since I'd still be targetting .NET 2.0 and the bytecode is the same, but I want to make sure before I spend any time on it.
Also after seeing what you guys have to go through just to open files, I'm going to remove all the System.IO stuff from the emulator, though I'm still trying to figure out how.
Do you mean the .NET Framework 3.0? I always make Zune programs with .NET Framework 3.5... I was not aware that you could use previous versions of the framework.
Using System.IO to open files is incredibly easy. All you need to do is: System.IO.FileInfo file = new FileInfo("path"); How much easier could it get? If you suggest using the Content Pipeline, you have to go through a lot more for that.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
No I meant C# 3.0, automatic properties are a language feature. I think you need the C# 3.0 compiler to use .NET 3.5, so I guess it'll work. Actually SharpDevelop has the option to target the compact framework, I'll have to try that.
About System.IO, there's another thread on this board where they say you have access a bunch of functions before using a file. Plus using System.IO limits any possible use of the content pipeline. I'd like to keep anything platform-specific out of the emulation code.
No I meant C# 3.0, automatic properties are a language feature. I think you need the C# 3.0 compiler to use .NET 3.5, so I guess it'll work. Actually SharpDevelop has the option to target the compact framework, I'll have to try that.
About System.IO, there's another thread on this board where they say you have access a bunch of functions before using a file. Plus using System.IO limits any possible use of the content pipeline. I'd like to keep anything platform-specific out of the emulation code.
I have no idea what the difference is between C# 2.0 and C# 3.0.
You do not have to access a bunch of functions. The only other one would be Directory.GetFiles("path"); to get the files in the Rom folder. An optional one would be one that makes sure that the directory exists so the program does not crash.
System.IO is not platform-specific. You would just need to put in one #if ZUNE and #endif. I do not see any advantage of using the content pipeline. It is actually worse to use it, since it limits any use of the file system. What if someone wants to open a specific ROM in Windows? The only way you could really do that is to use System.IO. I would rather have a few lines of code added instead of having a rather inconvenient limitation.
Do it however you want. It seems like you have experience with the content pipeline and have not used System.IO before. It does not really matter to me personally, because I can just put System.IO back in whenever I download it. I was thinking about other people that do not know to do such.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
wow guys, I feel like we're on the verge of something big happening. I saw the screenshot of the original Pokemon game being played and I got so excited. Let's keep this thing going! Good job guys!
__________________
No. Just...no. Don't do it....don't do it...DON'T ****ING DO IT!!!
Yes kids, referral link spam abuse is a terrifying thing. Come here to learn how you can get help.
What if someone wants to open a specific ROM in Windows?
What if someone wants to load ROM files from ZIP files or other compressed files? What if someone wants to use the content pipeline? What if someone wants to store save states and battery files other than the way I do?
I haven't replaced System.IO with the content pipeline. The emulator has two interfaces, one for input and the other for input. They're rather easy to implement, here is my current implementation for the Win32 interface:
Code:
public sealed class InputStream : IO.BinaryReader, IInputStream
{
public long Length
{
get
{
return BaseStream.Length;
}
}
public long Position
{
get
{
return BaseStream.Position;
}
set
{
BaseStream.Position = value;
}
}
public InputStream( string Path ) : base( IO.File.OpenRead( Path ) )
{
return;
}
}
Quote:
Originally Posted by Netrix
I would rather have a few lines of code added instead of having a rather inconvenient limitation.
Me too
Quote:
Originally Posted by Netrix
It does not really matter to me personally, because I can just put System.IO back in whenever I download it.
Well you shouldn't have to go in and add System.IO, it kind of defeats the point of the project.
Quote:
Originally Posted by Netrix
I was thinking about other people that do not know to do such.
This is the point of the project. Anyone can write there own interface/port without having to deal with any emulation code.
Quote:
Originally Posted by Darkside
is this fairly close to being finished?
The emulator portion needs battery files and sound. Save-states also need to be re-implemented as the current implementation is crap.
As for the Zune interface, that's Tiptup300's job. There's also no guarantee that it'll run fast enough on the Zune.
What if someone wants to load ROM files from ZIP files or other compressed files? What if someone wants to use the content pipeline? What if someone wants to store save states and battery files other than the way I do?
Would it not be difficult to write a ZIP importer that decompresses ZIP files?
Quote:
I haven't replaced System.IO with the content pipeline. The emulator has two interfaces, one for input and the other for input.
I thought you said that you were going to "remove all of the System.IO stuff from the emulator". If you are putting both in, that would be great.
__________________
"Against logic there is no armor like ignorance." - Laurence J. Peter
There's a small XNA version I made in there to help speed up porting. If you want to change the frame skip value just edit it in Options.cs, change the "0" to something between 1 and 9. 0 is full speed and anything above 9 is pretty much pointless.
Hopefully this version is faster, although I still need to optimize the memory and processor code. If you want to see the number of VBlanks the system is getting, use Console.VideoProcessor.FPS, 59 or 60 is ideal.
There's a small XNA version I made in there to help speed up porting. If you want to change the frame skip value just edit it in Options.cs, change the "0" to something between 1 and 9. 0 is full speed and anything above 9 is pretty much pointless.
Hopefully this version is faster, although I still need to optimize the memory and processor code. If you want to see the number of VBlanks the system is getting, use Console.VideoProcessor.FPS, 59 or 60 is ideal.
is this playable on the zune yet or just for computers?
