freesci-develop
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [freesci-develop] Win32 Glutton patch


From: Christoph Reichenbach
Subject: Re: [freesci-develop] Win32 Glutton patch
Date: Fri, 25 Jan 2008 14:50:15 -0700
User-agent: Mutt/1.5.13 (2006-08-11)

Alex,

On Fri, Jan 25, 2008 at 08:40:49PM -0000, Alex Angas wrote:
> I've just sent Christoph a patch to allow building of Glutton from Visual
> Studio! I've only tested LSL3 with it which seems to work just with a few
> graphics oddities. Sound is fantastic and I didn't notice any bad
> performance at all! Thank you _so much_ for all the work put into this. A
> few notes:

  I'm glad to hear that we finally have a grip on sound on Win32!  The
graphics oddities are likely to be general issues.  Thank you very
much for the patch-- I will apply it ASAP (probably early on saturday).

> - In src/menu/game_select_screen.c I replaced snprintf with vsnprintf
> because snprintf doesn't exist under Win32. Unfortunately I didn't have time
> to test it so this may be broken now.

  That's fine.  This part of the code will hopefully be replaced
pretty soon anyway (-> new config subsystem), assuming that I can get
off my lazy behind...

> - In stable we used to have the keyboard constants listed below defined. Are
> they going to be implemented in glutton or are they no longer relevant?
> SCI_K_PLUS
> SCI_K_EQUALS
> SCI_K_MINUS
> SCI_K_MINUS
> SCI_K_MULTIPLY
> SCI_K_DIVIDE

  These constants used to map directly to ASCII characters, so we
removed them.  Just use '*', '/' etc. directly.

> - I no longer have Visual Studio 6 (which may be used by people building on
> Windows 9x), so those project files won't work.

  OK.  This should go into the next batch of release nodes.  (Not sure
how many people still use Windows 9x.)

> - I turned off most of the checking of memory allocations on the Visual
> Studio build because there were a lot of errors being reported and it kept
> breaking into the debugger. Are solving these a higher priority than the
> DirectX driver, or does more dev work need to be done to make this
> worthwhile?

  Both are important, for different client groups.  Can you give me a
hint as to where you're getting those errors?  If they look easy to
you, feel free to try and patch them, otherwise I'd suggest that you
send me a stack trace (or paste it into the bug tracker) and focus on
the DirectX driver.

  Again, thank you very much!

-- Christoph




reply via email to

[Prev in Thread] Current Thread [Next in Thread]