| |
| |
| |
|
Page: 1 2 3
Comments:
<0> yes
<1> code::blocks 's devpak downloader will probably ease your development needs
<1> and it also comes with mingw
<0> I am not tedious about visual c++ at all, just had it here preinstalled
<0> so devpak has sdl in its repertoire?
<1> sure.
<0> well.. that's a much better idea then.. I am using visual c++ mostly as luxurious notepad anyway, that's all
<1> personally I prefer no IDEs, but the devpak stuff helps
<1> otherwise I am all for mingw+ msys+ ConTEXT
<0> I program under windows?
<0> you
<0> not i ?
<0> :)
<0> ****ty keyboard here
<1> I make my linux stuff work on windows (=
<0> heh
<2> My code all compiles without warnings or errors on both g++ and vs2k5.
<2> All you need to do is use portable libs and standard-compliant code.
<1> mine also works, after a little nudging
<1> last time I had a problem with SDL_Delay working differently on windows
<1> the other time SDL did some -Dmain=SDL_Main, so my own code which used "main" got screwed
<1> like namespace bsdl{ struct main{..
<1> but that was fixed later.
<0> sdl is supposed to be platform independent right?
<1> supposed to be portable
<0> that's good.. after all.. first when I head of SDL I was so prejudged.. I start to like it more and more..
<0> still I cant await ogl 2.0
<2> SDL you mean?
<2> OpenGL is up to 2.1.1 or something already.
<0> sdl
<0> I mean I like ogl but glut is so outdated
<1> why would you want sdl 2.0
<1> anything wrong with 1.2 ?
<0> I gues it has potential
<0> can I use the devpacks in mingw?
<1> wait, what have we been typing about ?
<0> can I use the devpacks in mingw?
<1> no, you can't.
<0> okay
<1> I can, though
<0> yea in your linux console under windows :)
<0> I am a 'family' programer !
<1> so this is german humor
<0> I guess its polish
<0> who said I am german?
<1> now I have to learn more about europe
<0> where are you from?
<0> let me guess.. naber lan
<3> which function(s) should i use if i want to keep a surface on a different surface?
<3> i'm building an fps meter, which works, and i want to display it (using SDL_ttf) on my surface
<3> problem is, it doesn't erase the last fps count already on my surface (duh), so i need to remove it somehow
<3> i figured out i can get my surface, and copy the left hand corner of it to a different surface, then blit it from the second surface to my original surface, then use SDL_ttf to write the new fps
<3> however, it's not really working :)
<4> either save your background or just redraw it
<3> how do i save the background?
<4> blit it to another surface
<3> http://cpp.sourceforge.net/?show=28603
<3> here is what i have so far
<3> however it isn't working
<4> never say "it isnt working"
<3> (font() works, and clip() basically copy the other parameter into the first one, SDL_Rect&)
<3> well it is working, but not the way i want it to work
<5> it is working, but as you don't need ;)
<3> instead of deleting the last fps check, it keeps the old, and overwrite the new one on the old ones
<3> ;)
<3> what am i doing wrong?
<4> you are ... copying surface to prefps, then copying prefps to surface, then drawing the font aren't you ?
<3> yes
<3> point is, i'm copying surface to prefps BEFORE the first fps font() is being written
<3> or, that's what i'm looking to achieve
<3> i figured "if i could save the picture before the first fps draw, i could simply redraw it on surface every time i get a new fps"
<4> well i'm not sure i get your code
<4> make sure the copied surface is what you expect with savebmp
<3> ah! that's a good solution! i must have missed it when going through the html files SDL gives
<4> i might look into it further with a minimal runnable example
<3> thank you. well i'm gonna have a small break and return later to complete the function
<6> Hello
<6> Is libSDL still being developped? it's been quite a time since there was an update
<6> Or am I just wrong?
<4> yes, it's being developed
<6> when was the last release, then? Didn't see anythign on the page, maybe I'm blind
<6> or better: Where can I find a list of changes / changelog?
<7> http://libsdl.org/release/changes-1.2.html
<7> 1.2.11 was released january 21 (so it is about two weeks old now)
<7> Oh, wait, no, that isn't right at all
<7> Timestamps have all been reset. Thought it sounded much too recent.
<7> Summer 2006 then :)
<6> ah, ok, thanks
<6> always thought, it was much older
<6> Wasn't there some development on SDL 2.x or something like that?
<7> Overall it depends, no big feature releases are really expected, but maintenance and minor feature bumps is very much active and ongoing.
<8> there were some rumours at least but there weren't anything major to add so the rumours stopped :)
<7> There have been past attempts at a 2.0, but nothing is really happening
<6> I saw SDLmm (isn't directly related to SDL afaik) and it stopped. too bad :7
<6> I'd love an OOP SDL
<9> hi there, im having problems with smpeg playing very slowly. Looks like a painters algorithm (ie it starts with a decent framerate and then slows after each frame).
<7> I don't really like C++ wrappers for the sake of C++ wrappers, an good application would probably just construct its own appropriate abstraction anyway.
<9> here is the code: http://rafb.net/p/89Zn9j31.html
<8> pwned, what was that sdl thingie you were making?
<6> tesmako, well, SDL in itself should be probably OOP, yes. :)
<1> Eclipser: a boost signals wrapper for the events.
<8> ah
<9> can you see anything obviously wrong here
<6> the SDLmm _wrapper_ isn't too good in the end
<7> Nembutal: SDL is pretty OO.
<8> pwned, have you worked on it lately? :)
<1> Eclipser: not really why?
<8> just wondering
<6> tesmako, never looked in the source of SDL (not before today) :)
<1> there's an invaders example in it
<8> yea I saw that
<6> but cl***es would be pretty... structs are nice for making things look cleaner but they don't suffice in my opinion
<7> Nembutal: I disagree, the approach used is just fine.
<6> tesmako, why? Would C++ be slower in the end?
<8> pwned, I refactored the xmms2 c++ bindings a bit - removed about 2kloc :)
<7> No, but rather unnecessary.
<6> or why do you think it is better the way it is?
<8> tesmako, that's just whatever one likes
<7> C++ linking is a fair bit more restrictive for other languages.
<7> Eclipser: ?
<6> Most bigger applications are written OOP these days
<1> Eclipser: great. You had your own type which wraps it , right ?
<7> Right, but SDL has a small simple API
<1> by it I mean boost function and stuff
<7> Which is already very much object-oriented. Throwing in C++ for the sake of it would achieve rather lirrle.
<7> s/rr/tt/
<1> yeah, throw in c++ for benefit, not for the sake of it
<8> pwned, the C api had its own callback functions and I exploited it to use boost.signals..
<7> pwned: Exactly what benefit would we derive from it?
<6> besides, talking of APIs and such, is there anything similar like SDL (in size) for linux ?
<7> ...SDL?
<1> tesmako: being able to adapt it to even more c++! using member functions as callbacks and stuff
<1> I know, it is a matter of style, but it at least provides more compatibility with existing c++ APIs.
<7> pwned: Callbacks to member functions is one of the things one just might actually want to do yes, but they are rather trivial to fake anyway
<8> tesmako, what I meant earlier was that c++ coders are usually used to nice stuff like member function callbacks, exception safety and stuff :)
<8> but one can always wrap SDL pointers to boost.shared_ptr's
<7> Throwing exceptions from callbacks would be a rather horrid design in any language.
<8> tesmako, of course, I never intended that :o
<1> yeah nobody says bring them together
<8> tesmako, exception safety overall, like in constructors
<7> I am starting to suspect that I don't understand this problem, what impact does exceptions have on SDL currently?
<8> tesmako, none really, but you must release all reserved memory by hand if it's not wrapped in for example shared_ptr, which is annoying - ending up with function wide try-catch blocks
<7> Either which way, my argument is rather straightforward here: SDL is tiny, and any use of SDL in an application should be abstracted away a bit anyway, and using C gives us the advantage of bindings to all languages imaginable. C++ would be slightly nice for C++ user, but that is about it.
<8> tesmako, of course, SDLmm just wrapped SDL for "nicer" usage in C++, didn't it? :)
<1> SDLmm ****s, sorry.
<8> pwned, agreed
<6> mh, there are quite a few OOP languages, that use SDL
<6> java for example
<1> I could do better standing upside down with my hands tied at the back
<7> Eclipser: But using C++ reference counting stuff would not only *really* *really* wreck interoperability but also have actual performance impact.
<8> Nembutal, they all wrap the C version :)
Return to
#sdl
or
Go to some related
logs:
damn small linux ma111
centos hang grub RAID1
+ncurces +select list
n64 emu ubunut
#perl
suse save configuration yast
uncinc.nl
intel_piix driver
#gentoo
bugmenot Sun Online Account
|
|