Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Göran Krampe
@gokr
Mmm, I think I end up in trouble due to lots of things starting with "_" and "__" - I think Nim has some restrictions here. I need to ask on the Nim channel
Göran Krampe
@gokr
Ok, so... have added some mangling directives and I have come lots further :)
iarwain
@iarwain
What's the next hurdle then? :)
Göran Krampe
@gokr
Well, one thing I haven't looked at yet is...
c2nim barfs with "did not expect ##"
What is that thing?
"token concatenation" ok.
iarwain
@iarwain
it's the concatenation operator of the C preprocessor
Göran Krampe
@gokr
Humhum
iarwain
@iarwain
similarly, # is for stringification
Sausage Johnson
@sausagejohnson
I notice that when I compiled my game release on one version of lubuntu 16.04 and moved it to another machine with lubuntu 16.04 (but slightly older), I got a runtime error about the version of GLIBC c.

This sounds very much like the results I had for windows which resulted in me documenting here: https://wiki.orx-project.org/en/tutorials/community/sausage/preparing_a_windows_release#checking_library_dependencies

And previous conversation: https://gitter.im/orx/orx?at=5bd8e86e4775f53eb3175be9

My Linker Options="-static-libgcc;-static-libstdc++;-m64;-L/usr/lib64;-Wl,-rpath ./;-Wl,--export-dynamic"
Sausage Johnson
@sausagejohnson
The only difference... could this be because I am missing a leading -static ?
iarwain
@iarwain
I don't think so, my guess is that you have incompatible version of glib C on both OSes
Sausage Johnson
@sausagejohnson
They certainly are different GLIBC. 2.27 on the compiled box. And I can't remember the version on the destination box, but it was a little earlier.
Sausage Johnson
@sausagejohnson
Thanks, reading...
iarwain
@iarwain
That being said, lately I've been toying with https://appimage.org/
Which is a similar system to OSX's bundles, having all dependencies packed with your application, including data
I've used it for the last gamejam we did: https://ldjam.com/events/ludum-dare/46/railroad-lantern
Sausage Johnson
@sausagejohnson
It would be good advice then to ensure whatever version of linux you compile your game with should not be the latest and greatest. It would mean noone could run your game until their linux (and glibc) surpassed your own.
iarwain
@iarwain
Or have it packed with its dependencies :)
Sausage Johnson
@sausagejohnson
yes.
That app image is interesting.
For now, I'll put a newer lubuntu on the target box.
iarwain
@iarwain
Yes, if you have control over the target, that's the easiest solution.
Sausage Johnson
@sausagejohnson
If AppImage is adopted everywhere, this could be a great thing. Might take a while to propagate everywhere.
iarwain
@iarwain
It doesn't need to be adopted, per se. The applications you make with them should be able to run on any linux system.
Without any direct support from any distributions.
Sausage Johnson
@sausagejohnson
I'll check out the video. Could supply in AppImage format or regular executables, and people could choose their download.
Keen to test this.
iarwain
@iarwain
Sure, I don't see any drawbacks to AppImage though, they end up being a regular linux executable from the user's point of view
Hezekiah M. Carty
@hcarty
@gokr Haven't used c2nim, just (like you guessed) tools that are similar. And I agree with @iarwain's assertion that the orx*.h headers are pretty tame! I've written several C-to-<not C or C++> library bindings and Orx has been one of the simplest to understand and thankfully most consistent across the whole API
Sausage Johnson
@sausagejohnson
Latest Lubuntu installed onto the pinball machine and the binaries work now. All fixed.
iarwain
@iarwain
Nice
FullyBugged
@FullyBugged

Latest Lubuntu installed onto the pinball machine and the binaries work now. All fixed.

Good to hear :)

Did you ever made a small video of the game running ?
iarwain
@iarwain
@/all Our Discord server is now ready, we're going to be transitioning there for all chat purposes. Can someone please let me know if this link works for them? https://orx-project.org/discord
Hezekiah M. Carty
@hcarty
Repeating here - worked for me
iarwain
@iarwain
Perfect, thanks!
znakeeye
@znakeeye

So I have a player that needs to die. Is this the right design?

[PlayerObject] ChildList = HeroObject # HeroDeathObject

znakeeye
@znakeeye
@iarwain In this case, I want to initially disable the death object. Why can't I do that from config?
znakeeye
@znakeeye
My HeroDeathObject is a simple animation with LifeTime = anim. Maybe I'm better off creating this object on the fly?
iarwain
@iarwain
Hey @znakeeye we moved our chat to discord at https://orx-project.org/discord
MichalSkysky
@MichalSkysky
good day every1. I have a very basic question. How can I save the window and monitor position of an app? I am working on multiple monitors and whenever i rebuild it opens the app on the same monitor as VS, which is quite annoying over time. I found some forum posts saying to save it in the app settings, but I couldn't figure out how to access these.
Thanks in advance for any help. :)
ah, right, discord... see u there :)
Ondrej Pokorny
@Ondra09
Hi, firslty I would like to say you have a nice little engine here. I am just trying to implement a few simple games in it and I noticed it is leaking a memory in Debian Linux, it is constant amount. Do I need to tear down engine somehow? Is this a known issue? Valgrind Log attached: ```* This template project creates a simple scene
  • You can play with the config parameters in ../data/config/05-minesweeper.ini
  • After changing them, relaunch the executable to see the changes.
    ==1692009==
    ==1692009== HEAP SUMMARY:
    ==1692009== in use at exit: 297,911 bytes in 2,545 blocks
    ==1692009== total heap usage: 332,193 allocs, 329,648 frees, 316,765,460 bytes allocated
    ==1692009==
    ==1692009== 4 bytes in 1 blocks are definitely lost in loss record 5 of 1,899
    ==1692009== at 0x483AB65: calloc (vg_replace_malloc.c:760)
    ==1692009== by 0x13439A3E: pa_xmalloc0 (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.1)
    ==1692009== by 0x1340EF9E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.1)
    ==1692009== by 0x50821E4: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x5084734: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x50502CD: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x537634E: __pthread_once_slow (pthread_once.c:116)
    ==1692009== by 0x504F513: alcOpenDevice (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x491AA54: orxSoundSystem_OpenAL_Init() (orxSoundSystem.c:1297)
    ==1692009== by 0x494E9B4: orxSoundSystem_Init (orxSoundSystem.c:146)
    ==1692009== by 0x49DC369: orxModule_Init (orxModule.c:366)
    ==1692009== by 0x49DC11B: orxModule_Init (orxModule.c:318)
    ==1692009==
    ==1692009== 4 bytes in 1 blocks are definitely lost in loss record 6 of 1,899
    ==1692009== at 0x483AB65: calloc (vg_replace_malloc.c:760)
    ==1692009== by 0x13439A3E: pa_xmalloc0 (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.1)
    ==1692009== by 0x1340EF9E: pa_context_new_with_proplist (in /usr/lib/x86_64-linux-gnu/libpulse.so.0.21.1)
    ==1692009== by 0x50821E4: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x50823C7: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x5082AC2: ??? (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x504F811: alcOpenDevice (in /usr/lib/x86_64-linux-gnu/libopenal.so.1.19.1)
    ==1692009== by 0x491AA54: orxSoundSystem_OpenAL_Init() (orxSoundSystem.c:1297)
    ==1692009== by 0x494E9B4: orxSoundSystem_Init (orxSoundSystem.c:146)
    ==1692009== by 0x49DC369: orxModule_Init (orxModule.c:366)
    ==1692009== by 0x49DC11B: orxModule_Init (orxModule.c:318)
    ==1692009== by 0x49DC11B: orxModule_Init (orxModule.c:318)
    ==1692009==
    ==1692009== 40 bytes in 1 blocks are definitely lost in loss record 1,038 of 1,899
    ==1692009== at 0x4838DEF: operator new(unsigned long) (vg_replace_malloc.c:342)
    ==1692009== by 0xEF8BC93: ???
    ==1692009== by 0x400FFB1: call_init.part.0 (dl-init.c:72)
    ==1692009== by 0x40100B8: call_init (dl-init.c:30)
    ==1692009== by 0x40100B8: _dl_init (dl-init.c:119)
    ==1692009== by 0x4FA429C: _dl_catch_exception (dl-error-skeleton.c:182)
    ==1692009== by 0x4014333: dl_open_worker (dl-open.c:758)
    ==1692009== by 0x4FA423F: _dl_catch_exception (dl-error-skeleton.c:208)
    ==1692009== by 0x40138C9: _dl_open (dl-open.c:837)
    ==1692009== by 0x5360257: dlopen_doit (dlopen.c:66)
    ==1692009== by 0x4FA423F: _dl_catch_exception (dl-error-skeleton.c:208)
    ==1692009== by 0x4FA42FE: _dl_catch_error (dl-error-skeleton.c:227)
    ==1692009== by 0x5360A64: _dlerror_run (dlerror.c:170)
    ==1692009==
    ==1692009== 5,312 bytes in 255 blocks are definitely lost in loss record 1,896 of 1,899
    ==1692009== at 0x483877F: malloc (vg_replace_malloc.c:307)
    ==1692009== by 0x4EF9E1A: strdup (strdup.c:42)
    ==1692009== by 0x846F086: ???
    ==1692009== by 0x846EE34: ???
    ==1692009== by 0x8411506: ???
    ==1692009== by 0x5707356: ??? (in /usr/lib/x86_64-linux-gnu/libGLdispatch.so.0.0.0)
    ==1692009== by 0x5707CF8: ```
iarwain
@iarwain
Hi @Ondra09, we've migrated our chat to Discord, would you mind posting there (https://orx-project.org/discord) in the #support channel?