cooliscool
Nintendo Zealot
heh, it would be great for a new ultrahle to be compiled, especially for those of us with lower end PCs. hope you guys do it,
Best Regards,
Me
Best Regards,
Me
UltraHLE 2002 Reborn?
- Thread starter aprentice
- Start date
I have a comment on the "Open source is better" reply.
My product, GuildFTPd, an FTP server for windows, is a closed source application. That has not stopped it from becoming the best FTP server available on Tucows.com, Download.com, and many other sites. Sure, there are bugs, but I say that the original programmer knows his code best, and can fix the problems faster, than any other person could. (Given the education) Sure, SOME open source applications do get more features added faster, but that does not make them problem proof.... it just helps to make the program progress faster.
I say that some programs should be open source, and some should not. I say that Windows should not be open source, because that would just make things run slower. Take Linux for example. I have Windows XP installed on a Pentium II 266, with 64 Megs of ram. It runs like a top, YET, Redhat, mandrake, and a couple of other distro's for Linux run like crap. They take over 2 minutes to start up, and they run slow. Sure, they may be stable, but they are slow; not only that, but my 850 AMD Athlon processor, with 256 Megs of rammed CAN “T EVEN RUN Linux... it crashes at random when trying to start up. I had to get another PC to learn Linux, because every time I tried to start it up, it would crash on my main PC. I'm not saying that Linux is like this on everyone's PC, I'm just saying it is like that on mine, and that Windows has never given me a problem installing, ever.
So maybe that’s why I don't like open source, but everyone is up to their own opinion.
-Nitro
http://www.nitrolic.com
My product, GuildFTPd, an FTP server for windows, is a closed source application. That has not stopped it from becoming the best FTP server available on Tucows.com, Download.com, and many other sites. Sure, there are bugs, but I say that the original programmer knows his code best, and can fix the problems faster, than any other person could. (Given the education) Sure, SOME open source applications do get more features added faster, but that does not make them problem proof.... it just helps to make the program progress faster.
I say that some programs should be open source, and some should not. I say that Windows should not be open source, because that would just make things run slower. Take Linux for example. I have Windows XP installed on a Pentium II 266, with 64 Megs of ram. It runs like a top, YET, Redhat, mandrake, and a couple of other distro's for Linux run like crap. They take over 2 minutes to start up, and they run slow. Sure, they may be stable, but they are slow; not only that, but my 850 AMD Athlon processor, with 256 Megs of rammed CAN “T EVEN RUN Linux... it crashes at random when trying to start up. I had to get another PC to learn Linux, because every time I tried to start it up, it would crash on my main PC. I'm not saying that Linux is like this on everyone's PC, I'm just saying it is like that on mine, and that Windows has never given me a problem installing, ever.
So maybe that’s why I don't like open source, but everyone is up to their own opinion.
-Nitro
http://www.nitrolic.com
zero0w
Maverick Hunter
Nitro187 said:
Windows is easy to install, agree; while installing Linux can be a bit tricky. Yet my experience with Linux has been generally positive (well I did try to install Mandrake a few times to get the best setting I wanted to, and btw AMD 850 Mhz with 256MB Memory should be able to run Linux fine even with the resource hungry KDE Desktop environment....), so might be there's a better distribution which can fit your system.
Also, I use the distribution CDs come with a magazine, probably downloading 700MB ISOs can inherit some sort of data transfer error for such a large chunk of data.... I don't know, but it's possible.
Last edited:
Moonlight
New member
Don't you mean "Do UHLE support NATIVE saves?"
Converting saved states from one emulator implementation to another would be anywhere from difficult to impossible if they're in any significant way different.
Saved states contain memory dumps plus chip registers which are common to all emulators of a given console and implementation-specific details which can be totally different from one emulator to another.
On the other hand, native states are just dump of what the game writes to the save device so these would most likely not require more than simple file format conversion. (change headers, byte alignments or other minor stuff)
... unfortunately, I don't remember UHLE doing native saves. Maybe someone will hack native saves into UHLE so people may convert their saved states to native saves and load those elsewhere.
Converting saved states from one emulator implementation to another would be anywhere from difficult to impossible if they're in any significant way different.
Saved states contain memory dumps plus chip registers which are common to all emulators of a given console and implementation-specific details which can be totally different from one emulator to another.
On the other hand, native states are just dump of what the game writes to the save device so these would most likely not require more than simple file format conversion. (change headers, byte alignments or other minor stuff)
... unfortunately, I don't remember UHLE doing native saves. Maybe someone will hack native saves into UHLE so people may convert their saved states to native saves and load those elsewhere.
Moonlight
New member
Most of the time, wether or not an emulator supports saved states isn't even a question since it's the first save method that can be implemented (dump everything into a file) and can be quite useful in investigating bugs.
For those still using UHLE and with lots of saved states, being able to reload and do native-states would be nice. This would have to be done before doing any changes to the core (adding flags, changing data structures, etc.) to maintain compatibility with the old states.
It's funny to think that a debugging feature is one of the things that make emulators so much more convenient than the real thing.
For those still using UHLE and with lots of saved states, being able to reload and do native-states would be nice. This would have to be done before doing any changes to the core (adding flags, changing data structures, etc.) to maintain compatibility with the old states.
It's funny to think that a debugging feature is one of the things that make emulators so much more convenient than the real thing.