Mod Archive Forums Mod Archive Forums
Advanced search  

News:

Please note: Your main modarchive.org account will not work here, you must create a forum account to post on the forums.

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - shai

Pages: [1]
1
MilkyTracker Community / Re: MilkyTracker ported to OS/2
« on: September 08, 2008, 11:31:54 »
ok,
I could simply commit them, too. But I don't have the permissions with anonymous access, have I? I'll simply send you the two files, should be sufficient as you're still working on the build system...

2
MilkyTracker Community / Re: MilkyTracker ported to OS/2
« on: September 08, 2008, 10:52:38 »
Hi,
the drive/directory sorting works now. Don't ask me why. Maybe it was just that I didn't rebuild enough files because the autogenerated Makefiles don't include all dependencies. After initial problems - a DLL hook caused problems and you need the "swap" option - MilkyTracker works fine on my Medion Akoya (rebranded MSI Wind), too. Have a look at the attachments. MilkyTracker (trunk version) running on eComStation (OS/2 Warp 4.52) on a Medion Akoya Mini :).

cheers,
Robin

ps: This is a Mac-OS-inspired theme only. OS/2 has nothing to do with Mac OS X.

3
MilkyTracker Community / Re: MilkyTracker ported to OS/2
« on: August 29, 2008, 01:46:55 »
Hi shai,

Congratulations on the port.  I'll try to address some of the issues you experienced:

"it requires SDL- and ALSA-check m4 macros (sdl.m4 and alsa.m4)"
These are included in the source distribution archive, they are purposel omitted from the svn repository (anything that is autogenerated isn't stored on the svn).
Couldn't find them in the latest source archive (v.0.90.80). They should be there, somewhere, expanded to shell script in 'configure' however. Also, I think they aren't generated (at least they state copyright/authorship at their beginnings).
Quote
"use macros to check for libzzip and remove it from the source archive (you probably know that as you already hardcoded in the automake files to link the binary against libzzip and don't use the internal version anymore)."
Again, this is on the svn development trunk only - it will be altered when the next version is released. Pailes is reluctant to remove it from the source archive at present due to various reasons.  It's worth pointing out that the automake build system is currently only used for the SDL version, OSX and Windows go there own way.
Yes, sorry. I know that most of the stuff I mentioned is trunk-only and that you already know about it.
Quote
"you should really check whether SDL supports OpenGL in configure.in"
Development version only.. The opengl support was just a test, and will probably be dropped altogether as it offered no advantages.

"Usually one has to add SDLCALL macros for SDL callbacks and you have to take care of atexit(SDL_Quit)-like statements because the SDL library calling convention (OS/2 syscall) differs from the C calling convention. Nevertheless it compiled and worked fine without it which even surprised me."
Are you sure? I had already made those changes to the trunk before you downloaded it.
Yes, the first version I checked out (and which was still up to date when I built it) didn't have the changes - I recall that I looked it up. It was introduced with a later changeset.
Quote
Regarding the mouse pointer flicker, blame SDL - it must not be using the hardware pointer, you'd be better patching SDL to fix this rather than writing a workaround specific to Milkytracker.
You are right.
Quote
Posix or native path handling? You decide! Native might be better.
The performance difference should be insignificant (although it is one layer above the bare OS/2 API, yes...). It's just that you have a lot of "#ifdef __OS2__"s in your otherwise posix-only code. I would prefer it because using more platform-independent APIs means less code to maintain and less for me to write in the first place!
Quote
I prefer Milkytracker's internal filebrowser/message box rather than the OS provided ones. Makes it feel more integrated. :)
I agree and I probably won't spend an effort until I know that I want to stay with MilkyTracker.

cheers,
Robin

4
MilkyTracker Community / MilkyTracker ported to OS/2
« on: August 28, 2008, 13:09:50 »
Hi,
I've ported MilkyTracker to OS/2 Warp (includes eComStation).
Compiling the SVN trunk version took me some time because I had to set up a whole new build environment and update a lot of stuff (you know, autotools have to be installed properly...). But otherwise the posix/SDL version compiled more or less out of the box.
However, I noticed the following issues with the build system:
  • it requires SDL- and ALSA-check m4 macros (sdl.m4 and alsa.m4). you don't have them if you didn't install ALSA and SDL properly. For instance, of course I don't have ALSA and my SDL build is Open-Watcom-optimized and doesn't include stuff like m4 macros. I had to download the source distros to get the macros. They should be included in the MilkyTracker source archive.
  • use macros to check for libzzip and remove it from the source archive (you probably know that as you already hardcoded in the automake files to link the binary against libzzip and don't use the internal version anymore).
  • you should really check whether SDL supports OpenGL in configure.in (you already know that). also it should be a site-configuration in case anybody wants to turn it off even if it's available. I had to manually remove the OpenGL-related stuff from the automake files because SDL for OS/2 doesn't support it. even if it would, it'd be incredibly slow because OpenGL is software-only on OS/2 (for now).
  • already fixed by the developers: add FileExtProvider.cpp to milkytracker_SOURCES

There were no other adaptions necessary. I know I've told something different in the IRC channel. Usually one has to add SDLCALL macros for SDL callbacks and you have to take care of atexit(SDL_Quit)-like statements because the SDL library calling convention (OS/2 syscall) differs from the C calling convention. Nevertheless it compiled and worked fine without it which even surprised me. Only explanation: GCC on OS/2 uses the syscall calling convention, too. I usually work with Open Watcom C on OS/2 and you have to care about the calling conventions there. So the change (you already committed it to the trunk) wasn't really necessary. It doesn't hurt though - and it might become necessary on other platforms/compiler/libsdl combinations.
Also, the crash-on-startup issue I've talked about in IRC is gone in the trunk version. Nice. Dialogue windows are movable, too... :)

The following OS/2-specific issues remain:
  • You've got drives on OS/2 just like you have in Windows. The posix path handling stuff doesn't care about it of course (PPPath_POSIX class) so I added OS/2 API specific code similar to what's done in PPPath_WIN32 to iterate drives. This is not a complete OS/2 specific PPPath implementation but I just extended the posix class. The drives are still not before all the other directories in the file browser. I'm working on this. If you don't like the embedded OS/2 code it would be possible of course to write a separate OS/2 specific PPPath (could do everything with the OS/2 API then).
  • Mouse pointer flickers when something moves behind it. Sometimes it leaves graphical glitches. Sometimes it disappears when I switch to fullscreen mode. I'm working on this. Maybe I will implement an OS/2 specific workaround (let the OS do the pointer handling instead of SDL - I never have such issues with other DIVE-based multimedia apps which let the OS handle the pointers).
I could of course implement native OS/2 filebrowser and message box support, too. But as I would almost consider this a misfeature I'd like to request a new MilkyTracker feature: Add an option which lets the user choose whether native dialogues should be used at all. If not fallback to the dialogues enabled in the SDL version. The "internal browser" option would be independent. If activated the "internal" browser would be used always.

Hope, I get the time to actually use the program one day :)

ps: screenshots coming soon

cheers,
Robin

Pages: [1]