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.

Topics - shai

Pages: [1]
1
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]