Recent Posts

Pages: [1] 2 3 ... 10
1
Support / Re: Crash (native)
« Last post by EgonOlsen on September 19, 2018, 02:34:56 pm »
The buffer sizes are fine. I've checked that multiple times in the past, because I had similar problems on some devices and on the desktop as well. If they wouldn't be, the engine couldn't even store the data in the first place, because it would crash with a buffer overflow kind of exception. You can do such things in C, but not in Java (unless you are assigning the wrong buffer, but that's not the case either).
2
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
3
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.
4
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.
5
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?
6
Support / Re: Float Positioning Blit Images
« Last post by AGP on September 04, 2018, 11:45:20 pm »
And software-rendered Polylines, please?
7
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.
8
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,
9
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...???
10
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.
Pages: [1] 2 3 ... 10