Converting Ruby Gosu Gem into Executable

By kyonides Date 2020-08-21 05:58

I was wondering if any of you guys would know effective ways to achieve such a goal with relative ease.
As of late I'm working on a different machine so I no longer have access to my old testing code. Still, I do recall I had issues with this project because I couldn't manage to display every single sprite on the game window as intended because some of them disappeared at random Z coordinates. I thought that the only way was to keep the loop inside the C executable that would replace the gem and still use all the usual Ruby code.
Since that doesn't seem to be a nice way to deal with this issue, how would you do it?
By the way, I'm working on a Linux box.

By kyonides Date 2020-08-26 23:33 Edited 2020-08-27 01:56

I'm still working on this executable but I was wondering if I didn't explain myself clearly. I'd prefer to think none of you hate me for unknown reasons. :P

EDIT

Here's a piece of C++ code that lets me intercommunicate between both CRuby and C++ portions of code.

Code on HasteBin

Any suggestions or corrections would be appreciated.

I also got rid of the tick-ish loop because it bothered me how Ruby didn't stay in control because of that inner loop. :S

By kyonides Date 2020-09-03 23:04

Well, I've pretty much ready to get some features work without SWIG's interference but I managed to change the scale of all drawables by changing some specific value... the very same one I don't recall and I can't find it even if I've checked the source code several times already. :P

So jlnr or anybody else, you could please remind me of where in the original C++ code is the factor or scale that doubles the size of all images from the very beginning?
I should have documented it on my own but forgot to do it. :)

By jlnr (dev) Date 2020-09-04 18:41

Hey, I had this thread open in a tab but didn't really understand the CRuby parts. If you want every image to be twice the size, then the most pragmatic approach would be to subclass or monkey-patch Gosu::Image to apply a factor to the scale_x/scale_y arguments. If you want to scale all coordinates, not just image sizes, then you can put a Gosu.scale(2) do ... end block around your Window#draw implementation.

If you want to do the same by modifying the Gosu source code, then multiplying scale_x/scale_y in Image::draw would be one simple way (plus draw_rot probably).

By kyonides Date 2020-09-05 04:05

Thanks jlnr, but that's EXACTLY what I wanna avoid. It's not even necessary to do it, you know. If I included a bug in the source code I was modifying, while I was trying to do something else, now sprites look as dwarves or sprites in the mythological sense. XD This means it can be done by default with a few additions. I know, I've already used a variable to let it change but that's only a disguised bug, so to say. Nope, it wasn't a Gosu::Image.scale_x or scale_y call, I've already discarded it. The window remained as big as originally intended.

Don't you recall where in the gosu code there was a place that was multiplied by some value that enlarged sprites displayed on screen?

I do remember we once discussed something on the discord channel about images being slightly enlarged by default in gosu, you'd said back then they'd look kind of tiny otherwise. Where's that part of the code? That part contains the key to implementing a "fake" scaling effect without needing the Gosu.scale(params) method call.

By jlnr (dev) Date 2020-09-25 08:19

Hmm, sorry, not sure what place in the code you mean specifically. All the high-level scaling happens in Window::resize, which also keeps the scaling of graphics and mouse input in sync.

By kyonides Date 2022-02-25 01:05

I see, still, I do think you might have forgotten the time when you told me all images were actually displayed scaled to 110% or 1.1 of its actual size...