Skip to main content ↑ ↓
Topic: The Sphere Studio v1.2.1 (Read 2624510 times) previous topic - next topic
0 Members and 7 Guests are viewing this topic.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #60 –
Alright guys, v1.1.4.0 is out, here's some of the changes:

- added mirror modes to the image drawer
- fixed alpha not updating on color switch in image editor
- added bg to color box to see alpha colors
- optimized image switching, no need to redraw bg if same sized images
- changed folder browser for sphere executables to use a file dialog
- added font editor to tree view
- added error handling to the font editors, (it didn't filter for TT fonts)
- fixed not enough margin for folding on larger script files.
- made project tree show up first on project loads
- quick fix for pausing the modification of the tree view when engine runs.
- added an outline when drawing invisible rectangles in the image editor.
- minor fixes and changes

Get while it's hot! Thanks to some of LordEnglish's suggestions I think it's a bit more comfortable to use now.
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.4.0

Reply #61 –
Quote from: Radnen – on

Alright guys, v1.1.4.0 is out, here's some of the changes:

- added mirror modes to the image drawer
- fixed alpha not updating on color switch in image editor
- added bg to color box to see alpha colors
- optimized image switching, no need to redraw bg if same sized images
- changed folder browser for sphere executables to use a file dialog
- added font editor to tree view
- added error handling to the font editors, (it didn't filter for TT fonts)
- fixed not enough margin for folding on larger script files.
- made project tree show up first on project loads
- quick fix for pausing the modification of the tree view when engine runs.
- added an outline when drawing invisible rectangles in the image editor.
- minor fixes and changes

Get while it's hot! Thanks to some of LordEnglish's suggestions I think it's a bit more comfortable to use now.


Haha, you even fixed a few bugs I noticed but forgot about!  Thanks for the tree view font switcher Radnen, you're a lifesaver! :) Changed it to 10-point Segoe UI, now it's perfect! You should probably consider using Segoe UI as your default project tree font instead of MS Sans Serif, as it's much easier on the eyes.  Oh, and speaking of fonts, the Sphere font generator is basically useless right now because it renders the characters anti-aliased, which makes the resulting font look blurry when displayed at a lower resolution.  Any way of fixing that?

Oh, regarding the folding margins though... you should probably scale those based on the font size; 10 point is fine in the new version, but up that to 12 and the fold arrows overlap the line numbers again.

Edit: I cloned the spherestudio repo and checked out the code, and it appears you might be able to fix the antialiasing issue by adding...
Code: (csharp) [Select]
g.SmoothingMode = SmoothingMode.None;

...before drawing the characters.  I couldn't test it though as when I went to run the editor I immediately got a null reference exception on TreeContent.Activate();.  I don't know if it's because I'm missing files or what (I had to disable the ClickOnce signing just to run it), or just because I compiled it with VS2012 instead of VS2010, but yeah, couldn't get my own build to run.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #62 –
Good one on the smoothing mode, thanks! The red/blue stuff though I cannot get rid of. That has to do with the Windows 'clear type' layer, which you could turn off in the 'appearance and personalization' section of the control panel. There was a way, but it involved hacking the OS (turning it off, then back on), and I don't want to set your User OS settings just to get a feature working right.

Oh damn it, good one on the TreeContent.activate(), apparently I was doing it wrong. The correct interface has to load first before I can activate it. I have made the option of turning on and off the dock panels. They are off by default and so for those first building it with fresh files, you can get such a null reference. I'll fix these changes.

Edit:
If you want to update your fork, you can. Hopefully one can build from scratch again.
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.4.0

Reply #63 –
One more bug report, then I need to get some sleep: If two files have the same filename and you have one of them open, Sphere Studio gets confused if you try to open the other and just switches to the existing tab, even when the files are in different folders.

Oh, and you're not supposed to commit the .csproj.user files!  Those are machine-specific I believe, similar to the hidden .suo file but at the individual project level instead of the solution.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #64 –
Quote from: Lord English – on

One more bug report, then I need to get some sleep: If two files have the same filename and you have one of them open, Sphere Studio gets confused if you try to open the other and just switches to the existing tab, even when the files are in different folders.


Yeah, I was relying on the filename rather than the path. I really need to check against the full path.

Quote from: Lord English – on

Oh, and you're not supposed to commit the .csproj.user files!  Those are machine-specific I believe, similar to the hidden .suo file but at the individual project level instead of the solution.


It's in the .gitignore file under .user; I'm surprised that file made it through. It said 8 months ago... If it was going through it'd update each time. It was *supposed* to be deleted. Sigh. I don't know what to do about it.

Edit:
I'm surprised, but it got deleted only when I deleted it (by temporarily moving it out of the repo). This is a weird bug in git. I furthermore added a '*.csproj.user* field in the .gitignore (it shouldn't have made a difference, but now it's stricter... I guess).
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.4.0

Reply #65 –
Sleep is overrated... I figured out how to solve the ClearType issue without changing the OS settings:
Code: (csharp) [Select]
g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.SingleBitPerPixel

Re: Radnen's Sphere Studio v1.1.4.0

Reply #66 –
Quote from: Lord English – on

Sleep is overrated... I figured out how to solve the ClearType issue without changing the OS settings:
Code: (csharp) [Select]
g.TextRenderingHint = System.Drawing.Text.TextRenderingHint.SingleBitPerPixel



Wow! A while ago when I first tried solving the problem I was looking everywhere and many people resorted to P/Invoke calls that muddled with the OS. I'm glad you found this! I think the word 'hint' hinted you off? 'TextRenderingHint' huh, never knew it existed in the options until now and I've gone over them like dozens of times when originally trying to solve the problem. :o
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.4.0

Reply #67 –
One minor change to make it perfect: Change that from SingleBitPerPixel to SingleBitPerPixelGridFit.  The latter uses hints in the TT file to make the resulting text look much, much better.

Edit: Hm, looks like characters are being cut off due to not enough space at certain point sizes.  I think I'll experiment some more and see if I can fix all the bugs... :)

Re: Radnen's Sphere Studio v1.1.4.0

Reply #68 –
For the old editor's font-to-RFN, I was mostly fine with changing Windows' rendering settings before conversion. If you're going to force a particular rendering method in the conversion I really think you should allow the user to choose the setting (even through a simple toggle) instead of forcing one (the Adobe Font Folio version of Helvetica Neue, for example, will almost always look better at small sizes when rendered with anti-aliasing instead of turning it off; don't know if Adobe or Linotype updated the hinting since, but at least until Font Folio 11 this is the case).

Keep in mind that allowing certain methods of anti-aliasing may not be supported outside of Windows. This is where something consistent like FreeType would come in handy, and if I ever add font conversion to my phoenix-based app I'll use it myself.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #69 –
Quote from: N E O – on

For the old editor's font-to-RFN, I was mostly fine with changing Windows' rendering settings before conversion. If you're going to force a particular rendering method in the conversion I really think you should allow the user to choose the setting (even through a simple toggle) instead of forcing one (the Adobe Font Folio version of Helvetica Neue, for example, will almost always look better at small sizes when rendered with anti-aliasing instead of turning it off; don't know if Adobe or Linotype updated the hinting since, but at least until Font Folio 11 this is the case).

Keep in mind that allowing certain methods of anti-aliasing may not be supported outside of Windows. This is where something consistent like FreeType would come in handy, and if I ever add font conversion to my phoenix-based app I'll use it myself.


Antialiasing is one thing; you never want ClearType used for a TrueType-to-raster conversation, however, as the conversion invariably looks like crap if rendered at a different resolution or on a different background.  ClearType is something that has to be done in realtime for it to work as intended.  And we can't exactly ask every Sphere user to turn it off manually when generating fonts for Sphere!

Also, the method I figured out for doing this is a standard part of the .NET framework (specifically, the System.Drawing namespace), so there's no reason it shouldn't work in, e.g., Mono.  So I wouldn't be too worried about cross-platform issues in this particular case.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #70 –
I merged your pull request. I feel tempted to make you a developer on it, but I'm going to do a massive overhaul soonish. I aim to take each editor component and turn them into individual plugins. Starting with the script editor and then possibly ending with the map editor last.
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.4.0

Reply #71 –
I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???

Re: Radnen's Sphere Studio v1.1.4.0

Reply #72 –
Quote from: Lord English – on

I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???

The reasons would be twofold: one, it would act as a nice test to ensure that the plugin system is sufficiently powerful to handle large plugins with lots of functionality, and two, it would make the core architecture cleaner and easier to maintain.
Oh, and I would disable the script editor, seeing as I use Emacs for all my script editing.

Re: Radnen's Sphere Studio v1.1.4.0

Reply #73 –
Quote from: alpha123 – on

Quote from: Lord English – on

I don't know if I would split out the script editor myself--just sounds pointlessly idealistic for no real gain. The main strength of plugins is that you can pick and choose which ones you want to use based on your needs, but I can't think of a single use case where it makes sense to disable the script editor!  ???

The reasons would be twofold: one, it would act as a nice test to ensure that the plugin system is sufficiently powerful to handle large plugins with lots of functionality, and two, it would make the core architecture cleaner and easier to maintain.
Oh, and I would disable the script editor, seeing as I use Emacs for all my script editing.


And someone can then make a plugin that redirects all script files to "Open With..." Emacs, if it can be done. Do you use it standalone or in a shell such as cygwin? Doesn't really matter, it just changes the method of opening a file that's all.
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.4.0

Reply #74 –
Quote from: Radnen – on

And someone can then make a plugin that redirects all script files to "Open With..." Emacs, if it can be done. Do you use it standalone or in a shell such as cygwin? Doesn't really matter, it just changes the method of opening a file that's all.

Standalone. I will probably make such a plugin, unless I find out some way to embed Emacs in a .NET application (which would be so amazing, but I'm pretty sure it's impossible).

EDIT: Also, Sphere Studio 1.1.4.0 seems to crash as soon as I try to open it (Windows immediate displays that "The Sphere Studio has stopped working" dialog). I didn't have this problem with any prior versions (currently using 1.1.2.0; didn't try 1.1.3.0).