yes Goran introduced me to the Nim language that compiles to C and they hired the creator of it to work for their company , Goran made a squeak (it also works with pharo) to nim bridge . But I was not aware of him using Unreal. Definetely will send him a message . Will keep you posted on my progress, Unreal is definitely coming to Pharo :)
On Sat, Jan 16, 2016 at 6:24 PM Esteban Lorenzano <esteba...@gmail.com> wrote: > On 16 Jan 2016, at 17:17, Dimitris Chloupis <kilon.al...@gmail.com> wrote: > > Thanks Estaban as I said I am not giving up on Pharo. > > I am actually very interested making pharo work with Unreal to give Pharo > access to the most powerful graphics engine out there. Yeap moving to SDL > could help a lot, I am 100% behind this idea. > > Definetly will keep using Pharo but I will try to integrate with powerful > existing technology , so maybe I can bring something new to Pharo too , its > not a suprise that Morphic is not up to my demands, these things take a lot > of coders and resources that pharo does not have. Like you I believe in > leveraging existing technologies from inside Pharo like SDL. > > If I am able to build Unreal Engine with a minimal Pharo API as a DLL and > use your FFI to control it, I think I will have the best of both world. I > will have to experiment and see :) > > > btw… I think joining unreal with pharo can give us a lot of power :) > Also this something already done by Goran at 3dicc (http://www.3dicc.com) > … I think his work is closed but Goran has always been very helpful and > offered guidelines, etc. (I wanted to do the Unreal-Pharo bridge myself but > well… no time so I stopped) :D > > I think if you are serious in your attempt I can put both of you in > contact... > > cheers, > Esteban > > > On Sat, Jan 16, 2016 at 5:49 PM Esteban Lorenzano <esteba...@gmail.com> > wrote: > >> Hi Kilon, >> >> I’m sorry to feel you frustrated. >> Is clear than morphic (and the world) as it is now is not well suited to >> the kind of development you want to do, and clearly documentation is not >> good enough (even if we have moved forward recently, in part with your >> collaboration)… >> Anyway, yes, using the world as is and morphic are not very suitable to >> hard consuming graphics, but there are works that have been happening that >> improves all that: >> >> Using not the world, but SDL2 (through OS-Window) will reduce the cpu >> consumption drastically… in fact, what happens now (as far as I can guess… >> since I don’t know your stuff) is not that instancing a png is slow, but >> the rendering (you are redrawing every time and that is not optimised in >> morphic, who takes area as damaged every time and redraws it… using athens, >> who is vectorial and then consuming). >> So, with SDL2 you will improve (and you will have separated windows). >> Also, I think you do 3d stuff so in your case I would explore wooden… I >> remember Ronnie showed me an animated scene (I think it was the water >> example) with more then 200 fps without much effort. >> Finally… I know about people doing animations with Pharo (and morphic) >> than have a lot better performance than you had… so there is clearly a >> problem there. If you give me your sources I can give them a look and try >> to figure out what is happening. >> >> So well… I think is not that is not possible, but that you are traveling >> paths that are new for us, then not documented (or even tested), or really >> optimised. >> Something that we are willing to improve, as always :) >> >> cheers! >> Esteban >> >> >> On 16 Jan 2016, at 15:47, Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >> in any case, ignore my bug reports, I am done with this, I waste my time >> and your time . Its clear pharo is not really suited for my needs, life >> goes on. >> >> On Sat, Jan 16, 2016 at 4:40 PM Dimitris Chloupis <kilon.al...@gmail.com> >> wrote: >> >>> disk, 1TB. why it matters ? from my profile its clear that its not the >>> primitive that is the problem but how Pharo processes pngs. >>> >>> I happen to work with a lot of big data both in 3d graphics, a blender >>> file can easily reach 250 mb and it opens under a second and audio files , >>> plus instrument that uses alot of audio files as samples of several gbs >>> giving again instanenous loading. I am not talking here 60 files, I am >>> talking thousands of files. >>> >>> I report a sever limitation and I have been told >>> >>> a) I have not done enough to isolate the problem when I post clear >>> profiling reports and the code that is responsible for it >>> b) why I make a fuss about it since there are work arounds >>> c) that its a hardware limitation when the hardware is able to perform >>> light years ahead of what pharo is currently doing >>> >>> Sorry but this kind of attitude is really bad, when someone reports a >>> bug I find it a lot better to tell him that you don't care or not reply at >>> all and ignore him than just find excuses for the bug or limitation. >>> >>> I see it every single time I complain about a problem there is a few >>> people who are logical about this like Ben , Esteban etc and then some >>> other that in complete denial zone and easily offended by the truth. >>> >>> On Sat, Jan 16, 2016 at 4:07 PM Stephan Eggermont <step...@stack.nl> >>> wrote: >>> >>>> On 16-01-16 14:48, Dimitris Chloupis wrote: >>>> > sorry but thats plain horrible performance wise and those images are >>>> > needed as soon as the gui is opened. So there can be no lazy loading >>>> for >>>> > them. The total size for all the 60 images is 530kbs . What would >>>> happen >>>> > if I did some serious animations of 10s of mbs , I will have to go to >>>> > buy a coffee to get my GUI opened :D >>>> >>>> Is that on a disk or an SSD? You won't be able to get much more than 60 >>>> files opened/s on a disk. >>>> >>>> Stephan >>>> >>>> >>>> >>>> >>
