Envision, Create, Share

Welcome to HBGames, a leading amateur game development forum and Discord server. All are welcome, and amongst our ranks you will find experts in their field from all aspects of video game design and development.

OpenGame.exe - Pre-Alpha

logo.png
OpenGame.exe


OpenGame.exe is a custom Ruby-powered game engine that supports RPG Maker games. It aims to emulate the original RPG Maker's Game.exe functionality as closely as possible, and to later be expanded to provide new functions to empower RPG Maker games.

OpenGame.exe is currently in a pre-alpha phase - expect significant issues for the time being. I am working as quickly as I can to get things ready for production use, but it takes time.


Usage

OpenGame.exe acts as a drop-in replacement for RPG Maker's Game.exe. RPG Maker XP, VX, and Ace are supported. Make sure you also add the dependency DLLs to the game's /System/ folder. (The download already has this arranged for you.) You will no longer need the RGSS dll or the original Game.exe, but it does no harm to leave them in place.

OpenGame.exe requires .NET Framework 4.0 or greater.


Features

The engine will soon be capable of emulating vanilla RPG Maker XP, VX, and VX Ace games. The engine also provides additional features.There are command line switches to enablethe console in older RPG Maker versions, as well as forcing a particular version of RGSS emulation.

OpenGame.exe console - will display the console window

OpenGame.exe rgss1 - would force RGSS1 backend regardless of RPG Maker version.

OpenGame.exe rgss2 - would force RGSS2 backend regardless of RPG Maker version.

OpenGame.exe rgss3 - would force RGSS3 backend regardless of RPG Maker version.

The rendering backend is now OpenGL - this requires a (slightly) more modern machine, but will offer superior performance on compatible machines.The specific target OpenGL version is yet to be decided.

More enhanced features will be added in time.


Limitations

There are two significant features of "vanilla" Game.exe behaviour that will not be emulated for deliberate reasons.

The first is MP3 support.This is due to the fact that there are licensing issues surrounding the distribution and playback of MP3s, and it does not offer any significant benefit over the OGG/Vorbis file format. Don't believe me? See this link for MP3 licensing details. There are patents involved.

Secondly, encrypted RPG Maker archives will not be supported.While the format is well known at this point, Enterbrain (the copyright holder for RPG Maker) has directly expressed that it is against their wishes for the encryption details to be investigated or made public. I will look into an alternative, external encryption method, as I do understand the significance of protecting your game assets.


Credits and Thanks

Thanks to you guys here at hbgames for helping me learn the RPG Maker series over the years.

Thanks to vgvgf for demonstrating how to pack and unpack Table, Color, and Tone classes.

Thanks to Xilef for a ton of valuable input that has accelerated this project significantly.

Thanks to tmm1 for the soft Fiber implementation, and for granting me permission to use it in this project.


Contributing

Want to help? Please do! See the CONTRIBUTING.MD on GitHub, and send me a tested pull request.


License

OpenGame.exe is licensed under a Creative Commons Attribution 3.0 Unported License.


Dependency Licenses

IronRuby is licensed under Apache License v2.
OpenTK is licensed under The Open Toolkit library license.


Source Code (woot!)

OpenGame.exe on GitHub


Download

OpenGame.exe Pre-Alpha Preview Release 1


Thanks!

Thanks for checking out my project. This project has been a very-long-term ambition of mine, and I'm excited to share what I have so far with you. It's not perfect, yet, but it's reached a stage where its very much alive and will continue to grow from here. I do look forward to any feedback you'd like to share.
 
I'm super excited, this looks fantastic av :biggrin:
The lack of .mp3 support is a shame though - I totally understand why you'd do it, hell I'd do the same, but it breaks the project I'd like to use it with :<.
 
I noticed that the NuGet invocation is done by the OpenGame.exe project, yet RGSS has a dependency on the NuGet results.

Shouldn't the invocation be made by the RGSS project or am I missing something?

I seem to be missing references for Microsoft.Dynamic and Microsoft.Scripting as well as IronRuby, IronRuby.Libraries and OpenTK.

EDIT2: Ah I'm a dummy, looks like RGSS3 support isn't in yet. Ignore my complaining :V

EDIT3: With an XP project I get;
error":117i2idq said:
An exception of type 'System.MemberAccessException' occurred in Snippets.debug.scripting but was not handled in user code

Additional information: uninitialized constant Object::RPG

ot8RChn.png


Also to get XP projects working I had to make a Font folder in my RTP directory.

May be worth you setting up a virtual machine and running this on a fresh OS to figure out the steps the end user needs to take to get it working (and resolve them) as right now I can't get this working at all (pre-compiled download or compiled from source).
 
Wow, look at you diving right in @Xilef!

RGSS3 should be mostly supported. RGSS1 is going to be added today.
And at the moment they both have references to the dependencies, sloppy, I know. I'll get it cleaned up, still wrapping my head around some of these things.

Glad you caught the Fonts folder issue for RGSS1 - that saves me one headache later today, haha.

Also, regarding MP3 support - apparently you can bypass the licensing issue by getting the OS to play the file instead of playing it locally in the program. Absolutely no promises but I will look into it. (Seems its going to make cross platform that much more difficult.) The tedious part of this is having to get the OS to play it with the proper features (pitch, volume, and the reverb/speed options I'm adding to OGG).

I'm aware audio isn't integrated yet, I have a separate project for that which I'll merge in as soon as its functional enough.

EDIT: @Xilef
Missing references- I launch the program from Launcher.cs which is effectively an empty shell that adds a DLL resolution path to ./System/ . I personally prefer "pretty" binary folders, especially when its something like this, where I want to make the replacement not-immediately-obvious. Perhaps that's somehow not working for you? If you know how, get me a Failed .NET Binding Log. (If you don't, I can post the steps here).
 
Something I've been pondering on about - I'd like to make the option to hard-disable "test" functionality for production games. How do you guys think I should handle this? Simply ignore it in Release build? But that's counter-intuitive as people may expect the Release build to function identical to the original. Was thinking I could add it to the configuration file, but... that would hardly be a hard-disable.

I'd love some suggestions on the matter.
 
avarisc":3szushw2 said:
Also, regarding MP3 support - apparently you can bypass the licensing issue by getting the OS to play the file instead of playing it locally in the program. Absolutely no promises but I will look into it. (Seems its going to make cross platform that much more difficult.) The tedious part of this is having to get the OS to play it with the proper features (pitch, volume, and the reverb/speed options I'm adding to OGG).
I was going to suggest something like this but the route to go is play via Windows Media Player, and there are people who actually un-install this program and they tend to complain most about games having a dependency on Windows Media Player.

I don't think there's a good solution, but the Media Player one was the first that came to mind for me. Does Windows have an alternative Media Player or does .NET provide something of this sort?

If you can give me steps to providing the log I can do so. I can see the System folder with all the DLLs in them. Downloading your pre-compiled results in nothing happening at all when running (not even a crash) and builds that I compile myself Program-Crash with various errors from the scripting engine.

Being able to hard remove the test functionality is something that people on Steam message me asking about all the time. I would say with great confidence that disabling it in release builds and enabling it on debug builds is the best option.
 
Xilef":2bsqoyzt said:
I don't think there's a good solution, but the Media Player one was the first that came to mind for me. Does Windows have an alternative Media Player or does .NET provide something of this sort?
Not really. I'm leaning back towards my original inclination which is just to forego MP3 support, or maybe make it an optional "plugin" once we get that far. The OGG codec I'm working on is beautiful, and there are free programs to convert MP3 to OGG so maybe we can just suggest one of those in the eventual documentation.

Xilef":2bsqoyzt said:
If you can give me steps to providing the log I can do so. I can see the System folder with all the DLLs in them. Downloading your pre-compiled results in nothing happening at all when running (not even a crash) and builds that I compile myself Program-Crash with various errors from the scripting engine.
Run this program with administrative priveledges: https://msdn.microsoft.com/en-us/librar ... 4(v=vs.110).aspx
While it's running, open the Debug build of the game (which has the neccessary symbol information to create a log entry) and hit Refresh in the program. You should get an entry in the list - just hit View Log to find out why it failed.

Before doing all that, please make sure the DLLs are Unblocked (right click, properties, Unblock). I really, really hate that Windows likes to block them by default, but I had that issue myself when trying a clean build. If that is it, the only way around it is not to use the prebuilt DLLs; but for some reason building from source, be it from the repositories or from sourceforge, doesn't work. Neither does the NuGet version. Running with those, it fails to instanciate any RGSS class. Not sure if the difference is version related or if the official binaries had some special treatment.

Xilef":2bsqoyzt said:
Being able to hard remove the test functionality is something that people on Steam message me asking about all the time. I would say with great confidence that disabling it in release builds and enabling it on debug builds is the best option.
I get those messages myself, though likely not as many. I think this makes sense.
 
Also excuse my terrible github usage, I'm usually using git via command line when it's teams so going through github's web interface was a new deal with me :V I think I figured it all out, though.

I'll try it out tomorrow, it's 2am here and I'm rather tired
 
Xilef":4l2momg7 said:
Also excuse my terrible github usage, I'm usually using git via command line when it's teams so going through github's web interface was a new deal with me :V I think I figured it all out, though.

I'll try it out tomorrow, it's 2am here and I'm rather tired

No worries - I'm far from a git expert myself. (Meaning I'm more lax in my standards than it seems most people prefer). I can keep it working though, and that's the main thing.

Got a few more things done in the repo - I have RGSS1/2 booting now, dealing with a pesky Input issue at which point they should be playable until you reach the tilemap. I'm waiting for the new tilemaps to do the next preview release.

I am trying to get the GitHub issue tracker populated with known problems, so if anyone sees any that aren't listed, share them. Likewise, if you want to know the current state of things, that's probably a good place to get a feel for it.
 
Got Mono compatibility restored, if someone wants to attempt a Mac or Linux build. I'm not set up for building those at the moment, but I will be in a week or so.

I expect Win32API will simply not work on non-Windows OS's. We may need to add a build configuration for them and manually skip loading Win32API (see the first couple lines of System.rb).
 
Unblocking the DLLs got the pre-compiled versions working for me (I didn't even know DLL blocking was a thing!), however when I say working I mean they work as good as compiling myself (crashes with script engine errors).

I'm testing an OS X build now

EDIT: On OS X I have the same build problem I had when I tried building on OS X yesterday;
Failed to execute custom command 'Tools\build-deps.bat': ApplicationName='Tools\build-deps.bat', CommandLine='', CurrentDirectory='/Users/felixjones/github/OpenGame', Native error= Cannot find the specified file
Build canceled.


EDIT2: And just like yesterday, removing the command "successfully" builds, however the launch target doesn't start up. Running from command line results in;
terminal":2yx6d05g said:
Unhandled Exception:
System.EntryPointNotFoundException: GetConsoleWindow
at (wrapper managed-to-native) OpenGame.ConsoleWindow:GetConsoleWindow ()
at OpenGame.ConsoleWindow.Show () [0x00000] in <filename unknown>:0
at OpenGame.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
at OpenGame.Launcher.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.EntryPointNotFoundException: GetConsoleWindow
at (wrapper managed-to-native) OpenGame.ConsoleWindow:GetConsoleWindow ()
at OpenGame.ConsoleWindow.Show () [0x00000] in <filename unknown>:0
at OpenGame.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
at OpenGame.Launcher.Main (System.String[] args) [0x00000] in <filename unknown>:0

I'm going to attempt to attach the mono debugger.
 
Xilef":1apumsa0 said:
Unblocking the DLLs got the pre-compiled versions working for me (I didn't even know DLL blocking was a thing!), however when I say working I mean they work as good as compiling myself (crashes with script engine errors).

I'm testing an OS X build now

EDIT: On OS X I have the same build problem I had when I tried building on OS X yesterday;
Failed to execute custom command 'Tools\build-deps.bat': ApplicationName='Tools\build-deps.bat', CommandLine='', CurrentDirectory='/Users/felixjones/github/OpenGame', Native error= Cannot find the specified file
Build canceled.


The script crashes should be fixed in newer versions (until you reach a tilemap anyway- tilemap for VX and XP are still on the to-do list).

As for building on Mac.
That's a custom pre-build step that I have set to occur between building the RGSS DLL and the main project. All that batch file does is copy the DLLs from their current locations to the proper output locations (because "Copy Local" obnoxiously dumps everything right in the output root).
For testing, you can completely disable the Pre-Build Custom Command in OpenGame.csproj options and just copy the files manually (edit the batch file to see what goes where).

If that works, let me know and I'll setup custom build configurations without the batch file for Mac.
I have no idea how to do batch file stuff on a Mac as I have embarressingly little experience with any Apple OS. So I'll probably need a hand there, but for now we can resort to manually copying libraries.

Not sure if Mono actually uses DLLs on Mac or if we need to recompile the libs into something else - I don't yet have the OS to work this stuff out with, so to get it going sooner I'll be relying on feedback.

Edit: I expect to have it working on Linux later today. (at least "as working" as it is on Windows, lol).
 
Mono on OS X is a bit like an emulator, you use the command "mono my_app.exe" to run a mono-compiled win32 application.

The best way to think about it is like Java; the Mono runtime is a virtual machine and the .exe is the byte-code (which is pretty much how CLR applications run in Windows environment).

I figured out manually copying the files, I've ended up with a security access error;
Unhandled Exception:
System.Security.SecurityException: No access to the given key ---> System.UnauthorizedAccessException: Access to the path "/Library/Frameworks/Mono.framework/Versions/4.0.2/etc/mono/4.5/../registry/LocalMachine/software" is denied.
at System.IO.Directory.CreateDirectoriesInternal (System.String path) [0x00000] in <filename unknown>:0
at System.IO.Directory.CreateDirectory (System.String path) [0x00000] in <filename unknown>:0
at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir, Boolean is_volatile) [0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.KeyHandler.Ensure (Microsoft.Win32.RegistryKey rkey, System.String extra, Boolean writable, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.CreateSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.CreateSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.OpenSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x00000] in <filename unknown>:0
at Microsoft.Win32.RegistryKey.OpenSubKey (System.String name, Boolean writable) [0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey:OpenSubKey (string,bool)
at Microsoft.Win32.Registry.ToKey (System.String keyName, Boolean setting) [0x00000] in <filename unknown>:0
at Microsoft.Win32.Registry.GetValue (System.String keyName, System.String valueName, System.Object defaultValue) [0x00000] in <filename unknown>:0
at OpenGame.RTP..ctor (System.String DefaultLocation) [0x00000] in <filename unknown>:0
at OpenGame.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
at OpenGame.Launcher.Main (System.String[] args) [0x00000] in <filename unknown>:0
[ERROR] FATAL UNHANDLED EXCEPTION: System.Security.SecurityException: No access to the given key ---> System.UnauthorizedAccessException: Access to the path "/Library/Frameworks/Mono.framework/Versions/4.0.2/etc/mono/4.5/../registry/LocalMachine/software" is denied.
at System.IO.Directory.CreateDirectoriesInternal (System.String path) [0x00000] in <filename unknown>:0
at System.IO.Directory.CreateDirectory (System.String path) [0x00000] in <filename unknown>:0
at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir, Boolean is_volatile) [0x00000] in <filename unknown>:0
--- End of inner exception stack trace ---
at Microsoft.Win32.KeyHandler..ctor (Microsoft.Win32.RegistryKey rkey, System.String basedir, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.KeyHandler.Ensure (Microsoft.Win32.RegistryKey rkey, System.String extra, Boolean writable, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.CreateSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable, Boolean is_volatile) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.CreateSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x00000] in <filename unknown>:0
at Microsoft.Win32.UnixRegistryApi.OpenSubKey (Microsoft.Win32.RegistryKey rkey, System.String keyname, Boolean writable) [0x00000] in <filename unknown>:0
at Microsoft.Win32.RegistryKey.OpenSubKey (System.String name, Boolean writable) [0x00000] in <filename unknown>:0
at (wrapper remoting-invoke-with-check) Microsoft.Win32.RegistryKey:OpenSubKey (string,bool)
at Microsoft.Win32.Registry.ToKey (System.String keyName, Boolean setting) [0x00000] in <filename unknown>:0
at Microsoft.Win32.Registry.GetValue (System.String keyName, System.String valueName, System.Object defaultValue) [0x00000] in <filename unknown>:0
at OpenGame.RTP..ctor (System.String DefaultLocation) [0x00000] in <filename unknown>:0
at OpenGame.Program.Main (System.String[] args) [0x00000] in <filename unknown>:0
at OpenGame.Launcher.Main (System.String[] args) [0x00000] in <filename unknown>:0
Looks like there's a fair amount that needs to be done for OS X to get working.

DLLs in both Windows and under mono are simply executable binaries with multiple entry-points, they aren't anything special so don't think about them as any different to an EXE. If Mono can handle mono EXE files, it can handle mono DLL files.

EDIT: And once you have it working on Linux, I'd expect it to simply work on OS X. The operating systems are both POSIX based and share similar security practises (inherited from Unix on Darwin, inspired by Unix on Linux).
 
The ConsoleWindow class uses some Windows-exclusive trickery to show the console conditionally. That's a feature that will likely have to be bypassed for other platforms.

The registry keys for RTP paths are obviously failing as well- because I imagine there is no registry. Another feature that will have to be nulled for other platforms.

So I'm thinking we set up a "non-Windows" build configuration which sets a custom #define for us, then use that to disable a couple features such as a code-conditional Console window and the RTP.
 
Yeah no disgusting registry bullshit on Linux or OS X.

As some advice; keep platform specific defines as high level as possible. You don't want to litter #if WIN everywhere, it should be done as class definitions;
Code:
<div id="{CB}" style="font-family: monospace;"><ol>class MyConsole {

    public void DoStuff() {

    #if WIN

        WindowConsoleStuff();

    #elif POSIX

        PosixTerminalStuff();

    #else

        #error implement

    #endif

    }

}
I also noticed you've snuck the release directory as the output path in the debug build of OpenGame.exe, copy-paste slip? :p
Weird, seems to have fixed itself...???

EDIT: Active solution config is wrong, that's what was up. Probably when the x86 platform was added

EDIT2: Also; woo things starting to work! Up to tilemap in RPG1 as you said :D
I'll be checking out some of the other problems. I'm supposed to be working now so I'm won't be available until around 8pm UTC+1
 
Xilef":ntaud7i4 said:
Yeah no disgusting registry bullshit on Linux or OS X.

As some advice; keep platform specific defines as high level as possible. You don't want to litter #if WIN everywhere, it should be done as class definitions;
Code:
<div id="{CB}" style="font-family: monospace;"><ol>class MyConsole {

    public void DoStuff() {

    #if WIN

        WindowConsoleStuff();

    #elif POSIX

        PosixTerminalStuff();

    #else

        #error implement

    #endif

    }

}
I also noticed you've snuck the release directory as the output path in the debug build of OpenGame.exe, copy-paste slip? :p
Weird, seems to have fixed itself...???

EDIT: Active solution config is wrong, that's what was up. Probably when the x86 platform was added

Thanks for the tip. Was planning to add an OS enum to the Program class which could be checked. I really don't think there will be many places - pretty sure we've already stumbled over the majority of them.

Sorry about the solution configuration issues - I've never had to get so in-depth with configuring anything before like this project has required so far, not hard to believe it's gotten a bit messy. I've had to make several of the edits by hand due to a lack of IDE options for them. Once things settle a bit I'll likely try to go through and clean some of them up by hand, which will make spotting such errors a bit easier.

Xilef":ntaud7i4 said:
EDIT2: Also; woo things starting to work! Up to tilemap in RPG1 as you said :D
I'll be checking out some of the other problems. I'm supposed to be working now so I'm won't be available until around 8pm UTC+1
That is awesome and hope-inspiring! Try it with an Ace project if you can, as that supports the most at the moment.
I too have some things to take care of, I'll be working on the Linux build later today (in about 12 hours or so). If you get bored (ha, right) and I'm not around, I've tried to populate the issues list to be comprehensive-ish.
 
How do you write out your enumators?

I added support for a -game switch and used enumators to record the argument key for the argument value as such;
Code:
<div id="{CB}" style="font-family: monospace;"><ol>private enum Key

{

    NONE,

    GAME

}

 

Key key = Key.NONE;

The pull request discusses a few other points, but this is the one I was most unsure about. Should it be EKey or KEY_NONE, KEY_GAME, or something?

In C++ I would do this;
C++:
enum key_e {

    KEY_NONE,

    KEY_GAME

};

 

const key_e key = KEY_NONE;
 
Also notably, if the Mac build experiment reached a title screen (sounds like it did) then my worst cross platform fear is already eliminated. I was concerned that IronRuby's load_assembly function (which loads the RGSS dll into Ruby) would throw a fit on non-Windows OS. Really glad to see that works okay.

Xilef":276ezr4p said:
How do you write out your enumators?

I added support for a -game switch and used enumators to record the argument key for the argument value as such;
Code:
<div id="{CB}" style="font-family: monospace;"><ol>private enum Key

{

    NONE,

    GAME

}

 

Key key = Key.NONE;

The pull request discusses a few other points, but this is the one I was most unsure about. Should it be EKey or KEY_NONE, KEY_GAME, or something?

In C++ I would do this;
C++:
enum key_e {

    KEY_NONE,

    KEY_GAME

};

 

const key_e key = KEY_NONE;

Personally, I think your contributed code was fine as-is. Key.KEY_SOMETHING seems a bit redundant; the variable names already have unique scope by the enum name, so I personally find that less redundancy is more digestable at-a-glance. At the end of the day, however, this is a matter of preference which will vary greatly from one programmer to the next. Use whatever makes the most sense to you (long as its relatively sane).
 
avarisc":1t5i2wyn said:
Also notably, if the Mac build experiment reached a title screen (sounds like it did) then my worst cross platform fear is already eliminated. I was concerned that IronRuby's load_assembly function (which loads the RGSS dll into Ruby) would throw a fit on non-Windows OS. Really glad to see that works okay.
Forgot to say that this was all on Windows I was working on, not OS X. Sorry for the confusion there

EDIT: By the way, I figured out why fonts aren't appearing in messages;

The font texture is built on a different thread than the OpenGL context is created on, you need to do that on the Main thread.

"internal void SyncBitmap()" in Bitmap.cs is running within the Ruby Fiber for Message box font building.

It is certainly worth logging GL errors after every GL call in debug mode, however we're using OpenGL1 here so that would mean a lot of junk debugging code...I'm conflicted about this :V
 
Xilef":1arcmuih said:
Forgot to say that this was all on Windows I was working on, not OS X. Sorry for the confusion there

EDIT: By the way, I figured out why fonts aren't appearing in messages;

The font texture is built on a different thread than the OpenGL context is created on, you need to do that on the Main thread.

"internal void SyncBitmap()" in Bitmap.cs is running within the Ruby Fiber for Message box font building.

It is certainly worth logging GL errors after every GL call in debug mode, however we're using OpenGL1 here so that would mean a lot of junk debugging code...I'm conflicted about this :V

OpenTK's Debug build actually provides nice error reporting. Unfortunately, for reasons unknown to me, it also prevents the application from starting. This program is incredibly version-sensitive when it comes to the libraries- far moreso than anything I've worked on before. It's quite frustrating at times. I can only imagine I'm doing something wrong, but I haven't the foggiest idea what.

Excellent info on the text! That had me running in circles for literally days before I decided to move on to more pressing tasks. Never considered threading to be the culprit. Resolving that may take some creativity- I'm not very experienced with threading, to be forthright. Let alone communicating with the program's main thread from its embedded interpreter's child thread :\ But at least it's a lead to follow.

Also, regarding GL1, I have yet to "lock in" a decision on target GL version. I'm almost tempted to propose GLES2, as if I understand correctly its purely a subset, meaning it would be compatible with desktop or mobile as-is. I'm aware it will take a bit of reworking, that's on me for going oldschool to begin with.
 

Thank you for viewing

HBGames is a leading amateur video game development forum and Discord server open to all ability levels. Feel free to have a nosey around!

Discord

Join our growing and active Discord server to discuss all aspects of game making in a relaxed environment. Join Us

Content

  • Our Games
  • Games in Development
  • Emoji by Twemoji.
    Top