Game Boy

[Lordus]

/*
* jmboy.java
*
* Created on 17. August 2005, 20:04

...do the math.
It was my first emu project, but i know 'a bit' of low level hardware programming /design and assembler, which is quite helpful
And last year i did a bit of research already, because i made an OpenGL KartRacer, that took the tile and sprite data from a MarioKart rom. It actually looked quite cool, just that the whole thing was lost due to a hd crash in december...

 

[weston]

erm, I don't think cyberman has seen what java can do since 1997 or so... if you want to see what the java community is doing with games nowadays, check this out: http://www.iotd.kaioa.com/ 5x faster with C/C++ is ridiculous...

I also just finished a chip8 emulator (http://www.cyntaks.com/projects/chip8) written in java and I don't believe its slow at all (ok yes its a chip8 emu but still).

Startup time may be a little slower with java still, but keep in mind that this is a constant and doesn't increase with app complexity, its almost not noticeable anymore.

Can't say anything about j2me though as I've never used it.

 

[Cyberman]

erm, I don't think cyberman has seen what java can do since 1997 or so... if you want to see what the java community is doing with games nowadays, check this out: http://www.iotd.kaioa.com/ 5x faster with C/C++ is ridiculous...

Not really, it depends on the Engine used to run the JavaCode and the compilor. However Java has slowly improved in two key areas, memory management and execution management. GCC for example has a Java compilor front end. What's that mean? It means it can compile native binaries from Java code.

I also just finished a chip8 emulator (http://www.cyntaks.com/projects/chip8) written in java and I don't believe its slow at all (ok yes its a chip8 emu but still).

Fine with me.. what is the performance of the system you are running it on though? I believe you are mistaking improvement in processor execution performance, for improvement in Java execution performance. Trust me they aren't the same. In fact special variants of ARM processors had to be made for improved performance of J2ME on Cell Phone and PDA platforms.

Startup time may be a little slower with java still, but keep in mind that this is a constant and doesn't increase with app complexity, its almost not noticeable anymore.

Well it does take a certain amount of time to load the Java bin data and perform initialization of the Java Engine. It's expected. Sort of like watching PJ64 run through an N64 ROM.

Can't say anything about j2me though as I've never used it.

Java 2 + Mobile Embeded? Hmmm which means the only thing you have to compare is with a desktop machine. Ok.. let me explain this in understandable terms then. Your DT machine 2Ghz processor 32bit to 64bit 133mhz to 500mhz 64 to 128 bit FSB and has 3 FPU pipelines and 3 Integer pipelines along with several look ahead engines to precompute addresses and fetch code for speculative execution uses from 20 to 50 watts of power, your Cell Phone 200mhz processor uses 1mw to 1W, uses a RISC processor optimized with power as the primary concern, FSB 100mhz tops 32 bits tops most likely 33mhz and 16bits. In order for that thing to run Java with any speed, it has to have specialized instruction set and hardware. Otherwise it might be like running Java on a 486/66

I hope this sinks in, that if you used your processor to its full performance for your DT it is likely to be about 10 (normal apps) to 100 (optimized apps) times faster than the Cell phones. That's the complete picture. A well written and properly optimized C++ program will be 5 to 10 times faster than that the equivalent Java program depending on the compilor and if it's native compiled code or not. It's not far fetched that's just reality. Sometimes you don't need to tweak that extra bit of power out of your machine. Well at least not with the hugely powerful systems of today as opposed to 1997

The important thing to keep in mind, is does it work and is it fast enough. Cell phone's are a challenge for an emulator and Java and it's not fast enough as a consequence. Perhaps using GCC's Java compilor might help? Depends if the platform will allow native binaries to be run.

Cyb - have fun with Emu's!

 

[weston]

Hmm, should have clarified a couple things I guess. First of all, I'm talking about the standard implementation of java provided by Sun Microsystems. I am not talking about compiled java, or using a 3rd party virtual machine. When you say Java Engine, I assume you are referring to a jvm?

Second, I realize that cell phones and desktops have vastly different hardware. I was just talking about java in general (so on the desktop). I only mentioned j2me at the end because one platform Lordus could be writing for is cell phones and j2me != desktop java. J2me vs native cellphone code is different from desktop java vs native and I don't know how j2me holds up.

I also made the assumption that people would understand that I was talking about an increase in java's operating speed, not the fact that computer hardware has gotten better. As for startup time, I mentioned that it is independant of the program you run (jvm startup time, not the start up time for your specific program), so increase in computer hardware speeds is all that matters here (I'm not saying this is true about execution speed!!).

Now that thats all cleared up, I say once again: C/C++ being 5x to 10x faster than java code is a ridiculous statement (not talking about j2me which once again is not the same as desktop java).

 

[HyperHacker]

Well it all depends what you're running. A simple program like a word processor or image editor would probably run at the same speed in Java as in C, since the speed boost it gets from being native code wouldn't make much difference since the program is idling most of the time anyway (unless your CPU is particularly slow). An emulator is a lot more demanding, doing millions of calculations per second and probably not idling much, so a difference in speed is going to be very apparent. Java can get faster and faster but it'll never match native code (unless they can recompile the program to 100% native code at runtime ).

 

[weston]

I'm not talking about percieved performance, I'm talking about actual performance. I know people writing next generation game engines in java... not the crappy java applets that it got its reputation from. Look at the screens I linked to, those are hardly text editor type applications. Or even better, look at this benchmark comparing a current version of java vs. C running quake2: http://www.bytonic.de/html/benchmarks.html

Does that look like C is winning 5 to 10 times over? People seem to think that modern jvms are still just simple interpreters or something. There are trade offs between run-time and ahead-of-time compilers, both are able to gain speed in different ways. With a run-time compiler (e.g. a jvm), you can do things like adjust the size of code blocks to fit your current cache size.

I honestly just don't think you are going to run into the slightest performance problems writing an emulator 'because' you are using java. If its slow, thats because you coded it slow (exceptions made for ps2/gc/xbox perhaps).

 

[HyperHacker]

Well I'm sure Java can be pretty damn fast, but C will always be just a little faster.

 

[Cyberman]

I'm not talking about percieved performance, I'm talking about actual performance. I know people writing next generation game engines in java... not the crappy java applets that it got its reputation from. Look at the screens I linked to, those are hardly text editor type applications. Or even better, look at this benchmark comparing a current version of java vs. C running quake2: http://www.bytonic.de/html/benchmarks.html

Does that look like C is winning 5 to 10 times over? People seem to think that modern jvms are still just simple interpreters or something. There are trade offs between run-time and ahead-of-time compilers, both are able to gain speed in different ways. With a run-time compiler (e.g. a jvm), you can do things like adjust the size of code blocks to fit your current cache size.

I honestly just don't think you are going to run into the slightest performance problems writing an emulator 'because' you are using java. If its slow, thats because you coded it slow (exceptions made for ps2/gc/xbox perhaps).

I did put caveats, please stop busily defending your position, this hasn't anything to do with what's fast and what's not on a PC. I told you exactly why Java is not a good choice for a particular platform. I also said there are Java compilors etc. In addition I mentioned that a mobil platform is bad for Java. It has limited memory (you can't do dynamic REC easily if at all and JIT has the same issues), it has limited hardware performance (IE required special hardware to run the Java Engine). Bottom line is it won't run fast for the particular application I was refering too (IE mobil phones and PDA's). Sure it will get faster eventually, but in order to do that the JE's have to use the tricks of Emulators in order to improve Java. Basically JavaEngines are no longer JavaEngines but JavaEmulators. That's a more complete perspective of what's going on.

I have never been fond of Java but it does work for specific applications just fine. I'm not sure Java should be used for everything. That seems kind of like giving someone a hammer and nail, and everything suddenly becomes a board to pound nails into. It reminds me of the people who use to use 4th for everything, or assembly for everything. You use what's appropriate, Java is not appropriate for everything. You can't use Java at the current hardware level of mobil systems without using the low resource usage interpretor. That will change of course. As everything does. It doesn't make Java faster though, because it's not really running Java code anymore is it? Just like an emulator that uses HLE JIT and dynamic REC is no longer actually executing the original code inside the game. It's one of those strangely gray areas of the world. JE's that run that way are no longer JVM's. Reading the Jake 2 stuff revealed most of the optimizations are in Memory handling of which Java has been traditionally very bad at.

You have the same issues with Java and speed on emulation as you would with C and C++ with all the great and wonderful JavaEmulators. Unless you can do Dynamic Rec HLE etc in Java you will not see Java based N64 emulators that run fast for a while (hehe).

I'll continue to be skeptical. FUD is FUD.

Cyb

 

[zenogais]

Cyberman: I want to try and clear up this performance issue annoyance hopefully on these forums once and for all. Being a java programmer myself and having to take crap over the "performance problems" time after time I've come to sympathize with weston's point of view and quite frankly his frustration at these criticisms. First things first, the performance issues are quite frankly null and void anymore for most applications, and I've come to realize the people who talk about them are 99% of the time (1) Not Java programmers (2) Have no clue what they're talking about (3) Usually heard it either via word of mouth or from some ancient article.

Honestly I wouldn't mind if you disliked Java semantics etc. as you don't need to be an active use of the language to criticise these, but please have coded something "performace intensive" within the last 6 months in Java to even think you can speak on the topic. Now these criticisms are not aimed at you (Cyberman) in particular as your second posts shows you're fairly level headed on this issue, but instead more towards to ignorant "anti-Java" people in general. Please know wtf you're talking about before you talk about it. Finally, spewing these things doesn't make you sound knowledgable or informed, it instead shows that you possess neither of these qualities.

 

[Lordus]

I guess i shouldnt have mentioned Java in these forums :whistling

No programming language is better than the other, just use what u like best and what fits the purpose.
I just started with Java again after a while and its surely wonderfully easy to do some things with it, and you wont see any speed differences on most applications on modern hardware, as you wont see any speed difference between a bmw and a ferrarri in the rush hour.
To get the last bit of speed in a limited environment a C/Assembler combo will surely do the trick a little bit better.
Anyway, PEACE... and btw. just ported a GameGear emu to J2ME and its slow as hell of course, but nice to look at a Sonic-slideshow on my mobile.

 

[bcrew1375]

So, um, anyone interested in getting back on the main topic? :whistling

 

[ShizZy]

I finally made some progress... Got joypad emulation working. All the keys work, but for some reason I cannot get it to find the distinction between the directional pad and the rest of the buttons. Not important at the moment, nothing is playable yet anyways - all I need input for is testing.

Anyways, it allowed me to get in-game with Tetris I also roughly implemented sprites, although it doesn't actually read tile data yet. It draws a black 8x8 square instead (as seen in the screenshot by the score). It works afaik, but unfortunetly there's a bug which in tetris causes the emu to write garbarge into OAM throwing the sprites all over the place. It works right in other roms though...

So, fix input, find out what is wrong with the memory issues, and Tetris becomes fully playable Not going to bother with MBC yet, still too bug ridden....

 

[HyperHacker]

How did you manage to finish the game with no points?

 

[ShizZy]

Easy, you don't get any lines when you can't see the blocks Also love how the score is in hex when you do randomly get them

 

[Cyberman]

I guess i shouldnt have mentioned Java in these forums :whistling

No programming language is better than the other, just use what u like best and what fits the purpose.
I just started with Java again after a while and its surely wonderfully easy to do some things with it, and you wont see any speed differences on most applications on modern hardware, as you wont see any speed difference between a bmw and a ferrarri in the rush hour.
To get the last bit of speed in a limited environment a C/Assembler combo will surely do the trick a little bit better.
Anyway, PEACE... and btw. just ported a GameGear emu to J2ME and its slow as hell of course, but nice to look at a Sonic-slideshow on my mobile.

Putting aside all heritical Java remarks hehehe

I finally made some progress... Got joypad emulation working. All the keys work, but for some reason I cannot get it to find the distinction between the directional pad and the rest of the buttons. Not important at the moment, nothing is playable yet anyways - all I need input for is testing.

Well it looks like it sort of works
You need to port your jet hydro game to the game boy as one of your key emulated games

Cyb

 

[ShizZy]

LOL yeah I wonder how software based shaders would be handled on the GameBoy, rendering 20k+ polys on screen at a time, vertex based fogging, and atmospheric cloud settings - plus a physics engine

 

[HyperHacker]

Very, very slowly.

 

[Cyberman]

ShizZie it's obviously going to be at least 60fpm That is 60 frames per month LOL.

Cyb

 

[ShizZy]

Probably possible to get it to render though, in monochrome Not in my lifetime as a programmer

 

[HyperHacker]

If the GB has enough memory. Which I doubt.