I think it would be far better to come up with a cross-platform file I/O system which works transparently with both Awesomium and browsers which support file systems. However, that means not using the traditional file I/O, so I'm not sure what that would look like. It probably means unlimited file I/O, but in a sandbox (where the user can only choose files previously saved to the sandbox).
It sounds good, but I'm concerned with transferring the files in the sandbox into and out of the browser. It's not an elegant process having to use a windows dialog box to do it. What if I have a lot of files there that I want saved to a folder to reimport into C2's files section later? Would I have to save each one individually every time they get updated? Or would it instead work to basically "ship" the game WITH the sandbox to the user? If that's the case, then that would solve a lot of the reasons I wanted file I/O.
> File size - Not as much of an issue these days, but it seems a waste especially with needing 3 copies of each sound file in each backup of a game.
Not sure why this is a reason for EXE preview. Only .oggs are exported with Awesomium since it can read them.
It was more a reason for file I/O - what you mentioned above about the sandbox would fix it though (and it wasn't much of an issue anyway).
aving times - true, saving as a project is faster, but even with a small game it can start to take a bit of a disconcertingly long time when imagining how much longer it would take to save a big game.
Not sure what you mean here, do you mean save times in C2? Why would a new preview option affect this?
I was thinking the file I/O would affect it, because then c2's editor wouldn't have to do anything with the files when saving since they wouldn't be kept in the project, but on second thought, if you coded C2 so that if a file wasn't modified it doesn't get rewritten when saving, I guess that wouldn't happen.
reviewing times
Preview times for an EXE are likely to be the same as previewing in Chrome. Classic was slow because it would build a new data file for each preview, as if exporting. C2 now points the browser to the existing project files without copying anything, so even large projects should be fast. I don't see an EXE previewer improving on this.
I was thinking that the browser itself could potentially take quite a while loading everything at the start. However, with how you described how it works, as long as the eventual option for loading objects/layouts can read things from disk as they're needed rather than all at once at the start, I guess that's a non-issue as well.
pdating files - if we want to update a piece of music, we have to go through the process of importing and replacing it each time. If we could have it load from disk, all we need to do is overwrite the file.
If you save your project as a folder, don't you get this already?
*Facepalm* - yeah. Forgot about that.
ome people want to make EXE-only games - it would be very, very nice to preview directly via the output method they're going to use - no having to wonder if the game is going to work differently via the EXE exporter (bugs in awesomium or such, etc). A lot of bugs are found when testing other stuff in the preview - having to do a whole extra round of testing specifically for the export would be extremely inconvienent, especially for large games like an RPG!
I admit this is probably the best reason for making an EXE previewer. But if we can get it working nearly identically to Chrome, I still think that's a better solution. Hopefully the EXE exporter can literally be Chrome in its own window.
I have to disagree here. I still think it's important to preview the game as it will be delivered, as well as a complex game could potentially expose previously unknown bugs. Also, I just feel... uncomfortable with the idea of shipping a game that I didn't test thoroughly in its shipped form.
hat's worse, is when previewing via a browser, that's 2.5/5 MB shared for ALL games made with construct 2!
The limit, if any, is per-game. However it is most likely any limit can be removed anyway.
Per game if it's EXE, sure, but with web browsers it seems that the webstorage for all C2 games that I'm developing show up in the same keys list under resources in chrome - which implies they're sharing the same 2.5/5 MB limit. Is that incorrect?
ebstorage issues - as browsers have limits of 2.5 or 5 MB for webstorage...
This is only because browsers operate on the open web. The limit can be removed in Awesomium. I'll check if this is done already or if we need to do something.
That would be fantastic, but it still runs into the problem:
I'd prefer not to add a preview option for EXE if it basically works the same as the Chrome browser.
...that it doesn't work the same if EXE has no limit to webstorage and browsers do. Most of the benefits of unlimited webstorage are for while developing the game, rather than after export.
I understand your reluctance to add EXE-only features, and if sandbox you mentioned was implemented and especially the limit for webstorage was removed, I guess I'm okay with no direct to disk file I/O as it won't limit us that much, but I still strongly feel the need for previewing as EXE for the webstorage limit reason alone, and also I still think it's important to preview a game as it will be played. Would it be difficult to add it as a feature? Because I think a lot of people would use and appreciate it.