wonder Expert Licensed User Longtime User Sep 13, 2017 #141 If you have a game controller you can also plug it in (at any time) and play.
wonder Expert Licensed User Longtime User Sep 13, 2017 #142 @ilan, I fixed the black bars (so I hope) and added a way to modify the zoom: - Press back and select "Designer Mode" - Create a message script: <action = Debug_SetVBlocks(8)> - Move the knight to the block where you created the script - Activate it - Press back and Quit (to the title screen, do not close the app) - Start over Why is this solution so clumsy!! Can't you just modify camera.zoom in LibGDX???? - When I started this project a made a few mistakes in the beginning, such as linking physics to pixel size. I was an idiot. Last edited: Sep 14, 2017
@ilan, I fixed the black bars (so I hope) and added a way to modify the zoom: - Press back and select "Designer Mode" - Create a message script: <action = Debug_SetVBlocks(8)> - Move the knight to the block where you created the script - Activate it - Press back and Quit (to the title screen, do not close the app) - Start over Why is this solution so clumsy!! Can't you just modify camera.zoom in LibGDX???? - When I started this project a made a few mistakes in the beginning, such as linking physics to pixel size. I was an idiot.
wonder Expert Licensed User Longtime User Sep 24, 2017 #143 Ugh... Spent 8 hours reworking the player sprite in Photoshop... I managed to correct a lot of stuff and give the knight some blue boots and a brand new sword! The image is tilted for obvious reasons...
Ugh... Spent 8 hours reworking the player sprite in Photoshop... I managed to correct a lot of stuff and give the knight some blue boots and a brand new sword! The image is tilted for obvious reasons...
wonder Expert Licensed User Longtime User Nov 8, 2017 #144 New addition to the engine: ...and yes, they can be locked and require keys, all done by ingame scripting.
New addition to the engine: ...and yes, they can be locked and require keys, all done by ingame scripting.
wonder Expert Licensed User Longtime User Nov 13, 2017 #145 Here's something I wanted to try for a long time, ray casting! Why? Well, because lighting! KZ2D Debug Mode - Ray casting: As you can see, the current implementation (pure B4A) is veeeeeeeery slow. Solutions: - Algorithm optimization (B4A) - Rewriting the algo in C++ - Rewriting the algo as an OpenGL shader <-- best option, right? Last edited: Nov 13, 2017
Here's something I wanted to try for a long time, ray casting! Why? Well, because lighting! KZ2D Debug Mode - Ray casting: As you can see, the current implementation (pure B4A) is veeeeeeeery slow. Solutions: - Algorithm optimization (B4A) - Rewriting the algo in C++ - Rewriting the algo as an OpenGL shader <-- best option, right?
ilan Expert Licensed User Longtime User Nov 13, 2017 #146 wonder said: As you can see, Click to expand... I see "video not available"
wonder Expert Licensed User Longtime User Nov 13, 2017 #147 ilan said: I see "video not available" Click to expand... Fixed.
ilan Expert Licensed User Longtime User Nov 13, 2017 #148 U should use box2d for that. With spritekit its very simple to do and also runs very smooth and this should also work with box2d lights. U define bodies and the shadow mask for each body and shadow color so its much simpler and run smooth. It looks for me that something with your algorythm is wrong. It should not run so slow in libgdx.
U should use box2d for that. With spritekit its very simple to do and also runs very smooth and this should also work with box2d lights. U define bodies and the shadow mask for each body and shadow color so its much simpler and run smooth. It looks for me that something with your algorythm is wrong. It should not run so slow in libgdx.
wonder Expert Licensed User Longtime User Nov 13, 2017 #149 ilan said: U should use box2d for that Click to expand... Why would I throw away my own code? I think I am enough of a good programmer to get things done on my own. Besides, my engine doesn't utilize Box2D, so even if I wanted, I would have to convert the existing structures into Box2D structures (bodies). ilan said: It looks for me that something with your algorythm is wrong. Click to expand... Why do you say that? I don't see any leaks. The algorithm is correct and works as expected. It's the direct implementation of this one: https://www.b4x.com/android/forum/threads/raycasting-algorithm-demo-work-in-progress.73085/#content ilan said: It should not run so slow in libgdx Click to expand... That's because it's not "running" on LibGDX. Like I stated above, the algorithm is purely written in B4A, there are no LibGDX calls other than drawing the debug lines, which is not the bottleneck. The Box2D Lights implementation is most likely entirely shader based (if not entirely, it's most likely C++ and shader based). My implementation will be the shader based optimized version of this algo and if necessary, some of the logic can be offloaded to the native layer.
ilan said: U should use box2d for that Click to expand... Why would I throw away my own code? I think I am enough of a good programmer to get things done on my own. Besides, my engine doesn't utilize Box2D, so even if I wanted, I would have to convert the existing structures into Box2D structures (bodies). ilan said: It looks for me that something with your algorythm is wrong. Click to expand... Why do you say that? I don't see any leaks. The algorithm is correct and works as expected. It's the direct implementation of this one: https://www.b4x.com/android/forum/threads/raycasting-algorithm-demo-work-in-progress.73085/#content ilan said: It should not run so slow in libgdx Click to expand... That's because it's not "running" on LibGDX. Like I stated above, the algorithm is purely written in B4A, there are no LibGDX calls other than drawing the debug lines, which is not the bottleneck. The Box2D Lights implementation is most likely entirely shader based (if not entirely, it's most likely C++ and shader based). My implementation will be the shader based optimized version of this algo and if necessary, some of the logic can be offloaded to the native layer.
