Welcome Guest ( Log In | Register )

[ Big| Medium| Small] -



Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2  Next
    aphadeon
  Mon Jul 27, 2015 12:35 pm
1987-2023
User avatar
Staff

Generic Townsperson
Image 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.


Last edited by aphadeon on Thu Jul 30, 2015 4:44 am, edited 5 times in total.

Top Top
Profile      
 

    ZenVirZan
  Mon Jul 27, 2015 4:20 pm
very undead
User avatar
Sponsor

Inept Evil Stooge

Location: land of the snags 'n tracky-dacks
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 :<.

_________________
Image


Top Top
Profile      
 

    Xilef
  Mon Jul 27, 2015 5:42 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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 wrote:
An exception of type 'System.MemberAccessException' occurred in Snippets.debug.scripting but was not handled in user code

Additional information: uninitialized constant Object::RPG


Image

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).


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 1:15 am
1987-2023
User avatar
Staff

Generic Townsperson
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).


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 1:36 am
1987-2023
User avatar
Staff

Generic Townsperson
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.


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 1:41 am
User avatar
Staff

Big Dumb Guy

Location: UK
avarisc wrote:
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.


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 1:53 am
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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 wrote:
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 wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 1:59 am
User avatar
Staff

Big Dumb Guy

Location: UK
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


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 4:50 am
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 11:19 am
1987-2023
User avatar
Staff

Generic Townsperson
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).

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 12:21 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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 wrote:
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.


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 12:32 pm
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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).

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 12:38 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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;
terminal

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).


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 12:42 pm
1987-2023
User avatar
Staff

Generic Townsperson
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 12:47 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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;
Expand to see the code.

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


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 12:59 pm
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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;
Expand to see the code.

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 wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 1:49 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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;
Expand to see the code.


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;
Expand to see the code.


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 2:03 pm
1987-2023
User avatar
Staff

Generic Townsperson
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 wrote:
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;
Expand to see the code.


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;
Expand to see the code.


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).

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 2:15 pm
User avatar
Staff

Big Dumb Guy

Location: UK
avarisc wrote:
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


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 2:38 pm
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Tue Jul 28, 2015 2:59 pm
User avatar
Staff

Big Dumb Guy

Location: UK
avarisc wrote:
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++:
Expand to see the code.


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.


Top Top
Profile      
 

    aphadeon
  Tue Jul 28, 2015 3:10 pm
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    aphadeon
  Wed Jul 29, 2015 9:11 am
1987-2023
User avatar
Staff

Generic Townsperson
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.

_________________
Image ImageImage


Top Top
Profile      
 

    ZenVirZan
  Wed Jul 29, 2015 10:03 am
very undead
User avatar
Sponsor

Inept Evil Stooge

Location: land of the snags 'n tracky-dacks
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.

_________________
Image


Top Top
Profile      
 

    aphadeon
  Wed Jul 29, 2015 10:25 am
1987-2023
User avatar
Staff

Generic Townsperson
ZenVirZan wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Wed Jul 29, 2015 12:57 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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 wrote:
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.


Top Top
Profile      
 

    aphadeon
  Wed Jul 29, 2015 4:27 pm
1987-2023
User avatar
Staff

Generic Townsperson
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Wed Jul 29, 2015 5:06 pm
User avatar
Staff

Big Dumb Guy

Location: UK
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.


Top Top
Profile      
 

    aphadeon
  Wed Jul 29, 2015 5:45 pm
1987-2023
User avatar
Staff

Generic Townsperson
Xilef wrote:
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 wrote:
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.

_________________
Image ImageImage


Top Top
Profile      
 

    Xilef
  Wed Jul 29, 2015 5:57 pm
User avatar
Staff

Big Dumb Guy

Location: UK
avarisc wrote:
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!
Image


Top Top
Profile      
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 36 posts ]  Go to page 1, 2  Next


Who is online

Users browsing this forum: No users and 3 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum

We are an independent, not-for-profit game making community.
Homepage
Board Index
About Us
Downloadable Games
Free Browser Games
Games in Development
RPG Maker Support
Game Maker Support
Construct 2 Support
HBGames the eZine
Advanced RPG Maker
Site Announcements
Powered by phpBB © phpBB Group