April 2010 - Wine-Devel - list.winehq.org

Re: [PATCH 4/4] Add a blit method to arbfp_blit.

by Henri Verbeet

On 1 April 2010 12:50, Roderick Colenbrander <thunderbird2k(a)gmail.com> wrote: > - if (is_identity_fixup(src_format_desc->color_fixup)) > - { > - TRACE("[OK]\n"); > - return TRUE; > - } > - When did we stop supporting those? > + arbfp_blit.set_shader((IWineD3DDevice *)device, src_surface->resource.format_desc, > + src_surface->texture_target, src_surface->pow2Width, src_surface->pow2Height); You might as well call arbfp_blit_set() directly.

April 1, 2010

Re: Working on "DOS" VGA.

by Roderick Colenbrander

On Thu, Apr 1, 2010 at 10:17 AM, Morten Rønne <morten.roenne(a)tdcadsl.dk> wrote: > Hi Wine-devel > > My name is Morten and I would like for some of my old DOS/WIN95 games to > work with wine. :) > > I know that I most likely could solve this by using DOSbox and/or DOSemu. > But I don't consider either of them user friendly in it's raw form. > And I hope in the future it could be more of a Go to this menu item, click a > few choices and then play game thing. > > So I have been looking into what one of them is needing (XCOM Apocalypse). > > The first thing that needs work is the VGA screen driver. The game needs one > of the unsupported video modes. > After looking further into it, I can see that the current screen driver, > needs to be more of an emulator than just a copy of the framebuffer/RAM > window to/from the DirectDraw surface. > > But since I need to do a lot rewrite of the code, to get a emulator into > things, I would of course like to test all the stuff that I don't touch (in > term of videomodes). But there isn't a test catalog in dlls/krnl386.exe16. > That could of course be due to the fact that it is pretty hard to write test > for that old platform and get proper test on a live version. > Or am I missing something here? > > Looking over the list of videomodes, I can see that a lot of them says > supported. > Is that really true or do they simply not break? > Again is there anyway to test that those modes are truely supported in my > code change (and in the current code)? > > Another problem that I am facing at a later stage is that most of the games > needs to be installed in win95 mode. > But I think that most people will run with something like XP, Vista or Win7 > as default mode. > That will break most of the old installers as DOS version becomes 5.0 or > something "silly" like that. > So I am thinking about having to create a wrapper program where you can > install your old programs through so the mode gets set correctly during > install. And perhaps also creates some proper shortcuts in the menu. > And perhaps even into the new game database that new windows version have. > And thoughts/ideas on this? > > Another way to handle this would be to do something like a MD5 on the > install.exe (hoping that they differ) and then look up in the AppDB, to see > which mode to use as installer mode (and run mode). Yes, that would most > likely require changes to AppDB. But I can see a use for this even for the > above wrapper program (Autodetect using AppDB). > > Once I get a new VGA "driver" running, I will most likely start looking into > INT10h and others that try to interface to the VGA "driver". > > Best Regards > Morten Rønne > Hi Morten, First of all welcome to Wine. Myself I'm a bit worried about whether we should improve our DOS support even further. The problem is that more and more people are moving over to 64-bit Linux. While you can run 32-bit programs on a 64-bit system, there is no protected mode support (vm86; there is emulation in some cases using a kernel module). I don't know all the details about what works and not but I fear the 64-bit move makes DOS support in Wine not that useful these days but I might be wrong. Roderick

April 1, 2010

Working on "DOS" VGA.

by Morten Rønne

Hi Wine-devel My name is Morten and I would like for some of my old DOS/WIN95 games to work with wine. :) I know that I most likely could solve this by using DOSbox and/or DOSemu. But I don't consider either of them user friendly in it's raw form. And I hope in the future it could be more of a Go to this menu item, click a few choices and then play game thing. So I have been looking into what one of them is needing (XCOM Apocalypse). The first thing that needs work is the VGA screen driver. The game needs one of the unsupported video modes. After looking further into it, I can see that the current screen driver, needs to be more of an emulator than just a copy of the framebuffer/RAM window to/from the DirectDraw surface. But since I need to do a lot rewrite of the code, to get a emulator into things, I would of course like to test all the stuff that I don't touch (in term of videomodes). But there isn't a test catalog in dlls/krnl386.exe16. That could of course be due to the fact that it is pretty hard to write test for that old platform and get proper test on a live version. Or am I missing something here? Looking over the list of videomodes, I can see that a lot of them says supported. Is that really true or do they simply not break? Again is there anyway to test that those modes are truely supported in my code change (and in the current code)? Another problem that I am facing at a later stage is that most of the games needs to be installed in win95 mode. But I think that most people will run with something like XP, Vista or Win7 as default mode. That will break most of the old installers as DOS version becomes 5.0 or something "silly" like that. So I am thinking about having to create a wrapper program where you can install your old programs through so the mode gets set correctly during install. And perhaps also creates some proper shortcuts in the menu. And perhaps even into the new game database that new windows version have. And thoughts/ideas on this? Another way to handle this would be to do something like a MD5 on the install.exe (hoping that they differ) and then look up in the AppDB, to see which mode to use as installer mode (and run mode). Yes, that would most likely require changes to AppDB. But I can see a use for this even for the above wrapper program (Autodetect using AppDB). Once I get a new VGA "driver" running, I will most likely start looking into INT10h and others that try to interface to the VGA "driver". Best Regards Morten Rønne

April 1, 2010

Re: GSoC - keyboard input

by wylda＠volny.cz

----- PŮVODNÍ ZPRÁVA ----- Od: "Marcus Meissner" <marcus(a)jet.franken.de> Komu: wylda(a)volny.cz Předmět: Re: GSoC - keyboard input Datum: 1.4.2010 - 9:08:48 > On Wed, Mar 31, 2010 at 01:28:23PM +0200, wylda(a)volny.cz > wrote: > > Hi guys, > > > > if it is not too late, i would have a proposal for > > GSoC. I'm waiting > > > quite long for "BuildActionMap, SetActionMap, EnumDevicesBySemantics > > > > > > & co", i.e. to make games like need for speed happy/playable > > (bug 8754). > > > > > Thanks for reading, > > This would be welcome, I have had "DirectInput - Implement > missing > DirectInput8 features" in the ideas list for two years > now ;) > > http://wiki.winehq.org/SummerOfCode#head-d015ad97692f9f4d3431c3d739cc5dccf0… > > > Ciao, Marcus Hi Vitaliy & Marcus, this is unfortunately misunderstanding. I'm bit old for being a student although i remember for university studies with love... So i could not even qualify for GSoC and also my coding skills are pretty bad (probably none, in front of yours). The initial email was meant as proposal, if there would be volunteer who do not know what to do or his ideas were too high for GSoC, so some of the mentor could him offer this "DirectInput job". Sorry for noise - i was not aware, that there is a page http://wiki.winehq.org/SummerOfCode which has all the needed "jobs". W.

April 1, 2010

Re: Another proposal for your critique: improving .NET 3.5

by Hans Leidekker

On Thursday 01 April 2010 06:15:41 John Koelndorfer wrote: > DESCRIPTION > In Wine daily (as of 3/31/2010) .NET fails to install. The Wine debugging > output is riddled with stubs and fixmes. My initial work would be to examine > which functions are needed by the installer and prioritize work on them. > Priority would be given to blockers, obviously. Much of the work to be done > seems to be in advapi and msi; I would work with more experienced developers > in those areas to push patches through. I would expect this to take perhaps > six weeks of time, though it is hard to say since it depends largely on what > functions need to be implemented and how difficult implementation would be. This is not something within GSOC scope in my opinion, I expect you will need 6 weeks alone to get up to speed with the concepts of msi and patching. In general I think it's better to identify a small set of APIs to implement or improve instead of aiming for a broad goal like "improving .net 3.5", which is hard to quantify and more likely to fail. -Hans

April 1, 2010

Re: GSoC - keyboard input

by Marcus Meissner

On Wed, Mar 31, 2010 at 01:28:23PM +0200, wylda(a)volny.cz wrote: > Hi guys, > > if it is not too late, i would have a proposal for GSoC. I'm waiting > quite long for "BuildActionMap, SetActionMap, EnumDevicesBySemantics > & co", i.e. to make games like need for speed happy/playable (bug 8754). > > Thanks for reading, This would be welcome, I have had "DirectInput - Implement missing DirectInput8 features" in the ideas list for two years now ;) http://wiki.winehq.org/SummerOfCode#head-d015ad97692f9f4d3431c3d739cc5dccf0… Ciao, Marcus

April 1, 2010

Re: [PATCH 4/5] mmdevapi: Add dependency on openal

by Maarten Lankhorst

Hi Chris, 2010/4/1 Chris Robinson <chris.kcat(a)gmail.com>: > On Wednesday 31 March 2010 2:00:57 pm Maarten Lankhorst wrote: >> + local_contexts = palcIsExtensionPresent(NULL, > "ALC_EXTX_thread_local_context"); > > Missed a spot? Don't forget to use the correct function names for the > completed extension, too. Woeps, no wonder it wasn't complaining. I'll resubmit. Cheers, Maarten

April 1, 2010

Re: [PATCH 4/5] mmdevapi: Add dependency on openal

by Chris Robinson

On Wednesday 31 March 2010 2:00:57 pm Maarten Lankhorst wrote: > + local_contexts = palcIsExtensionPresent(NULL, "ALC_EXTX_thread_local_context"); Missed a spot? Don't forget to use the correct function names for the completed extension, too.

April 1, 2010

Another proposal for your critique: improving .NET 3.5

by John Koelndorfer

Wine-devel, Still looking at my options for summer projects and I thought this might be a good one that would work towards my goal of improving gaming for folks. As always, comments and critiques are very appreciated. I would request that, in addition to commenting on the general idea, that people also comment on the actual proposal. Does it look/sound good enough to be accepted? I fancy myself a fairly good writer but writing a proposal is still pretty new to me. :-) Thanks! John

April 1, 2010

Re: GSoC - keyboard input

by Vitaliy Margolen

On 03/31/2010 05:28 AM, wylda(a)volny.cz wrote: > Hi guys, > > if it is not too late, i would have a proposal for GSoC. I'm waiting > quite long for "BuildActionMap, SetActionMap, EnumDevicesBySemantics > & co", i.e. to make games like need for speed happy/playable (bug 8754). If you want to work on that it sure is more then duable. Only it would need to be everything, including joystick, not just keyboard/mouse. Keyboard/mouse is about one week worth of work tops. Vitaliy.

April 1, 2010