Recent Posts

Pages: 1 ... 6 7 [8] 9 10
71
Support / Re: Crash (native)
« Last post by AeroShark333 on September 19, 2018, 12:36:48 pm »
Unfortunately I am still getting the SIGSEGV errors...

However, I came across this:
https://stackoverflow.com/questions/18531835/java-android-fatal-signal-11-sigsegv
"The answer was that the buffer wasn't big enough. Then the openGL API (in my case) accessed an invalid offset (in low-level) and caused a segmentation fault, just like one would get for accessing invalid memory in C. This happens outside of java because bytebuffers are managed by the kernel to allow hardware and low-level code work with your memory."
Is it possible to check the buffers are initialized properly or something? (like see if everything (begin and end) in the buffer is accessible)
I don't know which buffer the problem is (I suppose jPCT has multiple buffers for different things)

Workflow:
Load the Object3D's (by world.renderScene + world.draw) individually which works fine (this should upload their meshes to the GPU I suppose)
Load textures and blit textures (so the VM memory is cleared)
Give all Object3D's their new scaling + position
Add all Object3D's to the world
@first draw world call => SIGSEGV crash (does not always crash)

Note: lower poly models reduce the crash rates
72
Support / Re: Float Positioning Blit Images
« Last post by AGP on September 07, 2018, 08:05:44 pm »
Quote
That's a whole different beast. Would it be sufficient to have them without depth buffering?

Is that like that one I did by extending Polylines? If so, no. ; )

I still haven't solved that displacement issue with AWTGLCanvas, by the way. I don't mean to be pushy but I dream of a day when you update the lwjgl version.
73
Support / Re: Float Positioning Blit Images
« Last post by EgonOlsen on September 06, 2018, 10:43:06 pm »
Hello,

getting back again on this matter, the outcome was because on Hardware Renderer we can blit with a floating coordinate system, whereas in the softwre renderer we can't, but we could use floating type for both and then just use the float point for hardware and cast to int on the software renderer, thus having the legacy code running well keeping compatibilty. I think that was the feasable idea behind this whole conversation.

lemme know if its possible to do or not,

many thanks,

Ok...as always, even simple things are not as simple as they seem at first glance, but this might do the trick:

https://jpct.de/download/beta/jpct.jar

and for jPCT-AE

https://jpct.de/download/beta/jpct_ae.jar

I've simply replaced the int types in the blit methods by floats. It worked fine on my tests albeit I didn't test the actual sub-pixel stuff.
74
Support / Re: Float Positioning Blit Images
« Last post by EgonOlsen on September 05, 2018, 08:10:24 am »
That's a whole different beast. Would it be sufficient to have them without depth buffering?
75
Support / Re: Float Positioning Blit Images
« Last post by AGP on September 04, 2018, 11:45:20 pm »
And software-rendered Polylines, please?
76
Support / Re: Float Positioning Blit Images
« Last post by EgonOlsen on September 04, 2018, 08:58:29 pm »
Yes, that should work. I'll try to add it in the next few days.
77
Support / Re: Float Positioning Blit Images
« Last post by Jamiro on September 01, 2018, 07:56:08 pm »
Hello,

getting back again on this matter, the outcome was because on Hardware Renderer we can blit with a floating coordinate system, whereas in the softwre renderer we can't, but we could use floating type for both and then just use the float point for hardware and cast to int on the software renderer, thus having the legacy code running well keeping compatibilty. I think that was the feasable idea behind this whole conversation.

lemme know if its possible to do or not,

many thanks,
78
Support / Re: How to convert a texture to a bitmap?
« Last post by EgonOlsen on July 31, 2018, 09:14:04 am »
Yes...but...why? If you have created a texture, you already have a bitmap...???
79
Support / Re: Camera rotation issue
« Last post by EgonOlsen on July 31, 2018, 09:13:26 am »
There will always be SIGSEGVs...no driver is perfect and people are doing all kinds of strange things with their devices that are out of your control.
80
Support / Re: Camera rotation issue
« Last post by AeroShark333 on July 30, 2018, 09:15:40 pm »
Doing the orthonormalization fixed the issue :)

Also I reported some SIGSEGV errors earlier at some point...
I thought that loading models/vertex data before texture data would fix the issue...
While it completely fixed the issue on the emulator (I was never able to reproduce it again), there are still SIGSEGV's happening according to the Play Store Console...
But I think the amount of reports did decrease
Pages: 1 ... 6 7 [8] 9 10