The second patch ports DosBox's OpenGL output backend to OpenGL 3.3. Core profile.
One thing you might want to note about the OpenGL 3 patch that it drops PBO (Pixel Buffer Object) support. The reason is that DosBox's PBO's don't work properly; they're the cause of a screen corruption bug. Also, I simply can't imagine an OpenGL 3.3-supporting setup where dropping this optimization is going to make a difference. If you're incorporating this patch into your own fork, and you want them, you can easily add them back; you can probably find a working PBO-enabled version in my git history.
Another thing you might want to note about the OpenGL 3 patch is that it uses GLEW. I include GLEW (including its license file) right in the codebase. As far as I know, this isn't a problem.
The third patch adds support for loadable, external shaders. The shader format is of my own design, and the goals were: a) use OpenGL 3.3, and b) make RetroArch shaders easy to port. The uniforms (values passed from the CPU to the GPU) are passed to the shader in the following format:
The fourth patch gets fullscreen working retina Macs. You should only apply this one if you actually intend to run it on a retina Mac and you find that you actually need it. What it does is documented here:
Would you consider implementing pixel-perfect scaling in your SDL2 fork via the SDL_RenderSetScale() function and the SDL_HINT_RENDER_SCALE_QUALITY set to 0 (nearest). You may take the scale-calculation routine from my patch:
1get_perfect_scale() 2in src\gui\pixelscale.cpp
and let SDL2 do the rest. The only problem will be to bypass the standard scaling and aspect correction. This version should work much faster than mine, and with any output supported by SDL2.
Edit: Furthermore, all the standard modes of scaling and aspect-ratio correction may be delegated to SDL_RenderSetScale() and the scale quality hint.
It's pretty easy if you used any othe versioning system. Clone is just the term git uses and pull requests are well explained on github. Of course grabbing the source via git, changing stuff and then let git make diff/patch is easy as well. Pull requests are just easier for the project maintainer.
I am not very comfortable with Unix and makefiles either, and had to follow these instructions to the letter in order to setup a working build environment on Windows in MinGW. Will those work for your fork, with the exception that I shall need to download and install SDL2 SDK?
If git can work from MinGW I will use it, but now I shall just download the patch, apply them to the source and see what is to be done.
I would post a new topic for this but I'm either thick or new members cannot post a new topic in this forum section.
I wanted to get DOS games running well on Steam Linux and with the Steam Link but as has become known DOS games don't work well with the Steam overlay due to how frames are only rendered when something changes. On Windows this is worked around with DosBox builds supporting DirextX pixel shaders that force the frames to sync with the display. Unfortunately no such feature is available for the OpenGL output. As I soon found dugan's SDL2 fork was working best for me (much more reliable screen resolution handling) I decided to write a patch to solve this with my very limited C++ skills. I think its kind of hackish but it works well for me. You can find the branch over at:
This patch adds a new configuration option to the render section: forceframeupdate. When set to true this will set a default minimal frame refresh rate. Only when the last frame render was below this minimum will a frame re-draw be forced. You can also set your own desired minimum refresh by setting it to a numeric value in milliseconds (e.g. 50 for roughly 20fps). The default is conservative (10fps) to be just good enough for a hooked in render overlay to work. Its disabled by default ("false") so make sure to add that config option.
The minimum config setup for this to work then is:
1fullresolution=desktop 2output=openglnb 3... 4 5[render] 6# Force minimum regular frame updates to fix overlay. 7forceframeupdate=true
Combine this with dugan's shader support and you have a great streaming experience to your lounge's big screen 😎
There is a known issue with the build if you don't use fluidsynth. It takes a few extra seconds to start as for some reason it probes for Jack. It only takes a few seconds though or you can simply follow dugan's instruction and hook it into fluidsynth with a soundfont which bypasses the issue.
I've only tested a few games and I'm really interested to find out how well it works for others. It should work on Mac's but I've not tested that myself.
I could succesfully build a Dosbox Fork from your Repository for Windows (using msys/mingw 32bit on Windows 7) but the sound doesnt work. Only "General Midi". No Soundblaster. No GUs etc. I hear only crackled Sound ?
If i capture to waveout, there is Sound.
Edit: Sound Works, SDL2.dll mismatch ..... 😒
Compiling with SDL2 v2.0.6+ the sound is cracled. With SDL2 2.0.4, sound works normal.
First.. I have figured out.Second i not very familar with Mingw and c++. This was a hell. But the compild fluidsynth.exe in mingw/bin folder works too and now i can compie Dosbox as single exe (fully static linked)
Source File Chnages: In the fluidsynth\include\fluidsynth.
Voila.. i can compile Dosbox as a single exe. All stuff is linked.
Edit: sdl2_net linkes in Dosbox exe. Adding a new Private Windows build Version to this thread to show what i mean.
And .. i would say
My thanks go to the DOSBox Team, dungan (for this Fork from Dosbox, i love the shader), nukeykt (Nuked OPL3 emulator), VileRancour (CGA w/ Monochrome Monitor Support), D_Skywalk (Multi-Floppy-Images), Michał Kępień (Volume Up/Down hotkeys ), TaeWoong Yoo (Various Patches), `Moe` (Speed Meter), Vasyl Tsvirkunov (Innovation SSI-2001 emulation ), kekko (3dfx voodoo emulation)