[GerbilSoft]

I've noticed that there seem to be some unfixable issues in the Gens/GS codebase. Most notably, these issues include random slowdown on various machines.

So, in order to fix these issues, I'm going to attempt to do a partial rewrite, tentatively titled Gens/GS II.

Main features of the rewrite:
- Separated emulation code from UI code. (libgens / gens-qt4)
- Qt4 UI for all major platforms.
- CMake-based build system.
- SDL video, audio, and input handling for all platforms. (no more separate DirectX code on Windows)
- Multithreaded emulation code. (Emulation runs in one thread; UI runs in another.)
- I will probably use pipes for inter-thread communication. Either that or SDL events, but SDL events are one-way. (That is, UI to SDL.)

I haven't started the rewrite yet, but I plan to start working on it sometime this week.

This post has been edited by GerbilSoft: 18 April 2010 - 11:50 PM

[Mad Echidna]

I like the multithreading idea a lot. That was one of the big things on BeOS back in the day was the strong thread support. Some apps used dozens, even the simpler apps.

[Overlord]

Multithreading would be great, yeah - computers with multiple CPU cores are only going to increase from here on out. One hopes this doesn't end up comparing to Gens/GS how SHWP II compared to SHWP. ;P

[GerbilSoft]

Multithreading would be great, yeah - computers with multiple CPU cores are only going to increase from here on out. One hopes this doesn't end up comparing to Gens/GS how SHWP II compared to SHWP. ;P

lol no.

Jeopardy! System, which I mentioned previously on #retro, uses multithreading for various things, including audio and Wii Remote handling. On JS, audio isn't synchronized with video at all, since it isn't necessary. For Gens/GS II, it will be necessary, so I'll have to do that differently.

In other news: http://gs_server.gerbilsoft.ddns.info/cgi-...I.git;a=summary - I managed to get starscream and mdZ80 to build correctly using CMake. Starscream, in particular, is annoying because it's a C program that generates assembly, which is then assembled using NASM. NASM also isn't directly supported by CMake, but someone posted NASM modules for CMake on the CMake bug tracker, so I used that.

The next step will be writing the main libgens code, which will include porting the emulation code from Gens/GS and adding the SDL loop. I also have to add two thread-safe queues for communication between Gens/GS and the UI. (The initial UI for the first preview release will probably be command-line only.)

[Mad Echidna]

Multithreading would be great, yeah - computers with multiple CPU cores are only going to increase from here on out. One hopes this doesn't end up comparing to Gens/GS how SHWP II compared to SHWP. ;P

lol no.

Jeopardy! System, which I mentioned previously on #retro, uses multithreading for various things, including audio and Wii Remote handling. On JS, audio isn't synchronized with video at all, since it isn't necessary. For Gens/GS II, it will be necessary, so I'll have to do that differently.

In other news: http://gs_server.gerbilsoft.ddns.info/cgi-...I.git;a=summary - I managed to get starscream and mdZ80 to build correctly using CMake. Starscream, in particular, is annoying because it's a C program that generates assembly, which is then assembled using NASM. NASM also isn't directly supported by CMake, but someone posted NASM modules for CMake on the CMake bug tracker, so I used that.

The next step will be writing the main libgens code, which will include porting the emulation code from Gens/GS and adding the SDL loop. I also have to add two thread-safe queues for communication between Gens/GS and the UI. (The initial UI for the first preview release will probably be command-line only.)

Good stuff Gerb, I look forward to hearing more about this.

[Xaklse]

Don't know shit about emulators code and what are exactly your needs, but did you consider using SFML 1.6 instead of SDL? Seems to me some features would be really useful for you.

[GerbilSoft]

Don't know shit about emulators code and what are exactly your needs, but did you consider using SFML 1.6 instead of SDL? Seems to me some features would be really useful for you.

SFML actually does look kinda interesting, so I might consider it. Ubuntu has SFML, but it seems to be an old version (1.5 in Ubuntu 10.04), so I guess I might include a statically-linked copy if I decide to use it.

EDIT: It seems that the current version of SFML has some joystick limitations. (Specifically, it only supports two joysticks.) It also looks harder to integrate with the Qt4 UI unless I use Qt code in libgens, which I don't want to do. So I guess I'll stick with SDL for now. (I can always port everything to SFML later on if the need arises.)

EDIT 2: I can't seem to find a source code download for SFML that isn't SVN. All I see are "SDK" downloads, so I'm guessing SFML was primarily developed for Windows systems, and Linux support was added as an afterthought.

This post has been edited by GerbilSoft: 20 April 2010 - 12:14 PM

[Xaklse]

EDIT 2: I can't seem to find a source code download for SFML that isn't SVN. All I see are "SDK" downloads, so I'm guessing SFML was primarily developed for Windows systems, and Linux support was added as an afterthought.

(?) The full SDK has the source codes; well, I guess so because when I downloaded the 1.5 SDK it had the sources.

Also, keep in mind that SFML is flexible, I mean you can choose one of the small packages like for instance the System one for threads.

[GerbilSoft]

I now have an initial Qt4-based UI. I'm currently using the QX11EmbedWidget for embedding SDL, since other widgets had issues with BadWindow errors, but I'll get it working with a standard widget for other platforms.

In the meantime, Gens/GS II is currently only buildable on Linux. Source code is available at http://gs_server.gerbilsoft.ddns.info/cgi-...I.git;a=summary .

[Andlabs]

I'm just going to say that if this is going to be a raw rewrite then then 32X emulation code in the old Gens is a joke and we both agreed it needs to be replaced. I'll start writing a new one once Gens/GS II can do MD emulation. I have been thinking ahead and I don't think the G BIOS would be needed unless it does something that I don't know about, but that's just what I can tell. After all, we already have everything set up on the emulator side =P

This post has been edited by Andlabs: 02 May 2010 - 03:10 PM

[sonicblur]

Main features of the rewrite:
- Separated emulation code from UI code. (libgens / gens-qt4)

With these changes, will it be possible to easily compile Gens without a UI?
It sounds like it, but I just wanted to confirm. (Since your current repository has SDL and Win32 stuff still mixed in with libgens)

This post has been edited by sonicblur: 02 May 2010 - 05:15 PM

[Mad Echidna]

Hey Gerbilsoft, how seriously do you take the Haiku port? If it reaches your quality standards will it be an "official" port at some point? How do you view this?

[GerbilSoft]

With these changes, will it be possible to easily compile Gens without a UI?
It sounds like it, but I just wanted to confirm. (Since your current repository has SDL and Win32 stuff still mixed in with libgens)

It would still need a "UI", but that UI could easily be a command line interface.

Hey Gerbilsoft, how seriously do you take the Haiku port? If it reaches your quality standards will it be an "official" port at some point? How do you view this?

Considering that very few people use Haiku, I don't know. The initial Haiku port will be Qt4, but a Haiku-native UI could be written later on.

[Mad Echidna]

Hey Gerbilsoft, how seriously do you take the Haiku port? If it reaches your quality standards will it be an "official" port at some point? How do you view this?

Considering that very few people use Haiku, I don't know. The initial Haiku port will be Qt4, but a Haiku-native UI could be written later on.

That's true, very few people do use Haiku, an OS that's still in alpha

:P

[Conan Kudo]

Hey Gerbilsoft, how seriously do you take the Haiku port? If it reaches your quality standards will it be an "official" port at some point? How do you view this?

Considering that very few people use Haiku, I don't know. The initial Haiku port will be Qt4, but a Haiku-native UI could be written later on.

That's true, very few people do use Haiku, an OS that's still in alpha

:P

I'm surprised nobody's brought up AROS yet...

Also, I thought Starscream was supposed to be replaced, since it isn't GPL compatible?

I'm no expert on m68k, but I found some GPLv2+ code that emulated an m68k CPU. I don't know how good it is or whatever, but here it is.

This post has been edited by King InuYasha: 04 May 2010 - 02:17 AM