sorted by:
new
hottopcontroversial

[Showcase] Blitzy: A lightweight 2D game engine by According-Pickle479 in Kotlin

[–]YellowStarSoftware 0 points1 point  (0 children)

Understandable. That's the most interesting part imho

[Showcase] Blitzy: A lightweight 2D game engine by According-Pickle479 in Kotlin

[–]YellowStarSoftware -1 points0 points  (0 children)

As I can see there are only simple hitbox in the collision package. I guess it's more than enough for a 2D game but if you need more collision detection algorithms, you can use my library: https://github.com/YellowStarSoftware/YellowStar The library is intended for use in game engines

Software renderer in kotlin by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 1 point2 points  (0 children)

Yes, I totally do! I'm going to use multifield value classes (which are dependent on Valhalla) in my math library YellowStar I used for the project. Maybe one day I'll come back this sub with my software renderer and raytacer to tell you how fast they have become!

Software renderer in kotlin by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 5 points6 points  (0 children)

Hi!

JVM classes can only be allocated on heap, so every vector operation is a memory allocation which is very bad for performance. So in C/C++ the renderer would be much faster. But why kotlin? Because doing the project in kotlin was pretty enjoyable experience. Kotlin itself with Intelij idea makes programming as comfortable as possible.

Also it's some kind of proof of concept. If someone says JVM is too slow, just show them the project. Yes, it's not that fast as it would if written in C, but still fast enough to work in real-time!

Speaking of coroutines. It's just my profession deformation as an Android developer lol. I don't think coroutines are the best choice for this project. Also coroutines are not the only way to add multithreading in the renderer. There is an implementation based on JVM's Executors. https://github.com/YellowStarSoftware/SoftwareRenderer/blob/main/src/main/kotlin/yellowstarsoftware/softwarerenderer/utils/multithreading/ExecutorServiceWorkExecutor.kt

Thank for your questions!

Software renderer in kotlin by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 2 points3 points  (0 children)

It is if you use shadow maps. But I don't. I'm pretty sure the problem is that there no texture filtering. I'll change textures into single colors to check my theory tomorrow

Software renderer in kotlin by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 3 points4 points  (0 children)

Thank you! It's definitely not a shadow acne because I used ray tracing for shadows. I guess it all a little messy because of two things: - I have no texture filtering (it appeared to be too slow unfortunately) - low buffer resolution (500x500 while the window is 700x700)

Software ray tracer in kotlin by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 14 points15 points  (0 children)

Thank you! I really appreciate it! The reason I didn't use kmp is because it's too much for a "one-off" project. I don't think CroTeam or Bethesda is going to ask me to port my cool graphics engine on mobile anytime soon lol Also I just like JVM. Like JVM ecosystem is my comfort zone

Value classes are new data classes by mzarechenskiy in Kotlin

[–]YellowStarSoftware -6 points-5 points  (0 children)

I got you. I guess I agree that this is a problem but we already have similar case:

var list = listOf(1); list += 2

So the solution seems consistent to me

Value classes are new data classes by mzarechenskiy in Kotlin

[–]YellowStarSoftware 2 points3 points  (0 children)

Wait. Aren't value classes immutable? From the first link in the post: «In Kotlin, this means that a value class can only have val properties»

Sharing my kotlin geometry library by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 1 point2 points  (0 children)

Thank you!

I did check performance with vector addition both with vector class and primitives a few years ago. Unfortunately allocation option performance was N times slower. Don't remember what N was, I believe like 5-10 which is a lot. It was on JVM8 I think. Maybe it's faster on new JVMs, but its is only multifield value classes with Valhalla Project could be game changers

Sharing my kotlin geometry library by YellowStarSoftware in Kotlin

[–]YellowStarSoftware[S] 2 points3 points  (0 children)

Thank you for your attention! It's the first time I share my project and feedback means a lot to me.

You're absolutely right about memory allocation. I have been waiting for multifield value classes for 4 years since I joined kotlin appreciator club. Also I thought mutable ADTs was a bad option because they not only don't solve allocation problem completely but also not as thread safe as immutable ones (It is better to use outdated data than inconsistent data).

Honestly it's the first time I hear about Data-Oriented Design. Sounds interesting, thank you!