|
|
Home » Developing U++ » U++ Developers corner » U++ video control to come soon
|
Re: U++ video control to come soon [message #29992 is a reply to message #29987] |
Thu, 02 December 2010 12:08 |
|
koldo
Messages: 3357 Registered: August 2008
|
Senior Veteran |
|
|
luzr wrote on Thu, 02 December 2010 11:13 |
koldo wrote on Tue, 30 November 2010 05:17 |
Zbych wrote on Tue, 30 November 2010 08:50 | Can you publish this "preliminary" version?
|
Uuuf, I would do it only if somebody would have a really urgent need. The code is changing so much that most of the testing effort would not be useful.
|
Well, perhaps you might need some help with that... Puttin code to Bazaar (or, if you do not feel like that, to uppdev) would expose it to more eyes, correct?
|
Hello Mirek
Weeks ago MediaPLayer had an important crisis... However now coding goes fast, so in few time it will be uploaded to Bazaar.
Meanwhile SDLCtrl can be checked. All feedback is acknowledged.
Best regards
Iñaki
|
|
|
|
|
Re: U++ video control to come soon [message #32150 is a reply to message #32148] |
Thu, 28 April 2011 10:32 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
my problem was to get through all that dll mess, and make it compilable both mingw and msc, both static and shared. while mingw worked out pretty fine msc only provides for shared linkage.
thats why i enhanced the install instructions inside, to point to some pain generators. tried to touch as little as possible with the provided sdl packages, so user does not have to bother there.
i think my instructions are more straight forward in this way. this is actually like i install other libs in upp as well.
as of pain generators, especially the #define main SDL_main issue was boggling me. but still, the sdl guys have reasons for it (since one can specify some commandline goodies to SDL apps) which will be processed by the own main in SDLmain. so i tried to make this work too, without the need to #undef main. now it kinda works.
i noticed that MSC compilation first was making trouble, when using blitz in optimal. but this is known issue. but disabling blitz crashed the ide during compile. and couldnt figure out why. but now it works. maybe there was some recompile problems. could you check that package if the errors occure with you as well?
just msc shared, debug with blitz and optimal without.
i didnt want to mess up things from others. so it's up to you to take that one. but i think it's bit better in terms of installations and handling. more sdl native.
|
|
|
Re: U++ video control to come soon [message #32151 is a reply to message #32150] |
Thu, 28 April 2011 11:22 |
|
koldo
Messages: 3357 Registered: August 2008
|
Senior Veteran |
|
|
Hello Konstantin
I have found problems in DrawPixel() and GetPixelPos() that avoid to compile in MinGW-Speed only. They are now solved and will be uploaded today.
With this, without any change, package works well for MSC and MINGW, Debug and Speed.
SDL official binaries/prebuilt packages AFAIK come only for shared. Anyway I have not done any effort in compiling statically (although original SDL is supplied with MSC project files to compile it statically) because the shared one is the more general focus (SDL is LGPL).
As I have indicated before, there is a compilation in https://sourceforge.net/projects/upp/files/GPL-sources/SDL%2 0plugin_LGPL.7z/download just to avoid any problem to U++ programmers.
Of course, forget about SDL_main or libSDLmain.a.
Best regards
Iñaki
[Updated on: Thu, 28 April 2011 11:24] Report message to a moderator
|
|
|
|
|
Re: U++ video control to come soon [message #32158 is a reply to message #32156] |
Thu, 28 April 2011 14:35 |
|
kohait00
Messages: 939 Registered: July 2009 Location: Germany
|
Experienced Contributor |
|
|
well, basicly its downloading the 2 original devel archives from SDL page and placing them in say C:\, 2 because mingw and msc.. if one uses one of em only, well it's one. editing build methods to point to the location and done..
that's what inside the SDL package i posted. it's actually as easy as your package, but the sdl stuff remains untouched.
if you're alright with it i can commit it.. or you can, if you prefer.
the installer instructions are in the package as well.
here for short.
Quote: |
Medium
Linux
install the SDL 1.2.x package of your distro, dont forget to install the SDL-devel package for headers.
Windows
download binaries / prebuilt packages for msc and mingw
(http://www.libsdl.org/download-1.2.php)
http://www.libsdl.org/release/SDL-devel-1.2.14-VC8.zip
http://www.libsdl.org/release/SDL-devel-1.2.14-mingw32.tar.g z
unzip the stuff into 2 separate locations, e.g
C:\SDL-devel-1.2.14-VC8\SDL-1.2.14
C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14
the build methods need to access those respective folders
MSC build method, add to
PATH: C:\SDL-devel-1.2.14-VC8\SDL-1.2.14\lib
INCLUDE: C:\SDL-devel-1.2.14-VC8\SDL-1.2.14\include
LIB: C:\SDL-devel-1.2.14-VC8\SDL-1.2.14\lib
MINGW/TDMGCC build method, add to
PATH: C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14\lib
C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14\bin
INCLUDE: C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14\include
LIB: C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14\lib
C:\SDL-devel-1.2.14-mingw32\SDL-1.2.14\bin
the MSC libraries only come in shared linkage flavor, while the mingw flavor can be linked both shared and staticly.
the mingw SDL.dll.a is needed for static linkage and has got that weired name. who knows why. the SDL.dll comes in bin folder, thats why double folder specification is needed fir MINGW build method
the WinMain@16 compile problem for mingw (google for it) makes the change of lib link order obligatory, thats why mingw32 is specified explicitly last. this makes the
WINAPI WinMain(...) { return main(); }
hack obsolete and enables the native usage of SDL means to handle entry point. because SDL redefines your own main to be SDL_main (see SDL.h), and provides own main, the signature is critical.it must be (which in Upp is matched as well)
int main(int argc, char* argv[]);
so no need to take care of that
|
|
|
|
|
|
|
Goto Forum:
Current Time: Tue Apr 23 22:55:33 CEST 2024
Total time taken to generate the page: 0.02505 seconds
|
|
|