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 ... 797
1
Support / Re: Crash (native)
« on: October 16, 2018, 10:46:34 am »
So far, I wasn't able to reproduce it. What's your actual crash rate in Google Play that can be attributed to such kind of native crashes?

2
Support / Re: texture repeat mode support
« on: October 11, 2018, 03:54:58 pm »
Yes, you can use this http://www.jpct.net/jpct-ae/doc/com/threed/jpct/Texture.html#setClamping(boolean). To repeat properly, your model has to be build in a way so this makes sense, of course (i.e. using uv-coodinates <0 or >1 for some polygons). This setting (as well as the GL settings you've mentioned) don't make textures magically repeat whose uv-coordinates are just between 0 and 1.
However, you can't specify the number of repeats because that's defined by the way in which the model has been build. It's NOT a texture related attribute.

Edit: Added a 'not' where it belonged...

3
Support / Re: Crash (native)
« on: October 09, 2018, 08:08:18 pm »
After downloading half the internet to upgrade to AS 3.2, I now had the chance to try the test case. What exactly is it supposed to do? I can see some "loading" message followed by a white screen. Is that intentional or am I missing something?

If the emulator runs (in most cases, it just crashes (not the app in the emulator, but the whole emulator)), it also prints out these buffer size warnings. However, I've checked the code again...it's impossible that I reserve the wrong size for them, simply because I'm using the Android API to create them based on int[]-arrays. If the Android API reserves 2064 bytes for and int[]-array of 33292 bytes and then wonders why it doesn't fit, then I'm out of luck. But I don't think that's the case. I think the emulator messages are a red hering.

4
Support / Re: Crash (native)
« on: October 08, 2018, 09:53:19 am »
No, I just came back from holiday.

5
Support / Re: Crash (native)
« on: October 01, 2018, 10:25:32 pm »
Thanks. I'll go and try the test case on my devices (...when I'm back from holiday) to find one that crashes and start from there. I really don't trust emulators, so I prefer to find a non-working device instead.

6
Support / Re: Crash (native)
« on: September 28, 2018, 08:28:05 am »
Also, the crash also happens when only using drawWireFrame(...) instead of draw(...), I don't know if this can give you some clue but who knows
I don't think so. It's basically using the same data in a different way. Lets take one step back to narrow it down, please:

  • On which devices (exact model number if possible) does this happen?
  • Which Android versions are affected?
  • Does it happen only sometimes or all of the time?
  • Can you provide a simple test case that has this problem?

7
Support / Re: Crash (native)
« on: September 28, 2018, 08:25:23 am »
Since then I used another 3D software to convert and generate "factory.obj" file and started serialization again. it fix this problem and i do not understand why my old "factory.obj" file was bad ? serialization issue ?  format Wavefront .obj incompatible ?
Any problems with the format itself should never lead to a native crash. Looks more like some kind of memory issue to me...these things are very hard to track, because there are gazillions of different devices out there and I've seen all kinds of strange behaviour from some of them.

8
Support / Re: Crash (native)
« on: September 27, 2018, 08:20:20 am »
I'm really not sure about this emulator thing. I would say, it's a emulator issue, because it doesn't make any sense what it's printing out there. I don't reserve these 2064 byte large buffers for sure.
I'm not sure how your loading and rendering mix...maybe it's a threading issue of some kind? Maybe it tries to render objects that aren't fully processed?

9
Support / Re: Orthographic Camera
« on: September 27, 2018, 08:17:56 am »
Actually both plus the renderers contain some related code as well. It's a huge undertaking to change this, which is why I never bothered. You can move the camera far away and use a very tiny fov. That kinda gives you an orthographic projection, but of course it's not feasible in all situations.

10
Support / Re: Crash (native)
« on: September 26, 2018, 10:11:36 am »
This looks very strange:

Code: [Select]
09-26 00:54:36.764 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.765 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2208
09-26 00:54:36.884 12287-12307/com.aeroshark333.artofearthify I/ArtOfEarthify: Loaded textures: 2
09-26 00:54:36.889 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 3168
09-26 00:54:36.891 12287-12307/com.aeroshark333.artofearthify E/emuglGLESv2_enc: a vertex attribute index out of boundary is detected. Skipping corresponding vertex attribute. buf=0xeb70fce0
    Out of bounds vertex attribute info: clientArray? 1 attribute 3 vbo 18 allocedBufferSize 2064 bufferDataSpecified? 1 wantedStart 0 wantedEnd 2272
It's obviously the same buffer instance, which the driver tries to fill with different sized input data...which never fits. I've no idea why that is.
Could you try to set Config.byteBufferLimit to 0 (or some other small value) to see if that changes anything?

11
Support / Re: Orthographic Camera
« on: September 26, 2018, 09:49:43 am »
No. An orthographic camera support would require drastic changes to the whole culling, clipping, reprojection and blitting code.

12
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).

13
Support / Re: Float Positioning Blit Images
« 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.

14
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?

15
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.

Pages: [1] 2 3 ... 797