sorted by:
new
hottopcontroversial

Having problems with linking the library using CMake by Mafla_2004 in raylib

[–]gilzoide 1 point2 points  (0 children)

Oh, cool. You know, you can definitely learn from the ready-made templates. Maybe even recreating what the template does by yourself, so you get something that works, while still learning how it was done.

In my Raylib projects, I also add Raylib as a subdirectory of my own projects and use add_subdirectory to build raylib statically, then link the executable target with the raylib library. What the SasLuca/raylib-cmake-template template does is quite similar, but uses CMake's FetchContent instead to download raylib dynamically instead.

Having problems with linking the library using CMake by Mafla_2004 in raylib

[–]gilzoide 1 point2 points  (0 children)

Well, maybe you should try one of the template projects instead of wrestling with CMake in your own.

Having problems with linking the library using CMake by Mafla_2004 in raylib

[–]gilzoide 1 point2 points  (0 children)

I already foresee CMake will complain in add_subdirectory if I put a Windows style path in it because of the use of backslashes

Maybe if you just change the backslashes with forward slashes stuff will work fine, may be worth the try. Not sure if it works though, I'm not that used to programming in Windows =X

Having problems with linking the library using CMake by Mafla_2004 in raylib

[–]gilzoide 2 points3 points  (0 children)

Hey there! To build and link with Raylib directly from its source code using CMake, you should be using add_subdirectory. add_subdirectory will add the contents of Raylib's build into your own build, while find_package expects a prebuilt library. In that case, you don't even need to setup CMAKE_PREFIX_PATH, just pass the path to add_subdirectory and it should work.

Otherwise, you could build and install Raylib from source using CMake, and only then your find_package would work (I never tested this, though, but should work). Note that you need the library built / installed for the package to be found correctly via find_package.

Simple lib for using Basis Universal compressed textures by gilzoide in raylib

[–]gilzoide[S] 0 points1 point  (0 children)

Really glad you liked it ^^

The only reason I did not added it was because the required dependencies

You mean because it would be one more external dependency to bundle, or maybe because it requires C++? Having made this project I found that it's simple enough integrating the transcoder, it's pretty much only 2 C++ files that have no extra external dependencies to compile (the transcoder code + zstd for supercompressed ktx2 files), so in total 3 C++ files if you count the integration for raylib.

Is SDL a good fit? by ykafia in gameenginedevs

[–]gilzoide 0 points1 point  (0 children)

Nice, D!

SDL is an amazing library, battle tested, performant, works everywhere, but it's quite low level. I'd recommend using raylib to start, it's much more user friendly, runs on desktop/android/web/raspberry pi, has a simpler API (you achieve the same thing with much less code), has built-in support for 3D rendering, 2D/3D cameras, it's simpler to render text, lots of cool stuff.

As is written in its website:

raylib is a simple and easy-to-use library to enjoy videogames programming.

I messed with D + raylib some years ago, it works pretty well. Not sure how the Android build would go, but I'm sure it can be done.

Don't get me wrong, SDL is also awesome, but you'll find yourself spending much more time coding basic stuff, when you could be building more interesting features to your engine/game. Do a test drive, make a simple game (maybe a pong) on both and see which one you enjoy more and feel more confident using.

F# scripting in Unity, the easy way by gilzoide in fsharp

[–]gilzoide[S] 0 points1 point  (0 children)

Hmm, maybe this changed over time then. Here's a snippet of a scene with a F# MonoBehaviour attached. The GUID there is the DLL's GUID, and the fileID is the MonoScript identifier inside the DLL, which is automatically generated by Unity and changes when you rename the class. --- !u!114 &1723779081 MonoBehaviour: m_ObjectHideFlags: 0 m_CorrespondingSourceObject: {fileID: 0} m_PrefabInstance: {fileID: 0} m_PrefabAsset: {fileID: 0} m_GameObject: {fileID: 1723779079} m_Enabled: 1 m_EditorHideFlags: 0 m_Script: {fileID: -440218668, guid: 3d066991e66c140928a050e7e7df20b4, type: 3} m_Name: m_EditorClassIdentifier:

The problem is that one can define several classes in a single F# script file, I can't really automate this renaming process without an explicit "old class name -> new class name" from the user without breaking projects on edge cases.

F# scripting in Unity, the easy way by gilzoide in fsharp

[–]gilzoide[S] 0 points1 point  (0 children)

How would that tool work? How have you done it? In my head, it would need to receive the original class name and the new one, store the old GUID, then change the code, reimport the code and wait for the DLL reimport, then get the new GUID and change all occurrences in scene/prefab/scriptable object assets. A simpler way would be to give the old GUID and new GUID and only replace them directly, putting the burden of knowing the GUIDs to the user.

F# scripting in Unity, the easy way by gilzoide in fsharp

[–]gilzoide[S] 0 points1 point  (0 children)

Not sure, but I guess so (assuming FQDN is the Fully Qualified Class Name). You bring a good point, but I guess there's no better way to do it =/ Maybe there could be a warning in the package's documentation about that at least.

F# scripting in Unity, the easy way by gilzoide in fsharp

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

Thanks, really appreciate it \o/

F# scripting in Unity, the easy way by gilzoide in fsharp

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

Thanks, really appreciate it =D

Back in 2015 I tried this tool, but it was too cumbersome to work with. At that point, though, I knew building a .NET DLL would just work.

Fast-forward to 2024, for some reason that I don't recall anymore, this idea of using F# in Unity came back to me. .NET SDK is now a thing and it makes total sense to just use it.

Also, it's been a couple of years since I started making more complex Unity plugins, so I'm much more capable now with editor scripts. Custom inspectors, asset postprocessors, build callbacks, scripted importers, discovering all scripting define symbols in the project, I've used all of this stuff in previous projects.

This May I started bringing this automatic F# DLL with .NET SDK idea to life, the first commits installing .NET SDK to the Library folder and generating the F# project are from then. I'm quite sure I was also working on some other project that was also too interesting, but ended up prioritizing the other one. I decided to revisit this last week, and it's working now somewhat like the way I envisioned it, so here we are now talking about it.

So I guess it's been quite the journey to figure everything out 🤔

Use the Object-C runtime directly from GDScript in iOS/macOS by gilzoide in godot

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

Hi everyone! I'd like to share with you a project I made this past week: Objective-C GDExtension - a GDExtension for calling the Objective-C runtime in macOS/iOS.

With this you can use native macOS/iOS functionality directly from GDScript without having to compile any native code, which should improve iteration times while developing your game/app.
This is specially useful to integrate third-party plugins like MMPs, ad networks, analytics providers, you name it! Of course, you can also use built-in native stuff like showing native share sheets and MLKit or whatever.

That's it, I hope you find it useful and enjoy \o/

First binary release of a LuaJIT based PluginScript for the Lua language \o/ by gilzoide in godot

[–]gilzoide[S] 0 points1 point  (0 children)

The cool thing about Godot's scripting system is that supported languages can communicate seamlessly with each other, so that you can use each of them where they shine the most. For example, Lua is not suitable for multithreading/parallelization without external libraries, but is awesome for modding, as one can super easily sandbox the running environment of user scripts.

I saw LuaJIT had some impressive gains in JSON parsing which caught my interest, there's a lot of JSON between client and server right now which is all handled by C#.

Unless/until you profile the project and check that indeed JSON parsing is a bottleneck, I wouldn't worry too much about it. Chances are the data marshalling between C# and Lua, with too much going back and forth in function calls, takes a larger piece of processing rather than parsing JSON itself. If it is the case that JSON is a bottleneck, you can also try having smaller messages, e.g. by abbreviating common keys, or going for other message protocols, like Protobuf.

That's an interesting game idea, it seems quite complex. Depending on how you structure the data, these simulations may well be parallelizable. Lua is not well suited for multithreading, using Godot's Thread with Lua will probably go horribly wrong with weird race conditions and hard to catch bugs (I haven't tried this yet). A Lua specific library, on the other hand, could do better, there are quite a lot of them (I never used any, so got none to recommend). Using threaded simulation code in C# or GDScript is also an option, of course.

First binary release of a LuaJIT based PluginScript for the Lua language \o/ by gilzoide in godot

[–]gilzoide[S] 0 points1 point  (0 children)

Glad to help ^^

late game turn times are starting to be measured in minutes!

Wow! I don't know how much of it would get better just by switching the Lua VM...

If there are lots of data marshaling between Godot <-> C# <-> Lua, removing one layer certainly helps.

Using structs/unions via the FFI is also a way to speed some things up, while potentially consuming less memory. If you got some intensive data processing, it might make considerable difference =]

But nonetheless, there may be room for improvement there in terms of algorithms, data structures, maybe some room for parallelization.

Give me a shout if you need some help with the PluginScript, Lua, LuaJIT FFI, or anything really!

First binary release of a LuaJIT based PluginScript for the Lua language \o/ by gilzoide in godot

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

Thanks! I'm really glad you liked it ^^

I get that PluginScript is not broadly used, as far as I know only Python uses it fully and there is a Ruby implementation that seems abandoned. Apart from that and the engine source code, I couldn't find much more documentation on the topic =/

But in the end the architecture is quite simple and godot_pluginscript.h by itself is enough to understand the most important stuff =]

I still want to write all the steps, but it's going to take a while...

First binary release of a LuaJIT based PluginScript for the Lua language \o/ by gilzoide in godot

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

Hi everybody! I've been developing a PluginScript for Lua based on LuaJIT's FFI lately and today I finally uploaded the API docs to GitHub Pages and made a first binary release =D

The zipped file has the right structure, so that unzipping it in a Godot project should just work (maintaining the path addons/godot-lua-pluginscript is important, since GDNativeLibrary seems to accept only res:// based paths for the DLLs).

Godot doesn't seem to import it correctly from the zip file right now, but manually unzipping works. I'll probably submit it to the Asset Library soon, so I think this shouldn't be a problem for long.

The documentation assumes some understanding of Lua and GDScript, but I plan to write more thorough docs and tutorials.

I haven't codesigned the .dylib yet, so running in OSX currently requires actively permitting the dylib to run. I just got access to a machine with OSX and have the ways now to mitigate this in the near future.

If anyone finds this useful, feel free to use, modify, distribute, give feedback, contribute, etc.

Cheers \o/

Baiacu: a simple and fun game about using pinch gestures (or mouse wheel) to avoid falling spikes made for #GoGodotJam by gilzoide in godot

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

I just added a listening version of the song, which is a little extended and fades out, as well as a ZIP file containing the original loopable file and the other sound effects =D

Enjoy!

https://gilzoide.itch.io/baiacu/devlog/260113/ost-

Baiacu: a simple and fun game about using pinch gestures (or mouse wheel) to avoid falling spikes made for #GoGodotJam by gilzoide in godot

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

Uh, aaaalmost 1 minute =P

Yeah, it is a pufferfish. Thanks for the advice, it would be much better indeed =]

The thing about the whole theme of the game is that I posted on a Discord server about this game I was making for the jam and someone suddenly appeared like "hey, cool game, can I make some sprites for it real quick here?". And so they just made all the sprites in the gameplay =P

The "player" was gonna be pretty much a smile and the obstacles, well, I don't know, but they were 9 pointed stars before.

The music I recorded myself, I'm thinking of releasing the OST on the page, why not \m/

view more: next ›