Latest LCDGameModes

[JonAbbott]

Is the latest binary / source on the dev FTP site?

Whilst testing AutoVIDC, I noticed Pesky Mustrats (which is broken by the latest ADFFS incidentally) has an extra line (possibly 2) at the bottom of the screen, it's not there with monitortype 0, so I want to see if its due to the version of LCDgm I'm running. I don't believe it's an issue, I'm just curious.

[JonAbbott]

I'll take that as a no then

Steve - if you can upload the latest source to the dev site, I'll merge it in for you. From the last source I looked at, the only things that need changing are *LCDgm to *LCDGameModes in ADFFS and some splitting of the module init code from memory, so we can import the required bits into ADFFS and leave the rest for the stand-alone module.

[steve3000]

Sorry missed this thread. I'll look into pesky misuse at the weekend...

I now have the Risc PC and R Pi connected to the Internet, so uploading shouldn't be a problem...just need to find time...

As for LCDgm splitting out the init code and amalgamating with ADFFS - sure, shouldn't be a problem. One q - What happens if user has a later version of LCDgm loaded, then runs ADFFS? Is the ADFFS version loaded over the version in memory? Do they both remain in memory or does the later version remain?

Steve

[JonAbbott]

I believe the later module wins, if they're using the same *command.

We'll have to keep the two separate, adding a RMKILL to the !Run of ADFFS is the simplest method.

[JonAbbott]

Would it not be more sensible, as its already been released separately, to strip LCDGameModes out of ADFFS and just bundle it as we're doing with AutoVIDC?

Are we going to lose any functionality by doing that? Will it affect any future VIDC translation etc? I suppose we could cover any potential integration by registering an SWI block in the future, should we need tight integration.

The obvious advantage is that we can release them independently and just ensure ADFFS releases have the latest version.

[steve3000]

Would it not be more sensible, as its already been released separately, to strip LCDGameModes out of ADFFS and just bundle it as we're doing with AutoVIDC?

Are we going to lose any functionality by doing that? Will it affect any future VIDC translation etc? I suppose we could cover any potential integration by registering an SWI block in the future, should we need tight integration.

The obvious advantage is that we can release them independently and just ensure ADFFS releases have the latest version.

Humm, I had been thinking about this over the past week or so - perhaps it is the best way to go?

Reasons to combine the two are to minimise duplication and maximise integration. I'd really like to avoid duplication where possible - right now there isn't any duplication - but if I add a VSync frame-reducer to LCDgm, that would be duplication, but TBH it's easy and it isn't much code, so really that's not a big problem.

For integration, this could still work with the two kept separate. For example, real time VIDC translation won't be part of LCDgm - that would be too specialised and it would sit much better in ADFFS. However, LCDgm could work happily side-by-side with VIDC translation...Even allowing LCDgm's patch commands to be translated in real time...?

Steve

[JonAbbott]

I'll strip it out for the time being then, we can always add it back later should duplication become an issue.

As with AutoVIDC, we'll bundle it and load in the !Run with a version check.

[steve3000]

Ok Jon, that's fine.

Can you just make sure it is the current release version of the module - as available on Paul's website v0.21b.

EDIT: just checked and it is