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

avarisc":1hit27xo said:
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.
You should never have the Main thread lock or wait for anything (if you are, then you're a naughty boy avarisc >:C ). What you should do is send the method that you want to be called into a pool that is consumed by the Main thread when it loops around, immediately after sending the method you need to wait for a semaphore (Win32 calls them Events or Signals) which will be fired at the end of the method.

Excuse the C++:
C++:
class WorkPool {

public:

    typedef void    ( * function_t )( void * const _data );

    

    // Job structure

    typedef struct job_s {      

        job_s( function_t _function, void * const _data ) {

            function = _function;

            data = _data;

        }

        

        function_t  function;

        void *      data;

    } job_t;

 

    Array<job_t>    jobs;   // Job List

    Mutex           jobLock;

    

    // Add job and its data to the queue

    void AddJob( function_t _job, void * const _data ) {

        jobLock.Lock(); // Prevents adding a job while the list is being consumed

        

        jobs.Add( <span style="color: #0000dd;">new job_t( _job, _data ) );

        

        jobLock.Unlock(); // Allows adding a job while the list is being consumed

    }

    

    void RunNextJob() {

        job_t * const job = jobs.Next(); // Remove the first job from the list

        

        job->function( job->data ); // Run the function with the data

        <span style="color: #0000dd;">delete( job ); // Delete the job

    }

    

};

 

class MainThread {

public:

    WorkPool    workPool;

    

    void Loop() {

        // If there's work to be done

        if ( workPool.jobs.Count() > <span style="color: #0000dd;">0 ) {

            jobLock.Lock(); // Prevents jobs from being added

            while ( workPool.jobs.Count() ) {

                workPool.RunNextJob(); // Run jobs until they are all consumed

            }

            jobLock.Unlock(); // Allows jobs to be added

        }

                

        ReadInputs();

        UpdateState();

        DrawState();

    }   

};

 

static MainThread mainThread;

 

class Thread {

public:

    Signal signal;

    

    void DoStuffThreaded() {

        // Doing some threaded stuff

        

        signal.Reset(); // Lower the signal so we can wait for it in a moment

        

        mainThread.workPool.AddJob( ( WorkPool::function_t )DoStuffMainThread, <span style="color: #0000dd;">this );

        

        signal.WaitFor(); // Wait for the signal to be raised

    }

    

    static void DoStuffMainThread( Thread * const _thread ) {

        // Doing some main thread stuff

        

        _thread->signal.Raise(); // Raise signal at the end of method

    }

};

That is something like what I have for my work's codebase with a similar scenario. You want to push the function you want to do on the main thread into a list for the main thread to be consumed, then you want to wait for that specific function to be consumed.


EDIT: Also the only version of GL that mobile is compatible with is GL 4.3 which has full support of GLES 3.0.
GL2 and GLES2 are very different. If you have plans for mobile you'll be writing a new GL renderer.
 
Xilef":5ziqj1xt said:
EDIT: Also the only version of GL that mobile is compatible with is GL 4.3 which has full support of GLES 3.0.
GL2 and GLES2 are very different. If you have plans for mobile you'll be writing a new GL renderer.

Hmm. The new renderer isn't that big of an issue (I have a GL4 renderer as a side project I can use for reference). That said, I don't want to limit the application to current-gen video cards. So I'll likely implement an entirely separate renderer for mobile targets. That will wait until I have a solid understanding of exactly what needs to be rendered, and how. (i.e. when the bugs are virtually gone)

I'll play with the threading thing tonight and see what I can do.

EDIT: Going radio silent for ~10 hours.
EDIT: Back.
 
So, doing some massive refactoring. Got a few things implemented that were discussed earlier.

Another opinion check - is there any real reason to want standard fullscreen over borderless fullscreen? I know that Windows in particular can disable a couple features (like Aero) which may buy a marginal difference in FPS- but this comes with quite a cost as well (terribly ALT-TAB lag, lossy cursor tracking, and having to wait while your machine switches resolutions - even if the resolution is unchanged).

Personally, since I discovered borderless fullscreen window about a year ago, I've absolutely loved it and prefer it (and even hack it in to some things that don't support it). As I have control over the renderer, going either way is a rather trivial task. I am tempted to default fullscreen handling to borderless fullscreen, perhaps with a conditional fallback.

The benefits of borderless window fullscreen include:
1.) Launches instantly - no delay and flicker while changing resolution
2.) Mouse performs better
3.) Can switch between applications seamlessly
4.) Does not interfere with streaming when focus is lost
5.) I like it :tongue:

However, at the end of the day, this project is "for the people", so I'd value any input you guys want to share on the matter.
 
I'd add a switch for it, and let the scripter decide. If you did that, make regular fullscreen the default, just for standard's sake.
 
ZenVirZan":qami92uf said:
I'd add a switch for it, and let the scripter decide. If you did that, make regular fullscreen the default, just for standard's sake.

I like that idea. Match vanilla by default, but still sneak in an option for my preferred method.

Speaking of switches!
Let's assume that not everyone wants to make a launcher app or use batch files to start their games. To setup default parameters, I assume a configuration file would be the obvious choice. Anyone have some input on what syntax/language, where to put it, and what to name it?

Edit: Completely unrelated to anything: I made a swamp cooler today and it works awesome.

Edit 2: I am so tired of the library dependency version issues with this project. Nightly OpenTK works on Linux, crashes on Windows. Stable works on Windows, crashes on Linux. -_-
I am now testing commit-by-commit to try to find a build that works for both. Exhausting.

Notably, I use C#/OpenTK for quite a range of projects, and have never had an issue with it before. This project is just very picky for some reason.
 
I think moving configuration options to be available in scripting is a good idea, means people can make in-game setting menus, however I think there's still a place for the F1 menu and RPG Maker instinct tells me that's where the borderless/fullscreen mode should be set along with other options.

But flexibility should probably be top priority; letting people disable the F1 menu and not use a global configuration file seems like a great idea.
avarisc":3ejcsnhu said:
Let's assume that not everyone wants to make a launcher app or use batch files to start their games. To setup default parameters, I assume a configuration file would be the obvious choice. Anyone have some input on what syntax/language, where to put it, and what to name it?
Configuration file should probably be .ini to match the use of game.ini by RPG Maker.

I think configuration should be user-account based by default, so the configuration.ini could be stored as /AppData/Local/OpenGame.exe/config.ini and all OpenGame.exe projects check for that configuration by default.

However, disabling this by script seems like a good idea. The global configuration could be handled by an F1 menu, but in script that menu can be disabled, or enabled but pointing at a game specific config file.

The game specific config file could be a section in the /AppData/Local/OpenGame.exe/config.ini or it could be a section in the game's game.ini or it could be /AppData/Local/Game Name Here/config.ini

I think all these options are good ones and should be implemented to achieve good flexibility.
 
So, I've got Linux build working. Not "ready", as it still needs some automation and a couple utility shell scripts I have yet to make to get it to assemble itself correctly.

One thing I ran into is the delimiter issue - the "cheap" fix is just to forcefully replace all instances of "\" with "/", because while the latter is improper on Windows, Windows doesn't actually care and will work just fine with either. Linux and Mac on the other hand are particular about their delimiters, and will straight up fail if the wrong delimiter is used. Likewise, capitalization becomes mission critical.

This issue applies to arguments provided via commandline, the ResourcePath array, and paths from the game scripts themselves (Because suddenly "Graphics\Titles\Night01" doesn't exist).

Notably, for any adventurous testers out there, Virtualbox broke OpenGL support due to the new mesa interface. So testing requires a real Linux install (this was a major hangup seeing I was trying to use a virtual machine to test Linux. Ended up building a custom LiveCD on USB with the project files present.)

EDIT:
I need an opinion for the Linux build. LoadAssembly, which I'm using on Windows to load DLLs from the /System/ directory, does not work on non-Windows OS. The other method of accomplishing this is a file, OpenGame.exe.config . I am not a fan of clutter in my bin folders, hence opting for the former. Now that that is impossible, there are two options for Linux- either we dump the dependency DLLs right in the bin folder, or we dump the .config in the bin folder to set the library path.

Pros of .config:
Only one additional file in the bin folder, as vs. 5 DLLs.

Cons of .config:
An additional file which is absolutely required.

Another issue is launching - seeing as most Linux users, I anticipate, at least, are not going to have Mono set up to automatically invoke when an .exe is double-clicked, the command "mono OpenGame.exe" is neccessary. I don't want to make them open a terminal to start the game. Is a simple .sh script to launch the game sufficient, or should I make a native Linux launcher app (the latter is "prettier" but opens a whole new can of worms, in that native apps have to be rebuilt for several different distros.) If anyone has better ideas, please share.

EDIT 2:
I'd like to take a moment to shoutout to Xilef, I really appreciate all the input! The light at the end of the tunnel is coming clearly into view.
 
You'll notice in one of my latest changes I added a path resolution method (again), I suggest this be used to make sure paths are correct.

As a rule; they should always end in a delimiter to distinguish them from files, windows delimiters should be \ for clarity sake and POSIX systems should be /

Are delimiters referenced in script or resources at all? I also noticed that with the -game switch custom resources are not loading, it always uses RTP for me.

For OS X the DLL files can be next to the binary; they are all hidden together when in an app bundle.

Linux the trend is move shared objects into user/system library paths, I disagree with this and I'd rather have the DLLs in the project's System folder like with Windows even if that means a config file. Can we move the Linux .exe binary into the System folder and have a new launcher at the project root?

If only Linux had OS X style app bundles...(and Windows for that matter, so many scenarios where bundles would be handy on Windows!)

EDIT: Actually moving the .exe binary into the System folder and having a custom launcher a level up also solves your problem of people not knowing to open .exe files with mono.
 
Xilef":1563ukrx said:
Are delimiters referenced in script or resources at all? I also noticed that with the -game switch custom resources are not loading, it always uses RTP for me.

In my linux test build there is no RTP, and resources are loading from a custom -game directory fine. This issue must be Windows-specific, I'll look into it in awhile.

Xilef":1563ukrx said:
For OS X the DLL files can be next to the binary; they are all hidden together when in an app bundle.

Linux the trend is move shared objects into user/system library paths, I disagree with this and I'd rather have the DLLs in the project's System folder like with Windows even if that means a config file. Can we move the Linux .exe binary into the System folder and have a new launcher at the project root?

If only Linux had OS X style app bundles...(and Windows for that matter, so many scenarios where bundles would be handy on Windows!)

EDIT: Actually moving the .exe binary into the System folder and having a custom launcher a level up also solves your problem of people not knowing to open .exe files with mono.
My goal is to keep Mac and Linux the same (at least until packaging), for simplicity, so that we only have two modes to concern ourselves with; Windows and Not Windows; as opposed to Windows, Linux, Mac. That said, I agree that moving Game.exe into /System/ resolves the issues in one blow, so I'll work towards that. Should just be a matter of looking up one level for the project root when it's not specific via commandline and we are on a non-windows platform.

EDIT 2: Do you think most people are comfortable with Make? I'm having trouble getting the build targets set up using just pre-build events.
 
avarisc":3t6040xd said:
My goal is to keep Mac and Linux the same (at least until packaging), for simplicity, so that we only have two modes to concern ourselves with; Windows and Not Windows; as opposed to Windows, Linux, Mac. That said, I agree that moving Game.exe into /System/ resolves the issues in one blow, so I'll work towards that. Should just be a matter of looking up one level for the project root when it's not specific via commandline and we are on a non-windows platform.
If Linux has it all in the System folder with a launch 1 up, OS X should have it all in the .App bin folder with the .App bundle directory being the project location.

In reality, it really is not Windows/not Windows. There will be OS X specifics and Linux specifics, the way my C++ projects go is by detection of;
Kernel Level
  • __LINUX__
  • __DARWIN__
  • __WINDOWS__
OS Level
  • __LINUX__
  • __ANDROID__
  • __OS_X__
  • __I_OS__
  • __WINDOWS__
API Level
  • __POSIX__
  • __WIN_API__

You're going to hit these differences. I suggest we separate with Windows and POSIX at one level, then have POSIX split into Linux and OS X as there will be OS specifics coming into this.

Things like paths around the system are very different, as an example; Windows has the \AppData\Local\MyApp, OS X has ~/Library/Application Support/MyApp or ~/Library/Preferences/MyApp, Linux has ~/.MyApp

EDIT: If people are building anything on Linux, Mono or not, they should be capable of using Make!

EDIT2: Here's text boxes working
http://i.imgur.com/dAtnpOy.png

EDIT3: Now with colour toning!
f284329e-363b-11e5-93b6-06946e99720f.png
 
Show Choices, Show Gold, and Show Text w/ "Dim" background are all missing contents. Likely a related issue. Window color and the tiling fix look amazing.

EDIT: Fade in and fade out are so simple- and yet so not fading in or out all the way. When they're only 1-3 lines of code each, clearly the answer is staring me in the face. But I don't see it.

EDIT 2:
If anyone wants a little test bed to see how support is coming along for the various engines, here's one I am using to test it.
http://www.mediafire.com/download/a0za4 ... e_Test.zip

Note that it does require the related RTP for a version to work.


EDIT 3:
I'm a fan of making things that "just work" - even at the cost of bending a few rules. I managed to get batch files to execute in a cross-platform manner, so you can now simply open the project and build on Linux, Mac, or Windows, and you should end up with a ready, working output. Needs more testing and prettying up, obviously, but I'm still amazed it actually works.
 
Got initial Audio implemented. At the moment it only supports .ogg files. It does support pitch and volume, but fade in and fade out are not quite ready yet.
Implementation is a bit messy at the moment, but as I get more comfortable with it it will get cleaned up.

I tried to match volume and pitch to vanilla RPG Maker, but testing was far from extensive (consisted of "ehh that's pretty close"). MIDI support will be up next, at which point I'll start getting this mess cleaned up. Then it's just the subtle details.

Notably, OGG playback has 3d support (you can specify an x/y/z position, and the engine will vaguely compensate).
OGG playback will default to centered on the screen if an x/y/z position is not provided.
Other formats will not have this capability.
 
I'm still not able to get it working on OS X at all, when I open it in Xamarin studio the NoWindows configurations are not available and after repairing that I cannot run from Xamarin studio, I hit go and nothing happens despite the build being successful.

Running from terminal works better, but it is unable to find the RGSS.dll no matter where the DLL is.

If I can get the debugger to work then I can probably work on solving these issues
 
The nowindows targets were removed in favor of a cross platform batch file.
Apparently Xamarin supports the windows side of the batch file on Mac OSX, as the Unix side would deploy the .config file which fixes your issue.

I'll tinker some more, if I can't figure something out I'll restore the NoWindows configurations.

EDIT: Actually, the nowindows configs didn't have the batch files, if you only tested those. Did you try just the regular Debug/Release build targets? I keep having issues getting my test environment to work, so I still don't have a solid way to test other platforms just yet.

EDIT 2: Onto the big task. Refactoring the tilemap to be more performant (and support other makers).
 
avarisc":3d93x8hw said:
Actually, the nowindows configs didn't have the batch files, if you only tested those. Did you try just the regular Debug/Release build targets? I keep having issues getting my test environment to work, so I still don't have a solid way to test other platforms just yet.
The regular is what it kept defaulting it to. It kept reporting that it didn't understand a command or something. I'll see if I can get the error message for you in the morning
 
And here I was figuring RGSS2/3 tilemaps were the hard ones. Then I realize that XP's "priority" tiles change z in realtime. Meh.

Just finished a heavy refactoring that fixes some of the performance snags. Also got Table ported to C#, so that I can control the tilemap directly as the engine provides it instead of copying data back and forth between Ruby and C#.

Starting on the new tilemap now, will likely take me awhile (a day or two, maybe three) but it should support all three engines when finished, at which point I'll pack up a new (and far improved) preview release. Note that tilemap rendering has been disabled in the interim (maps still work in all three engines, they are simply not visible at the moment).


EDIT: Sorry about the lack of updates for the last few days here. Real life stuff getting in the way. I about have it sorted, and progress will resume shortly.

EDIT 2: The solution was literally haunted. Because the Linux version of Xamarin Studio or MonoDevelop didn't recognize the included files, it was somehow using a precompiled version; I still have no idea where it was finding that version. The "can't find RGSS.dll" error had my head spinning - because RGSS.dll hadn't existed for several builds now, nor are there any references to it anywhere in the repo. Apparently VS precompiles resources, and Xamarin/Mono use that if it exists rather than recompiling them. So I made a new branch on the repo, called 'xplatform', and temporarily broke Windows support but got Linux working (tested on Mint, which is Ubuntu-based). There were several other minor errors which were easily fixed. Restoring Windows support should be fairly easy, I just don't have access to a Windows OS at the moment. I expect to have that fixed within a couple days, then I'll merge the xplatform branch back into master and we should have some cross platform functionality. I'll have access to OSX for this weekend, and make sure I can get it compiling there too.

Sorry about the still-missing tilemap in the latest commit. The previous tilemap had some bugs with rendering priority, and was designed in a very rigid way, not versatile enough to adapt for the other map formats. I'm still wrapping my head around XP's map format. Once I get xplatform merged I'll get the new tilemap rolling. It will load faster (as that was the cause of the 5 second delay on starting a new game) as well as support all three makers.

Side note: I love the XP map editor. It's my personal favorite. But peeking under the hood, I hate the XP map format. The priority handling versus layer depth is just akward and feels hackish.


Update:
OpenGame.exe is discontinued in favor of a replacement project, which focuses primarily on XP support, both editor and runtime. Stay tuned for announcement.
 

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