sonicmax/bloodrogue

Roguelike for Android. (In development)

bloodrogue's Issues

Refactor ProceduralGenerator

Ideally this class would just contain the instructions for generating different types of terrain, and all the generation code would be contained in other classes (see: the CellularAutomata/PoissonDiskSampler classes). Good place to start would be decoupling the maze generation code from the corridor generation

Switch to entity-component-system

The GameObject class will become extremely bloated and unwieldy by the time all of the gameplay features have been implemented - it would be much better to separate the object behaviour from the base class and plug in components when we need them. (the difficulty is that the whole engine is written around GameObject and it would take a lot of effort to implement)

Fatal signal 11 (SIGSEGV), code 2, fault addr 0xa4915000 in tid 8582 (GLThread 370)

10-25 19:36:20.019 8539-8582/com.sonicmax.bloodrogue A/libc: Fatal signal 11 (SIGSEGV), code 2, fault addr 0xa4915000 in tid 8582 (GLThread 370)
10-25 19:36:20.121 1145-1145/? I/DEBUG: *** *** *** *** *** *** *** *** *** *** *** *** *** *** *** ***
10-25 19:36:20.122 1145-1145/? I/DEBUG: Build fingerprint: 'Android/sdk_phone_x86/generic_x86:5.1.1/LMY48X/4174727:userdebug/test-keys'
10-25 19:36:20.122 1145-1145/? I/DEBUG: Revision: '0'
10-25 19:36:20.122 1145-1145/? I/DEBUG: ABI: 'x86'
10-25 19:36:20.122 1145-1145/? I/DEBUG: pid: 8539, tid: 8582, name: GLThread 370  >>> com.sonicmax.bloodrogue <<<
10-25 19:36:20.122 1145-1145/? I/DEBUG: signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0xa4915000
10-25 19:36:20.123 1145-1145/? I/DEBUG:     eax a4904050  ebx abe8a92c  ecx 00010fc0  edx a3c0cc82
10-25 19:36:20.124 1145-1145/? I/DEBUG:     esi 00001406  edi 00000010
10-25 19:36:20.124 1145-1145/? I/DEBUG:     xcs 00000073  xds 0000007b  xes 0000007b  xfs 0000006f  xss 0000007b
10-25 19:36:20.124 1145-1145/? I/DEBUG:     eip b74850be  ebp a4904050  esp a4c4d938  flags 00210287
10-25 19:36:20.124 1145-1145/? I/DEBUG: backtrace:
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #00 pc 000170be  /system/lib/libc.so (memcpy+46)
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #01 pc 0006a4e8  /system/lib/libGLESv2_enc.so (glUtilsPackPointerData+88)
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #02 pc 00044010  /system/lib/libGLESv2_enc.so
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #03 pc 0002153a  /system/lib/libGLESv2_enc.so (GL2Encoder::sendVertexAttributes(int, int, bool, int)+1050)
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #04 pc 00021de7  /system/lib/libGLESv2_enc.so (GL2Encoder::s_glDrawElements(void*, unsigned int, int, unsigned int, void const*)+855)
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #05 pc 0000d5a1  /system/lib/egl/libGLESv2_emulation.so (glDrawElements+81)
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #06 pc 00092a21  /system/lib/libandroid_runtime.so
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #07 pc 00acd01a  /data/dalvik-cache/x86/system@[email protected]
10-25 19:36:20.124 1145-1145/? I/DEBUG:     #08 pc 00100c07  [stack:8582]

Presumably caused by the call to GLES20.glDrawElements() but it only seems to happen in the emulator (so far). Also doesn't happen consistently - maybe 1/10 launches

Figure out better way to handle screen transitions

Specifically how to handle cases when a new floor is loaded before the transition out from the old floor is complete. The previous method was causing lockups in certain situations (not good lolz)

Probably need some kind of queue/stack to handle scene changes