Skip to main content

News

Topic: The Sphere Studio v1.2.1 (Read 200500 times) previous topic - next topic

0 Members and 7 Guests are viewing this topic.
  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.6.0
Reply #315
It had partial support in Wine, I know Wine has gone a long ways now, but since I moved this code to .net 4.0+, I doubt it'll have the support it once had.

My best guess honestly is to simply try it out in Wine and tell me how it goes. Try using the newer development versions. Now, it is possible to compile it in mono, but I'll have to do some rework with the form controls etc.
  • Last Edit: March 04, 2014, 07:21:04 pm by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: Radnen's Sphere Studio v1.1.6.0
Reply #316
You have to compile it in Mono if you want 4.0+ code to work well in Mono. The runtime code that .NET 4.0+ produces is not fully supported by Mono, but if you compile it in Mono to begin with there should be no issues. I actually found this out after having issues with several other .NET programs that wouldn't work on Mono, and it is a known problem.

Still very much willing to test things out for you if you decide to rework those form controls. I'd love for this to be fully cross-platform, as it just looks so much better than the standard editor.

Re: Radnen's Sphere Studio v1.1.6.0
Reply #317
+1 for a Mono version, too. I tried a couple times to compile it with Mono, but I just do not know enough about the editor, C#, or Mono to make it work.

I would love to have this working in Linux! That would mean I could actually have Sphere 1.6 and a Sphere editor running on my computers without Wine!

Re: Radnen's Sphere Studio v1.1.6.0
Reply #318
+1 mono. I tried it yesterday with both wine and mono. Mono got me closer it seems to open window components but freezes up trying to display content within those windows. Judging by the last couple posts, it doesnt work under it yet...

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.6.0
Reply #319
So I just did some reformatting and moved some plugins over to the official unoffical Sphere Studio plugin repository.

Here: https://github.com/sphere-group/sphere-studio-plugins

So if anyone wants to make a plugin, they can start there. I hopefully made it easy to make plugins. I'm planning on making an irc plugin for Sphere Studio; I just need to find a good irc library and then create a plugin for it. ;)
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

Re: Radnen's Sphere Studio v1.1.6.0
Reply #320
Are there any plans for a subversion or Git plugin?

Because that would be really cool!

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!
  • Last Edit: March 19, 2014, 06:57:38 pm by Flying Jester

  • Rahkiin
  • [*][*][*]
Re: Radnen's Sphere Studio v1.1.6.0
Reply #321

Are there any plans for a subversion or Git plugin?

Because that would be really cool!

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!


+1.

I support this idea! Even though I can't use the editor :P I will implement it in my own IDE.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: Radnen's Sphere Studio v1.1.6.0
Reply #322
It's funny, because the thought crossed my mind to make a git plugin for Sphere Studio.  Git support is built into VS 2013 now, and it's really nice to have it built into the IDE like that.  But I didn't do it because it would be a ton of work and I really want to concentrate on Specs at present.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Rahkiin
  • [*][*][*]
Re: Radnen's Sphere Studio v1.1.6.0
Reply #323
Git is also integrated in since Xcode 4 (but it sucked ballz back then). Now it is quite nice.

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.6.0
Reply #324

If you make one, a rich sub-plugin system would be nice, too. The ability to dynamically generate or modify git repos to include submodules that contain the plugins required for the game when used on a plugin-based Sphere engine, depending on what plugins the game needs, would be some seriously cool and powerful stuff!


I can a kind of dependency management system like what Node.js has. Games require files that exist on the Sphere downloads repo and are downloaded when the game is 'built' on the machine. It could aid in shrinking the overall library code in your repository. For Lord English's game, he could use something like this to separate kh2bar, link, analogue, etc. from his own code.

But that's still some time away. My priorities are not on the editor right now, even though I'd love to do more plugins.
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Radnen's Sphere Studio v1.1.6.0
Reply #325
Re dependency management - that's the exact reason I pushed so hard back in the day for Flik to add /common directory support to the file management functions. I'll likely write an official recommendation for this in the Sphere-compatible wiki article once I'm on a PC but in the meantime I'll declare here any dependent resource management system written for Sphere should ideally download to a subdirectory of a given format inside the common directory pointed to by Sphere.
  • Last Edit: March 22, 2014, 05:14:57 pm by N E O

  • Rahkiin
  • [*][*][*]
Re: Radnen's Sphere Studio v1.1.6.0
Reply #326
I'd like to disagree.

I propose the following format:

spritesets/
maps/
...
scripts/
    main.js
libraries/
    link/
        scripts/
            link.js
        maps/
        spritesets/
        ....
        package.json
    persist/
        scripts/
            persist.js
        package.json

Then we can use git submodules to add modules to our source code (a module in the library/ folder) and use gitmodule init and update to download the data. One can then export the project by just copying all the files (except the .git folder in the root of course). As a sidenote, I think downloading at runtime of the game should never be done.

// Rahkiin

  • N E O
  • [*][*][*][*][*]
  • Administrator
  • Senior Administrator
Re: Radnen's Sphere Studio v1.1.6.0
Reply #327
@Rahkiin - I don't understand what you're disagreeing with. If you could elaborate on what your proposed file structure is meant to replace so I can respond to it directly that'd be great, thanks :)

Until then, I'll elaborate on the existence of the /common directory:


  • Back in the day (pre-v1.2 or so, IIRC) Sphere file loading functions like LoadSpriteset and LoadFile could only read/write files from within the project's structure if the functions used didn't explicitly load system objects (e.g. RequireSystemScript, GetSystemArrow, etc); excessive use of ../ and/or the root / was ignored and/or stripped.
  • While this meant that one could write a ReadFile function that read, say, a text file from a randomly named directory of the game, subfolders of Sphere's base directory other than system were completely inaccessible.
  • I proposed the addition of a common directory to Sphere's base folder and the ability to read/write from/to it using the various file functions for just this purpose.
  • Support for the directory (empty as it may start) was added around v1.2 (IIRC) as well as modifying the various file functions to accommodate accessing it by starting the file path with /common ; using the root / to reference Sphere's base directory was also added, as well as aliasing ~/ to the project's directory, though use of these two has historically been not nearly as common as /common.


The intent of the /common directory is to allow separate distribution of resources and libraries intended to be global but not officially included as system resources to ease the necessity of updating every single project that uses them. Ideally the files would be put into the /common directory in a consistent structure (either like /common/some-username/scripts/somelibrary.js or /common/scripts/some-username-somelibrary.js or similar depending on the resource's type) similar to that of a normal Sphere project and users would then reference the common file path using the resource's non-system loading function (e.g. Tung's persist.js would be placed in /common/tung/scripts/persist.js and the script would be loaded using RequireScript("/common/tung/scripts/persist.js"); in a project, a font "Square 1" packaged by myself would be placed in /common/neologix/fonts/square1.rfn and loaded in script using LoadFont("/common/neologix/fonts/square1.rfn"), etc).

From anecdotal evidence (IIRC) not many users actually used /common (I'm still under the assumption it was due to lack of advertisement of the feature), opting to instead package local copies of specific versions of scripts known to work with particular projects, but it's been used: Flik afterwards put most or all his non-system flik_* scripts into common file format, Radnen did it once or twice with some RadLib stuff, Flying Jester I think intended to put Majestic in there once, and I myself created an assortment of different resources to be used freely and commonly (not quite an RPGMaker RTP, but still a thing) from /common. I didn't yet restore the "Common files package" article because I wanted to first generalize the process of coming up with a common file and/or package then put my specific package in a separate article and reference a list of resources prepped for /common directory placement.
  • Last Edit: March 22, 2014, 05:53:22 pm by N E O

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: Radnen's Sphere Studio v1.1.6.0
Reply #328
I didn't tend to use /common because it was local to your machine and made the distribution of your game's code tricky. But it is definitely a place to put libraries if the editor were to download them for you and put them in there. But, then we have git.

A lot of people like me put their games on github, so the same directory for your game is also the git repo, making /common inaccessible. Further, you can have git sub-modules in your repo, putting them in a /libraries folder like Rahkiin suggested is a good idea for something like this. Therefore I don't see /common a practical thing in the modern day of Sphere. Especially since with git you can clone a git repo, then require all the dependencies (sub-modules) you need.

But! /common's structure for other Sphere filetypes is not bad at all. There's just got to be a way of making it friendlier to games hosted on repositories. Now, Rahkiin on IRC has stated his Load* functions will check in /libraries for his engine. Which is not a bad idea for loading those other types like maps and fonts. But of course that's only going to be a feature unique to his engine.
  • Last Edit: March 22, 2014, 06:10:54 pm by Radnen
If you use code to help you code you can use less code to code. Also, I have approximate knowledge of many things.

Sphere-sfml here
Sphere Studio editor here

  • Rahkiin
  • [*][*][*]
Re: Radnen's Sphere Studio v1.1.6.0
Reply #329
Right. What she said.

As Radnen said, my idea of the libraries folder is to be able to ship it. My own game engine will ship with a single game in a complete package. I won't ship multiple games in an engine so I don't have such thing as common/. @Neo, when you said common/, I thought you meant the same thing as my libraries/, but with another name.
The use of SCM with a common/ folder is very troublesome, as it breaks everything.

To elaborate on my Load idea:

My load functions, actually any function dealing with resolving of paths, is using a resource path resolver. It always uses the same order of files. (This is not set in stone yet).
Example, loading a font, LoadFont('myFont') / new Font('myFont') (note the missing extension, because it is not needed for fonts).

  • Look in the game/fonts/ folder

  • Look in the libraries/*/fonts/ folder

  • Look in the ./ folder (relative to the file)

  • Look in the system/fonts folder
[li]
[/li][/list]

(I will have to figure out what the best order is: maybe like DLLs, local overwriting system, thus ./ as first...)
Now it is a bit more complex than that: when a library loads a file, it will first look in the own library folder, then in other libraries, and not using the game folder.

This can of course be implemented by any engine.

I had the idea of remapping ~/ and / too, because I want the file system of the game to be sandboxed. It is so easy to screw things up with the file api. I probably need to have a pointer to the User's library folder (on mac) to store game data like savegames, because an application can't just write in its own folder (IIRC). Mapping / to the game and ~/ to the User Application Data is usable i think (~/ is normally /home/USER, and / is the system. The idea fits.)
As a sidenote: in my resource path resolver, when prefixing with ~/ or /, the path is 'absolute'.


I hope this helps.

// Rahkiin