CEN64-Qt

[Presence]

I've thrown together a frontend for CEN64 written using Qt. I'm a Linux user, so I can't make use of the .net frontend by Breadwinka. I wanted to make something that was cross-platform and licensed compatibly with CEN64, so I've licensed this under a 3-clause BSD license.

Using the Qt framework allows me to code a single frontend that should work across all platforms.





Github Repo: https://github.com/dh4/cen64-qt
Binary Downloads: https://github.com/dh4/cen64-qt/releases

For Linux, you need to have qt4 installed for it to run. Build instructions are in the Github README if you prefer to go that route.

Let me know any issues you have or anything you'd like to see in it. It's fairly basic right now, and I don't want to add a ton of features yet until CEN64 matures more since a lot will probably change.

[s]Save file support: I've added two options here. You can specify a directory, and it will create a .eeprom and .sram file for each ROM that's launched. It creates an md5 hash of the ROM file to use in the filename so it doesn't accidentally overwrite a file if the filenames are the same for whatever reason. The other option is to specify an eeprom or sram file individually. I'm guessing this is something that CEN64 will handle on it's own eventually.[/s] Save file support is not functional since the new core does not yet support it.

[Devin]

Sweet I was hoping a Linux frontend would show up. Thanks for making this.

[MarathonMan]

Sweet I was hoping a Linux frontend would show up.

Second that thought.

[beannaich]

Could we move all the Front-end/Launcher/GUIs to the same sub-forum?

[MarathonMan]

Could we move all the Front-end/Launcher/GUIs to the same sub-forum?

Done.

[Presence]

I've added a couple more features to this I was wanting to work in:

There's now a simple v64->z64 converter you can use in the file menu.

Also added a status bar. If you've compiled cen64 to flush the output buffer everytime it prints the VI/s, you should get this information there. Otherwise, it will just update everytime the output buffer is flushed.

To flush the output buffer add this after line 141 in video/Controller.c:

Code: Select all

fflush(stdout);

[Presence]

Added one more feature here:

I wanted to make sure this wasn't useless with a debug build, so I've added an "Output to Console" option. When this is checked, it will redirect the output from CEN64 to CEN64-Qt so you can launch CEN64-Qt from the console and see the output from a debug build (or the VI/s from a regular build) just like you would be able to if launching CEN64 directly.

The VI/s won't appear in the status bar when this is checked since the output is redirected.

[mikeryan]

I could compile the application statically, but I believe this means I'd have to license it under the GPL.

Not true. GPL only cares that code that links against it is at least as permissive as GPL, and BSD is much more permissive.

[Presence]

I could compile the application statically, but I believe this means I'd have to license it under the GPL.

Not true. GPL only cares that code that links against it is at least as permissive as GPL, and BSD is much more permissive.

Hmm, I'm not too savvy when it comes to the nuances of each license. Looks like you are right though.

Section 6 of the LGPL license (what Qt is licensed under):

6. As an exception to the Sections above, you may also combine or link a "work that uses the Library" with the Library to produce a work containing portions of the Library, and distribute that work under terms of your choice, provided that the terms permit modification of the work for the customer's own use and reverse engineering for debugging such modifications.

[Snowstorm64]

Great! A front-end for Linux! I'll keep watching this topic.

I didn't still tried it, but... I think this front-end is missing the Good Name column.

[Presence]

Great! A front-end for Linux! I'll keep watching this topic.

I didn't still tried it, but... I think this front-end is missing the Good Name column.

No, it doesn't have good name support, just lists the filename and file size for each ROM it finds.

I've meant for this to be fairly basic until CEN64 matures more, and good name support is something I'm not sure what the best way to implement is. Project64 and Mupen64plus both maintain their own lists as far as I can tell.

[GFD]

It's probably worth mentioning that some ROMs with Good Name filenames won't be saved with the same filename when converting to z64 though. For example, when converting, it tries to save all of these:

Code: Select all

Legend of Zelda, The - Ocarina of Time (U) (V1.0) [!].n64
Legend of Zelda, The - Ocarina of Time (U) (V1.1) [!].n64
Legend of Zelda, The - Ocarina of Time (U) (V1.2) [!].n64

As this:

Code: Select all

Legend of Zelda, The - Ocarina of Time (U) (V1.z64

The problem obviously being it doesn't correctly parse the filename for renaming, stopping at the first period it reaches instead of the last one before the file extension.
Great launcher otherwise though, it's simple and the converter has been handy. Now if only I could actually get CEN64 to run...
Edit: turns out SSE3 and SSSE3 aren't the same thing. A less ridiculous naming scheme could've saved me hours of troubleshooting.

[Presence]

It's probably worth mentioning that some ROMs with Good Name filenames won't be saved with the same filename when converting to z64 though. For example, when converting, it tries to save all of these:

Code: Select all

Legend of Zelda, The - Ocarina of Time (U) (V1.0) [!].n64
Legend of Zelda, The - Ocarina of Time (U) (V1.1) [!].n64
Legend of Zelda, The - Ocarina of Time (U) (V1.2) [!].n64

As this:

Code: Select all

Legend of Zelda, The - Ocarina of Time (U) (V1.z64

The problem obviously being it doesn't correctly parse the filename for renaming, stopping at the first period it reaches instead of the last one before the file extension.

Thanks for finding this. I'll fix it and rebuild the binaries when I have time after Christmas.

[Presence]

Should be fixed now. I've updated the links in the first post with the new downloads.

[Presence]

For anyone paying attention, I've converted this to work with Mupen64Plus as well:
http://www.emutalk.net/threads/54976-Mupen64Plus-Qt

I don't plan on adding a lot to that version, but it was fairly simple to port since this is a fairly basic launcher without a lot of CEN64 specific code at this point.

I've added some of the features I added to that version back to CEN64-Qt and updated the downloads in the first link. It now supports displaying the ROM GoodName from Mupen64Plus' catalog file (for now). If you're using Linux and have Mupen64Plus installed, the file is usually located at /usr/share/mupen64plus/mupen64plus.ini. On Windows, it's in the same directory as the Mupen64Plus executable (win32 download is here: https://code.google.com/p/mupen64plus/downloads/list).

I've also edited some of the configuration value naming, so you'll probably have to reset some of your configuration.

[Presence]

I've added an OSX build to the first post. I haven't built CEN64 on a Mac yet, but the frontend by itself seems to work fine.

[Presence]

I've updated this with support for thegamesdb.net (game information/cover images) and also a grid view and list view in addition to the default table view. I've added images to the first post to show what these look like.

These views are customizable as you can see by the added background image on the Windows preview. These changes are purely cosmetic, but something I've wanted to add. I'll put together some binaries and get those uploaded tomorrow if I have time.

To enable the thegamesdb.net API, go to Configure->Other->Download Game Information. Once this is checked, you'll need to refresh your rom list.

It uses the GoodName to search for matches if you have the catalog file enabled. This worked pretty well on my ROM collection with a couple small hacks. Let me know if there are any obvious ROMs it's not matching.

Otherwise it will use the internal name from the ROM (with a few small string manipulations for better results). This works but not near as well. When I tested on my collection, about 2/3rds of the ROMs were matched correctly. A couple were matched incorrectly and the remaining ones were not found.

I'd appreciate it if some people could test this when I get the binaries uploaded and let me know any bugs you find or usability/other suggestions. I'm sure there's something not working right I overlooked.

[MarathonMan]

It's possible for me to add some kind of mapping to assist frontends. Maybe a CRC -> GoodName entry?

I've been really tied up lately, but I'll try it out when I get the chance. Never built anything Qt before.

[Presence]

Yes, I was assuming something like that would eventually be implemented. How would it be made available?

Adding GoodName support from the Mupen64Plus catalog (this) is just a temporary solution to match up ROM->GoodName so I can implement features that use it.

[MarathonMan]

Yes, I was assuming something like that would eventually be implemented. How would it be made available?

I'm not a frontend developer and don't know what's common/useful/etc., but I'm assuming the easiest way would be to integrate it into the (planned) socket API. For the socket API, I want to eventually get to the point where CEN64 creates a library that frontends could link against to provide functions like:

Code: Select all

const char *get_rom_goodname(int socket_fd, const char *rompath).

Passing everything through the command line will continue to get increasingly clumsy as debugging support and other features are added.

[Trivial Man]

I don't know a lot about the programming side of emulators, but I see some talk about implementing a feature that can identify roms by their GoodTools name. As someone who doesn't care so much for those auditing tools, I'd like to request an alternate No-Intro name field as well as the ability to possibly enter a custom name or description for roms and sort by that.

Whether you prefer No-Intro or GoodTools is largely a matter of taste, but I believe that No-Intro's database is now large and popular enough that many users would appreciate including it. I personally think it is both more correct in it's identification and more accurate in it translations and labeling, not to mention that it isn't flooded with similarly named hacks or known bad dumps that I don't care about. The custom names field would be useful for the few hacks that I have that are either newer versions of the hacks identified by GoodTools or simply were overlooked by Cowering.

A hierarchy of display names could be a useful feature too. For example, if a game has a custom name display that first, if not then GoodTools name, and if not that the No-Intro name, or however the user sets this up. This would be significantly farther down the development cycle though I'm sure and warrants no serious discussion on its merits or method of implementation yet.

[MarathonMan]

In that event, it's possible to just provide two API calls:

Code: Select all

const char *get_goodtools_name(int socket_fd, const char *rom_path);
const char *get_nointro_name(int socket_fd, const char *rom_path);

[Snowstorm64]

But isn't it better to identify commercial ROMs by MD5/SHA1 checksum? It could avoid all problems on the filename.

[MarathonMan]

I was going to use some sort of CRC/hash; the rom_path is just so the backend can open the file to access the ROM data.

[Presence]

I don't know a lot about the programming side of emulators, but I see some talk about implementing a feature that can identify roms by their GoodTools name. As someone who doesn't care so much for those auditing tools, I'd like to request an alternate No-Intro name field as well as the ability to possibly enter a custom name or description for roms and sort by that.

Whether you prefer No-Intro or GoodTools is largely a matter of taste, but I believe that No-Intro's database is now large and popular enough that many users would appreciate including it. I personally think it is both more correct in it's identification and more accurate in it translations and labeling, not to mention that it isn't flooded with similarly named hacks or known bad dumps that I don't care about. The custom names field would be useful for the few hacks that I have that are either newer versions of the hacks identified by GoodTools or simply were overlooked by Cowering.

A hierarchy of display names could be a useful feature too. For example, if a game has a custom name display that first, if not then GoodTools name, and if not that the No-Intro name, or however the user sets this up. This would be significantly farther down the development cycle though I'm sure and warrants no serious discussion on its merits or method of implementation yet.

This will ultimately depend on what Marathon Man implements in CEN64 to identify ROMs. If a database of ROMs->No-Intro names is added, I'll add support for that to the frontend.

I'll see about adding a hierachy field at some point that queries the Game Title (from thegamesdb.net), the GoodName, and Filename, etc. in a certain order to make sure information is shown. As for adding custom names, you could just use the Filename field and enter your own custom name there.

I've added support for .zip files to this. It will check all zip files in your ROM directory (and supports multiple ROMs per zip file). You can also open zip files directly. If it only finds one ROM inside, it will open that, otherwise it will provide a list to choose from.

This also now caches information about the users ROM collection in an sqlite database instead of throwing it in the config file (much cleaner).

[Snowstorm64]

Code: Select all

./cen64-qt: error while loading shared libraries: libquazip.so.0: cannot open shared object file: No such file or directory

Unfortunately libquazip0 seems don't exist anymore in Debian's repositories. Can you make this frontend to use libquazip1 instead of the old one?

[Presence]

Code: Select all

./cen64-qt: error while loading shared libraries: libquazip.so.0: cannot open shared object file: No such file or directory

Unfortunately libquazip0 seems don't exist anymore in Debian's repositories. Can you make this frontend to use libquazip1 instead of the old one?

I built that on Ubuntu 14.04 since I figured that would be the most used Linux platform. 14.04 still has libquazip0. All I've done to build that is what I have in the Github README: `qmake && make` (assuming you have everything installed thats needed). It should link to libquazip1 fine. Let me know if you have any issues.

[Snowstorm64]

That's right, now I have recompiled cen64-qt and it's working again.

[Presence]

That's right, now I have recompiled cen64-qt and it's working again.

Awesome

[MarathonMan]

I built that on Ubuntu 14.04 since I figured that would be the most used Linux platform.

Is it possible to do static builds with Qt? Was looking into it for CEN64 to get around this issue myself.

[Presence]

Yes, very possible. Both the Windows and OSX binaries there are statically linked. I've left the Linux version dynamically linked since that's the way the vast majority of Linux applications are distributed (and it cuts down quite a bit on the application size).

The way to get around issues like that would just be to distribute several different versions for the most popular distributions. Or if it gets popular enough to be included in the repositories, the distributions would handle that themselves.

[Presence]

I've added support for specifying the N64DD IPL ROM file to this. Once you've added the path under Configure->Paths, check "Enable N64DD" under emulation to enable it.

I've also added an "Additional Parameters" field under Configure->Other. This allows you to specify what other parameters to send to CEN64. Should be useful for testing out any new features that are released in CEN64 that I haven't gotten around to adding to the frontend yet.

Also the Linux builds are now built with libquazip1 since Ubuntu 14.10 ships with it. If you're on 14.04 or another distribution that uses libquazip0, you'll have to compile using the instructions on the Github readme.

[Snowstorm64]

Thank you, this is a great update, especially 64DD and the "Additional Parameters" field. The last one is really useful.

[MarathonMan]

So, the introduction of 64DD support presents some issues with regards to the command line argument convention. My top priority with any change in command line usage is to NOT break the convention currently in place. If a command line launches CEN64 with some ROM or setup now, it should work after any change as well.

Keeping that in mind, the following scenarios are all possible now that 64DD is a thing:

• Cart only (i.e,. no 64DD support)
• Cart + 64DD disk (i.e., F-Zero Expansion)
• 64DD disk only (i.e., Super Mario 64 Disk Edition)
• No cart or 64DD disk (i.e,. 64DD IPL ROM)

Given the current convention:
cen64 [params] pifrom cart

I plan on changing it to:
cen64 [params] pifrom [cart]

where params include both (-ddipl and -ddrom).

Any input on this? For the scenarios above, here's what the invocations would be:

• Cart only -> cen64 pifrom cart
• Cart + 64DD disk -> cen64 -ddipl path -ddrom path pifrom cart
• 64DD disk only -> cen64 -ddipl path -ddrom path pifrom
• No cart or 64DD disk -> cen64 -ddipl path pifrom

EDIT: Actually, we might need even more than -ddrom as LuigiBlood's proposed format calls for two different files for each 64DD ROM (since the magnetic media consists of both volatile and non-volatile sections).

[Snowstorm64]

Does it have necessarily the parameters after cen64? I'd do a thing like this:
(since the PIF ROM is mandatory)

cen64 pifrom [params]

Where [params] may have these:
-rom -> It loads the regular ROM cart
-ddipl -> It loads the IPL ROM
-ddrom -> It loads the 64DD disk image
-ddram -> It loads (if any, otherwise it will be created) the RAM area of the 64DD game

Cart only: cen64 pifrom -rom cart.z64
64DD only: cen64 pifrom -ddipl iplrom.bin -ddrom 64ddgame.ndd
Cart + 64DD disk: cen64 pifrom -rom cart.z64 -ddipl iplrom.bin -ddrom 64ddgame.ndd
64DD, but no disk inserted: cen64 pifrom -ddipl iplrom.bin

And if we want to load the RAM area, just add the -ddram option at the end.

We could also not use -rom parameter:
cen64 pifrom [cart] [params]

IMHO it's much clearer this way.

[LuigiBlood]

EDIT: Actually, we might need even more than -ddrom as LuigiBlood's proposed format calls for two different files for each 64DD ROM (since the magnetic media consists of both volatile and non-volatile sections).

I mostly thought of it as <dump>.ndd, and automatically searches for <dump>.sdd based on the filename. But for now it's not needed, we need to emulate disk reading first. To me, -ddrom is just enough. We'll update when needed.

[MarathonMan]

EDIT: Actually, we might need even more than -ddrom as LuigiBlood's proposed format calls for two different files for each 64DD ROM (since the magnetic media consists of both volatile and non-volatile sections).

I mostly thought of it as <dump>.ndd, and automatically searches for <dump>.sdd based on the filename. But for now it's not needed, we need to emulate disk reading first. To me, -ddrom is just enough. We'll update when needed.

Agreed. Moved forward with -ddrom and making the cart an optional argument. This shouldn't impact the frontend's ability to boot things.

[Presence]

Wouldn't worry too much about breaking the current command line convention at this point in CEN64's development. Rearranging the order of the arguments in the frontend is trivial. More important would be creating a convention that is logical and easy to use.

As for launching 64DD games, I'll get around to implementing something for this when I have some time. My current idea would be to have another frame pop up below the current ROM list when "Enable 64DD" is checked. This frame will list out the 64DD ROMs within a user's collection and allow them to select both a regular ROM and 64DD ROM at the same time (also add an option for no cart to be attached for launching 64DD games by themselves).

Here's a (very rough) draft:


If someone has any other ideas, let me know.

[Presence]

Had some time to work on this yesterday and this morning. I've added another panel that appears when "Enable 64DD" is checked. It will search for .ndd files in your ROM collection to add to this panel. You can select both a regular ROM and 64DD ROM at the same time, then double click on either one or select Emulation->Start to start both of them together. The 64DD panel just lists the filename currently, as there's no GoodName information or thegamesdb.net information to import for these games.

Also added the ability to specify multiple directories to look for ROMs. This release changed the database structure, so it will delete your ROM collection and refresh it on the first launch.

I had to tweak several things to add support for launching 64DD games, so I'm sure there are a few bugs. I've already caught and fixed a couple, but I'd appreciate it if anyone poked around to see if they can find any bugs as well.

[ShadowFX]

So now that CEN64 is advancing quite well, I was tempted to work on improving the existing CEN64 logo and theme:


As for CEN64-Qt (mockup!):


Avatar:

[Narann]

Very nice logo! I would let marathonman the privilege of having the avatar for himself!

[Net_Bastard]

Eh, I feel like the logo is a bit over-designed (remember, it's a system icon and therefore has to look uncluttered when shrunken down) but I'm a fan of minimalism so I'm a bit biased.

[Snowstorm64]

Eh, I feel like the logo is a bit over-designed (remember, it's a system icon and therefore has to look uncluttered when shrunken down) but I'm a fan of minimalism so I'm a bit biased.

I partly agree with this affirmation, just one thing: A system icon should be square-shaped and not a rectangle. The new logo is fine if it's on a website, but not in the frontend, IMHO.

[MarathonMan]

I admittedly wasn't a fan of it at first, but it's meant to mimic the original console forum design.

tl;dr: It looks nice with fresh bit of paint that's on its way.

[ShadowFX]

New release of this very nice frontend! (20150915-alpha)

Get it here: https://github.com/dh4/cen64-qt/releases

[Presence]

There's not much new in that release, but there are a few small changes, so I figured it was time to make one.

More interesting probably: I've set this up with Travis CI to create builds of each git commit. You can download the latest build from the links in the Github README. Will make it much easier to test new features.

[ShadowFX]

More interesting probably: I've set this up with Travis CI to create builds of each git commit. You can download the latest build from the links in the Github README. Will make it much easier to test new features.

I will be trying out the newer automated builds for sure.
Do you also take bug reports, requests or suggestions of some sort?

[Presence]

Yes, the issues page on Github is the best place. I also pay attention to anything posted here.

[tony971]

http://forums.cen64.com/viewtopic.php?f ... 2270#p2270