https://kotlinlang.org logo
Join Slack
Powered by
hey guys. What content would you like to see in a ...
# korge
n
hey guys. What content would you like to see in a next tutorial video? What would have helped you the most when you started korge or what would help you now?
t
To get an overview over the tooling around KorGE would be a good addition the the manual. Create a Font with Hiero, use Free 2D Skeletal for animation, create a tile map, use the Particle Tool, create a stretchable Ui element with Gimp and show the features of the KorGE IntelliJ plugin. I already used these tools with LibGdx, but for beginners it may help a lot to see what is possible and how to use these tools. Sometimes there are different tools which can achieve the same, or they only run on Mac or its not clear how to install them. For example my js game will benefit from a texture packer, to get a faster loading time. But which one should I use? Do I need a paid software? How to shrink Png files for web?
d
Regarding to the atlases, korge includes an atlas generator out of the box: https://korlibs.soywiz.com/korge/atlas/
n
the free skeletal creation might pose interesting. dragonbones seems to be dying off: unfixed broken download links for weeks now, no support in the forums, people already asking if its dead
@tobsef what can you recommend in skeletal animations besides spine?
d
the other alternative https://brashmonkey.com/ dragonbones -> free spriter -> cheaper than spine and less restrictive, less features and a bit buggy (the last version I tried). Spriter 2 is taking AGES. Announced maybe a years ago or earlieer? spine -> the expensive one, lots of support and features
n
dragonbones is free but maybe dead 😃
d
indeed
s
Hey! I find the existing guides very helpful, they give a good overview and allow to start with KorGE easily. Thanks! I'm doing Flappy Bird clone (as you probably already know) and there many questions: 1. Standard library. I use 
Point
but it's mutable. How to define immutable point, for example, to be used as a constant? Is there a vector2 class with the same capabilities, just to name it more suitable for using in velocity/acceleration or is it OK to use 
Point
here? 2. What's the recommended way to create custom views? What should I override (w/h, hitshape)? Should I always treat xy as the upper-left corner of the view or is it OK to use it as a center in some custom views? 3. How to split logic from representation, for example, where to handle collisions, which place should update position of views (a view itself or some kind of master object)? Need an example and a common algorithm! 😊 4. Scenes are not covered in the guides yet. I wish to see a simple app with a dynamic game scene and a main menu scene (background better be dynamic too). I want to know how I should design actions on scenes so I can easily switch them and pass some progress. And a general discussion of why scenes are needed and when I need to create it. 5. Working with images (yep, another guide). I still don't understand how can I prepare my loaded assets. For example, rotate, scale, mirror. Or should I do this when I render? Also, I have the following two lines in my code, can the first one be improved, can I flip a slice?
Copy code
skullUp = texture.slice(RectangleInt(192, 0, 24, 14)).extract().flipY().slice()
skullDown = texture.slice(RectangleInt(192, 0, 24, 14))
Also, you even can take a look at my project https://github.com/SerVB/korge-zombie-bird (of course if you have much time) and find some antipaterns a KorGE newbie uses (which I don't even treat as bad practice) and make a video about those and how to implement games better. If you decide not to create a video on any of these 6 variants but answer here, I will appreciate it too.
d
1. https://github.com/korlibs/korma/blob/28bef554b2beaf48f903d0b6e13831d6d1edcb16/korma/src/commonMain/kotlin/com/soywiz/korma/geom/Point.kt#L9-L10 - But not a good thing in terms of Kotlin/Native performance. Also problematic so some people use IPoint others Point. My suggestion is to just use the mutable Point, where you have it private you know for sure it is not mutated, and in other places, just copy it when required immutability
2. For custom views just extend View or BaseRect. You have to implement getLocalBounds and maybe internalRender
3. Normally you use plain views with a DOM, since you are doing it otherwise you have to decide where to place yourself 🙂 in the end you can put an addUpdater in your view then put the logic there
4. I think there are some gamejam games with scenes
5. Might need some work to support rotations and flippings. But in the end this is the interface: https://github.com/korlibs/korim/blob/2b07a051146e52ce3541f4789db680ec6935d95b/korim/src/commonMain/kotlin/com/soywiz/korim/bitmap/BitmapSlice.kt#L8 handling the coordinates. You can create an object implementing that interface with flipped or rotated textures. Still we have to add a few methods to simplify this --> https://github.com/korlibs/korim/issues/57
👍 1
s
1. What's wrong with K/N?
2. I've created my objects extending Container, is it OK? And I haven't overriden getLocalBounds or internalRender. I think a video guide can give a comprehensive answer on this
3. Again, I think this question can't be answered fast. Text or video guide will be great!
4. gamejam games are indeed a good way to look but they can't be compared to a concise guide containing only required info
n
d
K/N devirtualization doesn't seems to do a great job at this point from what I have tested mysel. At least in 1.3
s
I have tested
I'm very curious. Have you any digits? Have you reported it at Kotlin YouTrack so they can fix it?
d
well I did a profiling session in a mac using instruments
you can check the kind of things I changed here: https://github.com/korlibs/korge/pull/168
also ArrayList.clear is awfully slow
I had to do some tricks to reuse arraylists
once project valhalla is out, and kotlin native support stack-based structures next version of korge will use structures for Point and stuff. The only reason it is mutable right now is to avoid allocations
s
Sorry, but you don't answer my question... I just want to know if it is really necessary to mark 
IPoint
as deprecated. Because for example if it gives only 10% performance loss only on native targets -- well, I can totally live with it. I would rather not have warnings from compiler... And if there is huge loss of performance, for instance, 50%, we should better report it to Kotlin team so they fix it and add regression tests.
d
It is not only performance. It is the complexity it added. Some places required IPoint, others Point and was a bit confusing.
It is marked as deprecated since the idea is to remove the interface
initially to only have the mutable version, and in a future breaking version (maybe KorGe 3.0) to have an immutable version
s
Is it a final decision? Won't I be able to create a constant Point until KorGE 3.0?
Some places required IPoint, others Point and was a bit confusing
I think it's more than OK, not confusing. Some places aren't meant to modify the point so they should receive IPoint. Like a constant reference in C++. Is there any other reason?..
d
not a final decision
but still you can cast the IPoint to Point and modify it
maybe better to have a PointImmutable or something
I have been a lot of years doing the immutable part, because thought was better, and it is more correct, but added some complexity, required overloads and stuff
s
cast the IPoint to Point and modify it
Well yes, but actually I won't do this because I don't want to harm myself 🙂 I guess the same is true for stdlib functions. For example, the function 
.map
is not trying to cast its receiver to mutable iterable and spoil it. And the same is true for that C++ case: nobody will try to cast a constant reference to a reference and modify it because it's obviously a not designed action while it's easily performable. What I want is to have some compiler protection. And the current situation is that I have plain Points everywhere: I don't know which functions modify their arguments and which not. I can unintentionally change the function to modify its argument because I forget that it has been designed not to do so. If I could use IPoint, I would be reminded that the function shouldn't try to change its parameter. And I will know where I can pass contstants because I believe nobody will try to cast. My opinion is that IPoint shouldn't be deprecated so I can use it. Of course, this doesn't mean immutable, this means read-only and it has its limitations. However, we all using Kotlin for quite a while and I believe we are used to read-only types and we know how to work with them.
PointImmutable
This is an option, but it's not required. This will just add one more class and complexity but will give extra guaranties. I think this can be done later if there is such demand
d
Okay. It is not a big deal. We can undeprecate the IPoint interface. We won't use it in Kotlin/Native inside KorGE core for performance sake, but you can use it in your code. The core at least must be as fast as possible.
t
@Nico I only tested Spine for the skeleton animations... I even founded the Kickstarter project. But I never used it in my games 😅
s
We can undeprecate the IPoint interface
Awesome! Really looking forward to see this change.
The core at least must be as fast as possible
I still don't get the problem. Is it that when I pass an implementation where interface is declared in Kotlin Native, it's slow? If yes, of course it should be fixed from Kotlin side. It's great that the library works around this problem. I think Kotlin Native team will be happy to investigate and fix this, but more info is needed, for example, benchmarks. I can try to prepare the info if you confirm that I understand the problem right.
t
@Deactivated User Thanks for the hint with the atlas. I was able top drop the initial loading time of the web app from 4400ms down to 1300ms. But I also had problems with bitmaps loaded from the atlas. The 
centerOn(rootView)
is broken again and I had to switch to absolute positioning. And my game map tiles showed a minimal spacing at the corners, so my game looked like a chess board. I oversized my tiles 1% to get rid of it. I try to summarize this and other game jam problems and bugs next week.
🆒 1
d
Great, thanks for the feedback. Was not aware of issues with the atlas, so if you can make an issue that will be greatly appreciated
t
👍 Undepricate the 
IPoint
. I often used it as class delegation. This was very handy for game objects, that have a position and also provide all of the nice IPoint functions, like 
distanceTo()
. Switching to 
Point
is not an option, because it's not an interface and not 
open
.
👌 1
d
In games I think it is ok, but the core: https://blog.korge.org/korge-11290-optimizations/ when iterating 10K objects there is a huge impact on method virtualization lookup. Java and JavaScript can inline and make optimistic optimizations, but static compilers might not be able to do that kind of optimizations. So as long it doesn't impact the core, it is ok
👀 2
i
Hi guys, I just had one question, when I was making my game I realized that the collisions with the enemies were produced by transparent areas of the textures, I tried to make a hitShape to have a kind of pixel-perfect collision but I failed. I’d love a tutorial on that topic, or at least a kind sample about pixel-perfect collisions or vector path collisions. Thanks
s
@Iván C., maybe you have failed because of the issue with vector paths collisions: they just haven't worked sometimes. I guess the fix isn't published yet. However, it's already merged: https://github.com/korlibs/korma/pull/33
💯 1
Still I think a video/videos on overriding different View stuff is needed 😊
i
Thanks!
r
@tobsef, regarding 
centerOn(rootView)
, maybe you should use 
centerOnStage
function? I added it in 1.13.7, it uses virtual width/height to center a view
n
@Iván C. I updated the doc at korge.org under physics for using shape collision
t
@RezMike Yes I already discovered the new 
centerOnStage()
. But I can't use it. My game components extend the 
Container
class and add other views during 
init{}
. So calling 
centerOnStage()
for an added image, will always trigger a 
NPE
because the stage is 
null
for a unattached Container. So this is why I provide the 
rootView
, which is basically the Stage. Or is there a lifecycle phase where I can add Views after attach?
PS: We have a crazy time shift
d
t
I down't know how the FixedSizeContainer could prevent the NPE in 
centerOnStage()
. The problem is the order... I add the image to the FaqComponent, before the FaqComponent is attached to another View.
r
@tobsef you can try something like that:
Copy code
fun Container.faqComponent(): FaqComponent {
    return FaqComponent().addTo(this).onAttach()
}
where 
onAttach()
is your custom function
i
Thanks @Nico, I’m gonna check it!
3 Views
Open in Slack
PreviousNext
Powered by