Entraides et échanges autour de la technologie Scol - Informations and exchanges on the Scol technology
Vous pouvez changer la langue de l'interface une fois inscrit - You can change the language once registered
You are not logged in.
Pages: 1
Here a post to initiate discussion to get the good way of how we could port Scol on tablets.
What you need to know :
- scol actually start the scol voyager and then a new process for the application.
- This is not compatible for tablets since the current application should be associated to the displayed content. (Or am I wrong ?)
randoms ideas :
- make scol a deamon that instantiate scol VMs (don't like that too much on first though and this will be again os specific code to set a deamon)
- limit scol to stand alone applications on tablets, forget the voyager.
- make the kernel.dll free of os specific code and put that code into the executable file (myloop in usmwin.exe and additional dll entries in the kernel dll)
- from the following idea make an executable per OS and send inputs / app window to the kernel
- avoid window creation in a first step and only allow create the 3D buffer on the window (so all fullscreen and full 3D).
- so no 2D content for now (a 2D library per OS could be made later to allow 2D applications, but most API like windows 8 or android need fixed xml content for 2D controls so need to find a way)
- against create 2D libraries create only a more complete native 2D interfaces on 3D buffer (using widgets).
most tablet os need special manipulations / paid accounts to create an app on the store to distribute it.
- visual studio for windows 8 and build the application manifest, pay for the right to upload on store (and pay again for certification ?)
- android package is just a zip so it could be managed by code I think, but package signing and the upload on store should be manual
- IOS tsss... help
sure all this suppose all the scol libraries to be port on each OS.
The less work to start should be windows 8 metro app (not sure at all).
For the 3D engine :
- does Chronium can be compiled for all the OS ?
- remove the windows message hook and find a common solution (maybe use a kernel callback that communicate with the OS executable ?)
- need boost to works with ASIO / threads on each OS
- port to Ogre DirectX11 renderer for windows 8 / metro
- good news Ogre works on all this several OS
- Newton ?
BitmapToolkit :
- use OpenCV, this should not be too much complicated (I hope)
- Need specific OS code to detect / list / use the video inputs (webcams)
Sound :
- the sound library use OpenAL / Caudio
- no idea on this for now, I think openAL must be ready
Inputs :
- touch screen / mouse
so much work ^^
Offline
is there a way the vm could communicate to existing ports of components? for example, i think ogre (and newton? I don't know about newton) has been ported to the big 3 (ios, android, and windows metro(although metro isn't all that big like the other two)....could the vm call the c functions of these components in the case of ogre?
as for the 2d gui that does not appear within the 3d buffer, perhaps port the vm logic (math functions, logic functions, data structures like strings, lists, tables, structs) to various operating systems, and let the programmer use os specific api's for each os (so the vm would manage 3d scenes/phsycis/ and sound, along with logic), and it would communicate to the various windowing systems of the other operating systems.
i'm pretty ignorant here, but perhaps i have some completely unintended insights.
Offline
scol works with C/C++ binds to link a function to the scol language.
So sure to build the SO3 we will be able to compile ogre to the specific platform first, but scol dlls need the same work also.
3D buffer is 3D buffer, 2D component on this (like SO3 widgets) can only be 3D faces on the 3D view.
We can't gives access to OS specific function without providing them first to the scol language.
and the goal of scol is to use the scol language to make the same result on all platforms.
Offline
scol works with C/C++ binds to link a function to the scol language.
So sure to build the SO3 we will be able to compile ogre to the specific platform first, but scol dlls need the same work also.3D buffer is 3D buffer, 2D component on this (like SO3 widgets) can only be 3D faces on the 3D view.
We can't gives access to OS specific function without providing them first to the scol language.
and the goal of scol is to use the scol language to make the same result on all platforms.
I see, yes if that is the goal (to have a universal language like java) I understand. And I see it would be wasted time to make os specific calls when your goal is to make the same calls to all operating systems.
It's alot of work! But I think it will greatly expand the scol user base.
Offline
Another idea (which probably be on a level that you have already thought about): port basic scol non-graphic functions to each os, (basic types, strings, lists, numbers, etc.) along with the 3d engine. make an interface for the vm to send messages to its os environment (something like sending an activex message to a vb project), and each os will handle these messages in its own way. then the goal further down the way would be to incorporate os independent 2d ui calls to the vm.
Offline
the scol kernel (scol.dll) is the virtual machine that is the minimum requirement to execute scol language.
and no it can't work this way
Offline
any further comments on my part will make me appear even more ignorant, so nor more technical ideas from me.
Offline
- make scol a deamon that instantiate scol VMs (don't like that too much on first though and this will be again os specific code to set a deamon)
Write a specific code for each OS is the work for any Virtual Machine. The VM must take itself all specific code to provide the same APIs for any users.
- limit scol to stand alone applications on tablets, forget the voyager.
And i think to remove all hard coded loading packages in the VM (locked/lib/...)
- make the kernel.dll free of os specific code and put that code into the executable file
i don't understand what you wish.
- avoid window creation in a first step and only allow create the 3D buffer on the window (so all fullscreen and full 3D).
- so no 2D content for now (a 2D library per OS could be made later to allow 2D applications, but most API like windows 8 or android need fixed xml content for 2D controls so need to find a way
- against create 2D libraries create only a more complete native 2D interfaces on 3D buffer (using widgets).
Thus, allow 3D apps only ?
- does Chronium can be compiled for all the OS ?
I think yes.
- remove the windows message hook and find a common solution
Yes. There are the POSIX solutions ? but might not for Windows 7/8 (?).
If i understand all, you estimate that a specific code should be write for tablets.
Offline
At least one executable by OS this is why it could be easier if all OS specific code is removed from the kernel and put it in the executable
Only 3D at the first step yes at least a default 3D buffer
since the use on tablet will be most of the time end user applications distributed on a store and since apple do not allow VMs I think managing a demon would be a lost of time
Offline
Hello,
1) I don't think that we necessarily have to keep the Voyager approach (The Scol Voyager + new processes for applications) for tablets' Scol implementation.
This is a heavy load for a tablet as we need to launch two VM for a single (originally wanted) task.
Furthermore, if Arkeon is right, we may technicaly be unable to keep the current approach.
So standalone applications certainly are a solution.
2) "- make the kernel.dll free of os specific code and put that code into the executable file (myloop in usmwin.exe and additional dll entries in the kernel dll)
- from the following idea make an executable per OS and send inputs / app window to the kernel"
I'm not sure that it will be a simple task to separate OS dependant and independant functionalities, but it's a good idea.
3) "The less work to start should be windows 8 metro app (not sure at all)."
I agree with that. It seems logical.
Then comes Android ...
And then iOS if we can find a developer for that ...
I have to read some Android documentation before I make a new point on all this.
Bob
Offline
1) I don't think that we necessarily have to keep the Voyager approach (The Scol Voyager + new processes for applications) for tablets' Scol implementation.
This is a heavy load for a tablet as we need to launch two VM for a single (originally wanted) task.
Furthermore, if Arkeon is right, we may technicaly be unable to keep the current approach.
So standalone applications certainly are a solution.
Yes.
I think also that allowing for developers to load some libraries only. In particular, Scol loads in start-up the lexer and the compiler and few functions (like the current *.scol), next, loads other libraries (dll / so / ...) then launches the app. In the script, we have _load "package", we could add _loadLibrarie "librarie_name" or something like that. By default (if no libraries is set), all are loaded. The main difficulty may come from the compiler.
By example, the primary VM needs 2 or 3 libraries only to running.
Another application need not 2d graphics, newton, zzoEngine, etc...
Less memory used, start-up faster, ...
Offline
The idea for _loadlibrary() is a tempting one ...
Offline
Should we post ideas about scol functionality (what people do with 3d on phones/tablets as opposed to laptops/desktops) on mobile devices to this thread or should I start another one.
Offline
Pages: 1