PVB Collaborative Emulator

Thanks for your feedback, everyone. I feel like I’m getting a pretty good picture of what people want to do and what everyone’s expectations are. Very helpful for planning purposes!

HorvatM wrote:
Haven’t we had this conversation already?

Pretty close, yeah. (-: But the difference this time is that I’m actually prioritizing this in my life because I feel I owe it to the PVB community to give back in a big way.

ElmerPCFX wrote:
[… I]f you just want a “better” emulator than what’s available, have you considered not throwing away the years of work that other people have done, and to actually save yourself a lot of time and build upon one of the existing emulators and improve it?

I do appreciate your insights, since if things were as quoted, the lion’s share of the work could be sidestepped. However, it’s not having an emulator that I’m after with this activity; it’s making one.

One of my desires is to help lift the veil on the internet that enshrouds emulation in an air of mysticism. An emulator isn’t some arcane box of hocus-pocus: it’s a rigidly-defined set of rules that get from point A to point B. I want people from all over the industry to be able to look at Planet Virtual Boy and, in doing so, learn a lot about how emulation works and maybe take the system a little more seriously in the process. (-:

Alongside development of the emulator for its own sake–which was the focus of the previous thread–I will be writing up articles about how different parts of the emulator operate. My hope is that someone who is interested in their own emulator endeavors can find these articles helpful.

blitter wrote:
The VB community is *tiny*– I don’t think I can stress this enough– […] A Virtual Boy-exclusive emulator such as this one only serves to isolate us from possible contributions.

I wouldn’t worry about that too much since the project isn’t trying to attract a lot of people to work on it. At minimum, I’ll still have my little monthly goals–I promise–so it will be completed eventually. Should someone choose another project to contribute to instead of this one, that’s perfectly fine. This one has its own ambitions.

If nothing else, working on an in-house emulator is better than sitting around scratching our heads waiting for the next reproduction to be sent out.

blitter wrote:
C has no advantage over C++ performance-wise, and vice versa. C++ is a superset of C, meaning that you can use some or none of the extra features provided by the language, with no penalty in the latter case.

You’re correct, and I will consider C++ for this project. Even if C is specifically desired for whatever portion of the code base, they can still be used verbatim in a C++ project. The ease-of-use benefits of C++ may be conductive to better collaborative support.

I’ll need to research it a bit. I’m a big proponent of the “don’t allocate for every individual object” camp, and I have a feeling C++’s “new” keyword falls into that category upon object instantiation. I’ll get with a colleague of mine who deals more in such things and see what insights he can offer.

That was an especially interesting speech. Thank you for sharing it. I’m tickled to death by the notion that Nintendo downloaded Super Mario Bros. from the internet and then sold it.

Saying that, it’s not what I had in mind. I’m more interested in shedding light on how emulator’s work internally.
__________

After some discussion with my associate, I’ve decided to stick with C over C++ for two prominent reasons:

1) Some of the features of C++ necessarily have more demanding runtime requirements to compensate. I mentioned the “new” keyword, which was confirmed to allocate a small block of memory every time an object is created. But it was also brought up that trapping exceptions–one of the most powerful features C++ offers over C–has a host of overhead making it work. The runtime library required to use a C++ program has a larger memory footprint than the C runtime. While the difference in performance is negligible, there’s still a relevant impact when using C++ instead of C.

2) It’s imperative that the project is portable–especially the emulation core. While it’s true that C code can be used in a C++ project, that’s not necessarily true if you flip it around. Even in the case of the user interface, I’d really rather design it in such a way that if someone wanted to use parts of it in some other project, they’d be able to. This point more than the previous one is what’s pulling me to the C side of things. No amount of C++ trickery is going to make the emulation core work in a C environment, performance notwithstanding.

blitter wrote:

Absolutely false. (Seriously, this is the first Google result returned for “c wrapper for c++ library”– did you do any research yourself or are you blindly going by what your “associate” says?)

I understand that you have an emotional investment in using C++ (or, as the case may be, in not using C), but I remind you to think carefully before accusing someone of making unsubstantiated claims. I don’t want a constructive debate to devolve into name calling and hearsay.

The article you linked details a technique for implementing a C interface to a C++ library. I would posit that a superior approach would be to export to a DLL or something similar so that virtually any target language could load in the compiled library code at runtime. Heck, I was doing OpenGL in Visual Basic this way for years before switching to C. (-: From a literal standpoint, I will concede that this is a manner by which you can use C++ code in a C project.

That being said, as the article points out, this is not necessarily an elegant transition: every access to a C++ class’s fields or methods has to have a dedicated function for C to use. We’re left with a situation where we’re weighing a matter of convenience. Do we use C, where the source files can be used directly in a C++ project; or do we use C++, where a C interface will need to be maintained in order to use the code in a C project?

And what about porting to other languages? Many languages have classes, some have exceptions, and a few have operator overloading (the popular Java, incidentally, does not). If we leverage the powerful features that C++ brings to the party, what impact will that have on portability? It hardly needs to be said that C code will generally port with minimal modifications.

Like I said in my previous post, the main thing drawing me to C over C++ is portability. C can get tricky with indirection, but beyond that I believe a very strong case can be made that C is far more accommodating than C++ in this regard, and I consider that a significant factor in choosing which language to use.

blitter wrote:

[…] arbitrary restrictions […] preconceived notions […] less performant, top-heavy, memory-intensive […] without confirming it […] at best silly and at worst irresponsible […] recoup that .00001% […] speed or space issues […] time wasted over a mostly futile effort.

My priorities are portability and constructive discourse.

If anyone else feels that I’m being unreasonable, please say so in a reply to this thread or to me directly via PM. It’s not my intention to be stubborn or narrow-minded, and if additional feedback can put this project in a better direction, then I’d say only good can come of it.

blitter wrote:

Is it worth shooing away good C++ coders so you can recoup that .00001%?

I don’t believe that this is an actual issue: a good C++ programmer should be able to make heads or tails of a C program (and vice-versa).

Of course, there’s also the fact that C is trending nearly double what C++ is on the internet right now. If I were concerned with alienating programmers, I’d be more hesitant to decide on C++ for fear of driving away potential C developers.

Many thanks to those who have pitched in ideas so far. I’ve got a good idea of where to start and how to proceed, which is what I set out to do so hooray. (-:

I started this write-up before Gookanheimer came about, and I haven’t had a chance to discuss things with him yet, so I’ll just say this: until such a time that others are interested in working on the project with me, I’ll be working independently. As such, I will not be setting up a git repository at this time (just as well, since I’m no expert at git), and will be posting ZIP files from time to time containing the current progress and binaries for the project.

So hey, let’s get started.
__________

License

I’m in prime position to piss off a fair number of people by doing this, but I’m going to make another executive decision: no traces of GPL in any way, shape or form, at all, ever. I’m all for keeping open software open, but there are certain ways to take that ideology too far, and GPL’s requirement to make the source of your entire project available on request just because you used that one library is one of them. I will not reconsider my position on this matter.

This project will be released under the terms of the zlib license. This means anyone can use any part of the emulator code for any purpose–commercial or non-commercial–with or without making the source code to their software available. Heck, Nintendo themselves would be within their rights to use the Planet Virtual Boy emulator in Virtual Console releases and never tell anyone where they got it. (-:

GUI Stuff

Before getting into the emulation side of things, let’s take a moment to talk about GUI. The project will need to work with the native windowing systems of the target platforms, and in the interest of maintainability, a solution should be selected that minimizes the amount of code that will differ by platform.

And before getting into that, what are the target platforms? I specifically want to support Linux, Microsoft Windows and Apple OS X as operating systems. Exactly how far back to support kinda hinges on the dependencies of the GUI library, but it’d be cool to support as far back as Windows 95 and OS X Tiger. Even though usage share is trending for 64-bit OSes, 32-bit releases of the emulator are still important since some people still use them and they’re not really that big a deal to build for.

With that out of the way, the GUI solution should ideally support basic window management across all three target OSes, but without hogging resources or introducing some staggering runtime footprint.

The GUI library I want to go with is Simple DirectMedia Layer: it’s free, fairly minimal, supports many architectures and is supported by many game development platforms. It’s missing a few things like directory listing and exposing the POSIX sockets API, but anything that’s missing can be implemented without too much of a hassle. And hey, maybe we can improve SDL while we’re at it, right?

SDL is so minimal, in fact, that it doesn’t actually provide a GUI library out-of-the-box. What it does is gives you a system window into which you can draw pictures (and receive input, etc.). It has a built-in API for 2D accelerated graphics, but I think we should cut out the middle-man and use OpenGL directly. Let me explain… although SDL is supported on many platforms, and OpenGL on even more, there’s never going to be The One GUI Solution™ that works absolutely everywhere. By using OpenGL instead of SDL’s 2D library, that’s one part of the program that gets to be that much more portable as a result.

An additional complication is which OpenGL features to use. I’m leaning towards 1.1 since it’s supported on the oldest versions of Windows (and in software-rendered situations like virtual RDP), and I myself have some tablets and netbooks that don’t support shaders (and I really like programming with shaders). When it’s all said and done, OpenGL 1.1 seems to be the least common multiple and should hypothetically cast the broadest net for the user base of the emulator application.

As for GUI controls themselves, well… I’d really rather just implement those myself. Sure, it’s reinventing the wheel, but the application only needs some simple buttons and scroll bars and stuff. I really don’t feel like kissing frogs trying to find the right GUI library that works with our license and bloating the code base with controls we don’t need.

So that’s what I have in mind. If you know a better way, say so now, before something gets set in stone. (-:

Portability

Portability is paramount, especially for the emulation core. If the core library is to be useful in as many applications as possible, then it has to be written in such a way as to minimize the requirements of the application trying to use it.

This section applies mainly to the emulation core, so don’t get discouraged. The following are some considerations to increase portability of this central library:

• Common compilers. A language should be chosen to maximize the likelihood someone will be able to compile the emulation core on their target system. This is a bit of a sticky subject, since using old programming languages can be seen as failure to get with the times. But at least one PVB member has expressed interest in getting it to run on DOS, so it’s worth consideration. Much to everyone’s dismay, I want to support stock C89, even so far as to require /* style comments. If it won’t compile in gcc with [font=Courier New]-std=c89 -pedantic[/font], then maybe it shouldn’t be used. I’m open to suggestions if an argument can be made for using newer C features.

• No C runtime. Not every system using the emulation core will necessarily have a C runtime to draw from. This means any standard library functions that would otherwise be used by the core (such as math, string or memory allocation functions) will need to be implemented in C code to avoid the C runtime requirement.

• Architecture-independent implementation. Certain CPU architectures process the same instructions differently, even if the C code itself is unchanged. There are two key ways this can occur in my experience: endianness and alignment. No assumptions can be made regarding the order of bytes within data types, and unaligned memory accesses need to be avoided. Has anyone else dealt with any other architecture-specific gotchas we might need to watch out for?

Again, these considerations are primarily for the emulation core library. The GUI application with the debugger and stuff won’t be held to such strict rules.

Conventions

I started writing up coding conventions, then I remembered I would probably be working independently. Basically how this is going to go down is that I’ll establish a coding convention, then if anyone contributes to the code base, consistency should be maintained. (-:

I spent the last week considering the best way to handle GUI stuff, and settled on a disappointing conclusion: it will be most appropriate to treat SDL as the target plaform, rather than try to make everything platform-independent.

When considering how to implement GUI things in a platform-independent way, the solution I kept coming back to was basically “write a generic API that wraps around SDL for one implementation and whatever else for other implementations.” Since SDL is already doing that with native windows and I/O, it just adds another layer of abstraction where there doesn’t really need to be one. If some port of the emulator application needs to implement its internal API regardless, it may as well implement a stand-in for the SDL functionality directly.

In other, more exciting news, I’ve decided to add [font=Courier New]armhf[/font] and [font=Courier New]arm64[/font] to the list of supported architectures for Linux. This benefits the general mobile market, but has particular significance for single-board development. Raspberry Pi in particular has a community with a strong emphasis on video game emulation.
__________

EDIT:

Oh yeah, forgot to mention… As part of the initiative to treat SDL as the target platform, I’ve also opted to forego OpenGL directly and use the SDL 2D rendering API instead. This was an easy decision because there’s about one finity ways to implement something, and even if my OpenGL code works one place, it may not be suitable in another. May as well code up the GUI renderer in such a way that it’s best-suited for the platform at hand, and that would be through letting SDL decide how to best carry out its drawing instructions.

A 3DS version of this emulator will probably just wind up using the emulation core library and implementing its own GUI from scratch…

• This reply was modified 8 years, 3 months ago by Guy Perfect.