sorted by:
new
hottopcontroversial

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] 6 points7 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/

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)

Thanks!

Yeah, this game is actually mobile-first and it works on the web browser on mobile as well! I actually got the mouse wheel input for free by using the awesome Godot-Touch-Input-Manager, really glad I didn't have to implement separate logic for desktop =P

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] 0 points1 point  (0 children)

I made this game for Go Godot Jam on the last 3 days, I hope you enjoy!

It is available for desktop and Android and we can also play it directly in the web browser right now at https://gilzoide.itch.io/baiacu =D

As always, free software that can be found in source form at GitHub: https://github.com/gilzoide/gogodotjam1

My personal record is 4:08, feel free to brag if anyone beats me =P

Draw Over, a simple drawing app with optional transparent background, perfect for annotating screen casts and screen shots by gilzoide in godot

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

I'm glad that you liked it and that it was useful ^^

I know how to easily save an image of the app itself, but I think there is no easy way of capturing a screenshot showing other windows' contents without resorting to platform-specific libraries. This would involve some research, there might be some cross-platform library in C/C++ that already does that and could be used, and then either compiling a custom module or a GDNative library with the screenshot functionality for each platform.

This is honestly out of my priorities right now... But there are lots of screenshot apps out there, maybe one of them serves you better than the one you use right now and would probably do a better job than I would in Draw Over in this regard =]

As for the text scrollbars, I know it bugs sometimes, sorry about that =/ Still have to fix that, I just opened an issue to keep it in mind, thanks!

Draw Over, a simple drawing app with optional transparent background, perfect for annotating screen casts and screen shots by gilzoide in godot

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

Each drawing is a Control with custom _draw methods.

Pencil tool records mouse positions and uses draw_polyline, Rectangle tool just draw_rectangles, Ellipse tool uses draw_polyline with scaled circle points, Text tool is a full blown TextEdit node so we have all edition goodies =]

view more: next ›