@kas1e

Whoops, I should have checked the thread's dates better.

Varthall

@orgin

I have opened a thread on amiganews.it, asking if anyone there is the uploader, I'll report back.

Varthall

@spotUP
Hi Spot, nice to see you posting here again!

Varthall

@Capehill

Thanks, I'll try to test it this evening. I don't know who put those symbols in the code, I have ported Milky only to OS4. Maybe they are used by the old AROS port, I'll try to ask on the #milkytracker IRC channel if the devs have any idea where they come from. There's a Morphos port too, and only recently a 68k port attempt has been started:

http://www.apollo-core.com/knowledge. ... =3¬e=9105&x=0&z=SfTvzJ
https://github.com/mbeijer/milkytracker-amiga68k

Varthall

In the old Milky compiles you could easily detect what keys were not working by selecting an instrument and pressing all the keys from Q to P, one by one; some of them would not play the note. I have checked in an old revision of the source code, there was a commented out "#define NOT_PC_KB" in src/tracker/sdl/SDL_KeyTranslation.h which needed to be set so that all the keys would work. I see that it has since been removed; if all the keys work as expected (i.e. the Q-P and Z-M rows mimic the white keys on a piano, the 1-0 and A-L the black ones), then no fix is required anymore.

Great to hear that the ASL requester is now working. BTW there are a few #ifdef AMIGA in compression/unlzx.cpp and an #ifdef __AMIGA__ in ppui/osinterface/posix/PPSystem_POSIX.cpp, I wonder if both are already defined in the SDK, alongside __amigaos4__.

Varthall

@Capehill

From memory, some code should be added so that other devices could be accessed apart from the one where Milky is started. Should be trivial, but I have never managed to finish the work due to time constraints. Milky used to compile out of the box as you have noticed, but a few tweaks are required, e.g. there was one define that needed to be set so that all the keys would be recognised, it has to be checked if that define is still required though. Also, at least on my A1XE speed was an issue, it used 100% of my CPU everytime a bigger module (=> 8 tracks) was played, it should be checked how's the CPU usage now.

Varthall

Hi,

that is strange, I have successfully used that compiler under Cygwin some time ago, on a Windows 7 machine, at least the GCC 4.4.3 worked. AFAIR you need to use the 32bit version of Cygwin, since gcc has been built for i686 and not for x86_64 CPUs.

Varthall

@SpotUP

Damn... pretty sad to hear that. Hope that you'll return in the future :(

@ChrisH

Ah, pity then. I loved this game as well, very playable, though I never finished it.

@spotUP
Do you still have that bugfixed version?

Varthall

@xenic

The port of the original version had a bug which prevented the game to be completed. The bug was found, with the help of the original author, and I believe that a new, fixed version for OS4 was released by Spot which was 100% playable. I hope that the version uploaded on the tribute site is the latter one... Here's a thread about that bug: http://amigaworld.net/modules/news/ar ... php?storyid=4422&start=20

I have checked on SF if my old account is still valid, seems it is not, although my username seems to be still stored in their users' database (I'm unable to create a new account with the same username). Since I registered it using an email address which is now not valid anymore, I had to send a message to the support service to manually reactivate it.

@LiveForIt

Thanks for the heads up, I guess SF.net is the way to go for MPlayer, too. I like that they will automatically import all the tickets, wikis and downloads, too.

@ggw

Thanks for your offer! I'll maker again a try, if I won't succeed I'll gladly pass the port to you, I'll let you know. Pity about your effort on tcl, I personally wouldn't even dare to port such a beast :)

Varthall

Hi,

I'm alive, but I have barely any free time to use my AmigaOne at home (I have two small children). I will try again to work on it these days, but I believe that someone other might be better suited for this work. And no, thanks for the bounty idea, but it's time that I'm missing, not motivation :)

@pseudaxos

Yes, that's what I'm working on now.

I hope this time to make it :) A second beta with just a minor bugfix for a start, the keyboard should work correctly now:

https://docs.google.com/uc?export=down ... qDqDmouu0zZl9tU0otSHY5cjQ

Regarding the octave down/up issue, are you using the note transposing or is this related to the keyboard issue too?

Please let me know of any other issue (except for the AmigaOS devices change in the requesters and the general GUI slugginess).

Varthall

@K-L
Quote:

I used to be that when I was a little boy, at least according to my parents :)

Varthall

A small update from me. As you have seen, I have created a test repository on Google Code and mirrored all the code there, so that I can do a test merge of the latest MPlayer code without the fear of messing up the main repository. Once I'll finish the merge I'd keep this project open in case anyone would like to do some tests there.

I have first tried to mirror the main repository using svnsync, but I had problems in finding a way to do it from a repository to another, all the info I have found expect to first dump the whole source repository in a local file, a feature not implemented in Google Code. I have therefore done all the commits manually.

Now I'm trying to use the svn_load_dirs script to merge the old official sources with the latest ones. The script complains about some files being of different types between the two revisions, I believe this is because SVN converts all the soft links to text files containing the link's path, in order to be compatible with Windows' systems. A solution might be to commit again the old revision of the original sources and forcing the use of Linux' links.

Varthall

@samo79

Quote:
That's what the SVN's for :) time to merge all the stuff and release betas there... I'll reply to all later.

VArthall

@samo79
Quote:
No need to, I'm closely following this thread, and I have sent a PM to joerg :)

@joerg
Thanks for your work, I'm looking forward for your contribution, especially to update the ancient SVN mplayer revision to the latest one. I'd like to do a "vendor branching" as described here:

http://svnbook.red-bean.com/en/1.1/ch07s05.html

In a nutshell:
- Import the SVN revision you have worked on in a new directory under "branches/", merge the changes between the old and new official Mplayer in "branches/official" (which contains the old official r32634 version imported by abalaban), then finally merge the differences between the two versions in our trunk.

At this point, you should be able to import your updated PIP driver to the trunk. What I'd need to know is what is the SVN revision of svn.mplayerhq.hu you have worked on.

What I worry is if all the current versions of the VO drivers will have to be updated to work with the latest MPlayer sources, we'll see.

Varthall