First off I dont know of this has ever come up before, sorry if it has. Has anyone thought to add a option to update the dosbox.conf from within dosbox itself? I now such an option is really demanding on a full PC install, but it would be helpful and a time saver to keyboardless devices. Im not …

Be aware thats touchscreen support for the GP2X, it wont necessarily work on a windows platform or any other machine. On the other hand you dont really need to rebuild dosbox, just SDL. Reason being in windows SDL is link by DLL (dynamic linked lib). So you can change SDL, recompile it and it should …

It worked for the GP2X since the SDL was modified to use emulate the touchscreen as a mouse device. I would think your running windows and I dont know if the SDL windows build supports touchscreen, my guess is that doesnt. Which if that is the case you need to get SDL modified not dosbox.

Well overall the idea is working. Heres a summary: Normal mode dosbox works as normal only using the sdl.surface. When an OSD is turned on the sdl.surface is copied to sdl.blit.surface and all updates are then made to sdl.blit.surface. I then blit sdl.blit.surface and then my OSD to sdl.surface. If …

Well I will take your word on the int10 font, thats deeper than into dosbox than I know about.

if you havnt used sdl ttf, its a pretty brainless operation: Open TTF Open a font Create a surface using font and a printf type interface Blit your surface Close TTF

I guess I should add that most of the changes we have made should be compatible with non-GP2X builds. Adding ttf is not too difficult, no harder than adding SDL. Add the header and you should be able to call of the needed functions. I even think the windows dll version is available precompiled. …

if (retFlags && (sdl.surface->flags & SDL_DOUBLEBUF)) { sdl.blit.surface=SDL_CreateRGBSurface(SDL_HWSURFACE, sdl.draw.width, sdl.draw.height, sdl.surface->format->BitsPerPixel, sdl.surface->format->Rmask, sdl.surface->format->Gmask, sdl.surface->format->Bmask, 0); /* If this one fails be ready for …

Well the results are good so far. I forced sdl.blit.surface to be created and the flickering has gotten better, I didnt notice a speed decrease, but I attribute this to our fast harware blitter. I am still going to look into dynamically switching between the two methods.

I think this is the best solution at the moment. Im going to give it a try. I post back with the results when its working.

No its been going through the Locking section, thats where some of the surfaces were being blitted. Another idea is to keep the normal render structure if the OSD is off and then only use my buffer idea when the OSD is on. The way if any slowdown is introduced it's when the OSD is active. None of …

Another thing to consider, our SDL is designed to use our built in hardware blitter. Im not completely sure, but I think this would cut down the performace cost of doing a full screan blit.

Yes, i have it set to: // 1: complex scalers off, scaler cache off, all simple scalers on

I am blitting the osd in the GFX_EndUpdate function before the flip. Would I need to dig into render.cpp for the partial update? Ive only looked GFX_StartUpdate and saw the pixel exchange.

Yeah I have seen that you modify the pixel data directly and that only the pixels that change are updated. I thought the flickering was a result of this. As soon dosbox updates the pixels it draws onto the screen, then I blit my surface to the screen, and then the pixels get updated again and so on. …

Hi, im been working on the GP2X port of dosbox. I am using the SDL ttf lib to create surfaces with info, for debug and ui. Blitting these surfaces to the screen works fine, although we have problems with flickering and unless the location where the ttf surface changes, the pixels will remain showing …