Welcome, Guest. Please login or register. Did you miss your activation email?

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - didito

Pages: [1] 2
1
General discussions / Mac OS X port to be continued
« on: June 01, 2010, 11:32:33 pm »
pressuuuuure *drums rolling* ;)

no, i got something coming up. coming back to you later ...

2
General discussions / Mac OS X port to be continued
« on: June 01, 2010, 04:59:09 pm »
finally started working. so stay tuned (and patient), people!

3
General discussions / Mac OS X port to be continued
« on: May 22, 2010, 08:47:56 am »
sorry guys, i was kind of offline the last weeks (moving + my macbook getting repaired). i'll need a couple of days more to setup but then i think i'm good to go. i've already done some thinking and i think i've got some questions for you, ceylo :) more on that later ...

so please, stay tuned!

4
General discussions / Mac OS X port to be continued
« on: April 29, 2010, 08:30:13 pm »
hello again,

so i spent the whole afternoon on trying to compile sfml2 (updating the whole xcode project before) and trying to figure out what needs to be done and what is going on behind the scenes.
for that i compared it to what was going on in sfml1 on the macosx side...

first of all - kudos to the person that wrote the macosx part before!
it is clean (in terms of coding convention/style/formatting, no dead code) and it does some things really well. like providing standard functionality available on other platforms for SFML, i.e. creating opengl views + and windows at runtime. before i thought this was done via Carbon. but then i saw that it already had an Cocoa implementation. hell, i didn't even know this was possible without a NIB.

and it is hiding the implementation from the user!
and IMHO this is also the bad part. it tries so hard to mimic behavior of other platforms (like linux and windows) and for this a lot is going on in the background (create a global context, global appcontroller, a dummy window, etc) and i can only think this thing must be hell to test, debug and maintain ... ok ok, i knew that mixing objective-c(++), cocoa and c++ would be strange and that everything is packed in 3 gigantic obj-c++ files certainly does help to further obfuscate things ...

so my questions would be?
what would you like to change for the new macosx/cocoa backend?
and why? why not stick with the old?
do you want to have a opengl-context wrapper because of multithreading?
it would really help if someone could shed some light on this topici n general ...

gracias!

5
General discussions / Mac OS X port to be continued
« on: April 29, 2010, 02:16:03 pm »
hey there,
sorry for being quiet for so long but i have some things going on right now.
i am still willing to contribute to the macosx port with my recent cocoa experience.

i just updated my working copy and wanted to ask you to point me into the right direction for starting ...

Quote from: "Ceylo"
What will you have to do ? Update the current port to match the SFML 2 Window interface, implement the new features SFML 2 is to provide (I don't really know the changes, but I saw there is now a separate class for windows and OpenGL contexts for example), provide the most easily usable product you can, answer all the questions on how to use SFML on Mac OS X, and in a general way.. fix all the bugs you can.

My personal note on the most tricky point I found is how to adapt Cocoa to the way Windows and Linux GUI API work. If you try to do a bit of Cocoa, I think you'll find out it's quite different from the Win32 API for instance.


could someone please elaborate on that?!? how far is SFML2 on windows and linux? what is missing on macosx?

6
General discussions / Mac OS X port to be continued
« on: February 24, 2010, 10:26:59 pm »
well i can announce that i've wrestled very much with cocoa and opengl (and quicktime and corevideo ...) in the last 2 months and after this project will have been finished (in 3-4 weeks) i would like to rethink about my proposal to help. i still would love to have a good framework like SFML with proper mac support. so maybe i can help ... we will see. i will come back to you soon!

7
Window / how to check for mutated vowels?
« on: November 06, 2009, 01:49:08 pm »
thank you very much for clearifying that! i definitly have a lack of knowledge in this area  :oops:

i do not need this string displayed in the console, i need it on the display and the string should get converted and sent over network via UDP (mac to mac system).
and i need to process the text somehow (append character, delete last char).
so if i use sf::String and cast it to std::string will i postpone the problem and loose my symbols again?

8
Window / how to check for mutated vowels?
« on: November 06, 2009, 01:09:49 pm »
ah ok, i thought so, but i did not find any good documentation on that and the keypressed version did work properly so far.
i used this sample code i found somewhere on SFML-Dev

Code: [Select]

if (event.Type == sf::Event::TextEntered)
{
    std::string ucStr;
    ucStr += event.Text.Unicode;
    printf("[INFO] incoming event \"TextEntered\" - %s\n", ucStr.c_str());
}


but i still get the output "[INFO] incoming event "TextEntered" - ?".
for ö, ü and ä i should not even need unicode, since they are only extended ascii and are available on every standard german keyboard.
so if i consider using textentered, how do i get the right symbols/chars then?

9
Window / how to check for mutated vowels?
« on: November 06, 2009, 12:50:55 pm »
hi all,

i am prototyping a very simple text input application for my project
and since we are currently expecting german speaking users i need
to check for mutated vowels like ö, ä and ü. they are very important in our language and i can't use their alternatives (oe, ae or ue).

is there a way to detect them?
as event.Key.Code i always get a zero value when i press those keys on my mac...

using current revision of SFML 1.5x on macosx 10.5.8

thanks in advance
didi

10
Graphics / [solved] FFMPEG problem
« on: October 20, 2009, 08:35:32 pm »
hello,

i'm glad to have stumbled upon your thread since i am trying to do something similar. although i would like to use live video from a camera.

i will try to get your example to work on my mac though. can you tell me on which platform (os, compiler, ffmpeg version) you have developed this?
and another question regarding the timing? does ffmpeg handle this internally or do you just ignore it for now?

thanks in advance,
didi

11
Feature requests / Cross-platform Video solution
« on: October 20, 2009, 08:25:43 pm »
well, just for the report - i found the entry in the french wiki and another thread on that topic. i'm sorry, i can't speak french but i will try to look into that ...

http://www.sfml-dev.org/forum/viewtopic.php?t=1428&highlight=video

http://www.sfml-dev.org/wiki/fr/tutoriels/integrervideo

12
Feature requests / Cross-platform Video solution
« on: October 20, 2009, 08:18:53 pm »
any news on that topic? i could not find the entry in the wiki :(

I have done this before with DirectShow and OpenGL on windows, but now I am trying to do this as well on mac osx the first time. and I would like to integrate this into SFML.

I will try looking into openFrameworks, reacTIVision, macam, vlc/ffmpeg and quicktime for this.

i think it could basically be done in SFML - using sf::Thread for continuously grabbing the frames and uploading the pixels of the current frame into the texture in the graphics memory (i already found the function in sf::Image). this would probably involve some locking or shared gl contexts though.

and for a more advanced version of this video engine:
upload speed would benefit from pixelbuffer objects.
and we probably need different pixelformats on different platforms to not fall off the fast path (i think we need this anyway).
and if we want to speed things up further and decode YUV to RGB then we need framebuffer objects and shaders ...

jm2c, cheers,
didi

13
General / trying to build/use SFML2 on mac osx
« on: October 19, 2009, 01:47:47 pm »
well thanks for pointing me to the interesting thread.
i don't see all my questions answered but i guess it does not matter for now, since the SFML2 is defacto in a unuseable state on mac right now.

14
Graphics / sf::Strings - copy ctor, copy assignment not working
« on: October 14, 2009, 05:37:33 pm »
believe me, it does not work here. i am sitting in front of the code.
and what do you mean, i already have posted the code?!?

maybe it has something to do with the problem of not being able to create/load a font before the opengl-context (i ran into that one before).
should i create SFML objects in any specific order?

btw, i am using a revision of SFML 1.5 (or 1.6?) on mac.

15
Graphics / How Views Work
« on: October 14, 2009, 05:33:10 pm »
ok, good to know, since i might need this feature.
maybe it is time to switch to the SFML2 branch...

could you please tell us what is the status on that?
what is working / stable, what not (platforms, features, ...)?

TIA
didi

Pages: [1] 2