Jpc - Java Linux & Arm Optimized Dos Emulator

[ldesnogu]

Sorry, I didn't mention this but that's not including the flat overhead you'd have to pay for blitting the screen and other OS stuff. That's not a multiplier and doesn't go away, so naturally it'll limit the number of fps. But I'm pretty confident that a 20-40MHz Athlon64 X2 could play Duke Nukem if it were running it in DOS. In fact, given that it was released in 1991 (and thus probably ran fine on 386's), I think even a 10MHz Athlon64 X2 could possibly do it.

Oh you meant by running it natively?

 

[Exophase]

Sorry, I didn't mention this but that's not including the flat overhead you'd have to pay for blitting the screen and other OS stuff. That's not a multiplier and doesn't go away, so naturally it'll limit the number of fps. But I'm pretty confident that a 20-40MHz Athlon64 X2 could play Duke Nukem if it were running it in DOS. In fact, given that it was released in 1991 (and thus probably ran fine on 386's), I think even a 10MHz Athlon64 X2 could possibly do it.

Oh you meant by running it natively?

.. yes. You thought I meant that such a CPU could emulate it? I see how that could have caused some confusion.

Interestingly, I happened to come across this on Pocketheaven:

"DOSBox is pretty amazing though. I was able to run Duke Nukem I under DOSBox with the dynamic core on an old Pentium 1 100MHz with 1 frameskip pretty smoothly. However, that game was pretty much the exception to the rule (it seemed to be able to run rather smoothly at a meager 400-800KHz)."

So apparently all it takes is a 400-800KHz x86, whatever that means for actual IPC. I'd love to know how they pulled off the graphics like that.

 

[bufalo_1973]

For optimizing Java what you do is optimize the JVM, not tweak the code. Is the same thing GCC does with C++ or any other language.

 

[pupnik]

This thread is made of fail.

What we need is a faster dosbox.

The sound blaster emulation (fmopl) is a serious problem right now. I've gotten confirmation that it trashes the 32kB cache. I would donate to anyone who can optimize dosbox fmopl (or the variants out there) for arm.

(and i hope y'all would too)

Then there's the core speedup possible with dynamic recompilation. Afaict nobody has made progress on this either. Yes i know zodttd is interested but he's a damn busy guy.

So there's basically two things that need work for better dos emulation (gp2x, pandora and other arm devices). Also faster fmopl would help projects that use adlib type sound like freesci and scummvm.

 

[Hitnrun]

This thread is made of fail.

What we need is a faster dosbox.

The sound blaster emulation (fmopl) is a serious problem right now. I've gotten confirmation that it trashes the 32kB cache. I would donate to anyone who can optimize dosbox fmopl (or the variants out there) for arm.

(and i hope y'all would too)

Then there's the core speedup possible with dynamic recompilation. Afaict nobody has made progress on this either. Yes i know zodttd is interested but he's a damn busy guy.

So there's basically two things that need work for better dos emulation (gp2x, pandora and other arm devices). Also faster fmopl would help projects that use adlib type sound like freesci and scummvm.

On the GP2X dosbox ie "nearly there" in performace, I assume on the pandora it should work fine right out of the box.

 

[bnolsen]

It's a brain in neutral, head up backside mode of thinking that produces this sort of crap.

An OO purist will tell you that's the "proper" way of doing things. Perhaps if you're using
Smalltalk or Eiffel it is. In at least C++, it's not. The only time you need to declare accessors
or similar is if you're needing to do special overrides from the normal compiler accesses
of public members or if you need to set/get a protected or private variable (which brings us
to the question, "if you're doing those things, why are they protected/private?"- there's a few
good reasons for doing things that way, but if you're not wanting to strictly regulate accesses
for mutex similar reasons, if you're accessing it all the time, you're better off treating it as
a public and accessing it as if it were a member value instead of calling a method against the
class instance. This is because if you do methods and goofy things like in your examples, you're
producing bloated dispatch code to methods, whereas in many cases, if you do it like I describe
the compiler does very, very simple things and makes much tighter, efficient, and reliable code.

It's the difference between operating off of understanding and operating by rote. Many programmers
really don't understand what they're asking the computer to do when they code up whatever they're
doing.

Ding ding ding, you're one of the few who understands object oriented and c++ coding! Do what's obvious and keep it simple and readable! I for one hate adding extra code to a unit test just to make sure that a private member accessor function works properly. And the biggest bonus with this style is that it tends to keep performance more or less on par with 'c' implementations.

The biggest problem with c++ has been ease of writing compliant compilers for it. Follow that with a lack of smartly designed generally open utility libraries (I hate the iostream library). Java has the uility libraries but there's really not much smart about their design.