Menu
▾
▴
1 Attachments
#57 port to sdl2
Before we start - yes, I know current (r1382) svn is broken in quite a few ways.
Due to the low quality of this code, this is actually more of an RFC, than a patch.
In fact, I'm just about sure I've broke joysticks.
Nevertheless quite a few things already work.
Some of the quirks of this patch (some unrelated to SDL2):
- explicit '-D_GNU_SOURCE was added for the sake of lexer/parser as SDL2 no longer adds it
-
'-DSOURCEDIR' was IIRC my resolution to running gvbam built outside source dir without installing - I think it predated current workaround of copying the ui files
-
that snippet in gtk/main.cpp is a solution of a a problem you won't run into yet; I'm using my gtk3 patch (slightly improved over the one from patch #35, but still without opengl support) and combining gtk3 and sdl2 leads to a crash at the start without XInitThreads (it's a mater of init order - it would work fine, if gtk was initialized after sdl)
-
LoadConfig() in gtk/window,cpp is a minimal workaround for ConfigManager breakage
-
'~SDL_INIT_HAPTIC' is needed due to certain inconvenience in sdl2 with SDL_INIT_EVERYTHING
-
in this patch resizes and focus tracking aren't implemented yet, but filter changes do change window size when required
-
for some reason gvbam freezes at closing on SDL_PauseSound; doesn't happen if it's build with openal sound instead
Now, I should get to the real reason I'm posting this incomplete patch.
I know very little about OpenGL and consider forcibly porting some of the apps to OpenGL 3.0 more of an ego trip than a real issue (though that might be just my old hardware speaking), yet if possible some restrain should be used.
In that light, OpenGL ES 2.0 (the way I read the manpages) doesn't allow GL_BGRA for for glTexImage2D.
Changing this triggers some issues with filters:
- hqnx needs transparency support fix (can be cherry-picked from one of implementations that float around)
- xbrz group just needed a switch from xbrz::RGB to xbrz::ARGB
- simple scale filters seem unaffected
- 2xSaI group...well this one has me stumped, it's affected, though depending on the screen it might be hard to notice, yet I see no reason why it should be; any hints ?
Oh, minor detail I've missed - since as of cmake 3.2.1 there's no upstream FindSDL2, I've used one from zdoom.
I'll take a look at it. I've actually been looking at eventually migrating to sdl2 for the sdl interface, as for gtk, iirc we might be deprecating that eventually in favour for the more cross platform wxwidgets interface.
Well, just my personal opinion, but while gtkmm GUI has fallen quite a bit behind, I don't consider toolkit wrappers like wxwidgets being true cross platform, especially given their disk space reqs on top of the actual toolkit (which AFAIK got even worse with wxwidgets 3).
On unrelated note: any plans on giving ffmpeg module a bit of API polish ?
I've tried to rewrite avcodec_encode_{audio,video} to avcodec_encode_{audio,video}2, but couldn't come up with a good source for pts, so couldn't get av_interleaved_write_frame to work properly.
Also, how is fixing ConfigManager coming along ? The directory verification is broken and ReadPrefHex could use a default value variant (so for example soundEnable could default to enabled).
yeah... I'm sure windows and osx /love/ having 50+ megs of runtime to run a gtk app on their platform (and to be honest on those platforms they are gui wrappers too and worse than wxwidgets). We are investing our time on 2 interfaces, wxwidgets (which will be the eventual gui for all platforms and easier to maintain one codebase instead of several different others) and sdl.
As for ffmpeg. Right now that isn't really high on the list just yet. It will get taken care of when we get to it. Right now priority is getting the wxwidgets interface up to date.
...as opposed to ca. 12MB of wxwidgets libs (that's without debug symbols, with them it it's ca. 90MB) - that's for 2.8, as I've said, 3.0 is supposed to be much larger.
OK, I'm not being quite fair here - gtkmm chain does take about 48MB (again, libs with debug symbols, stripped much less) and I just don't get the mess of an API that's wxwidgets IMHO.
Though I do understand manpower shortages.
Yet this is going offtopic. So, any hints why 2xSaI group behaves differently under SDL/OpenGL with my patch ? (I'm not sure if I was clear - soft mode works, so it's somehow triggered by GL_BGRA -> GL_RGBA switch).
Filters expect colors in BGR (24bpp) or xBGR (32bpp) format (some filters dont care, eg. pixelate, scanline...).
Oh, and would you mind setting eol:native on the recently added files (xbrz filters and ConfigManager stuff among them) ?
Correction: it seems that none of the files have the props set, it's simply that before, the original files all had '\n' line endings, it's only later when commits started mixing it.
So, could you set that prop on all of the text files ?
Last edit: galtgendo 2015-05-02
This is a new version of the patch.
Not much has changed, besides maybe that the code quality has dropped.
Some of notable differences:
- there are large and wasteful blocks were I've tried swapping the byte order before sending data to the filters - it didn't help
- I've tried using new audio API in SDL2; in the process, I've learned, that the current code works only because SDL_OpenAudio is initializing audio subsystem, otherwise it's initialized late, as such, moved audio initialization fully into driver init (probably needs an error message, though SDL_GetError sometimes returns an empty string)
- ConfigManager/iniparser changes are mostly just slight tightening of API to silence warnings; my ReadPrefHex method with default value might be a bit byzantine, but didn't have a better idea for it; strdup line is a (semi-obvious) crash fix; BTW, config saving under vbam is completely broken - new ':' are prepended at each save to the options (that's a problem with the original code, not my changes)
- that SDL_Init change in gtkmm probably completely breaks joysticks, so needs work (sound init not necessary there, as moved into driver)
- resizing opengl now works, fullscreen has been simplified; as for focus tracking, funny thing - AFAIU, the '#if 0' code for SDL_WINDOW_EVENT_FOCUS_{GAINED,LOST} should work, yet it doesn't: sometimes it doesn't pause, sometimes it freezes vbam
Last edit: galtgendo 2015-05-03
So,...
While there was a need for some ugly code for the swaps, I've managed to trim it down as much as I could.
It seems there's something broken with sound locking under SDL2, but those sem either deadlocks or heisenbugs, so about no progress there.
In the process, I've noticed that SuperEagle filter is already bugged under OpenGL. I've managed to find a fix in mednafen sources - it involved simply extending the masks for 32 bit.
Now, that basics work, I'm looking at input changes and all that ConfigManager breakage. The keyboard was bit more tricky than I thought (especially that because of ConfigManager, I need to restore the defaults (those strcmp checks before each inputSetKeymap were there for a reason)), but while not yet in this patch, I've already have it in semi-working condition (changes in inputProcessSDLEvent and sdlUpdateKey were required).
galtgendo, your changes look fine. The commented out code should be removed before the code gets committed.
Feel free to maintain the gtk ui. We have no intentions of removing the gtk code.
The aim with ConfigManager was to make the configuration common between the different front-ends. The ConfigManager is to go between the core and the UI. That way, the UI's would be able to read/write the same ini file. After digging deeper, I have come to realise that the configuration is probably better split between Core configuration (eg. throttle control, peripherals like the battery and sensors) and UI configuration (eg. ROM directories, screenshot format, input controls). ConfigManager is a work-in-progress.
One consideration I would ask for is; try to keep the code compilable on both SDL1.2 and SDL2. SDL1.2's input controller code is a bit more compatible than SDL2's. I'd like to keep SDL1.2 side by side with SDL2 and maybe give the user an option of picking between the two. SDL2 can be made a mandatory dependency and SDL1.2 optional.
The patch does not currently compile under Windows because the Windows build is missing the SDL2 dependency. I'll try adding that tomorrow and see how that fares.
Thanks for the patch. Keep us updated.
With SDL2 added, the patch compiled fine after I changed strdup to _strdup with a WIN32 define.
I have committed SDL2 2.0.3 to the Windows build dependencies in svn 1398.
So, I'll let myself use this bug as something repo alike for a dump of current state.
Quality of the attached patch is quite low, as (as opposed to the previous cases) I did little to no cleanup.
What does this patch contain:
- a failed attempt of avcodec_encode_video -> avcodec_encode_video2
- a completely failed attempt of adding ffmpeg recording to gtk frontend
- a mostly working port to gtk3 (the non working part is opengl output - needed to dump it before, because gtkglext; with gtk+ 3.16 it might be possible to do that better, but I don't have it yet)
- a mostly working SDL2 port (pause on unfocus still broken, as are the joysticks)
- a fix for ConfigManager loosing all the old settings upon upgrading to it (now, all the unknown keys are simply moved into [preferences] group)
- that one line in memgzio.h is needed for any not outdated zlib
- various const correctness tweaks to ConfigManager
- targets for building gtk/sdl frontend with openal backend (the backend itself is based upon src/win32/OpenAL.cpp with minor fixes - not contained in this patch)
- a fix for 2xSai filter not to break with alpha channel
- xbrz filter also uses its method for source with alpha
- hqx filters...yeah, that's a longer story: I've took its ffmpeg implementation, restored the original not-really-YUV and attempted to write a 16bit version of it; well, can't say if the 16bit version works (no real way to test it), but 32bit look working and the code is much smaller (and compile time is significantly reduced too) - again, the implementation itself not in this patch
Back to the cutdown version (though left the placeholders for openal).
Fix the audio pause - it was a matter of too many pause vars in the post-ConfigManager code; once the right one got picked, it stated to work properly.
Didn't touch the joysticks.
I'd say it's almost done, that is it's in a mostly-working state.
Hey, Just been following up on your patch (been playing catch up on some things etc) So far I'm liking some of the changes you've made and may merge some of them in. Now regarding the gtk ui changes you've made. I'd personally would like to avoid some specific X11 changes, Yes X11 is still supported, however we should be thinking about wayland support. Could you rework your gtk changes to at least reflect wayland support on top of X11?
This wil be yet another dump...(I really should finaly make use of git and split this into a patch series; for some reason though I just can't get around to it).
Anyway, it's not a complete dump, as some filter changes were cut out...On that note, I wonder about two things:if perhaps it would be worthwhile to pull lq3x and lq4x from the place lq2x comes from and how hard it would be for someone more skilled in python to adapt the scripts used to create ffmpeg's hqx implementation to work on those three (the compilation time is much shorted with those and the resulting code is much smaller; haven't tested if there's a speed difference too). On a different, but somewhat related note, does anyone have an idea where do the factors of the orignal pseudo-yuv conversion come from ? Not the ones in the more modern versions, where real factors are used, but those in RGBtoYUV_16.
The changes since last version (IIRC) are little but cosmetic, mostly moving a call of a function to a different place, so it's not caled redundantly.
I don't quite understand that line about X11 - about the only thing I see it could be refering to is that XInitThreads call, which should land behing a properly picked define, but is still mandatory as a crasher fix on xserver.
gtk3 itself can be built with wayland backend, but that's handled internally.
...and a minor note about gtk3 OpenGL widget: IMHO, it sucks; upstream might have considered sticking to >= OpenGL 3.0 a right idea, but that throws away quite a bit of older hardware and pretty much forces you to work with shaders; well, that has its advantages, but ticks me off nevertheless.
...and now I've noticed, that my trimming was a bit random - I've trimmed some parts that are needed by non-trimmed parts..:sigh:
:shrug:
Whatever, the older patches should have the mising bits...
Could you rebase off of current git https://github.com/visualboyadvance-m/visualboyadvance-m
...?
While a few commits were pulled (haven't done it in awhile, but the last post was already git based), there were no changes in the patch itself...
Well, what might mater was that the patch was produced via 'git diff -w' preceded with 'git mv src/gba/debugger-expr.y{,pp}' (parser/lexer changes might be flex/bison specific and not tied into the build system (yet ?)).
That's mainly because at the time of writing, the sources in the repo are a horrible mess, both wrt. line endings and indent style (that's how things ended up when Forgotten has left and there was nobody to set janitorial policies).
Which reminds me: could someone look into fixing the strict aliasing warning flood ? Preferably in a way not involving '-fno-strict-aliasing'.
Ataching more reasonably stripped dump.
Your patch is missing SoundOAL.cpp, without this I can't really fully test your changes
TBH, you could have just removed those OpenAL parts...
On the other hand, as mentioned before, that file has very little changes from src/win32/OpenAL.cpp. It's far older than SDL2 changes.
The header is just the removed class definition without ALFunction (and the preceeding LOGALL block) prefixed by SoundDriver.h and OpenAL includes.