Shamus

You sir, are truly a madman.

Bug reports for RMAC/RLN are always welcome, especially if they come with good detail and a small snippet of code that demonstrates the bug.

Hmm, I suppose I should get around to compiling that thing.

That would be fine except for the fact that 1) rotary control on Impulse X is a joke, 2) collision detection in Impulse X is a joke, and 3) Impulse X is expensive. Other than that, yeah, completely agree!

OK, fixed the spurious "undefined register equate" error. New version of RMAC (1.3.2) is up at the usual place. Now just have to deal with the vbcc compiler errors now.

Doesn't work if you don't have Google Drive, but I found a workaround. Getting back on topic, it looks like you've found another bug in RMAC. Shouldn't be too difficult to fix.

Could you post a zip file of this on your Google Drive? I really don't have time to go and click on every file in there to save them one by one. Thanks!

Fixed the aforementioned bug with the -l switch. New version of RMAC (1.3.1) can be found in the usual place.

Which sources are these? Can't tell a gosh darned thing without them.

AFAIK RMAC outputs BSD style .o objects. But it can probably be easily modified to support others as well. Also found a bug in RMAC when using the -l switch: If you assemble GPU code with that switch it causes RMAC to barf on "OR" opcodes (I suspect it may cause similar/worse effects on other platforms; YMMV).

I should also add that I was able to successfully build Tube SE with RMAC/RLN without any problems; not sure why you can't.

You must have been using an old version. RMAC has been 64-bit clean for well over a year now. If SMAC works on a 64-bit platform, it's more a case of pure luck than anything else, as it stuffs pointers into the token stream.

RMAC is 64-bit clean. BTW, RMAC is being actively developed and bugfixed, maybe you should give it a try.

In the case of Rick Dangerous, which is a 4MB cart, it's because it wouldn't fit into the Jaguar's RAM, which is only 2MB. Generally speaking, something that is written for the Jaguar's ROM space can't be trivially converted to run from RAM.

Yes, it really needs Qt5 since we (and the Qt developers) are leaving Qt4 behind. I've already converted all of my projects over to Qt5, and it was really easy--especially when compared to the clusterf**k that was the Qt3 to Qt4 conversion. It's a bit of a shame that GLES isn't just a one-line change in the .pro file, but it isn't a disaster. It would be fairly simple to add a GLES renderer in the GUI and some #defines to control compilation. I do have a RPi kicking around, so maybe I'll have a chance to do some testing there. If you (or anyone!) want to write a patch to support GLES, feel free, and I'll make sure it gets supported by VJ.

Well, the doco is slightly out-of-date. If you're building from GIT sources, you will need Qt5 as you discovered. I don't know if Qt supports GLES; I would be quite surprised if it didn't as it's meant to work on tablets and phones now. Virtual Jaguar's use of OpenGL is quite minimal and I would suspect that supporting GLES would require nothing more than fixing some definitions inside the virtualjaguar.pro file. If I get a chance I'll look into it to see what's required.

RLN now supports .a archives with lazy linking as of v1.3.1. Library paths can be set by exporting RLNPATH. Check the usual place to get a copy.

Second try, got killed by the second jet fighter's bomb. I know it's too late for this round, but oh well. It probably wouldn't be too difficult to bodge in joystick support; it's just a matter of finding where the paddle reading code is and patching it.

Err, the score is displayed in the square box that the gun sits on.

I seriously doubt anyone has asked him; it would be worth a shot though. And serious kudos to you for going after primary sources yourself, that's something that's almost unheard in this day and age. Mad, mad props.

Bleh. More bluster with absolutely nothing to back it up. Color me surprised.

It could probably be arranged, but with 3 CPUs + OP + blitter, it's going to be a bit complex. Right now there's a fair bit of hooks in the 68K emulation already (including a backtrace buffer), but there needs to be some put in for the RISCs as well. All doable, just need a hunk of time to devote to it.

Guys like you are a dying breed--thank God.

Software that is meant to be run from the Jaguar's RAM most likely won't work when attempted to run from ROM (the Skunk's flash memory), and vice-versa. There are tools to convert Jaguar files, like Jiffi; you might want to give that a try if you want to convert a file from one to the other. That said, you still can't really rely on file extensions to tell you what's in a Jaguar file; unfortunately things are still muddy in that respect. Not for lack of trying!

Thanks to ggn and SCPCD, some fatal crash bugs were found and eliminated. If you were having trouble with 2.1.1, give 2.1.2 a try and see if that fixes things for you. Downloads to be had from the usual place.