Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - EgonOlsen

Pages: 1 2 [3] 4 5 ... 798
31
Support / Re: Crash (native)
« 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).

32
Support / Re: Float Positioning Blit Images
« on: September 06, 2018, 10:43:06 pm »
Quote from: 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,

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.

33
Support / Re: Float Positioning Blit Images
« on: September 05, 2018, 08:10:24 am »
That's a whole different beast. Would it be sufficient to have them without depth buffering?

34
Support / Re: Float Positioning Blit Images
« on: September 04, 2018, 08:58:29 pm »
Yes, that should work. I'll try to add it in the next few days.

35
Support / Re: How to convert a texture to a bitmap？
« on: July 31, 2018, 09:14:04 am »
Yes...but...why? If you have created a texture, you already have a bitmap...???

36
Support / Re: Camera rotation issue
« 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.

37
Support / Re: Object3D generating issue
« on: July 30, 2018, 09:50:29 am »
Some shader compilers for some chips can't handle some code...which can result in everything going black. Here's an older but (not comprehensive) list of what can go wrong: http://www.jpct.net/wiki/index.php?title=GPU_guide

To track that down, I think you need a device that shows the problem and start to remove stuff from the shader or move things around and see what happens.

38
Support / Re: How to convert a texture to a bitmap？
« on: July 30, 2018, 09:44:38 am »
I'm not sure what you mean? Which texture?

39
Projects / Re: Art of Earthify (3D live wallpaper)
« on: July 27, 2018, 02:20:04 pm »
I've used the first code from your list. The rendering looks really nice and there seem to be lots of customization options. Well done!
I'm not using live wallpapers at all, but if I would...this one looks like a really nice choice.

40
Support / Re: Object3D generating issue
« on: July 27, 2018, 10:15:58 am »
No idea about the UV-mapping...about the black polygons? Are you using shaders? If so, that's most likely the problem. Different GPUs show different behaviours in some edge cases and in some cases, it might result in just a black rendering. So...are you using shaders and which devices are affected?

41
Support / Re: Different light shading with compiled objects
« on: July 27, 2018, 10:13:25 am »
...not sure what that is then...

42
Support / Re: Different light shading with compiled objects
« on: July 25, 2018, 08:57:31 pm »
There might a small hickup when uploading textures, which is why you can preload them. But that applies to compiled as well as uncompiled objects. Have you tried to increase the VM's memory pool?

43
Support / Re: Different light shading with compiled objects
« on: July 25, 2018, 02:35:19 pm »
When not using compiled objects, I don't see where that staggering effect should come from. For compiled objects, it might be caused by the compilation process...but for uncompiled...I don't see that. Can you narrow it down somehow?

44
Support / Re: Different light shading with compiled objects
« on: July 24, 2018, 09:35:58 am »
That basic light formula is the same. I've noticed some differences between compiled and "normal" objects regarding vertex lighting as well depending on the GPU used. Especially older AMD based ones have a slightly different interpretation of how to shade the polygons which can result in dimmer lighting in some edge (no pun intended) cases. If you can't compensate for that with a brighter light or by changing some other values like the attenuation, you are basically out of luck and might have to switch to shaders.

45
Support / Re: Different light shading with compiled objects
« on: July 23, 2018, 09:18:57 am »
It's not linear vs. non-linear. Both use the same, linear approach, but this value http://www.jpct.net/doc/com/threed/jpct/Config.html#lightMul is 10 for non-compiled objects (for historical reasons) but 1 for compiled ones (because of the way in which the fixed function pipeline works). Have you tried to increase the intensity of the light source instead? Or played around with http://www.jpct.net/doc/com/threed/jpct/Lights.html#setRGBScale(int)?

Pages: 1 2 [3] 4 5 ... 798