Hi everyone,
I have a small technical problem to solve and hopefully someone knows an answer for it. Someone gave me a HTC Diamond 2 (very nice toy I think). I don’t know which hardware is exactly inside the phone but I assume it’s an ATI ImageOn 2300 which fully supports OpenGL ES 1.0 + Extension Pack (that’s what GL_EXTENSION is saying). And all of these extensions are doing fine. As everyone knows HTC is not providing a D3D driver for their phones and all other drivers I have seen are just a wrapper around OpenGL ES. So using D3D is currently not an option.
I have to write an application which requires some render-to-texture functionality in realtime and here my problems are starting to grow.
[1] glCopyTexImage2D:
I recognized that glCopyTexImage2D() is very slow. My framerate is dropping dramatically from >100 frames down to ~20 frames. Somehow this is done in software by the driver and not hardware- accelerated. glCopyTexSubImage2D() is even more slow (down to ~10 frames per second), but both functions are working. I tried to move it into a different thread, but the driver is not supporting shared contexts. Also it’s not supporting two bound contexts at the same time with two different windows and threads. So this can’t be improved or I’m doing something wrong.
[2]PBuffers:
PBuffer are working fine. But PBuffers which can be bound to a texture are not supported by OpenGL ES 1.0. And that’s what happens also on this ATI card.
[3]GL_OES_framebuffer_object:
This was my preferred choice. But framebuffers are not officially supported by the installed OpenGL driver. But the libgles_cm.dll on the HTC is exporting these functions so I tried them and recognized that they are not working correctly. Somehow the vertex pipeline is allowing only triangles in the center of the viewport. All others will be discarded. When I turn it off it renders correct. Using glDrawTexiOES() will be ignored while using framebuffers. I assume that either the current implementation of the framebuffers is just waste of some development guys or the functionality is locked in some way.
[4]D3D:
Normally D3DM is supporting to switch between different rendertargets. But we are all know the D3D problem. I tested some other D3D drivers but they are not usable. Also I can’t imagine how render-to-texture will be implemented in these drivers while it’s not working in OpenGL.
I’m wondering what TouchFlow3D is using internally, whether they are using render-to-texture or not. The only thing I know is that they are using OpenGL ES and some extensions. But Manila.exe is querying the functions of libgles_cm.dll during runtime. So I have to write a few proxy dlls first and need to hook into the system to track what they are doing. And I don’t want to spend time on this.
Does someone knows an alternative to do some render-to-texture on the ATI or knows some secrets of the libgles_cm.dll which I don’t know? There are a lot of private functions inside but can’t find some documentation about it. Also ATI and Qualcomm are not very helpful to me.
Thanks.
Maybe, glReadPixels and then glTexSubImage2D (what probably glCopyTexImage2D is doing)?
(I know that this goes two times over the graphics bus, but you never know...)
What kind of scene (number of triangles, lights, textures) are you rendering with > 100fps?
glReadPixels() + glTexImage2D() is even more slow than glCopyTexImage2D...
Also this can't be parallized. I thought using AHI2DATI.dll instead to do the same thing, but I don't know how to get a surface handle from a OpenGL texture id.
>>>What kind of scene?
A very simple scene yet. Only a few depth sorted + material sorted objects (via VBO) with some textures (backed lighting) on it. Textures are compressed. Currently no lighting, no skinning or other things. While the render thread is waiting for glFinish() to return, a second thread prepares the next frame. Also the rendering thread is not redrawing the entire viewport each time.
The OpenGL texture id is the handle. There's nothing more you can do with it. PBuffers or framebuffer objects are the only way I know for doing performant render to texture in OpenGL.
No...I mean the surface handle of the AHI2DATI library. Here you have access to the raw data of the surface. Somehow the libgles_cm.dll uses these surfaces for it own buffers and/or textures or not?!
But this is not really useful unless someone tells us whats going on inside libgles_cm.dll.
See:http://greengalaxy.wordpress.com/2009/04/18/ati-direct-access-to-hardware/
Hi jeansmsixer, I don't think there is no efficient way to do it. Have you tried eglCopyBuffers?
Aren't all textures stored in system memory? - they surely have to be because the device reports no available video mem.
Even if you get a pointer to the color buffer, it's impossible to wrap the memory in a HBITMAP to select onto a HDC and use GDI fonts for instance. (which is what I need to do).
If you do write the proxy dll like you were suggesting, can you please let me know what TF3D does for fonts? Are they textures or have they somehow mixed 3D with GDI?
Hi jeansmsixer, something else you could try is what is described here:
http://brewforums.qualcomm.com/showthread.php?t=10668
Looking on glbenchmark.com it looks like HTC devices support the extension. You should be able to get a pointer directly to the color buffer (which I presume is in normal system memory) so you could copy off pixels fairly efficiently with your own memcpy(). However, you will need to eglWaitGL() etc to ensure 3d stuff is complete before attempting to access it.
I love the irony of the only helpful information for WM opengl being found on a brew site for symbian. If WM7 is as terrible as the current mess, then I'm moving to iPhone.
Related
Hi frens, I would like to know is there anyway to change our device from VGA to QVGA? I mean maybe using some certain software we can toggle between using QVGA or VGA..something like that
Because VGA can't enjoy many cool interface things like Cube, Ifonts, etc
pliz help
did you find a solution ?
i am looking for the same soultion ? did someone find ?
i need it ASAP ?
thx
Not looking likely
Hi Guys
It seems fairly certain to be a no go see my previous threads
http://forum.xda-developers.com/showthread.php?t=350157
http://forum.xda-developers.com/showthread.php?t=347532
http://forum.xda-developers.com/showthread.php?t=351589
Sorry they are all a bit short but you will get the general idea, basically it comes down to there being no apparent way to hotswitch the dpi on a per app basis. The closest thing to any chance of it working would be to have a patch or layer that can emulate a lower res screen which GAPI for HPC's http://www.wincesoft.de/html/gapi_for_hpc_s.html is capable of doing for WinCE boxes that have widescreen resolutions but want to run an older 320x240 game or app so any potential solution would likely have to work along the same lines.
However the main issue is that the gx.dll method would not work in most cases as they are now quite heavily tied into the roms (certainly on my Athena) so I could never test it out fully, a generic or emulation layer based gx.dll would most likely 'break' the newer phones if it was forced into the windows directory and from some basic testing before simply placing the HPC gx.dll in the app directory does not enable you to make use of it as the base gx.dll is already resident in ram when the phones are started. I also tried reshacking a couple of apps and changing it to look for xg.dll and renaming the HPC one to match but that just broke everything as you have to re-sign the app which I managed but it just plain refuses to run and either brings up an error message or just does nothing when you run it.
Wow a bit long winded sorry about that but it may help anyone who wants to take up the challenge
I wrote some Managed Direct3D Mobile code, using fixed point arithmetic. It runs slow as a dog and its performance relative to the floating point version of the code shows little improvement.
This is on a Kaiser phone. I know that there are issues with graphics on that thing. I am only trying to use the software renderer, but the speed of my app is so slow that I wonder if it's in my implementation. It is a cube with textured faces, spinning as as fast as it can, and I can only achieve 7 seconds per frame (yes... seconds per frame. Obviously my goal is something in the FPS range!).
Would anyone with experience in writing D3DM code care to give me a hand by looking at my code? I'm at kramer (underscore inserted) ae (at) hotmail (dot) com.
Thanks,
Brian
Sorry to say the Kaiser only has reference drivers for d3dm, all software driven. Thats why its a dog.
and it also dont help that ms stoped all development of Managed Directx along time agoe and most people who wanna do 3d from .net these days use opengl
also on a as weak platform as arm compared to pc
.net being much much relatively slow on arm compared to on x86
doing 3d in a not truely native language as c++ will never give much speed
less so when it comes to graphics
These comments aren't helping. I understand that my environment is not up to industry standards in terms of performance (15-60 fps, for example). But rendering a cube in Direct3D should not be as bad as one frame every 10 seconds. I'm in search of someone who knows the correct baseline performance expectation for my scenario and can help bring the perf of my simple 3D application in line with what is really expected. Alternatively, there may be anecotal information that says my application is actually performing as fast as expected. I don't know that.
The attached archive contains a native and a managed D3D example showing a rotating textured cylinder (from the WM6 SDK). Both run interactive on my HTC Touch (Elf).
*** PLEASE READ CAREFULLY BEFORE INSTALLING OR FLASHING ANY SOFTWARE POSTED IN THIS THREAD ***
The software posted here is for TESTING purposes only, Team P3D or any of the posters of software, or links to software on this thread take absolutely no responsibility or liability for damage caused by the result of installing or flashing software or links to software found on this thread - correctly or otherwise, you do so on the sole understanding that you do so at your own risk.
---------------------------------------------------------------------------------------------------------------------------------------------------------------
Project Name: Polaris 2D Driver Project
Driver Name: P3D 2D Driver (Working title)
Development and Testing Team: SEE Post #2
---------------------------------------------------------------------------------------------------------------------------------------------------------------
ANNOUNCEMENT:
The P3D team would like to extend an OPEN INVITATION to all developers and programmers from all forums of EVERY device to come forward and help us create the 2D driver which, as it is being developed from scratch will require much development work with many dll files created from scratch.
If you are interested in helping, please post your interest in this forum and we will add your name to the developers list. If you would like to help but own a different device to which the 3D driver is yet to be ported to, we would also like to hear from you and hopefully assist you with the knowledge we have gained in return for your efforts here. (actually we'll help you anyway but.. we do want your help! )
---------------------------------------------------------------------------------------------------------------------------------------------------------------
11/10 - BigKVak successfully dumped the G810 rom and work has started in analyzing its content
---------------------------------------------------------------------------------------------------------------------------------------------------------------
P3D 2D Driver Development Team:
Administration/Testing:
Support and Testing:
Bally3
NikMel
Neos2007
BigKvak
Imfloflo
Developers: (TBC)
Rogro82
NuShrike
Chainfire
Monkeyass
maqui01
It started with a few simple questions:
"Can the Polaris be hardware accelerated?"
"Why doesnt the CA Kaiser 3D driver work on the Polaris?"
That was a month ago..since then, thanks to the help and support of NikMel, NeoS2007, Rogro82 and NuShrike to name a few, we now have a working 3D driver which is currently in a version 1 state and with the release of the cab version through CA last night, we can now concentrate on improving speed and compatibility to make better use of the graphic chips capabilities.
My intention then was never to start a 2D driver or work on a 2D driver until I was satisfied no more could be done to improve it and a "final" release was in the cards, but through my own testing and various posts and conversations, I now find myself wondering whether the improvements with 3D is linked to the 2D driver?
From day 1, before we released the 3d driver and after, users have expressed faster speeds in 2d as well as 3d - though many have explained it to be a "placebo" effect, we naturally attributed this to the gpu sharing the workload with the cpu which makes sense in a common sense way - itje posted a humorous answer on his thread explaining this very thing as worth a read just to put a smile on your face, but on a serious note a question has to be asked - Does improvement on 3D really effect 2D and if that is the case, would a 2D driver help improve the 3D drivers perfornance?
So why start a 2D thread when the 3D driver still needs refining?
Well, apart from the question above, the overwhelming requests for 2D support on both Polaris and Kaiser forums (it should work on both in theory), we now have a dump of the long awaited Toshiba G810 rom to get us started- A BIG THANK YOU TO BIGKVAK - welcome to the team!
Originally Posted by BigKvak
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
It is inevitable then that work needs to start on this project. We also need to preserve the 3D thread for future 3D driver developments and defer 2D driver related posts from it, for these reasons, this new thread has been opened for all to start working with the P3D team in bringing 2D greatness to our devices.
Lets share our knowledge and have fun doing it like we did with the 3D driver!
PS: Although I have named the project Polaris 3D driver project, I would like to extend an invitation to users of all devices that could benefit from the 2D drivers creation, after all through CA Kaiser development, we have now ported the 3D driver to the Polaris AND the NIKE and hopefully to many more devices
Let our devices not make us divisive - whats is the point?
It is common knowledge that files from newer devices are used to help create the drivers we need for our devices - so why should we gloat and mock other less supported devices, should we not help them and share our knowledge and in the words of a good friend here "Pay it Forward?"
This is not the spirit of XDA Developers and it is certainly not the ethos of Team P3D - We have and pledge tol share all knowledge with users of all devices.
Besides, its so much more fun when we all work together!
It appears that HTC-CA were already in the process of
Reserved for p3d 4
Reserved for p3d 5
Reserved for p3d 6
Reserved for p3d 7
Reserved for p3d 8
Reserved for p3d 9
Reserved for p3d 10
I found this link on microsoft MSDN: http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1214862&SiteID=1
It's a guy asking for a 2d driver library. Maybe we can look into that?
I have dumped ROM from Toshiba, here the link http://rapidshare.com/files/152085600/dump.rar.html
Click to expand...
Click to collapse
To move the discussion of 2d in here..
Windows Mobile 2D and 3D explained on MSDN
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Here's what functions there are:
AlphaBlend API
Provides information about adding support for the AlphaBlend function to your OS design.
Direct3D Mobile
Provide information about adding 3-D graphics support to your OS design and creating applications that use the API.
DirectDraw
Provide information about adding 2-D graphics support to your OS design and creating applications that use the API.
Gradient Fill Support
Provides information about adding support for the GradientFill function to your OS design.
Imaging
Provide information about adding support for compressed still images to your OS design and reference information for the API.
Multiple Screens
Provide information about adding support for multiple displays to your OS design and creating applications to support them.
NeoS2007 said:
I believe this: http://msdn.microsoft.com/en-us/library/aa911096.aspx will be out first place to look. It's mostly there: 2D AND 3D info.
Click to expand...
Click to collapse
reading it now.. some of it we know.. let see what we can learn..
http://msdn.microsoft.com/en-us/library/aa925824.aspx
Here we go:
"Applications direct output to a specified device by creating a device context for the device. The device context is a GDI-managed structure containing information about the device. An application creates a device context by calling device context functions. GDI returns a device context handle used to identify the device.
Applications can direct output to a physical device, such as a display or printer, or to a logical device, such as a memory device.
A device context also contains attributes that determine how GDI functions interact with a device. These attributes eliminate the need to specify every piece of information Windows Embedded CE requires to display an object on a device. If you want to change an attribute, you can use attribute functions to change current device settings and operating modes. Operating modes include text and background colors and the mixing mode that specifies how colors in a pen or brush combine with colors already on a display surface."
GDI is the source of 2D on our devices. Maybe we need to look out for GDI tweaks in the registry?
BPP (Bits Per Pixel) explained
I also found this blog about the colors used on a mobile device. It's said that if you have a colordepth of 18 instead of the usual 8, 16, 32 bits, it's more cpu intensive. Isn't there a registry key for colordepth?
http://blogs.msdn.com/windowsmobile/archive/2005/09/07/462187.aspx
"The next thing to understand is how the bits turn into colors on the screen. Say you've got a typical PocketPC with a resolution of 240x320 and 65536 colors. That means you've got 320 rows of 240 pixels (dots), each of which has 16 bits of data representing its color. All of that information is stored in a chunk of memory known as the "Frame Buffer." The LCD hardware takes whatever is in the Frame Buffer and converts it directly to what's on the screen. Want to change what's on the screen? Change what's in the Frame Buffer and the screen will update.
Okay, so we need 16 bits for every pixel, and we've got 240 times 320 dots. 16 bits is two bytes, so that's a total of 153600 bytes, or 150K of RAM used to hold what's on the screen."
Maybe a good thing to mention: we're hoping that the Toshiba g810 Portege has the files we need to develop a 2D driver. We're currently trying to extract a dump we got. Anyone have experience in extracting Toshiba's .Bin files?
Direct Draw explained
On MSDN:
"The DirectDraw® API provides support for hardware-accelerated 2-D graphics. It offers fast access to display hardware while retaining compatibility with the Windows graphics device interface (GDI). DirectDraw is a specialized memory manager for both system and display device memory and uses hardware acceleration where available. With DirectDraw, you can allocate and manipulate both system and graphics memory, including transfers between the two.
DirectDraw for Windows Embedded CE is adapted from DirectDraw for Windows-based desktop operating systems. Some capabilities from the desktop version have been extended and others have been curtailed to better suit embedded devices.
DirectDraw supports the following effects:
Bit-block transfers (blits)
Page flipping and multiple back buffers
Overlays, which is placing one image surface over another on the video display
Alpha source over destination blending, which is blending two surfaces using the source alpha image component
Video YUV pixel formats and color conversion
Direct video access to the frame buffer
What if we compare our HKLM\system\DDRAW\ keys in the registry with other devices? I see the values in ALL keys there are empty.
Yes.. I've noticed that and played around with them.. no difference.
I've tried the LG KS520, Diamond and HD ddraw.dll files.. none work out of the box. Maybe the G810 one might make a difference?
We need to find out what calls are made and to what other dll files. If you remember the problem we had with the 3.13 ddi? it could be similar situation in that theirs a dependencies issue.
General info:
Samsung S3C6410 processor supports OpenGL ES 1.1 and 2.0, but for some reason Samsung didn't include any proper OpenGL ES 1.0 implementation on our devices.
This is the project of creating a libgles_cm.dll library which compensates this.
So, here is the release of the OpenGL ES 3D v1 (and HTC) compatibility layer for Samsung Omnia II, Pro (Qwerty) and Giorgio Armani 2 (and M900 and...):
Installation:
ZIP download (current version):
(original GinKage material) Download it by clicking on this link.
The zip contains libgles_cm.dll, put this in your \Windows folder for activation across the entire device, or in the same folder as the EXE of the program you want to try this with.
CAB download (version 0.26):
(some additions by Chainfire) Attached!
This CAB will place the libgles_cm.dll file in your \Windows folder (unsigned). This means it will be used by all (capable) programs. I have also included libgles_cl.dll (an adaption from NuShrike's CL), which may add some compatibility for some games, but is untested in combination with GinKage's CM library.
Note:Don't forget to switch your device to HIGH performance mode or plug a charge adapter otherwise you won't get any decent performance.
Compatibility:
What works:
Xtrakt
Experiment 13
HTC TouchFlo3D v1.3, v2.0, HTC Sense v2.5
Tower Defense
Flight Commander
10 Games for Betting
S2P 0.80
Opera Mobile 9.7
glBenchmark 1.0/1.1
TestOpenGL
HG Engine (Hologram App) and HG Proton [reported by daskalos]
Known issues:
glBenchmark hangs after 10-13 tests, don't know why. So, if you want to benchmark, do it in 3-4 runs, few tests at a time. Also, 'Flat' shading mode doesn't work, everything renders as 'Smooth'.
Xtrakt has some minor texturing issues (as you may see on fonts) due to the unsupported 1024x1024 texture resolution. Although it's perfectly playable.
Some alpha-blensing issues with Spb Mobile Shell 3.5.2 and earlier, NFS: Undercover, 10 Games for Betting and Call of Duty 2.
What does NOT work:
Spb Mobile Shell 3.5.2 and earlier. Although you may switch acceleration on by registry at [HKLM\Software\Spb Software House 2\Spb Mobile Shell\Gl\], setting GlEnabed to 1, but it is really unusable: you can't tap on a panel or a message to select it, you can only swipe to rotate carousel. I don't really care, because Spb already added GL2 support in the later releases.
NFS: Undercover. Almost worked for some time, but used to hang or crash randomly, and now it won't start at all. Again, I don't really care, as there is NFS in Samsung's AppStore.
Tons of GL apps.
Remember, I DON'T actually want to know about apps that DON'T work.
What I DO want to know about, is if anything else apart from
the list above work. That would really be a surprise!
Source code
The project is open-sourced. There are three main reasons for this:
I want the project to evolve, even when I don't have enough time for it.
I want to see more GL2 applications for Omnia 2 created by third-party developers (waiting for a Samsung's GL2 SDK is some pain).
I want Samsung to finally fix their own GL2 driver (and I hope that maybe this lib's sources will help).
So, I don't really think there's any other way to make these wishes possible.
Project source is available at SourceForge here: http://sourceforge.net/projects/omnia2gl/
To build the source code you'll need Visual Studio 2008, Windows Mobile 6 SDK and GL2_SDK.zip from the Files section of the SourceForge project.
At the moment, only me (GinKage) and Chainfire are the project admins, so if you have something to commit you'll need to contact us.
You may also find Screentex source there. Simple app it is, but it may be compiled in both GL1 and GL2 modes (some time earlier, it was also D3DM-compliant, not sure about it now).
I kindly ask you not to criticize the code too much, as I haven't even tried to make it look like industrial-standard.
It was created as a hobby, a brain siesta. If you want to prettify it, do it (and send us a patch, so it would find its way to SVN).
Also, if you use some parts of the code, please do mention us (GinKage, Chainfire, NuShrike) in credits. That's all I ask in return.
Bonus (for Samsung representatives if any):
A short list of some stupid bugs found in Samsung's driver during my work on this project:
eglGetDisplay(0) fails. It should work with a zero argument, by standard, but it fails.
Calling glGetString() before eglInitialize(), crashes.
eglGetConfigs with config_size = 4096 crashes.
glBindBuffer generates GL_OUT_OF_MEMORY if buffer number is above 100 (it is an actual limit hard-wired into libGLESv2, I had to re-implement the whole buffer management by myself). And, Xtrakt needs 102 buffers...
glGetIntegerv(GL_MAX_TEXTURE_UNITS) returns 0 instead of 2. This one totally breaks NFS.
glGetIntegerv(GL_MAX_TEXTURE_SIZE) returns 2048. In reality, every texture larger than 512x512 is going to be ignored at all, with some allocaton errors in debugger output. It may be used with S3TC, but it's DXT1 only, not even DXT5. And, somehow, with a GL_RGBA_S3TC_OES format, an alpha bit is ignored at all.
And don't forget to create mipmaps, or GL_*_MIPMAP_* won't draw anything at all (it should just use the only level available)!
glAlphaFuncEXP is not iplemented in libGLESv2 (though the hardware DOES have this available), had to do a hack for this to work.
glViewport works wrong after all. If the parameters, e.g. X and Width have a larger sum than the width of the window surface, then the resulting width is clamped, which results in scaled down rendering.
eglCreateWindowSurface is a fail: it doesn't track window size change at all, so if you create a surface and change window size, your output will be of an inadequate size (e.g., in Opera 9.7 going from Widowed mode to Fullscreen, or in anything else when going from Landscape to Portrait mode).
eglSwapBuffers is slow as hell (probably because of plain BitBlt it uses), it takes about 10 ms, which limits fps to about 100 and reduces the speed of everything else (e.g., you'll get 16 fps where you could have 20, only because of this functon).
All textures have an offset by half-texel. This is probably done for mapping to the nearest texel (like, round(u + 0.5)), but it breaks everything that is drawn, for example, with glOrtho (like Opera 9.7). Well, not exactly breaks, but everything look "smoothed out".
Release history:
Version 0.2, pre-alpha (Sep 24, 2009)
Initial release (proof-of-concept)
Version 0.25 (Nov 2, 2009)
One of the nicest updates. Faster, smaller, better. That is:
It does QTC texture decompression more quickly, so Xtrakt loads a tad faster, and lags in TF3D were reduced (though haven't gone completely).
It has a smaller footprint, so Acer M900 users should be able to run Xtrakt now.
It allows to run an original unmodified TouchFLO 3D 1.3 (fixes yet another Samsung's bug, this time in glViewport). Maybe it can do even more, but that was not tested.
CFC 0.60 fully supported.
Though, if you want TF3D 1.3, I strongly advise you to use Chainfire's package with recompressed textures, as they have better quality, the package itself is significantly smaller and it runs much faster.
Version 0.256 (Nov 14, 2009)
A minor yet highly recommended update!
Introduced a minus half-texel offset for every texture coordinate that libgles renders (yet another Samsung's bug).
The difference, now, is huge. First thing you'll probably notice, is a perfect (pixel-wise) Opera 9.7 rendering.
Second, some of the irritating lines in Xtrakt are gone as well.
Third, Tower Defense gets a tiny bit more clear and sharp look.
Version 0.257 (Nov 20, 2009)
Following games are now supported:
Flight Commander
Experiment 13
Version 0.258 (Nov 29, 2009)
Yet another minor update:
adds PVRTC support (not sure if it gives anything useful, but let it be: maybe some game for Dell Axim will finally work, maybe not);
fixes minor ambient lighting issue (as seen in TestOpenGL's donut test;
removes matrix palette from extensions list (so that glBenchmark 1.1 wouldn't hang);
and fixes a crash on MindPol's Coin game from their 10 Games for Betting.
I'd say, the latter game is the only reason why anyone would want to update.
Congratulations to MindPol on getting Bronze medal in App Contest with this one!
Version 0.26 (Feb 23, 2010)
Back to the two-digit version numbers!
S2P 0.80 crash fixed;
HTC Sense 2.5 texturing and crashes fixed.
hi, is this compatible with the omnia pro b7610?
So, here is the release of the OpenGL ES 3D v1 (and HTC) compatibility layer for Samsung Omnia II, Pro (Qwerty) and Giorgio Armani 2 (and M900 and...):
Click to expand...
Click to collapse
Sure, as you can see.
Nice work !
Will you GinKage continue this project ? or 0.26 is the last version ?
ginkae please fix HTC Sense v2.5 landscape mode
Here's what I have observed after I installed the OpenGl 1.0 in my M900.
1) xtrakt and testOpenGL works fine with the current drivers.
2) When .net compact framework 3.5 is installed both applications crashed.
3) After unistalling .NET compact framework 3.5 still both xtrakt and testOpenGL crashes. Thus leaving me no choice but to hard reset the phone and re-install the drivers.
I am not sure what i am doing wrong but i wanted to know if there are known issues running both .NET framework and the openGL drivers in M900.
BTW, i am using daskalos custom lite ROM
THanks.
Can't say anything about M900, as I neither have one neither do I have any friends who has it.
And, as for Sense 2.5, I'll wait a bit, as I don't want to reflash right now, because I've finally found a good and stable firmware, and tweaked it all the way through. I'll wait for an official 6.5.3 ROM: someone says it may also have issues with Opera 9.7, so I'll have to dig through those sources once again anyway.
So, 0.26 is probably not the last version. Although I'm just not sure what else can I squeeze out of this project apart from fixing some annoying bugs.
I have with experience in VLSI, shell scripting (bash, windows powershell) and basic programming languages like C and Python (Matlab too, which uses a similar syntax).
I want to get into app development but I am completely new to this and unfamiliar with the whole structure - the IO libraries, rendering libraries especially. I mainly like to develop it for Windows 11 (but would be nice if I could make it cross platform, say using something like Vulkan as rendering library).
I wish to make a stylus based note making app (similar to one note, drawboard pdf etc). I wish to know about the libraries available for taking input from surface pen (or other pens). I found that there are a few API available for windows - RealtimeStylus, Windows Ink, etc but I am unable to find anything cross platform. I would like to know if there are open source, or cross platform alternatives. Alternately, I would like to know if it is possible to bypass these and create a custom API myself (including my own algorithms for tracing curves and predicting handwriting etc, at present I am left to use whatever was done in these APIs I think), also possibly making it lower latency within the app. To some extent I realized that pen position is very similar to trackpad input (on the data input to pc side) and then we have tilt and pressure sensitivity data which I'm not sure how it is accessed and used. I remember reading a little about libsdl sometime ago. I would like to know if there are alternatives to libsdl, or if Vulkan supports any alternate libraries.
I would like to know how I could code a program that works on both x64 and aarch64 on windows 11 (Not into 32 bit as I belive my tool will use more than 4GB RAM anyway, as a priority), and as mentioned above, it would be fantastic if I could make it cross platform. What I got from this page is that ( https://docs.microsoft.com/en-us/windows/arm/ ) if I write my program in C++ it should be possible to compile it for both x64 and aarch64 (and make possible optimizations for each of them separately). I am not sure how the whole development environment works - what is dotnet, what is unity, what is xamarin, and differences between each. I found a few code macros in dotnet that help in rejecting certain inputs (could be useful for palm rejection etc) : ( https://docs.microsoft.com/en-us/do...s.uielement.isinputmethodenabled?view=net-5.0 ) (https://docs.microsoft.com/en-us/dotnet/api/system.windows.uielement.ishittestvisible?view=net-5.0 ). As far as I am aware dotnet is cross platform. I might want to make instruction level optimizations to the software (like SSE, AVX, certain 64 bit instructions etc if that gives any hint) and would like to know if the dotnet environment/toolkit has sufficient low level coding possibility to access these. Also, I am curious if it supports vulkan or opengl. Vulkan is written in C++ and supports multiple platforms so I am more inclined to try it.