JEmu2 new driver: Commando

WIP games, tools & toy projects Archived Projects
#21

I do absolutely nothing fancy. All that’s done is draw one single textured quad, which is changed with new rgb values each frame. All rendering is done in software, only the final backfuffer is drawn using openGL.


                    updateTexture();
		GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_WRAP_S, GL11.GL_CLAMP);
		GL11.glTexParameteri(GL11.GL_TEXTURE_2D, GL11.GL_TEXTURE_WRAP_T, GL11.GL_CLAMP);
		GL11.glBindTexture(GL11.GL_TEXTURE_2D, pointer.get(0));
		GL11.glBegin(GL11.GL_QUADS);
		GL11.glNormal3f(0, 0, -1);

		GL11.glTexCoord2f(0, 0);
		GL11.glVertex3f(-width, -height, d);

		GL11.glTexCoord2f(tw, 0);
		GL11.glVertex3f(+width, -height, d);

		GL11.glTexCoord2f(tw, th);
		GL11.glVertex3f(+width, +height, d);

		GL11.glTexCoord2f(0, th);
		GL11.glVertex3f(-width, +height, d);
		GL11.glEnd();
#22

I don’t know if it’s noteworthy saying this but it’s not always a good idea to upgrade your video driver to the most recent version because sometimes it causes incompatibilities. I had this problem with the driver from NVIDIA. Many textures were invisible and when I installed the latest video driver from ASUS (because I have an ASUS card), everything worked fine. And the the one provided by ASUS for my card is by far older than the one from NVIDIA. So don’t assume that because NVIDIA (or maybe ATI in your case) claims that their driver is compatible with old cards that it’s true.

#23

I don’t know how protective you are of the source, but I would be willing to run it through a debugger to see if I can spot anything.

ps. I am on vacation until July 30, so I probably won’t get your reply until I get back.

#24

I don’t mind sending you the source, but be warned: It’s not a pretty sight :stuck_out_tongue:

#25

That’s ok. I am working on my own emulator for the Commodore 64(in Java) and it is already not a pretty sight.

#26

i think the server is down, links not working for me!

#27

yep, the link doesn’t work for me either :frowning:

a bit off-topic, erik:

what’s the progress on 68000 cpu emulation?
i’m developing a 68000 debugger for a future emulator http://blog.efx2.com/gallery/900-jslug_debugger.png and i’ve used oop technics like you mentioned on retrogames forums (operands and instructions interfaces) but i get relative poor performance.
In the development of Jario ( a snes emulator written in java) i’ve used interpretative technics for the 65c816 cpu and the performance is very good (i know, snes cpu is far more simple than 68000). I’m wondering now if generate the interpretative code like MAME or Generator (sega genesis emulator) does could become a boost performance in emulate a complex cpu like the 68000. Perhaps oop technics are not very suitable for emulation purpouses. ???

Thanks for your feedback

#28

The server seems to have vanished from the face of the earth.
I’ve finally purchased my own domain and hosting so a new (stable) site should be online in a week or two. I’ll keep you posted.

Regarding the 68k emulator, I’ve made fair progress with it and finally went for a code generator: It generates the code for all opcodes at compile time. I’m guessing this would give best performance but it makes development a bit slower because:
a) if I do a bugfix I have to re-generate the sources again.
b) because the huge number of opcodes, the sources become very big which eclipse has a hard time handling (a refresh of the project takes about 5 to10 minutes).

In this particular case, going for a clean OOP solution like I’ve been going for in the past will not give good performance because, as I understand it, it is impossible for the VM to optimize well.

At this point the status of the 68k core is that it runs the 2 game drivers I made (Food Fighter and Snow Bros.) for a few minutes but then goes wrong. Because the problems appear after a few minutes, the bug(s) is/are VERY difficult to find (it appears after billions of correctly emulated instructions) and I’ve been unable to track them down them yet. Maybe I’ll have to implement a driver for a console (maybe Genesis or something) to be able to test it against a large number of games.

Another issue is that it isn’t cycle accurate yet. I simply let each instruction take a fixed number of cycles (a number which seemed like a good estimate), but I don’t think this is a big issue as I suspect it will only affect some games which do some heavy trickery that depend on timing a lot. IIRC, StarScream (another 68k core, but asm based) did basically the same thing but still works for most applications.

#29

The new link is at http://www.gagaplay.com/jemu2/JEmu2.jnlp (I haven’t made a website yet though).

#30

Eric,

that’s so cool! :smiley: Congratulations for the very good work! Playing Commando again was so cool! I can’t wait to play it with sound. Do you intend to port sound for all the games?

#31

Thanks! :smiley:

I plan to add sound to all games. Commando uses a soundchip which the emulator currently doesn’t support yet (YM2203). If that soundchip gets supported, most games would suddenly have sound in no time :slight_smile:

BTW, there’s now a quick mock-up for the site as well (but I’ll change it). But at least you can see the high score saving at work (currently supported by just 3 games). http://www.gagaplay.com

#32

I am back from vacation if you still want me to try to run it from the source on my machine.