Focus for the next release will be preparation of Vincent for official submission to the OpenGL ES conformance test. As such, only fixes relevant to these tests will be prioritized.
- HM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am quite surprised that nobody answer this post...
First, I would like to say that your work is amazing and helping me a lot! I finished today my blog about my project, BlenderCE, if you are interested in it, you can go here:
you made a good work.
i heard you will now optimize vincent for better performance?
that will be great.
im going to make a pocketpc adventure together with a friend, and it will use ogre (i hope so), but till now, vincent is to slow to to this.
mit freundlichen grüßen :-)
cando
Ps: sorry for my english, my german is better...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
eglCreatePixmapSurface should be implemented. Vincent is a great implementation but since it doesn't support this function I cannot use it correctly (currently I have to render in a pbuffer and then use eglCopyBuffers that kills framerate)...
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
You could probably very easily add this yourself based on the code for window surfaces. The natural way to map a pixmap surface would be via GDI bitmap, I believe, which just happens to be the internal representation of a window surface, more or less.
WDYT?
- HM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
As a Mobile Games developer all I can add is my request and advice that Symbian and BREW support is added. Hybrid of Finland supplies an OpenGLES implementation that costs an arm and a leg to use in a commercial game. Getting this going will surely make Vincent a big player on the Mobile scene.
Good Luck.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I am new to embedded devices and had some questions about Vincent. I am working on an ARM 920T device w/ a PX255 Intel processor - so is Vincent the proper choice. Does it work on Linux? I downloaded the source code and all the release notes talk about it working with Visual C++ - are there any issues w/ compiling it on Linux and are there any Makefiles available?
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, GP2X, which is one of the supported platforms, is also ARM920T/Linux. It's probably best to check out the sources directly from SVN, as the current source tar ball on the download page seems to point to an older version (will fix that soon, but might not get to it immediately). There are no makefiles for this build (because I am using a x-dev environment hosted out of Visual Studio), but you really just need to compile and link all the .c/.cpp files.
- HM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Thanks. That helps a lot. However, when I tried to download using the example shown on http://ogl-es.sourceforge.net/getting_started.htm, that is: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ogl-es login, I get prompted for a password. I used both nothing and my email address as a password on different tries, and get the following message:
cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: No route to host
Any help?
Thanks again.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found a link to the svn repository, so please ignore my question about cvs.
I do have another question, however. Sorry to get specific (and if this is not the right place then please direct me), but I have been compiling the code for the ARM/Linux library and found that I cannot compile one of the files - FunctionCache.cpp in the arm directory. At the very end, in void FunctionCache::SyncCache(), the line
CLEAR_INSN_CACHE(targetBuffer, (U8 *) targetBuffer + cg_segment_size(cseg))
does not compile (and I can see why). targetBuffer, cg_segment_size, and cseg are not defined. I can include "segment.h" at the beginning of the file to get cg_segment_size defined, but targetBuffer and cseg look to be variables in a function in PipelinePart and not in this function. Should the line read
CLEAR_INSN_CACHE(base, (U8 *) base + size)
???
Thanks.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The current plan is to publicly release it alongside (and as part of) the Khronos OpenGL SC Adopter's package, which is supposed to be finalized this fall.
- HM
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
PS: SC is a stepping stone towards the 2.0 release, since it is targeting FP-enabled platforms. It's probably another 3 months effort to have a reasonably working 2.0 version together.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have updated my local repository with last EGL header from khronos and update projects for visual 2008.
If you are interested please let me know.
Since you have used your own definition for EGLContext, EGLSurface,... I had to add some casts in egl.cpp
What is the status of OpenFL ES 2.0 ? Are u still working on it ?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
the header in the library is based on the original EGL 1.0 header file, which is the API version that has been implemented [back then those types were defined in the platform-dependent egltypes.h]. Have you just replaced the header file, or did you actually make the implementation compliant to EGL 1.4?
Thanks,
Martin
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
First I thank you for the library .. have some limitations but is great :)
I want ask … I checkouted last revision 646 and there are compilation fails. Which last revision is compilable for ARM4i ?
There are some incompatimility between buffers (U8*, U16*), renamed buffers, configurations fail , etc
Is somebody working on it ?
Thanks
Jarek
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Share your thoughts concerning the next release of Vincent.
Just as update for whoever is watching this:
Focus for the next release will be preparation of Vincent for official submission to the OpenGL ES conformance test. As such, only fixes relevant to these tests will be prioritized.
- HM
Hallo Hans-Martin,
I am quite surprised that nobody answer this post...
First, I would like to say that your work is amazing and helping me a lot! I finished today my blog about my project, BlenderCE, if you are interested in it, you can go here:
http://blenderce.blogspirit.com/
I made a section about Vincent, I hope nothing is wrong there! If you want me to correct something, I will do it immediatly :=)
Concerning the next release of Vincent, would Vincent support drawing texture OES?
Thanks for your work,
Salvatore
Linux support?
Is already coming. I just posted an early version for GP2X (ARM Linux) here: http://www.gp32x.com/board/index.php?s=73d7f563274a33c607828e8a27095258&showtopic=26839
- HM
hi hans-martin...
you made a good work.
i heard you will now optimize vincent for better performance?
that will be great.
im going to make a pocketpc adventure together with a friend, and it will use ogre (i hope so), but till now, vincent is to slow to to this.
mit freundlichen grüßen :-)
cando
Ps: sorry for my english, my german is better...
Hi,
eglCreatePixmapSurface should be implemented. Vincent is a great implementation but since it doesn't support this function I cannot use it correctly (currently I have to render in a pbuffer and then use eglCopyBuffers that kills framerate)...
You could probably very easily add this yourself based on the code for window surfaces. The natural way to map a pixmap surface would be via GDI bitmap, I believe, which just happens to be the internal representation of a window surface, more or less.
WDYT?
- HM
As a Mobile Games developer all I can add is my request and advice that Symbian and BREW support is added. Hybrid of Finland supplies an OpenGLES implementation that costs an arm and a leg to use in a commercial game. Getting this going will surely make Vincent a big player on the Mobile scene.
Good Luck.
I am new to embedded devices and had some questions about Vincent. I am working on an ARM 920T device w/ a PX255 Intel processor - so is Vincent the proper choice. Does it work on Linux? I downloaded the source code and all the release notes talk about it working with Visual C++ - are there any issues w/ compiling it on Linux and are there any Makefiles available?
Thanks.
Yes, GP2X, which is one of the supported platforms, is also ARM920T/Linux. It's probably best to check out the sources directly from SVN, as the current source tar ball on the download page seems to point to an older version (will fix that soon, but might not get to it immediately). There are no makefiles for this build (because I am using a x-dev environment hosted out of Visual Studio), but you really just need to compile and link all the .c/.cpp files.
- HM
Thanks. That helps a lot. However, when I tried to download using the example shown on http://ogl-es.sourceforge.net/getting_started.htm, that is: cvs -d:pserver:anonymous@cvs.sourceforge.net:/cvsroot/ogl-es login, I get prompted for a password. I used both nothing and my email address as a password on different tries, and get the following message:
cvs [login aborted]: connect to cvs.sourceforge.net(66.35.250.207):2401 failed: No route to host
Any help?
Thanks again.
I found a link to the svn repository, so please ignore my question about cvs.
I do have another question, however. Sorry to get specific (and if this is not the right place then please direct me), but I have been compiling the code for the ARM/Linux library and found that I cannot compile one of the files - FunctionCache.cpp in the arm directory. At the very end, in void FunctionCache::SyncCache(), the line
CLEAR_INSN_CACHE(targetBuffer, (U8 *) targetBuffer + cg_segment_size(cseg))
does not compile (and I can see why). targetBuffer, cg_segment_size, and cseg are not defined. I can include "segment.h" at the beginning of the file to get cg_segment_size defined, but targetBuffer and cseg look to be variables in a function in PipelinePart and not in this function. Should the line read
CLEAR_INSN_CACHE(base, (U8 *) base + size)
???
Thanks.
Yes, it should.
Hi,
Hans when will you release a new version of ogles ?
I am talking about OpenGL SC or OPenGL ES 2.x.
Thanks
The current plan is to publicly release it alongside (and as part of) the Khronos OpenGL SC Adopter's package, which is supposed to be finalized this fall.
- HM
PS: SC is a stepping stone towards the 2.0 release, since it is targeting FP-enabled platforms. It's probably another 3 months effort to have a reasonably working 2.0 version together.
Hello Hans,
I have updated my local repository with last EGL header from khronos and update projects for visual 2008.
If you are interested please let me know.
Since you have used your own definition for EGLContext, EGLSurface,... I had to add some casts in egl.cpp
What is the status of OpenFL ES 2.0 ? Are u still working on it ?
Hi Vince,
the header in the library is based on the original EGL 1.0 header file, which is the API version that has been implemented [back then those types were defined in the platform-dependent egltypes.h]. Have you just replaced the header file, or did you actually make the implementation compliant to EGL 1.4?
Thanks,
Martin
Hi,
Actually I took the latest header files from khronos and I have fixed some cast issues.
I haven't implemented anything.
Hi,
First I thank you for the library .. have some limitations but is great :)
I want ask … I checkouted last revision 646 and there are compilation fails. Which last revision is compilable for ARM4i ?
There are some incompatimility between buffers (U8*, U16*), renamed buffers, configurations fail , etc
Is somebody working on it ?
Thanks
Jarek