> > > mode 3 on --- 175fps with "skip auto" --- 142fps with "skip none" > > > mode 3 off --- 50fps with "skip auto" --- 25fps with "skip none" > > Firstly, I hope it's obvious that it shouldn't run that slowly, so there's a > problem! Does disabling the 'Hardware support' option still give similar > results?
I've got these values with sync 50hz off. HW on, since HW off is too slow anytime. I'm not interested in HW off. (I like to not see that option on the final version.) > Are you sure you've got the 'mode 3' state correct there? There is a > problem with having the mode 3 option enabled when using the 1x1 window that > caused can cause big slow-down (already fixed). If your display driver > supports hardware stretching WinCoupe tries to create the DirectDraw back > surface in video memory so it can use it. However if it doesn't support > hardware shrinking then DirectX uses software emulation to provide the > shrinking. Reading from video memory is extremely slow, and the emulated > blit requires many reads from the source image to do the shrinking. I've > can only reproduce this with the TNT NT drivers, as the Win9x drivers DO > support shrinking. Possibly. I don't have much time to spend with any alpha's. Please send a beta, and we will see. > > > 1. I though "skip none" should be the fastest. I can see "skip auto" is > > > faster. A bug? > > 'skip none' means it generates and displays ALL frames, even if it means the > emulation will be running under real SAM speed, as it will on slower PCs. > > With the frame sync enabled, 'skip auto' skips as many frames as is > necessary to keep the emulation running at 50fps. At the end of each frame > it checks to see if the next frame is overdue (because the current one took > too long), and if so it skips the following frame (i.e. doesn't generate the > frame data or blit the image). With a fast enough PC no frames will be > skipped (well, the odd one might be if other Windows apps steal away too > much CPU time). It will still drop below 50fps if the image blitting is > taking an unusually long time, or if the system is too slow to even be able > to run the CPU emulation with the 1fps video generation (the minimum > allowed). > > With the frame sync disabled 'skip auto' will give the same effects, but > only if the PC isn't up to running at 50fps with the 'skip none' option. > With faster machines it doesn't work in the same way, but just happens to > skip some frames, so it'll still be faster than 'skip none'. I still mean that skip auto should do nothing when the total speed is above 50 Hz. > The current Alt functionality is actually exactly how I intended it to be! > Left-Alt is used for the SAM 'Cntrl' key, as it's in about the same position > on the keyboard. The menus can't be accessed directly using combinations > like Alt-F because the combination needed for cntrl-f on the SAM (as used by > TurboMON and more). I purposely left the menu text without any accelerators > to show they can't be used. I put in some special cases for Alt-Tab, > Alt-Esc and Alt-Space (tho this last one seems broken!) so they can be used > for their normal Windows operations. Well, there should be an option for these Alt+F etc. I don't use turbomon and I want Alt+F for emulator menu. Is it a problem to add some options to enable these shortcuts to the menu? > To access the menu you just have to press and then release the Alt key (or > F10, as Windows automatically uses that too), at which point it will be > highlighted (full screen mode too). You can then use the mouse as normal > (even when the SAM mouse is enabled), or press the initial letter of menu > you want to open (space for the system menu), or just navigate using the > cursor keys and press Return on your selection! You probably didn't see SimCoupe later than 0.78. Did you? I changed the F-functionality a bit. e.g. I moved reset to F12, since this is a really strong function and it should be "protected". So I moved to the end of the keyboard :) Also I moved NMI as well. (the same reason) btw. Your fast reset is the thing I everytime wanted. Thank you very much. > To keep everyone happy I've now made the use of Left-Alt as SAM Cntrl > optional. The PC right-Control key is also the SAM Cntrl key, so that can > be used to generate the combinations when Left-Alt is used exclusively for > Windows. Or reversed. (right for menu, left for sam) ? > If you think you can do better then you'd better get to work on enhancing > 0.79 (you obviously wouldn't want any of my crap code). You might then > appreciate how much time and effort I've put into it so far. What? I won't go into this. oooooo I have never played with video emulation, since I think this takes too much programmers time, and gives too little benefits (especially when we have your nice code) :))) > > I can imagine your sources. :-))) > > Well, have fun imagining... ;-P Thanks. I'm good in it. > > > Mame uses dirty rectangles (the thing you call "dirty lines") and it > > > benefits from it. You're right, that it can slow the whole emulator. > > > But how much? A little bit. > > Even the old simple method potentially is quite costly. EVERY memory write > needs to be examined to see if it falls within the display area of the > current screen mode, and if that's true then the something needs to be done > to ensure it's updated next time. The simple case just sets a flag in a > line array, but if you really do mean rectangles then it'll be a LOT more > costly! General solutions are fine for the general cases, but I felt that > more could be gained by examining the specific SAM case. This is right. The question is what you do when a program uses double buffering (i.e. switching VMPR at 50hz interrupt). Do you handle this anyway? > Just one change to border, palette or vmpr within a frame requires that the > full frame be redrawn to reflect the change. Since virtually all SAM games > and demos (even the SAM startup screen!) make changes to at least one of > those every frame, the screen will require complete updating every time. For > those there's absolutely no benefit in tracking what needs updating; in fact > the write address testing only slow things down further. > > The video optimisations in the DOS are present to improve the performance so > the user had a chance of running at normal SAM speed. The frame-skipping in > WinCoupe also gives the user the same benefit, but in a cleaner and simpler > way. Additional optimisations may be added in the future, but I think it's > fine for now. > > So Aley, how would YOU do it? Although you all usually see my mails as "flamewars" etc., I just give some questions and things to think about. I agree with your words, and - of course - I have a really fast computer, so I can hardly benefit from any "better" version of video emulation. (the same for audio) The thing which shlould be really optimised is floppy drive i/o. > Si
