> From: Ralph Versteegen <[email protected]> > Sent: Friday, November 12, 2010 6:27 AM > > On 12 November 2010 09:06, Jay Tennant <[email protected]> wrote: > >> From: Ralph Versteegen <[email protected]> > >> Sent: Tuesday, November 09, 2010 4:52 AM > >> > >> On 9 November 2010 07:25, Jay Tennant <[email protected]> > >> wrote: > >> > Are there any suggestions for gfx_directx? I know a few > >> > things that semi-annoy me, and I'm sure must annoy others. > >> > Maybe some features could be developed a little more? > >> > > >> > I'd like the sleep mode crash to be resolved. I'm > >> > starting to research how to use the Window's system > >> > message WM_POWERBROADCAST to determine when to release > >> > directx resources, and then when to reallocate them upon > >> > resuming. > > > > I almost have this worked out. At least, it's not crashing anymore, > > but I think it's impossible to fix fully (related to next bug). > > > > To pseudo-fix the this bug, I think I'll just include a > > "Backend Reset" button inside the options. It'll only reset > > the d3d and d3ddevice objects. > > > >> > I'd like the hotswapping-of-displays crashes to be > >> > resolved. > > > > This seems to be impossible to detect. I've searched all over > > the docs and the internet, but I only found that Windows > > does not send notifications about monitor connection state. It > > seems to "know" about it, but will not raise an event for the > > rest of the system. > > > > http://social.msdn.microsoft.com/Forums/en/etw/thread/01373322-30ea-4abc-b7ca-0e698febe39d > > > > Maybe by checking for connected monitors once every 3 seconds? > > > >> > I'd like the "Refresh Joysticks" option to refresh > >> > automatically upon plugging in or unplugging a joystick > >> > device. > > > > Haven't started, but I'll be using the WM_DEVICECHANGE > > message to refresh the connected controllers. > > > >> > The joysticks to have a configuration menu. > > > > That'll be the last thing I do. > > > >> > The settings to be saved between sessions, such as > >> > setting screenshot format, resolution, joystick config, > >> > checked settings, etc. > >> > >> OK, OK, time to look into preference files. > > > > Oh, I forgot about that. I was thinking of preferences saved > > as a resource in the dll. But an outside file would be easily > > configurable. I don't think all backends should access the > > same config file, though. Some resolutions for gfx_directx > > won't work right in gfx_sdl, etc. > > Yes, I agree that each backend should have its own set of options.
I can easily add support for this, but what set of options will take precedence? The preference file or the command line options? Also, if the preference file is not present, one will be generated. > > Because there aren't any major configurations, though, storing > > as a resource might be a little cleaner. If one wants to start > > the backend in "safe mode", perhaps an extra param could be sent > > through the v2 interface gfx_Initialize (that is, whenever we > > switch over...) > > > >> > The io_setmouse() to move the mouse to the correct > >> > screen location (it's off by a pixel, I think. You can > >> > see it when in the tile editor, and pressing the > >> > keyboard arrows in any direction. The mouse doesn't quite > >> > reach the right interval.) > > > > I'll attack this before other major changes. > > > >> The only thing that annoys me (I haven't encountered any other > >> problems) is that fast keypresses are lost. Switching to io_keybits is > >> actually a pretty tiny amount of work. Do something like the > >> following: > >> > >> On keydown, change > >> m_scancodes[ c_vk2fb[wParam] ] = 0x8; > >> to > >> m_scancodes[ c_vk2fb[wParam] ] = 0x7; > >> > >> On keyup change > >> m_scancodes[ c_vk2fb[wParam] ] = 0x0; > >> to > >> m_scancodes[ c_vk2fb[wParam] ] &= 0x6; > >> > >> And during a call to io_keybits, do > >> m_scancodes[i] &= 0x1; > >> for each i. > > > > I noticed that my xp box runs dramatically slower for this engine > > than win 7. I now know what you mean by fast keypresses lost. > > (I didn't really notice them until I sat down to test on xp. It > > runs at about 2/3 the framerate! Still fully usable, but so much > > slower.) > > Huh? What framerate does it run at? I thought that gfx_directx only > refreshes the display and processes input when gfx_setpage is called? > Surely almost any computer on which someone installed XP is capable of > running the OHR at 18 fps? It's only the menus which run at 18 fps on > which I see lost key presses. It seems to run at that rate. I guess my win7 box just runs the engine much faster. I like it much faster--seems more responsive. > > I'll get to this in a bit. > > > >> Also, I notice that the +/= key doesn't work. > > > > Ah, I fixed this. It was working, but I wrote it as a scancode > > SC_PLUS. The win docs were a bit confusing: > > http://msdn.microsoft.com/en-us/library/dd375731%28v=VS.85%29.aspx > > " > > VK_OEM_PLUS (0xBB) > > Windows 2000/XP: For any country/region, the '+' key > > " > > > > That key was actually the '+ =' key for us keyboards. > > > > I noticed the engine actually doesn't support the SC_PLUS and > > SC_MULITPLY codes for text input. Can somebody fix this? > > I assume you meant scNumpadPlus and scNumpadAsterix. Yes, I noticed > that (and already fixed in my local copy): for some reason, the > ancient scancode-to-ascii lookup table we had only went up to scancode > 53. Ah, yes. That's the one. I currently use gfx_directx\fb_scancodes.h as the scancode listing. Is there a different one I should use? > >> Also, I'm going to deviate from FB's scancodes, adding scancodes for > >> the missing keys (numpad / ?) gfx_fb won't support them, but all > >> others can. I noticed that gfx_directx is the only backend which > >> supports typing with the numpad! > > > > Oh. I've treated all numpad keys as extensions of the rest of the > > keyboard, so they're just duplications of either the number keys or > > arrow/navigation keys, depending on whether NumLock is pressed or not. > > Windows does differentiate between the keys, so that'll be easy to fix. > > > > When you designate those codes, we'll add support. > > I'm not totally sure how we should treat the numpad, specially numlock. > > The plan: I'd like to change the scancodes for the numpad keys to be > distinct from the scancodes for the arrows, home, insert, etc. keys. > (At the same time, we can fix the numlock/pause and > printscreen/numpadAsterix double ups.) scancodes.bi and scancode.hsi > (constants for scripts) would both get the same treatment. For > compatibility with old games, we can copy over key presses from the > new to the old scancodes, unless a general game bitset is set to > enable the new scancodes. This general bitset would also cause the new > scancodes to be aliases for the old ones, so that nothing changes if > you recompile your old scripts with a new version of scancode.hsi > > Now, how should numlock status affect this? Should we respect numlock > (mapping numpad keys to other keys when it's off), or never remap > numpad keys? I am tempted to say that numlock behaviour should be up > to the backend, and handled by the backend. I think it's already > impossible to support the numpad as described above with gfx_fb > anyway. Well, depends. Regular window controls respond to the numpad keys as duplicated keys. So having the familiar window interface for this app may be desirable. Yet, the differentiation may be more beneficial. I think of Blender, using the numpad keys as window view templates. I don't know. An option toggle could easily be exposed in the backend to support either duplicity or differentiation. Maybe the differentiation should be used, but the engine decides how to interpret the codes, as you were stating. Perhaps plotscripts could access the differentiation. Otherwise, the engine treats the codes as duplications in normal custom edits and gameplay? _______________________________________________________ Unlimited Disk, Data Transfer, PHP/MySQL Domain Hosting http://www.doteasy.com _______________________________________________ Ohrrpgce mailing list [email protected] http://lists.motherhamster.org/listinfo.cgi/ohrrpgce-motherhamster.org
