Aley Keprt wrote: > there are probably some weird bugs (in SimCoupe). I'm sure there are bugs - that's why it's an 'alpha test' version! (for SAM-users list members only). I've already found and fixed various things that were discovered since that version, but there are bound to be others. Before making that version available it was only tried on 3 different PCs!
> > 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? 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. > > 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'. > > Well, menu has no shortcuts. I want at least Alt+Space to enter > > the menu. 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. 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! 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. > > Dirty lines are too complicated? It's because you've probably did too > > optimised video code. 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. > I can imagine your sources. :-))) Well, have fun imagining... ;-P > > 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. 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? Si
