I've been thinking what users would mostly want from JEmu2. Probably most are using JEmu2 for nostalgia reasons, and I'm guessing many use JEmu2 for a quick bash at their favourite classic at work because they don't want to go the MAME route there (installing it, hunt for ROMs etc), in which case sound is probably not that important.

I've also been considering implementing enhanced graphics in some games. For example higher resolution graphics with more colors for Ms.Pacman, or some real funky texture mapped 3D graphics for the Star Wars arcade (already a 3D vector game, although not yet supported by JEmu2), or adding some '3D twist' to otherwise 2D games (for example I've seen a first person shooter version of an emulated Asteroids machine somewhere). Would that be cool, or would it just ruin the nostalgia trip?

Or should I try make JEmu faster? There's still some options left for optimization, but it probably won't ever reach the speed of MAME. Java is just not so great for making fast emulators (i.e. bounds checking and there's arrays *everywhere*, no unsigned bytes & ints, no union etc).

I think changing (or: enhancing) the games is not the way to go. To create a really slick version of the original, requires so much time and effort it just aint worth it. Besides that, what would the result be? It would probably be inferiour (for todays standards) to all that freeware/shareware out there. Sticking to the original version and emulating it 'as is' is what players expect and demand when visiting your site. You achieved that, now stick to it

Hi, appreciate more people! Σ ♥ = ¾Learn how to award medals... and work your way up the social rankings!

I think implementing kev's scale2x and scale3x on games such as Commando would give JEmu2 an edge over other emulators. Personally, i cant remember any of the games, so the "good old days" memories dont apply to me; I play them because they actually alot more fun than most new games IMHO.

I think changing (or: enhancing) the games is not the way to go. To create a really slick version of the original, requires so much time and effort it just aint worth it. Besides that, what would the result be? It would probably be inferiour (for todays standards) to all that freeware/shareware out there. Sticking to the original version and emulating it 'as is' is what players expect and demand when visiting your site. You achieved that, now stick to it

Good point.OTOH, if I look at for example the current Ms. Pacman clones I see nice graphics and the ingredients of the gameplay reimplemented. But, the gameplay is never exactly the same as the original, which is IMHO invariably better. Which is why I was thinking creating enhanced graphics would be a neat gimmick (if nothing more than a gimmick) to bring the original Ms.Pacman to today's audience. Maybe you're right, and people don't want that from an emulator, but maybe Ms.Pacman (just sticking to that one example here) deserves a bigger audience than just emulator freaks

I think implementing kev's scale2x and scale3x on games such as Commando would give JEmu2 an edge over other emulators. Personally, i cant remember any of the games, so the "good old days" memories dont apply to me; I play them because they actually alot more fun than most new games IMHO.

DP

Actually, there's already a scale2x renderer in JEmu2, I just didn't expose it yet. It takes quite a big performance hit, and personally I don't really like the look of this algorithms (but maybe that's just me )

the scale2x algorithms are only meant to run once during initing...and thats it. I dont see how that would impact performance in OGL for a bigger texture size thats still less than 4096x4096 in size (otherwise, software mode kicks in...)

the scale2x algorithms are only meant to run once during initing...and thats it. I dont see how that would impact performance in OGL for a bigger texture size thats still less than 4096x4096 in size (otherwise, software mode kicks in...)

DP

Sounds good, but it doesn't work.The thing with emulators is, there's no such thing as an initialization phase where all graphics are initialized: most of the times you don't know what the game is going to look like until the game runs.In the first JEmu I did some filtering per tile to make things look more smooth and gain some performance, but that really didn't look good. One reason is that when you have one tile, the filtering that needs to be done on the edges of one tile depends on the neighbouring tiles. So you end up with nicely filtered tiles with very obvious edges.And then there's also dynamic palettes, transparency, even tiles/sprites that are in RAM (so dynamic too) etc. so the right thing to do it, afaik, is to filter (scale2x, averaging, whatever) the final image.

These games run on a 68000 CPU. I have made a 68000 emulator for JEmu2, but I think I was on the wrong track for that one, because the code is way too large. In an attempt to make it as fast as possible, it's a code generator which generates specific code for all opcodes, with a minimum of branches. Because of the huge number of opcodes, the generated source is HUGE and thus it has very long start-up times and takes quite a lot of memory and makes Eclipse barf often when I work on it. And the result is not very fast anyway (probably because of it's size). For example on my 1.2GHz laptop, one game (Snow Bros.) doesn't get faster than 45-50 FPS, which is not good.This is the reason I stopped working on the current 68k emu for now and didn't include it (or any games using it) in the current JEmu2 binary.

The good news is, a friend also made a 68000 emulator in java which seems to work very well and he will be donating it to JEmu2 when he ironed out the last bugs. So stay tuned!

java-gaming.org is not responsible for the content posted by its members, including references to external websites,
and other references that may or may not have a relation with our primarily
gaming and game production oriented community.
inquiries and complaints can be sent via email to the info‑account of the
company managing the website of java‑gaming.org