JVic libGDX

You need an actual VIC.

Moderator: Moderators

lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

JVic libGDX

Post by lance.ewing »

Hi all,

After seeing the posts from a few months back about VIC 20 emulators on Android, I thought I'd have a crack at working on something. I've never built an app for Android, but I am a Java developer with about 18 years experience, and I do have an Android phone. And I still have the source code for the JVic emulator I wrote back in 2003. So I started wondering if I could hack the JVic code to make it work on Android (I lost the C code for V20 many years ago, and besides, I haven't touched a line of C code since 1998).

Although I haven't built any Android apps, I've been wanting to give it a try. So I've been doing some reading here and there and it wasn't long before I took notice of a cross platform game development library called libGDX. The idea is that you write your code once, in Java, building it against the libGDX libraries, and it will in theory build a version that will run on Android, desktop, HTML5, and iOS.

When I started thinking about an Android version of JVic, the libGDX library quickly came to mind. I started thinking "Converting JVic to use libGDX will not only produce an Android version but I'd get an HTML5 nearly for free (apparently there are a few gotchas) and I might be able to put that up on my web site as replacement for the applet that browsers have in general refused to run in recent years". Applets are deader than dead, so I need a new approach to make JVic run in a browser.

So on Wednesday, I started putting the plan in to action. It began by installing libGDX and its dependencies (the Android SDK, etc). I'm ignoring iOS for now but given that libGDX can generate an iOS app, that might come later when I've got it polished on the Android. On that first night, it was all about the environment setup. By the end of the evening, I had the project files all set up in the eclipse IDE.

Then on Friday I dropped in the JVic source code and started looking over the bits that I would need to convert to the libGDX equivalent. We're obviously talking about things such as the graphics, asset loading, and the keyboard input. The libGDX library provides its own classes for handling these, and if you code to those classes, the app generation for the different platforms will map that to the platform specific equivalents. The JVic code was using the JVM classes for rendering graphics and getting keyboard input. I'll admit that I spent almost all of Friday night reading up on rendering a pixel array using libGDX. It's not particularly straight forward. Under the hood, all of the target platforms are using opengl for the graphics, so its all about sending commands to a GPU in an efficient way. Sending an array of pixels to the GPU on every frame isn't something that opengl is particularly designed for. It's more about trying to get the GPU to do as much as it can for you. I found a lot of people asking the same questions on the Internet, about what the fastest way to send an array of pixels to the GPU using opengl was. LibGDX does hide the opengl calls from you if you don't want to use them directly, but it also gives you easy access to the opengl APIs if you do want to use them. So I'd identified a number of possible solutions but most people seemed to be saying that the things they'd tried were too slow.

I did begin to wonder at that point if libGDX was the right choice. I had a look over the source code of other 8-bit home computer emulators for Android (such as BeebDroid and a couple of Spectrum emulators) and every example I found was using native code for the graphics, and for most of the app. I started thinking that that is what I should be doing. But then I thought "No, this is all about JVic, an emulator written in Java, so I should just give this a go with libGDX (which incidentally does use native code under the hood for a number of things) and see what happens". If it turned out to be too slow then I'd take a look at what I could do about it at that point.

So that was it for Friday's effort. All reading and not much coding.

Saturday night is where it all happened. It didn't take long to convert the keyboard input over to the libGDX equivalent (although for some reason I couldn't find a key mapping for the dollar sign! It just doesn't seem to be there; certainly not obvious if it is) and then the asset loading code (ROMs) followed quickly after. And then I began on the graphics conversion. My Vic chip emulation was already producing an array of RGB values that represented a frame. I'd identified a way that should allow me to send an array of pixels to the GPU. It supposedly wasn't the quickest way of doing it, but seemed to be the simplest, which is all I wanted at the time. I just wanted to see something get rendered. After I'd done the conversion, and it was compiling, I clicked run for the first time and suddenly I had a blinking cursor!

Now, there were a few things wrong with that blinking cursor. There were actually four blinking cursors, appearing at different parts of the screen, and it looked more grayscale that coloured. It was fairly obvious that the RGB pixel data was not in the right format. So I tweaked the format description being used with libGDX and that fixed that problem. I now had the VIC 20 BASIC screen with the flashing cursor, but the border was yellow, and the text was red. Clearly there was still something wrong with the RGB pixel encoding. After a while I figured out the RGBA bytes were in the wrong order. I switched them around a bit and hey presto, it was now rendering the correct colours.

That was getting quite late at night by that point, but I typed in a quick "Hello world" BASIC program, typed in RUN, and it all worked.

I'd been testing it on the "Desktop" platform up to that point, but just before retiring for the night, I thought I'd plug in my Android phone and click the "Run on Android" option. Do you know what? It actually worked. I had the same screen appear on my Android phone with a flashing cursor, and the flashing appears to be at the expected rate. There are several issues with it though. It's only taking up a very tiny part of the screen (I'd say maybe 1/25th of the screen) and I couldn't figure out how to bring up the keyboard. These will be trivial to solve. I was just really glad to see that tiny little VIC screen spring in to life on the phone and thought it was a good time to hit the sack.

Now that I've got that far, I think the next step is to get this in to github. I don't want the JVic source to go the way of the V20 source code. Now that I've posted this post, I'll try to add regular updates over the next few weeks.

Lance
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: JVic libGDX

Post by beamrider »

Very interesting, will be sure to keep tabs on this!

There's already a Vic Emulator on Android, but the UI leaves much to be desired.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

Yeah, I've got that one on my phone, but its certainly not the easiest to use. I really like BeebDroid, the way the screen and keyboard is laid out, how easy it is to load games. I'm going to aim for something like that as far as the UI goes.

I'm pretty much going to ignore the emulation of the VIC 20 itself for a while and focus solely on the usability within Android. I'm going to trust that whatever I was thinking 13 years ago when I wrote the bulk of the Java code for the emulator that I got it roughly right. I'll revisit the emulation once its looking fairly slick on my phone.

Lance
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: JVic libGDX

Post by beamrider »

Indeed Beebdroid has one of the better UIs.

What games would you put onto the quick access list?
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

I haven't thought that far ahead yet. I guess for starters I'd go with the games that I normally test with, the ones that have appealed to me personally since my first days of experimenting with VIC 20 emulation back in 1996. I discovered a lot of new games at that time, just after the Internet became wide spread and I discovered web sites that had almost all the games. I also have my favourites from back in the 80s that I played on the physical machine. I liked Gorf, Rockman, Psycho Shopper, Skramble, Raid on Fort Knox, Galactic Abductor and all of the Scott Adams adventures. Through writing my first emulator, I discovered games like Bongo, Terraguard, Demon Attack, Atlantis, Pharoah's Curse and Perils of Willy that appealed to me. I guess those are my personal favourites. Rockman is probably one of the ones I spent the most time playing.

After I've actually got something that other people can take a look at, I'll most likely ask for suggestions as to what could be in a quick access list.

For those that are interested, I've now created a github repo that I'll push to whenever I've made any progress.

https://github.com/lanceewing/jvic

I haven't made much in the way of progress over the past few days. What I have been doing a lot of is installing as many emulators of other machines on my Android phone to see how they present the keyboard and what they do when you rotate the screen. Some show the keyboard in transparent form over the screen when in landscape mode. Others are completely opaque when in landscape mode. I think I prefer the see through keyboard when in landscape mode as it allows the bottom part of the screen to show through.

Portrait mode presents a problem though. I certainly can't fit the whole VIC 20 keyboard across the bottom and keep its original look. The keys would be far too small. The C64 emulators haven't tried to do this either. What I'm thinking is that given there should be plenty of room underneath the screen when in portrait mode, I might have to render the main QWERTY bit at the bottom and then some of the surrounding keys above that. It's not going to be authentic but it would hopefully be usable. I'd be keen to hear if anyone has any other ideas how that could work.

Obviously in landscape mode, I should be able to show the keyboard in its original layout.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

Yesterday evening when I was searching for VIC 20 keyboard images, I found this online keyboard layout editor:

http://www.keyboard-layout-editor.com/# ... dore-vic20

The cool thing about it is that someone (I assume the author) has added a VIC 20 preset configuration. It looks like it would be perfect as the basis of an emulator's keyboard. The keys are very clear, particularly if you zoom in with the Ctrl key and mouse wheel. It would be even more perfect for use with a JavaScript VIC 20 emulator, as it generates the raw styles, json, and html to be used to generate the keyboard. For my emulator, I'll need to settle for a cropped screen capture of it. I may well do that. I think it looks great.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

I was playing around with this a bit tonight, looking at what this keyboard layout would look like on my phone in both landscape and portrait modes. I think it looks reasonably good for the landscape mode:
landscape_full_keys.png
...but the same thing is clearly not suitable for portrait mode. The keys are just far too small.
portrait_full_keys.png
So I started thinking about what the Beebdroid emulator has done with its keyboard, taking a 5 row keyboard and producing a 6 row keyboard by moving some of the outer keys up and down and around. I used the online keyboard layout editor I'd mentioned earlier to rearrange the keys (this turned out to be really easy) and produced the following for portrait mode:
portrait_pet_keys.png
Reminds me of the PET 2001 keyboard: http://lowendmac.com/wp-content/uploads ... layout.png

:D
User avatar
joshuadenmark
Big Mover
Posts: 1217
Joined: Sat Oct 23, 2010 11:32 am
Location: Fr-Havn, Denmark
Occupation: Service engineer

Re: JVic libGDX

Post by joshuadenmark »

All these looks really good, would love to have this on my Doogee 8)
Kind regards, Peter.
____________________________________________________
In need of a wiki logon - PM me
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: JVic libGDX

Post by beamrider »

Yes, the portrait layout looks good. I would always use in portrait personally.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

Yeah, I prefer the portrait mode as well. The other night I got the mapping between touch events and the keyboard image working in the portrait mode and was trying it out on my phone. My phone has a 5 1/2 inch screen, and even with the adjusted layout, it still feels like the keys are too small.

The touch screen keyboard built in to the phone has bigger keys, with only 10 keys across the width of the screen in portrait mode. I started thinking that that's the way I needed to go, and there is certainly room to spare between the keyboard image and the VIC screen.

So I'm now trialling a further adjusted keyboard layout with only 10 keys across the screen and 7 rows. That gives enough space for the QWERTYUIOP row to fit without breaking that line up, and then everything else just kind of moves up again. It looks like this (had to make the function keys regular size):
portrait_10x7.png
Thoughts on that one? I may end up supporting both layouts for portrait mode and either let the user select one, or make the decision based on the physical size of the device (assuming that information is available somewhere). What I'm thinking is that Android tablets won't have the same problems I'm having trying to hit the keys on my phone.

An issue with this keyboard layout would be related to games that expect certain keys to be located around each other. What I'm thinking is that the more common of these game key layouts would be made available at an increased size, hiding all the other keys. I've seen it done in a number of other emulators on the phone. Beebdroid seems to be programmed to know what particular games need in the way of keys. There would be some way of swiping between the full keyboard, the joystick, and the game keys for the currently loaded game.

In the landscape mode, the joystick option might be the only usable input for games. Having the keyboard, even if it is a reduced set of keys, is going to have to overlay the screen. But for joystick input, I might be able to make use of the black bars to the left and right of the screen, e.g. tap one side and it fires, drag in certain directions on the other side and it moves in that direction. It doesn't even have to be within the black bars. That could simply be a guide. I might code it so that tapping on one half of the screen is fire and dragging on the other is movement and then the user can decide if they want to keep their fingers within the black bars or not.
User avatar
beamrider
Vic 20 Scientist
Posts: 1447
Joined: Sun Oct 17, 2010 2:28 pm
Location: UK

Re: JVic libGDX

Post by beamrider »

Looking good! A suggestion, provide an option to hide the keyboard completely (both orientations) , as for my Nexus tablet, I have one of those physical cover/keyboards which I often use.

Let us know when you have a beta we can play with and we can provide more feedback.
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

Prior to working on the keyboard image approach, I did have it working with keyboard events. This worked fine when running on the desktop, but when running on my phone, using the built in Android soft key keyboard didn't work at all. I initially thought that the events weren't getting as far as the emulator, but I set break points and could see that the events were actually entering the emulator. My current theory is that the key down and up might be happening too quickly and perhaps the VIC doesn't have enough time to poll the keyboard for events. This is an outstanding bug. If it turns out that the duration is too short, then I might need to handle the key input in a different way, perhaps ignoring the key up event and artificially triggering my own key up event 50 ms after the key down, or something along those lines. I still need to prove that it is the down duration that is the issue. It may end up being caused by something else.

The keyboard image shown in my previous post works perfectly fine on my phone, but in that case the emulator is responding directly to touch events rather than key events. Perhaps the time between touch down and up is longer than between the key down and up when using the soft keyboard on my phone. Maybe. Regardless of why, "real" keyboard events is something I need to sort out.

There is currently no way to load a game file, other than for me to add a line of code and redeploy to my phone. So I'll certainly need to provide a way of handling that. Maybe for some quick testing, I might support swiping on the VIC screen to switch to another game from a pre-defined list. Not sure how that would work for a final solution though. A Beebdroid-like pop up list seems like a nice final solution but might take some time to build, given I'm picking up libGDX and Android development as I'm plodding along.

What model Nexus tablet do you have? When you use the physical cover keyboard, is that in landscape or portrait orientation? If it is landscape, then does the tablet automatically adjust the screen size so that the keyboard isn't covering part of what is being rendered to the screen?
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

joshuadenmark wrote:All these looks really good, would love to have this on my Doogee 8)
What model Doogee have you got? How are those things so cheap? I thought I'd struck gold with the Oneplus One but those Doogees look like they're worth having a look at. Might be able to pick up one as a test phone. :)
User avatar
joshuadenmark
Big Mover
Posts: 1217
Joined: Sat Oct 23, 2010 11:32 am
Location: Fr-Havn, Denmark
Occupation: Service engineer

Re: JVic libGDX

Post by joshuadenmark »

I've got the X5 from Ebay, great phone for the price, well worth the money indeed.
Kind regards, Peter.
____________________________________________________
In need of a wiki logon - PM me
lance.ewing
Vic 20 Afficionado
Posts: 413
Joined: Sat Nov 10, 2012 3:19 pm
Website: https://sites.google.com/site/mos6561vic/

Re: JVic libGDX

Post by lance.ewing »

The F5 looks quite nice as well. A bit more expensive than the X5 but still much cheaper than the phone I've got.

I've worked out what is happening with the normal Android virtual keyboard on my phone. I'm not getting the "key down" event coming through when I touch the key. Instead I get both the "key down" and the "key up" coming through when I release the key. There is about 25000 nanoseconds between the two events. The way I'm doing things at the moment, that is too short a time to get picked up by the VIC emulation. The timing between the key down and key up events on my desktop are more like 50 ms. I'll almost certainly need to go down the path of artificially making those Android key events appear to be 50 ms long.
Post Reply