May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] developing games in Pharo

by Eliot Miranda

Hi Hilaire, mornin'. Thanks for such a helpful, in-depth answer! You ask about support for ARM... answer below. On May 11, 2014, at 3:09 AM, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > Morning! > > As several people mentioned it, I may have a few tips to share regarding > developing educative applications with Pharo (you can read Squeak as > well, but you may have a better support with Pharo if you want to target > touch devices as well, I don't want to write the Squeakers are helpless > -- not at all -- but it seems to me there are more experiences to bring > Pharo applications on touch devices from A to Z -- from the developer to > the consumer I mean). > > You are a Smalltalker so you definitely know the related benefits to > develop with Pharo, so no need to spend words on that. You also know > your application will be portable to the three workstation operating > systems, very easily as the VM are routinely compiled for these hosts. > > To get an idea about how could look your end user application, I suggest > you take a look at Dr.Geo - http://drgeo.eu for workstation and touch > devices ; then also iStoa for Linux - > https://launchpad.net/istoa/+download. These are packaged for end user. > For Windows the installer could be improved with installed entry in the > system menu. > > >> 1) I know I have to build a suitable executable but I have never done >> this. I have only written Smalltalk code that I then >> use. So how do I build such an image and how big is it (assume code >> for game is small (say 3000 lines of code)). > > To build the end user application, you will have to do it in two steps: > > 1. Prepare your image: install your source code and related source code > package, set the state of the image, shrink your image and save it. You > will use Metacello. I use smalltalk script for that. > > 2. Build your application package: you will use a pre set application > hierarchy with the VM, icons, execution script if needed, etc and > install your image, the necessary media and translation if any. I use > bash script to do so. > > For inspiration you can have a look at Dr. Geo subversion repo[1] or > iStoa launchpad repo[2]. The later one may be easier to follow as I gain > some experience from Dr. Geo work. > > Once you setup this, building your application is easy. It is just a > matter to update your ConfigurationOf. and executing your bash script. > > >> 2) How do I get the virtual image on the customer's machine. Keep in >> mind the customer is someone somewhere >> on the Internet who probably knows little about how to install >> Smalltalk or anything else. I am assuming here that >> installing the game and installing the VM are two different tasks. >> Is there a way to make this a single task? > > No installing the game and VM will be done at the same time. > You ship your application in a zip archive or auto-installable > executable with VM, image, and related media, documentation and > translation files. > > >> 3) So far I am assuming the target machine is Linux/Windows/Mac on a >> Desktop/Laptop. >> But can Smalltalk be run on any of the IPad/Notebook/etc out there? >> These machines represent a larger game market I believe. > > Yes it is possible. Look at DrGeo on AppStore[3] and GooglePlay[4]. > > Sadly we do not have JIT support for these devices. > Is it just a mater to support the ARM instruction set or much more > complicated? I would be please to know. On iPhone Apple expressly forbid JITs other than their own so until that changes the fastest VM on iPhone will be the Stack VM. On Android JITs are allowed. Tim Rowledge is currently working on the Cog ARM back end which was started by Lars Wassermann, and is making good progress, working in the VM simulator. He is targeting the Raspberry Pi. I don't know whether he'll have time to port to Android, but I'm sure someone can. I don't want to talk for Tim but I expect he'll easily be finished this year. On a related tack, Doug McPherson has recently implemented the ARM support for Cog's FFI module, so there is now FFI support! And the Pharo team have taken on a person to work on AsmJIT for ARM. So at least on Android the Squeak/Pharo support will be good (although I expect more work is needed to provide good touch support). Hilaire, perhaps you can tell me whether touch support is OK or whether work needs to be done in the VM? > Any way for touch devices, you still have the two aspects of Smalltalk > to consider: > 1. The VM: it will be the interpreted VM, or COG without JIT support. Cog without JIT support is called the Stack VM, (since it optimizes message sending by mapping contexts to stack frames). Soon (some time this year) we should have a Spur Stack VM which may be -35% to -40% faster. > Esteban and Dmitry were really helpful and collaboration was great to > let me concentrate on the image level considerations below. > 2. Your image. > > For point 2, you will have extra work, better to take it into account > since the beginning of your project if you target touch device: > > a) no support for multiple touch, at least as far as I know. I read > there and there people talking or doing things, but no real stuff. > Anyway it is definitely not a show stopper: you can be ok with tap and > dragging. But you need to consider it. > > b) support for the virtual keyboard, Esteban and Dmitry added hook to > show or hide the touch device keyboard (see drgeo code with > showVirtualkeyboard). In your GUI design, you need to be careful your > text zone is not hidden by the virtual keyboard. Again it is resolvable. > > c) the numerous screen resolutions of the touch devices. For DrGeo and > iStoa I took very different directions. Probably the most interesting > for you will be the one I took for iStoa. The application window is a > full screen morph with scaled bitmap. My bitmap are scaled for a Nexus5 > screen resolution (~2500x1600), then graphics and font are downscaled > according to the used screen device. I suggest you take a look at the > Linux iStoa application and resize the window to see what is happening. > > Using Athens is definitely not an option now for 2 reasons: it is not > supported yet by touch devices; as long as it is not used in Pharo > itself, if you put in perspective delivering to end user you have to > consider it as unstable. > > d) native look and feel: it was really a big concern -- the bigger in > fact -- for DrGeo. For iStoa it is nearly irrelevant, but there are > still some widgets around. Again games does use native widget, so it may > be ok. For DrGeo I need to subclass a Pharo theme to remove window > decorations, force dialog to be positioned on the top and centered and > other details I forgot about. It looks pretty ok for me, but not for > touch device users. > I tried to share the experience and work on this point but without > success[5]. > > >> >> 4) Assuming I can arrange for my computer game (if I write it) to be >> installed are there memory/cpu usage issues >> that I need to worry about (the game itself will use a minimal of >> memory/cpu except for graphics which also >> is pretty reasonable). I am thinking here of IPads etc. For >> Desktops/Laptops there should be no problem. >> Download time and subsequent storage space is also a concern; >> remember the device is probably used for >> lots of other things so the amount of space allocated for games may >> be small compared to the space on the >> machine? > > If your code and medias game are small, the image size will be a > problem, not something that will prevent your application to work > perfectly, but more a feeling of wasted resources. > > With Pharo1.4, I can shrink DrGeo image below 10MB, including DrGeo > code. With Pharo3, I can't get below 16MB with (smaller) istoa code. > It is really a deception, the new developer tools were not developed as > loadable code. I guess it was too difficult to be done, although it was > a promise (informal?) of the Pharo project when it start up. > Again it is not a show stopper. > > Good work on your project, I will be happy to read about its progresses. > > Hilaire > > >> 5) Sorry for the redundancy if these questions have been asked before >> (which I am sure they have). >> >> Thanks for any feedback; I am sure others are interested in this >> question too. >> >> Ralph Boland > > > [1] https://gforge.inria.fr/scm/?group_id=1308 > [2] > http://bazaar.launchpad.net/~hilaire-fernandes/istoa/trunk/files/head:/buil… > [3] https://itunes.apple.com/us/app/dr.-geometry/id559858173?mt=8 > [4] https://play.google.com/store/search?q=drgeo > [5] http://forum.world.st/iOS-polymorph-theme-anyone-tt3557696.html > > -- > Dr. Geo http://drgeo.eu Best regards, Eliot (phone)

May 11, 2014

Re: [Pharo-dev] Roassal 3D empty windows

by Nicolai Hess

2014-03-31 9:56 GMT+02:00 Nicolai Hess <nicolaihess(a)web.de>: > Hi Alexandre, Ronie, igor > > it isn't solved yet. It works if I make the default extent > larger: > > As I described here and on the NBOpenGL Windows thread, > on my machine(s) (both with ATI Graphics) ,the framebuffer objects > (all/one?) does not update its internal buffer sizes after they are > initilialized with the > default Morph extent 50@40. Therefore, the rendering happens > only in the upper left corner with extent 50@40. (and some rendering > artifacts > in the remaining area. not rendering artifacts actually, looks like > texture wrap clamp to edge. > Although I can not find a place where this texture wrap mode is set.) > > (on linux, phew, there are so many not working things, I don't know if it > is a driver issue: > hardcoded libpath, some distribution don't put the libGL.so under /usr/bin > missing type (something with GLXDisplay ?, I don't remember) > errors in some NB calls, > If I fix the first two issues it still does not work, because I don't know > how > to handle the NB call errors.) > > Maybe it is easier to list OS and Hardware where R3D does work, than > to list the non working one. > > What OS and graphic cards do you use and test for NBOpenGL and R3D, mac os > only? > > > > Nicolai > > > > > > > > > > 2014-03-30 22:07 GMT+02:00 Alexandre Bergel <alexandre.bergel(a)me.com>: > > Is this problem been solved already? >> >> Alexandre >> >> >> On Mar 17, 2014, at 7:35 PM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> >> > As described in the "NBOpenGL on Windows" thread, I have a windows >> > machine where NBOpenGL can not create frame buffer objects (driver >> issue maybe). >> > >> > But on another windows machine, there is no error but strange rendering >> results. >> > >> > On that machine, Roassals 3D IDE, still only shows empty windows. And >> other >> > demos shows the same strange rendering (see screenshot, includes GL >> context driver info). >> > >> > >> > (BTW, there is some class name missmatch in NBGLCurveRenderer in this >> NBOpenGL version. >> > It referse to NBGLFragmentProgram although there is only a >> NBGLFragmentProgramARB class >> > in the system). >> > >> > >> > >> > >> > 2014-03-17 15:55 GMT+01:00 Ronie Salgado <roniesalg(a)gmail.com>: >> > Hi Nicolai, >> > >> > What are your system specs?, specially your graphic card. >> > Roassal3D requires a graphic card with at least OpenGL 2.0 support. Try >> updating your graphic drivers >> > >> > Greetings, >> > Ronie >> > >> > >> > 2014-03-17 11:03 GMT-03:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >> > >> > Ohâ¦ Have you tried to update Athens and NBOpenGL ? Maybe you are using >> an old version of them. >> > Maybe an old version of OpenGL is installed on your Window? >> > >> > Ronie, any idea whatâs going on? >> > >> > Alexandre >> > >> > >> > On Mar 17, 2014, at 10:55 AM, Nicolai Hess <nicolaihess(a)web.de> wrote: >> > >> > > Thank you Alexandre, >> > > this was what I tried under windows, (I wasn't sure if this is still >> the right way to do it, I >> > > read it the Roassal3dTutorial.pdf). >> > > But it doesn't work. Either I am getting empty windows or (with an >> other >> > > NBOpenGL version) >> > > Frame buffer is incomplete: GL_FRAMEBUFFER_UNSUPPORTED') >> > > >> > > I tried this once with linux too, and it didn't worked. But I am not >> sure how long ago :) >> > > I'll try it again and report back. >> > > >> > > (Another note, after downloading the configuration, this: >> > > (Smalltalk at: #ConfigurationOfRoassal3d) loadDevelopment >> > > takes awfully long on windows (~ 5 min). >> > > I am sure it was much faster on linux, any idea how that can be?) >> > > >> > > >> > > >> > > >> > > >> > > >> > > 2014-03-17 14:34 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com >> >: >> > > Hi Nicolai, >> > > >> > > Roassal3d works well with the last Pharo 3.0. >> > > You just need to execute the following incantation: >> > > >> > > -=-=-=-=-=-=-=-=-= >> > > Gofer new smalltalkhubUser: 'ronsaldo' project: 'roassal3d'; package: >> 'ConfigurationOfRoassal3d'; load. (Smalltalk at: #ConfigurationOfRoassal3d) >> loadDevelopment >> > > -=-=-=-=-=-=-=-=-= >> > > >> > > This does not work for you? >> > > It works well on OSX and on Linux >> > > >> > > Alexandre >> > > >> > > >> > > On Mar 15, 2014, at 10:52 AM, Nicolai Hess <nicolaihess(a)web.de> >> wrote: >> > > >> > > > Hi, >> > > > >> > > > what could be the reason, that any Roassal3d example from the >> > > > Roassal3DTutorial.pdf only shows white empty windows? >> > > > >> > > > I loaded ConfigurationOfRoassal3d-RonieSalgado.10 and >> > > > (Smalltalk at: >> > > > #ConfigurationOfRoassal3d) loadDevelopment >> > > > >> > > > Any ideas? >> > > > >> > > > >> > > > regards >> > > > Nicolai >> > > > >> > > >> > > -- >> > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > > Alexandre Bergel http://www.bergel.eu >> > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > > >> > > >> > > >> > > >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> > >> > <PharoScreenshot.png> >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> > So, I finally solved this issue for me. Instead of making the initial framebuffer large enough, I changed the code in NBGLFrameBuffer>>extent: to reattach all attached Renderbuffers. ( I don't know if this is a driver issue or if it is a failure in NBOpenGL) Again, someone can tell me where (OS, graphic-card) Roassal 3D runs out of the box? And even now, that I solved this issue and all(many) Roassal examples are working, The R 3D IDE still only shows a black screen. And I still don't know what this is supposed to be, any tutorial screenshot or video, showing what R3D IDE is? Nicolai

May 11, 2014

Re: [Pharo-dev] New screenshots of Roassal3d

by Sean P. DeNigris

abergel wrote > we have posted some new picture of Roassal3d. Cool! What would be really great would be screencasts showing how to make these cool things for ourselves. Do any exist? ----- Cheers, Sean -- View this message in context: http://forum.world.st/New-screenshots-of-Roassal3d-tp4758397p4758667.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2014

Re: [Pharo-dev] Possible Zinc Bug: empty path segments returns nil

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > But I understand the confusion, I'll flag this for my todo/tothink - Conceptually, an empty collection seems to fit better e.g. there is: self assert: 'http://google.com/' asUrl queryKeys isEmpty - It also makes processing easier because you can just "url pathSegments do: aBlock" without always having to do a check first. This is how I found the problem - my code was working until I passed it a url with an empty path. ----- Cheers, Sean -- View this message in context: http://forum.world.st/Possible-Zinc-Bug-empty-path-segments-returns-nil-tp4… Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2014

Re: [Pharo-dev] I made a pass on the new website

by Marcus Denker

On 11 May 2014, at 10:11, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > I made a pass on the new website. > I improved a bit documentation: > - added âimmediate linksâ :P > - added pharodocs reference link > > We still need to do a lot of work, but we are making improvements. > > Ah, I also promoted Laurentâs video to first page :) > > Esteban More changes: - Donation button on http://pharo.org/get-involved - "Commercial Supportâ section added http://pharo.org/get-help - Google analytics finally configured Marcus

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by stepharo

thanks hilaire! We will continue pushing Pharo to help you. Stef On 11/5/14 12:09, Hilaire Fernandes wrote: > Morning! > > As several people mentioned it, I may have a few tips to share regarding > developing educative applications with Pharo (you can read Squeak as > well, but you may have a better support with Pharo if you want to target > touch devices as well, I don't want to write the Squeakers are helpless > -- not at all -- but it seems to me there are more experiences to bring > Pharo applications on touch devices from A to Z -- from the developer to > the consumer I mean). > > You are a Smalltalker so you definitely know the related benefits to > develop with Pharo, so no need to spend words on that. You also know > your application will be portable to the three workstation operating > systems, very easily as the VM are routinely compiled for these hosts. > > To get an idea about how could look your end user application, I suggest > you take a look at Dr.Geo - http://drgeo.eu for workstation and touch > devices ; then also iStoa for Linux - > https://launchpad.net/istoa/+download. These are packaged for end user. > For Windows the installer could be improved with installed entry in the > system menu. > > >> 1) I know I have to build a suitable executable but I have never done >> this. I have only written Smalltalk code that I then >> use. So how do I build such an image and how big is it (assume code >> for game is small (say 3000 lines of code)). > To build the end user application, you will have to do it in two steps: > > 1. Prepare your image: install your source code and related source code > package, set the state of the image, shrink your image and save it. You > will use Metacello. I use smalltalk script for that. > > 2. Build your application package: you will use a pre set application > hierarchy with the VM, icons, execution script if needed, etc and > install your image, the necessary media and translation if any. I use > bash script to do so. > > For inspiration you can have a look at Dr. Geo subversion repo[1] or > iStoa launchpad repo[2]. The later one may be easier to follow as I gain > some experience from Dr. Geo work. > > Once you setup this, building your application is easy. It is just a > matter to update your ConfigurationOf. and executing your bash script. > > >> 2) How do I get the virtual image on the customer's machine. Keep in >> mind the customer is someone somewhere >> on the Internet who probably knows little about how to install >> Smalltalk or anything else. I am assuming here that >> installing the game and installing the VM are two different tasks. >> Is there a way to make this a single task? > No installing the game and VM will be done at the same time. > You ship your application in a zip archive or auto-installable > executable with VM, image, and related media, documentation and > translation files. > > >> 3) So far I am assuming the target machine is Linux/Windows/Mac on a >> Desktop/Laptop. >> But can Smalltalk be run on any of the IPad/Notebook/etc out there? >> These machines represent a larger game market I believe. > Yes it is possible. Look at DrGeo on AppStore[3] and GooglePlay[4]. > > Sadly we do not have JIT support for these devices. > Is it just a mater to support the ARM instruction set or much more > complicated? I would be please to know. > > Any way for touch devices, you still have the two aspects of Smalltalk > to consider: > 1. The VM: it will be the interpreted VM, or COG without JIT support. > Esteban and Dmitry were really helpful and collaboration was great to > let me concentrate on the image level considerations below. > 2. Your image. > > For point 2, you will have extra work, better to take it into account > since the beginning of your project if you target touch device: > > a) no support for multiple touch, at least as far as I know. I read > there and there people talking or doing things, but no real stuff. > Anyway it is definitely not a show stopper: you can be ok with tap and > dragging. But you need to consider it. > > b) support for the virtual keyboard, Esteban and Dmitry added hook to > show or hide the touch device keyboard (see drgeo code with > showVirtualkeyboard). In your GUI design, you need to be careful your > text zone is not hidden by the virtual keyboard. Again it is resolvable. > > c) the numerous screen resolutions of the touch devices. For DrGeo and > iStoa I took very different directions. Probably the most interesting > for you will be the one I took for iStoa. The application window is a > full screen morph with scaled bitmap. My bitmap are scaled for a Nexus5 > screen resolution (~2500x1600), then graphics and font are downscaled > according to the used screen device. I suggest you take a look at the > Linux iStoa application and resize the window to see what is happening. > > Using Athens is definitely not an option now for 2 reasons: it is not > supported yet by touch devices; as long as it is not used in Pharo > itself, if you put in perspective delivering to end user you have to > consider it as unstable. > > d) native look and feel: it was really a big concern -- the bigger in > fact -- for DrGeo. For iStoa it is nearly irrelevant, but there are > still some widgets around. Again games does use native widget, so it may > be ok. For DrGeo I need to subclass a Pharo theme to remove window > decorations, force dialog to be positioned on the top and centered and > other details I forgot about. It looks pretty ok for me, but not for > touch device users. > I tried to share the experience and work on this point but without > success[5]. > > >> 4) Assuming I can arrange for my computer game (if I write it) to be >> installed are there memory/cpu usage issues >> that I need to worry about (the game itself will use a minimal of >> memory/cpu except for graphics which also >> is pretty reasonable). I am thinking here of IPads etc. For >> Desktops/Laptops there should be no problem. >> Download time and subsequent storage space is also a concern; >> remember the device is probably used for >> lots of other things so the amount of space allocated for games may >> be small compared to the space on the >> machine? > If your code and medias game are small, the image size will be a > problem, not something that will prevent your application to work > perfectly, but more a feeling of wasted resources. > > With Pharo1.4, I can shrink DrGeo image below 10MB, including DrGeo > code. With Pharo3, I can't get below 16MB with (smaller) istoa code. > It is really a deception, the new developer tools were not developed as > loadable code. I guess it was too difficult to be done, although it was > a promise (informal?) of the Pharo project when it start up. > Again it is not a show stopper. > > Good work on your project, I will be happy to read about its progresses. > > Hilaire > > >> 5) Sorry for the redundancy if these questions have been asked before >> (which I am sure they have). >> >> Thanks for any feedback; I am sure others are interested in this >> question too. >> >> Ralph Boland > > [1] https://gforge.inria.fr/scm/?group_id=1308 > [2] > http://bazaar.launchpad.net/~hilaire-fernandes/istoa/trunk/files/head:/buil… > [3] https://itunes.apple.com/us/app/dr.-geometry/id559858173?mt=8 > [4] https://play.google.com/store/search?q=drgeo > [5] http://forum.world.st/iOS-polymorph-theme-anyone-tt3557696.html >

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by Hilaire Fernandes

Morning! As several people mentioned it, I may have a few tips to share regarding developing educative applications with Pharo (you can read Squeak as well, but you may have a better support with Pharo if you want to target touch devices as well, I don't want to write the Squeakers are helpless -- not at all -- but it seems to me there are more experiences to bring Pharo applications on touch devices from A to Z -- from the developer to the consumer I mean). You are a Smalltalker so you definitely know the related benefits to develop with Pharo, so no need to spend words on that. You also know your application will be portable to the three workstation operating systems, very easily as the VM are routinely compiled for these hosts. To get an idea about how could look your end user application, I suggest you take a look at Dr.Geo - http://drgeo.eu for workstation and touch devices ; then also iStoa for Linux - https://launchpad.net/istoa/+download. These are packaged for end user. For Windows the installer could be improved with installed entry in the system menu. > 1) I know I have to build a suitable executable but I have never done > this. I have only written Smalltalk code that I then > use. So how do I build such an image and how big is it (assume code > for game is small (say 3000 lines of code)). To build the end user application, you will have to do it in two steps: 1. Prepare your image: install your source code and related source code package, set the state of the image, shrink your image and save it. You will use Metacello. I use smalltalk script for that. 2. Build your application package: you will use a pre set application hierarchy with the VM, icons, execution script if needed, etc and install your image, the necessary media and translation if any. I use bash script to do so. For inspiration you can have a look at Dr. Geo subversion repo[1] or iStoa launchpad repo[2]. The later one may be easier to follow as I gain some experience from Dr. Geo work. Once you setup this, building your application is easy. It is just a matter to update your ConfigurationOf. and executing your bash script. > 2) How do I get the virtual image on the customer's machine. Keep in > mind the customer is someone somewhere > on the Internet who probably knows little about how to install > Smalltalk or anything else. I am assuming here that > installing the game and installing the VM are two different tasks. > Is there a way to make this a single task? No installing the game and VM will be done at the same time. You ship your application in a zip archive or auto-installable executable with VM, image, and related media, documentation and translation files. > 3) So far I am assuming the target machine is Linux/Windows/Mac on a > Desktop/Laptop. > But can Smalltalk be run on any of the IPad/Notebook/etc out there? > These machines represent a larger game market I believe. Yes it is possible. Look at DrGeo on AppStore[3] and GooglePlay[4]. Sadly we do not have JIT support for these devices. Is it just a mater to support the ARM instruction set or much more complicated? I would be please to know. Any way for touch devices, you still have the two aspects of Smalltalk to consider: 1. The VM: it will be the interpreted VM, or COG without JIT support. Esteban and Dmitry were really helpful and collaboration was great to let me concentrate on the image level considerations below. 2. Your image. For point 2, you will have extra work, better to take it into account since the beginning of your project if you target touch device: a) no support for multiple touch, at least as far as I know. I read there and there people talking or doing things, but no real stuff. Anyway it is definitely not a show stopper: you can be ok with tap and dragging. But you need to consider it. b) support for the virtual keyboard, Esteban and Dmitry added hook to show or hide the touch device keyboard (see drgeo code with showVirtualkeyboard). In your GUI design, you need to be careful your text zone is not hidden by the virtual keyboard. Again it is resolvable. c) the numerous screen resolutions of the touch devices. For DrGeo and iStoa I took very different directions. Probably the most interesting for you will be the one I took for iStoa. The application window is a full screen morph with scaled bitmap. My bitmap are scaled for a Nexus5 screen resolution (~2500x1600), then graphics and font are downscaled according to the used screen device. I suggest you take a look at the Linux iStoa application and resize the window to see what is happening. Using Athens is definitely not an option now for 2 reasons: it is not supported yet by touch devices; as long as it is not used in Pharo itself, if you put in perspective delivering to end user you have to consider it as unstable. d) native look and feel: it was really a big concern -- the bigger in fact -- for DrGeo. For iStoa it is nearly irrelevant, but there are still some widgets around. Again games does use native widget, so it may be ok. For DrGeo I need to subclass a Pharo theme to remove window decorations, force dialog to be positioned on the top and centered and other details I forgot about. It looks pretty ok for me, but not for touch device users. I tried to share the experience and work on this point but without success[5]. > > 4) Assuming I can arrange for my computer game (if I write it) to be > installed are there memory/cpu usage issues > that I need to worry about (the game itself will use a minimal of > memory/cpu except for graphics which also > is pretty reasonable). I am thinking here of IPads etc. For > Desktops/Laptops there should be no problem. > Download time and subsequent storage space is also a concern; > remember the device is probably used for > lots of other things so the amount of space allocated for games may > be small compared to the space on the > machine? If your code and medias game are small, the image size will be a problem, not something that will prevent your application to work perfectly, but more a feeling of wasted resources. With Pharo1.4, I can shrink DrGeo image below 10MB, including DrGeo code. With Pharo3, I can't get below 16MB with (smaller) istoa code. It is really a deception, the new developer tools were not developed as loadable code. I guess it was too difficult to be done, although it was a promise (informal?) of the Pharo project when it start up. Again it is not a show stopper. Good work on your project, I will be happy to read about its progresses. Hilaire > 5) Sorry for the redundancy if these questions have been asked before > (which I am sure they have). > > Thanks for any feedback; I am sure others are interested in this > question too. > > Ralph Boland [1] https://gforge.inria.fr/scm/?group_id=1308 [2] http://bazaar.launchpad.net/~hilaire-fernandes/istoa/trunk/files/head:/buil… [3] https://itunes.apple.com/us/app/dr.-geometry/id559858173?mt=8 [4] https://play.google.com/store/search?q=drgeo [5] http://forum.world.st/iOS-polymorph-theme-anyone-tt3557696.html -- Dr. Geo http://drgeo.eu

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by Ronie Salgado

Hello, I am working in OSWindow, an API for making/controlling native operating system windows from the image side. It uses SDL2 as a cross platform backend, but I have tested it mostly in Linux, but I could make it run in a hacky way in Windows some week ago. For games, yesterday I could make it work along with NBOpenGL, this one was quite tricky, but in the process I also noticed something interesting about performance. Because SDL2 default renderer for Linux was based in OpenGL, I was having multiples OpenGL contexts in the same image. And they were interfering between them, because they were being called from different Pharo processes! The solution I made was creating a Pharo process, the OSWindowRenderThread, that receives rendering operations, with the objective of serialize rendering operations that require to keep a same OpenGL/Drawing API context. When testing this I made a simple animated example, that required periodic updates. But I didn't knew too much about the Pharo process priorities, so it had a priority too high, so it was blocking Morphic. It was wrong, but the simple animation was very smooth. When I reduced the RenderThread priority, morphic was not blocked anymore, but the animation was not so smooth. So, for video game performance, we should have a look in the Pharo scheduler. I am busy with UFFI/OSWindow/OpenCL and my studies, so is not my priority. For audio, having audio output using SDL2 it is very easy to do, but it relies on callbacks. It also does not support 3D audio. For 3D audio, I would use OpenAL. OpenAL API is not so big, and it does not have a need for callbacks, so his support can be done completely in image side. Greetings, Ronie 2014-05-11 4:15 GMT-04:00 stepharo <stepharo(a)free.fr>: > > On 11/5/14 09:39, kilon alios wrote: > > "What does "not support" mean? People have successfully deployed apps on > both iPhone and Android. Pharo can not (easily) be developed on iPhone but > can be deployed there-on. One can't develop iPhone apps on iPhone. you > need a Mac for that. Does that mean Apple don't support iPhone?? > " > > I think you replied what support means. Support means that there is > group of people out there to support you with your problems on that > platform. Pharo does not officially release for those platforms and there > are only a couple of applications that I know that run on iOS both from the > same developer. So pretty much you are on your own. > > > Well this is not true because Esteban helped a lot hilaire and there is > also Jeff > > "I disagree with 4. If graphics are done by external libraries (and > note that even BitBlt in Pharo/Squeak is not implemented in Squeak, but in > C) graphics can be as fast in Pharo as in anything else." > > It should not be a problem for an educational game anyway , I was > talking about games that are very demanding graphics wise. In those games > most of the code is most demanding anyway and so they use dynamic languages > only for scripting game logic . > > > how can you discuss when the requirements are so under specified. > > > "IMO this is a /really bad/ answer. There are Pharo and Squeak apps > deployed on Android and iPhone. The answer shouldn't be "this is a bad > idea", it should be "you can deploy natively like this..., or you can > deploy with a native UI and Smalltalk logic like this...". But the answer > should never be "this is a bad idea". Alas I don't spend my time deploying > apps so I don't know how to do it, only that people have (I have DrGeo on > my iPhone). So can those that know please write an FAQ that answers > ralph's question? I wish I could :-/" > > Well let me put it this way. Its been 12 hours since the OP has asked > the question and the only two people who answered the question are clueless > about these platforms. I think the situation verifies exactly the situation > I was describing in my reply. > > Come on. When you do not have experience just think twice about what you > think you know and the advice > you want to give. > > > > "Kilon, please don't take this personally but someone could easily > interpret your answer as "you're better off programming in JavaScript. > Pharo can't do deployment. " That's both a terrible and an incorrect > answer. I hope we can do much better." > > I don't take it personally when people disagree with me, I find it > refreshing because I may learn something new. > > No he cant interpet it like "Pharo can't do deployment" because I > already mentioned in my first reply that there are pharo apps distributed > on iOS and especially DrGeo is a really nice app that I have used. if he > interprets my post "you're better off programming in JavaScript" then yes > he would be exactly right. Because that was my intention. I also mentioned > Amber that is Smalltalk that compiles to Javascript so I think I did not > force him to consider only JS as an option. > > By the way I would love to be proven wrong because I also would love to > develop for those platforms with Pharo but right now I dont feel confident > about it. As you said it there is not even documentation about the process. > I remember someone once posted instructions on how to compile Pharo on iOS > but people did not show much interest and it just disappeared. > > Please prove me wrong !!! > > But this is not by saying that people should not do it then. > > Stef > > > > > > On Sun, May 11, 2014 at 12:23 AM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > >> Hi Kilon, Hi Ralph, >> >> I wish I could answer with concrete information. But that's not what I >> spend my time doing. However, I need to correct the impression the >> following answers give. I think they're discouraging to say the least. >> >> On Sat, May 10, 2014 at 2:03 PM, kilon alios <kilon.alios(a)gmail.com>wrote: >> >>> I am no Pharo expert but will try to answer with what I know >>> >>> 1) Pharo download is 16 mb compressed and 58 mb uncompressed. >>> >> >> and can be stripped. It is easy to get a development environment into >> 16Mb (e.g. Newspeak). Applications can easily fit in 16Mb. Applications >> don't need to be deployed with sources or changes files. >> >> >>> 2) Pharo is a standalone and as such it does not need installation. >>> Everything you need is in a single folder contained in a single zip with a >>> single download. I dont think you can get any easier than that. So its a >>> single task. >>> >> >> But there are scripts to create platform-compatible installers on Mac >> OS and Win32 if that's what you want. >> >> >>> 3) There are people who run Pharo on iOS like DrGeo. But Pharo does >>> not support those platforms and most likely you will experience few >>> problems with it. So its some extra work but its doable. They do represent >>> a larger market and a very important one I agree. >>> >> >> What does "not support" mean? People have successfully deployed apps >> on both iPhone and Android. Pharo can not (easily) be developed on iPhone >> but can be deployed there-on. One can't develop iPhone apps on iPhone. >> you need a Mac for that. Does that mean Apple don't support iPhone?? >> >> >>> 4) Again I dont know the issues on those platforms but bare in mid, >>> Pharo is a dynamic language and dynamic language are definetly not a first >>> choice for those platforms for game because they are slower than official >>> supported languages. Those are in iOS ObjectiveC and on Android Java. All >>> that assuming your game has some demanding graphics. For simple graphics >>> with not much animation and such you should be ok. >>> >> >> I disagree with 4. If graphics are done by external libraries (and >> note that even BitBlt in Pharo/Squeak is not implemented in Squeak, but in >> C) graphics can be as fast in Pharo as in anything else. >> >> >>> >>> Personally I think its not a good idea, because Pharo does not support >>> those platforms well. I think that in that scenario there is a better >>> alternative , that of Javascript + Pharo. Its possible to use JS as front >>> end and Pharo as backend. If you dont want to code in Js there is Amber. >>> Web apps are quite performant so you will be able to do some really >>> impressive graphics with this recipe. You will be using also technologies >>> that are well documented and well tested. >>> >> >> IMO this is a /really bad/ answer. There are Pharo and Squeak apps >> deployed on Android and iPhone. The answer shouldn't be "this is a bad >> idea", it should be "you can deploy natively like this..., or you can >> deploy with a native UI and Smalltalk logic like this...". But the answer >> should never be "this is a bad idea". Alas I don't spend my time deploying >> apps so I don't know how to do it, only that people have (I have DrGeo on >> my iPhone). So can those that know please write an FAQ that answers >> ralph's question? I wish I could :-/ >> >> >> >>> >>> Also there are like a ton of game libraries for JS out there. Which >>> will lift the amount of work you will need to do for your game. >>> >> >> Kilon, please don't take this personally but someone could easily >> interpret your answer as "you're better off programming in JavaScript. >> Pharo can't do deployment. " That's both a terrible and an incorrect >> answer. I hope we can do much better. >> >> -- >> best, >> Eliot >> > > >

May 11, 2014

Re: [Pharo-dev] [ANN] Phratch 3.0 released

by jannik laval

Thank you, I am thinking that the problem come from NativeBoost. It is not implemented for Android. I have to retrieve the script to unload it. I remember that there is something like that. And try again. Cheers, Jannik 2014-05-10 22:47 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: > yeah it will probably be quite painful to make pharo work on android > > be happy with what you already accomplished > > great job > > > On Sat, May 10, 2014 at 11:39 PM, jannik laval <jannik.laval(a)gmail.com>wrote: > >> I just tried and with Pharo3.0, the android version seems not working (I >> have a black screen). >> So, it needs more effort to make it work :( >> >> Jannik >> >> >> 2014-05-10 22:35 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >> >> ah ok because my experience with squeak port to android was with sticky >>> clicks, that made it impossible to operate it on a multi touch screen. It >>> did not know when I lift my finger so every touch was just moving a window >>> I selected instead of seeing it as a single click. >>> >>> But its great your are interested in android too. >>> >>> >>> On Sat, May 10, 2014 at 11:23 PM, jannik laval <jannik.laval(a)gmail.com>wrote: >>> >>>> >>>> >>>> >>>> 2014-05-10 22:19 GMT+02:00 kilon alios <kilon.alios(a)gmail.com>: >>>> >>>> just for your information Phratch does not load from Configuration >>>>> Browser, it just displays the same warning again and again about using a >>>>> deprecated method. >>>>> >>>> >>>> Hum, I have to update the config in config browser. >>>> I will do that in 10 minutes. >>>> >>>> Thank you for the report >>>> >>>> >>>>> >>>>> But the main download zip file works fine. >>>>> >>>>> Wow this works on Android too ? awesome. How ? >>>>> >>>> >>>> Not sure the version 3.0 is working. >>>> I am using this process: http://www.phratch.com/archives/408 >>>> >>>> Cheers, >>>> Jannik >>>> >>>> >>>>> >>>>> >>>>> On Sat, May 10, 2014 at 10:50 PM, jannik laval <jannik.laval(a)gmail.com >>>>> > wrote: >>>>> >>>>>> Not for now, I will try asap. >>>>>> >>>>>> Jannik >>>>>> >>>>>> >>>>>> 2014-05-10 12:44 GMT+02:00 Hilaire Fernandes < >>>>>> hilaire.fernandes(a)gmail.com>: >>>>>> >>>>>> Great! >>>>>>> Did you test this new build on Android tablet regarding the fluidity? >>>>>>> >>>>>>> Thanks >>>>>>> >>>>>>> Hilaire >>>>>>> >>>>>>> Le 10/05/2014 08:27, jannik laval a Ã©crit : >>>>>>> > Phratch 3.0 is cleaner, faster and more stable. >>>>>>> >>>>>>> -- >>>>>>> Dr. Geo http://drgeo.eu >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> ~~Jannik Laval~~ >>>>>> Ãcole des Mines de Douai >>>>>> Enseignant-chercheur >>>>>> http://www.jannik-laval.eu >>>>>> http://www.phratch.com >>>>>> http://car.mines-douai.fr/ >>>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> ~~Jannik Laval~~ >>>> Ãcole des Mines de Douai >>>> Enseignant-chercheur >>>> http://www.jannik-laval.eu >>>> http://www.phratch.com >>>> http://car.mines-douai.fr/ >>>> >>> >>> >> >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://car.mines-douai.fr/ >> > > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://www.phratch.com http://car.mines-douai.fr/

May 11, 2014

Re: [Pharo-dev] developing games in Pharo

by stepharo

On 11/5/14 09:39, kilon alios wrote: > "What does "not support" mean? People have successfully deployed apps > on both iPhone and Android. Pharo can not (easily) be developed on > iPhone but can be deployed there-on. One can't develop iPhone apps on > iPhone. you need a Mac for that. Does that mean Apple don't support > iPhone?? > " > > I think you replied what support means. Support means that there is > group of people out there to support you with your problems on that > platform. Pharo does not officially release for those platforms and > there are only a couple of applications that I know that run on iOS > both from the same developer. So pretty much you are on your own. Well this is not true because Esteban helped a lot hilaire and there is also Jeff > "I disagree with 4. If graphics are done by external libraries (and > note that even BitBlt in Pharo/Squeak is not implemented in Squeak, > but in C) graphics can be as fast in Pharo as in anything else." > > It should not be a problem for an educational game anyway , I was > talking about games that are very demanding graphics wise. In those > games most of the code is most demanding anyway and so they use > dynamic languages only for scripting game logic . how can you discuss when the requirements are so under specified. > "IMO this is a /really bad/ answer. There are Pharo and Squeak apps > deployed on Android and iPhone. The answer shouldn't be "this is a > bad idea", it should be "you can deploy natively like this..., or you > can deploy with a native UI and Smalltalk logic like this...". But > the answer should never be "this is a bad idea". Alas I don't spend > my time deploying apps so I don't know how to do it, only that people > have (I have DrGeo on my iPhone). So can those that know please write > an FAQ that answers ralph's question? I wish I could :-/" > > Well let me put it this way. Its been 12 hours since the OP has asked > the question and the only two people who answered the question are > clueless about these platforms. I think the situation verifies exactly > the situation I was describing in my reply. Come on. When you do not have experience just think twice about what you think you know and the advice you want to give. > > "Kilon, please don't take this personally but someone could easily > interpret your answer as "you're better off programming in JavaScript. > Pharo can't do deployment. " That's both a terrible and an incorrect > answer. I hope we can do much better." > > I don't take it personally when people disagree with me, I find it > refreshing because I may learn something new. > > No he cant interpet it like "Pharo can't do deployment" because I > already mentioned in my first reply that there are pharo apps > distributed on iOS and especially DrGeo is a really nice app that I > have used. if he interprets my post "you're better off programming in > JavaScript" then yes he would be exactly right. Because that was my > intention. I also mentioned Amber that is Smalltalk that compiles to > Javascript so I think I did not force him to consider only JS as an > option. > > By the way I would love to be proven wrong because I also would love > to develop for those platforms with Pharo but right now I dont feel > confident about it. As you said it there is not even documentation > about the process. I remember someone once posted instructions on how > to compile Pharo on iOS but people did not show much interest and it > just disappeared. > > Please prove me wrong !!! But this is not by saying that people should not do it then. Stef > > > On Sun, May 11, 2014 at 12:23 AM, Eliot Miranda > <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > Hi Kilon, Hi Ralph, > > I wish I could answer with concrete information. But that's not > what I spend my time doing. However, I need to correct the > impression the following answers give. I think they're > discouraging to say the least. > > On Sat, May 10, 2014 at 2:03 PM, kilon alios > <kilon.alios(a)gmail.com <mailto:kilon.alios@gmail.com>> wrote: > > I am no Pharo expert but will try to answer with what I know > > 1) Pharo download is 16 mb compressed and 58 mb uncompressed. > > > and can be stripped. It is easy to get a development environment > into 16Mb (e.g. Newspeak). Applications can easily fit in 16Mb. > Applications don't need to be deployed with sources or changes files. > > 2) Pharo is a standalone and as such it does not need > installation. Everything you need is in a single folder > contained in a single zip with a single download. I dont think > you can get any easier than that. So its a single task. > > > But there are scripts to create platform-compatible installers on > Mac OS and Win32 if that's what you want. > > 3) There are people who run Pharo on iOS like DrGeo. But Pharo > does not support those platforms and most likely you will > experience few problems with it. So its some extra work but > its doable. They do represent a larger market and a very > important one I agree. > > > What does "not support" mean? People have successfully deployed > apps on both iPhone and Android. Pharo can not (easily) be > developed on iPhone but can be deployed there-on. One can't > develop iPhone apps on iPhone. you need a Mac for that. Does > that mean Apple don't support iPhone?? > > 4) Again I dont know the issues on those platforms but bare in > mid, Pharo is a dynamic language and dynamic language are > definetly not a first choice for those platforms for game > because they are slower than official supported languages. > Those are in iOS ObjectiveC and on Android Java. All that > assuming your game has some demanding graphics. For simple > graphics with not much animation and such you should be ok. > > > I disagree with 4. If graphics are done by external libraries > (and note that even BitBlt in Pharo/Squeak is not implemented in > Squeak, but in C) graphics can be as fast in Pharo as in anything > else. > > > Personally I think its not a good idea, because Pharo does not > support those platforms well. I think that in that scenario > there is a better alternative , that of Javascript + Pharo. > Its possible to use JS as front end and Pharo as backend. If > you dont want to code in Js there is Amber. Web apps are quite > performant so you will be able to do some really impressive > graphics with this recipe. You will be using also technologies > that are well documented and well tested. > > > IMO this is a /really bad/ answer. There are Pharo and Squeak > apps deployed on Android and iPhone. The answer shouldn't be > "this is a bad idea", it should be "you can deploy natively like > this..., or you can deploy with a native UI and Smalltalk logic > like this...". But the answer should never be "this is a bad > idea". Alas I don't spend my time deploying apps so I don't know > how to do it, only that people have (I have DrGeo on my iPhone). > So can those that know please write an FAQ that answers ralph's > question? I wish I could :-/ > > > Also there are like a ton of game libraries for JS out there. > Which will lift the amount of work you will need to do for > your game. > > > Kilon, please don't take this personally but someone could easily > interpret your answer as "you're better off programming in > JavaScript. Pharo can't do deployment. " That's both a terrible > and an incorrect answer. I hope we can do much better. > > -- > best, > Eliot > >

May 11, 2014