JStella for Java released

[Thomas Jentzsch]

That is fantastic! I think I will set this up so all the homebrew games can be played in the store in this fashion.

GREAT idea!

 

I was about to suggest it myself.

[Mauvila]

Hey guys,

I've just created an account here...didn't even realize this JStella topic existed. Anyway, I did the JStella translation from Stella, and I've been managing the SourceForge project. As you've figured out, it's still in its alpha mode. However, it will be very helpful if everyone who sees a bug that needs to be fixed report it in some shape or form. I currently am using Vista with Firefox and IE, and I don't have access to a Mac or Linux machine.

 

The most recent .jar released (0.5) is only compatible with Java 6, but the current code on the CVS is backwards compatible (for Java 5). I might post a new compiled .jar and source code .zip tomorrow (Aug 23rd). Apple is in charge of the Java implementations for Mac, and it is way way behind on Java 6...

 

Thanks to a few of you who have submitted patches. The latest source code has more support for home brew games (F4 cartridge, and 6507 support for unofficial codes.) Previously only 'sax' was supported because that's the only one I ran into in the standard ROM zip downloads.

 

Future plans:

BUG FIXES:

-focus problems with Opera, etc.

-any type of threading issues

Save/load state

Better GUI stuff (e.g. help)

More parameters for Applet configuration (controls to use, screen mode, cartridge type, etc.)

"JStella singletons", self sufficient Jars that contain within them a single ROM--will be as if the program existed simply for that ROM

 

I will also be winnowing out some of the more redundant/byzantine portions of the code.

 

Sometime in the next few days, I may be issuing a call for help (i.e. for Java programmers to join the SF project), but I really don't know what kind of response to expect (too few, too many?). The project will also be needing graphics and web pages, etc.

 

Thanks,

JLA

[+stephena]

Hey guys,

I've just created an account here...didn't even realize this JStella topic existed.

Oops, sorry about creating the thread and not sending a message to you. I was busy with other Stella-related stuff (and work), and forgot to send the link.

[+SpiceWare]

Hi Mauvila, great work!

 

I've used JStella to put Medieval Mayhem up on my site, it's my take on Warlords.

 

I've got minor issues with a few things about JStella:

 

1) Is the "control panel" a fixed height? I'd like to be able to calculate the height and width to get pixels that are consistently 2x. I'm currently using 640x420 and a few rows of pixels don't get doubled and look a bit odd. Basically I'm looking for:

 

width = mult * 320

height = mult * 200 + panel_height

 

I suspect there's a chance the 200 is something else.

 

2) My games a paddle game and I noticed a problem where if I hold down the mouse button to capture the fireball, the paddle readings freeze. I found that right-arrow works as a workaround for the paddle's fire button.

 

3) is there going to be a way to start JStella with "a paddle plugged in"?

 

4) I noticed that flashing the screen's background color has a major impact on the performance. Not sure if that's something that can be improved upon.

Edited August 23, 2007 by SpiceWare

[Mauvila]

Hi Mauvila, great work!

 

I've used JStella to put Medieval Mayhem up on my site, it's my take on Warlords.

 

I've got minor issues with a few things about JStella:

 

1) Is the "control panel" a fixed height? I'd like to be able to calculate the height and width to get pixels that are consistently 2x. I'm currently using 640x420 and a few rows of pixels don't get doubled and look a bit odd. Basically I'm looking for:

 

width = mult * 320

height = mult * 200 + panel_height

 

I suspect there's a chance the 200 is something else.

 

2) My games a paddle game and I noticed a problem where if I hold down the mouse button to capture the fireball, the paddle readings freeze. I found that right-arrow works as a workaround for the paddle's fire button.

 

3) is there going to be a way to start JStella with "a paddle plugged in"?

 

4) I noticed that flashing the screen's background color has a major impact on the performance. Not sure if that's something that can be improved upon.

 

1. I'm not sure I know what you mean...are you talking about the applet or the stand-alone version? The little bar on the applet should be a fixed height, just tall enough for the buttons, so that you can alter the size of the applet in the HTML tags. If not, let me know, and the problem can be addressed.

 

2. This has been fixed as of version 0.7, which has just been released on SourceForge.

 

3. Do you mean with only paddle simulation? (Like paddle mode always on?) If so, let me know...it probably won't be hard to implement.

 

4. I don't think I'm able to replicate any performance issues on my computer, even at full screen, so any information on these things is extremely helpful...are these slowdowns, audio problems, frame messups, or a combination? It would also be helpful to know what operating system, java version, and CPU speed you have, as well as the ROM and circumstance, and the size of the window...

As the system currently is, a frame with isolated movement on one part of the screen is rendered extremely fast, while a busy frame can cause problems...(test the opening screen of TRON...that's a very busy frame).

 

Thanks for the bug reports, and please keep them coming.

JLA

[+SpiceWare]

Everything is related to using it as an applet on a web site.

 

1) basically asking for 2 things

a) what is the height of the little bar

b) 320's the width of the TIA output area, is 200 the height?

 

2) sweet - I'll update my website tonight

 

3) yep, my game is a paddle game. If the person doesn't right-click they can't play. It's just a minor issue as we know everybody reads directions

 

4) Performance issue happens on all systems I've tried it on. iMac G5, MacBook, various Dell systems(up to 2.6GHz) at the office running Windows XP SP2. Browsers used have been Firefox and Internet Explorer(doesn't work in Safari for some reason).

 

Basically what happens is when a king is killed the background gets color cycled. While this color cycling is happening the emulation slows down a lot. Once the color cycling is done the emulation then runs faster than normal for a few seconds before dropping back down to the proper speed. This is really noticeable when the last king is killed as the winner's knight sprints across the screen instead of marches. I can do some video captures of this problem if that would help.

[mos6507]

IMHO, there should be an option to just not have the bottom control panel area. That would make it easier to get a 1:1 pixel mapped screen. The console switches are all wired to the function keys anyway.

[Mauvila]

IMHO, there should be an option to just not have the bottom control panel area. That would make it easier to get a 1:1 pixel mapped screen. The console switches are all wired to the function keys anyway.

 

Agreed.

I know everyone is wanting to see option parameters for the applet, but which ones does everyone want? Besides the control bar visibility, auto-paddle mode, and manual cartridge type setting?

[+SpiceWare]

1) I'm not familiar with programming in Java, but in checking the source I found DEFAULT_DISPLAY_HEIGHT=210 in JSConsole.java and DEFAULT_HEIGHT=200 in JSVideo.java. I believe the 200 is being used as the last row of text in my easter egg is cut in half. You can see the easter egg on my page by hitting left and right arrow keys while in the game's main menu. This works because the paddle buttons are wired to the same inputs as the joystick's left & right directions.

 

I couldn't find the control strip's height in the source, so I did a screen grab and it appears to be 40. As such, I find that using the following works fine to calculate the height and width values to use in the <applet> tag.

WIDTH = SIZE * 320

HEIGHT = SIZE * 200 + 40

 

2) Paddle no longer freezes the left-button with 0.7 One thing I noticed last night was the AI players "jittered" in the prior version, they don't do that anymore with 0.7

 

3) n/a

 

4) the slowdown still happens in 0.7. I noticed the following comment in paintBackBufferToCanvas of JSVideo.java

//Tells the canvas to call the paint command...the coordinates are very important...drawing the screen is incredibly slow, so you must only

//draw a portion of it at a time. The portion that has changed is contained in myClipRect

//The calculations are there to scale, converting double into ints by rounding the correct direction

This tells me you're using dirty rectangles to minimize screen updates. The King Killed flashes cause the entire screen to have to be redrawn every frame for 64 frames, so as a work around I've changed my game to default the "Flash" option to "No".

 

I know everyone is wanting to see option parameters for the applet, but which ones does everyone want? Besides the control bar visibility, auto-paddle mode, and manual cartridge type setting?

besides those, I would love to see audio='STEREO' as Medieval Mayhem utilizes stereo sound. I would also like displayheight='210' and displayystart='34', which would correspond to the options on the DISPLAY tab of the GAME PROPERTIES screen of Stella 2.4.

 

I noticed that clicking outside the JSTELLA area in the browser will pause the game. The only way I could find to unpause was to click the control bar. Is there another way to unpause? If not, something will be needed if the control bar is set to invisible.

Edited August 25, 2007 by SpiceWare

[Hackmann]

1) I'm not familiar with programming in Java, but in checking the source I found DEFAULT_DISPLAY_HEIGHT=210 in JSConsole.java and DEFAULT_HEIGHT=200 in JSVideo.java. I believe the 200 is being used as the last row of text in my easter egg is cut in half. You can see the easter egg on my page by hitting left and right arrow keys while in the game's main menu. This works because the paddle buttons are wired to the same inputs as the joystick's left & right directions.

Those flags control the way the window is scaled, but shouldn't result in lines of video getting cut off. The culprit in your case is that JSTIA.java is misdetecting the top and/or bottom lines of resolution, so it's cropping the emulated video signal.

 

Adding a displayystart and displayyheight option like you propose would fix the problem.

 

I couldn't find the control strip's height in the source, so I did a screen grab and it appears to be 40. As such, I find that using the following works fine to calculate the height and width values to use in the <applet> tag.

WIDTH = SIZE * 320

HEIGHT = SIZE * 200 + 40

Don't assume a 40-pixel height! The bottom panel is set to use whatever height Swing chooses, which will depend on how tall Swing draws the buttons, which will in turn depend on your platform's look-and-feel and/or your selected layout manager.

 

Working around this is kind of tricky, since AFAIK you can't force Swing to reliably scale buttons to fit some size constraint. I have a couple of ideas that could guarantee the height of the control strip, but I'm not sure how well they'll work in practice. I've got a lot on my plate right now (grad school is a harsh mistress!) but if I get some free time today I'll see if I can hack one of the two up.

[Hackmann]

Working around this is kind of tricky, since AFAIK you can't force Swing to reliably scale buttons to fit some size constraint.

I stand corrected; you can set a button's preferred size to force it to fit an arbitrary size constraint. The button renders a little bit differently on OS X, but it does the trick.

[+SpiceWare]

Those flags control the way the window is scaled, but shouldn't result in lines of video getting cut off. The culprit in your case is that JSTIA.java is misdetecting the top and/or bottom lines of resolution, so it's cropping the emulated video signal.

I wouldn't blame the detecting on JStella then, the easter egg displays a few more scan lines than the main menu or game screen. Stella defaults to showing 210 scan lines so it doesn't get cut off there.

 

I stand corrected; you can set a button's preferred size to force it to fit an arbitrary size constraint. The button renders a little bit differently on OS X, but it does the trick.

Are you also working on JStella?

[Hackmann]

I stand corrected; you can set a button's preferred size to force it to fit an arbitrary size constraint. The button renders a little bit differently on OS X, but it does the trick.

Are you also working on JStella?

No, certainly not officially anyway. I just like occasionally going through small open-source projects like these to keep my Java skills sharp.

 

But if you have any simple requests that you don't think are worth hounding Mauvila over, I could give it a shot and submit a patch.

[mos6507]

IMHO, there should be an option to just not have the bottom control panel area. That would make it easier to get a 1:1 pixel mapped screen. The console switches are all wired to the function keys anyway.

 

Agreed.

I know everyone is wanting to see option parameters for the applet, but which ones does everyone want? Besides the control bar visibility, auto-paddle mode, and manual cartridge type setting?

 

Does it support keypad emulation also?

[mos6507]

I noticed that clicking outside the JSTELLA area in the browser will pause the game. The only way I could find to unpause was to click the control bar. Is there another way to unpause? If not, something will be needed if the control bar is set to invisible.

 

As far as I know, the Applet has to become input-active again, which means clicking inside the applet. I think it might be a good idea to use an overlay that renders PAUSED or something.

[frogstar_robot]

Cool... I've been looking forward to this for a LONG time! I got it working here.

 

So, it only works with Java 6?

 

It works on my Java6 equipped Ubuntu with Firefox.

[Mauvila]

1) I'm not familiar with programming in Java, but in checking the source I found DEFAULT_DISPLAY_HEIGHT=210 in JSConsole.java and DEFAULT_HEIGHT=200 in JSVideo.java. I believe the 200 is being used as the last row of text in my easter egg is cut in half.

 

I'm not sure if those DEFAULT settings still do anything...they may be a relic of an earlier version...There is an autodetection of frame height that goes on during the loading of the game...what it sounds like you need is simply a method of passing the height manually via APPLET parameters.

 

The animation DOES use the "dirty rect" technique...that is, it only updates the part of the screen that has changed. (A good example of the whole screen changing is the opening of Tron...) For the sake of debugging, try running your ROM in the JStella stand-alone mode (i.e. the non-applet mode, with its own dedicated window), just to see if the slow down occurs there as well...this will also give you the benefit of seeing at what window size the animation begins to slow down.

 

The pausing upon loss-of-focus (what I call auto-pause mode) can be disabled...this sounds like another good applet parameter. For my setup, though, to re-enable it, all I have to do is click any part of the applet.

 

Thanks for the feedback...please keep it up.

 

JLA

[+SpiceWare]

The animation DOES use the "dirty rect" technique...that is, it only updates the part of the screen that has changed. (A good example of the whole screen changing is the opening of Tron...) For the sake of debugging, try running your ROM in the JStella stand-alone mode (i.e. the non-applet mode, with its own dedicated window), just to see if the slow down occurs there as well...this will also give you the benefit of seeing at what window size the animation begins to slow down.

Tried last night. Same slow down. I made the window about 1X size and it worked better, it still had the slow down just recovered from it quicker. This was on my 2 GHz iMac G5.

[Mauvila]

The animation DOES use the "dirty rect" technique...that is, it only updates the part of the screen that has changed. (A good example of the whole screen changing is the opening of Tron...) For the sake of debugging, try running your ROM in the JStella stand-alone mode (i.e. the non-applet mode, with its own dedicated window), just to see if the slow down occurs there as well...this will also give you the benefit of seeing at what window size the animation begins to slow down.

Tried last night. Same slow down. I made the window about 1X size and it worked better, it still had the slow down just recovered from it quicker. This was on my 2 GHz iMac G5.

 

It may take some time to profile everything...I think it may depend on graphics cards as well. I'll check it out.

Also, currently on the CVS is a version of JStella that allows customization of the applet via parameters...it hasn't yet been released as a jar, as I figure a few more features would be needed to justify a new release, but be on the lookout for it.

[Mauvila]

Okay, the solution for the "options panel" at the bottom of the applet is multiple applets that communicate with each other. In the next version, there will be multiple applet classes, including the main one and a switches class. These can be put anywhere on the page. In the ever dwindling time I have before I'm completely consumed by med school, I will try to put out a graphics prototype, with .gif representations of switches...hopefully someone with artistic (or photographic) talent (at least more than the little I have) will be able to replace the graphics fairly easily.

[mos6507]

Okay, the solution for the "options panel" at the bottom of the applet is multiple applets that communicate with each other. In the next version, there will be multiple applet classes, including the main one and a switches class. These can be put anywhere on the page. In the ever dwindling time I have before I'm completely consumed by med school, I will try to put out a graphics prototype, with .gif representations of switches...hopefully someone with artistic (or photographic) talent (at least more than the little I have) will be able to replace the graphics fairly easily.

 

Can't you just make it scriptable with Javascript? Then maybe the controls could be done with DHTML or Flash.

[Mauvila]

Okay, the solution for the "options panel" at the bottom of the applet is multiple applets that communicate with each other. In the next version, there will be multiple applet classes, including the main one and a switches class. These can be put anywhere on the page. In the ever dwindling time I have before I'm completely consumed by med school, I will try to put out a graphics prototype, with .gif representations of switches...hopefully someone with artistic (or photographic) talent (at least more than the little I have) will be able to replace the graphics fairly easily.

 

Can't you just make it scriptable with Javascript? Then maybe the controls could be done with DHTML or Flash.

 

 

I know absolutely nothing about Javascript...can Javascript call public methods on a Java Applet? If javascript and Java Applets can interact, then there is already support for certain switches...and a lot more capabilities could be added.

JLA

[Mauvila]

The animation DOES use the "dirty rect" technique...that is, it only updates the part of the screen that has changed. (A good example of the whole screen changing is the opening of Tron...) For the sake of debugging, try running your ROM in the JStella stand-alone mode (i.e. the non-applet mode, with its own dedicated window), just to see if the slow down occurs there as well...this will also give you the benefit of seeing at what window size the animation begins to slow down.

Tried last night. Same slow down. I made the window about 1X size and it worked better, it still had the slow down just recovered from it quicker. This was on my 2 GHz iMac G5.

 

 

I just put up version 0.75, which completely eliminates the MedMadness slowdown (as well as Tron opening screen maximized) on my machine...I posted a new topic with links to the web page containing the new recommended applet tags, etc. It will allow you to separate the switches bar from the main applet. Please let me know if the slowdown is still present on other systems (especially those without decent graphics cards), should you come across this information.

 

(If this doesn't work for some reason, I think I know why the slow down is occurring--a thread is blocking for the graphics routine...I would have to think of an elegant workaround. But hopefully the new version will speed the graphics up enough so that the blocking doesn't matter.)

Thanks,

JLA

[Retro Rogue]

Does it support keypad emulation also?

 

 

Was this ever answered anywhere? I've been trying to play StarRaiders, but the normal Stella keypad mappings seem to be absent from JStella.

[boski]

This is a pretty old thread. Does anyone know if this thing still works?