Skip to main content

News

Topic: neoSphere 5.9.2 (Read 523226 times) previous topic - next topic

0 Members and 22 Guests are viewing this topic.
  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.0.10
Reply #360
So, um... anyone want to take 1.1 out for a test drive? ;)  I just posted minisphere 1.1b1.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • DaVince
  • [*][*][*][*][*]
  • Administrator
  • Used Sphere for, like, half my life
Re: minisphere 1.0.10
Reply #361

So I took a closer look at the print() output and figured out the issue: The alpha values on your mask rect are negative.  minisphere clamps colors to [0-255].  Sphere modulo's them, which I chose not to emulate because it screws up color tweening.  You can fix the effect by changing the alpha math to ensure the alpha is always in the range of [0-255].  It's not a bug, it's a feature! ;)

Yeah, I've sometimes made use of the fact that you can go beyond 255 and the color just loops.
I'm not sure I even realized the number was going into the negative back when I coded that. Maybe I did. Anyway, I'll have to figure it out. Maths is not my strong point. :(

Quote
Also, tip: If you put a 32x32 icon.png in the project root, minisphere will use it for the game's taskbar icon. :)

Will do! For the next version, though, this one was just a bug fix release!

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #362
Admittedly it was a clever trick--send the alpha into negative to "reverse polarity" so to speak-- (-1) = 255, (-255) = 0.  Unfortunately it won't work in minisphere. :P. I'll only go so far in the name of compatibility!
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #363
@DaVince: Let me just say I love the snarky remarks Boingers 2.0 gives when you die.  The new levels were too hard for me, so I started playing the "old" level set - my favorite had to be 6 levels and about 20 deaths in, it told me "Well done" when I died and I cracked up. ;D  The game seems very stable on 1.1b1, no crashes, errors or anything.

Oh, by the way:
Code: (javascript) [Select]
if (imgtime < 48) mask.alpha = 255-(imgtime/48)*255;
if (imgtime > imgmaxtime-48) mask.alpha = 255-((imgmaxtime-imgtime)/48)*255;


As for minisphere, I've been debating a slight name change to "miniSphere".  You know, seeing as people seem to want to call it that anyway. ;)  Everyone's thoughts?
  • Last Edit: April 22, 2015, 10:39:46 pm by Lord English
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #364
minisphere all lowcase shows it to be a light weight C built app. miniSphere sounds like a method to a JS function, and MiniSphere sounds like a legacy C++ or .NET app. :P
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: minisphere 1.1b1 (stable: 1.0.10)
Reply #365
miniSphere looks weird to me...

mini.js would be catchy, even if it didn't reflect the Sphere lineage.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #366

miniSphere looks weird to me...

mini.js would be catchy, even if it didn't reflect the Sphere lineage.


Nah, too much JS-related stuff uses the .js nomenclature (Node.js immediately comes to mind), it's a dumb fad as far as I'm considered.  It would be like me calling minisphere 'minisphere.c'.  Admittedly that works better if it were actually all in one .c file (I used to do that way back in the day too :P), but...

But yeah, miniSphere does seem odd.  I'll keep the name as minisphere.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #367
I got the idea from node.js...

But I agree. Node.js has a really dumb name, I think. I expect it to be written in JS with a name like that! It's like how when something is cname, I expect it to be written in C, like cpython.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #368
So I've been thinking about the config tool I'm planning to add in 1.1, and it strikes me that almost no existing Sphere game actually uses the key mappings set using it (i.e. the GetPlayerKey() function).  Thinking about why that would be, it strikes me that the likely reason is this: Sphere's config tool is, quite frankly, an atrocity.  You have the engine for normal gameplay, but if you want to change keys, plugins, etc., you have to close the engine, run config, and then run the game again.

This whole state of affairs is a shame, as one of the many great things about Sphere is how much tedium it offers to handle for you without getting in your way if you want to do things differently.  So me, not one to let a useful engine convenience go to waste, I came up with the following idea: An in-engine configuration screen.  I could even make it a little pulldown strip at the top of the screen so you can change settings without interrupting gameplay.  I could even allow per-game config this way!
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Radnen
  • [*][*][*][*][*]
  • Senior Staff
  • Wise Warrior
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #369

This whole state of affairs is a shame, as one of the many great things about Sphere is how much tedium it offers to handle for you without getting in your way if you want to do things differently.  So me, not one to let a useful engine convenience go to waste, I came up with the following idea: An in-engine configuration screen.  I could even make it a little pulldown strip at the top of the screen so you can change settings without interrupting gameplay.  I could even allow per-game config this way!


I agree. +1
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: minisphere 1.1b1 (stable: 1.0.10)
Reply #370
Always so much new stuff every day I check the thread. :)


@DaVince: Let me just say I love the snarky remarks Boingers 2.0 gives when you die.  The new levels were too hard for me, so I started playing the "old" level set - my favorite had to be 6 levels and about 20 deaths in, it told me "Well done" when I died and I cracked up. ;D  The game seems very stable on 1.1b1, no crashes, errors or anything.

Oh, by the way:
Code: (javascript) [Select]
if (imgtime < 48) mask.alpha = 255-(imgtime/48)*255;
if (imgtime > imgmaxtime-48) mask.alpha = 255-((imgmaxtime-imgtime)/48)*255;


Thanks! And ha, yeah, that's exactly what I did. Thanks though! :)

Quote
So I've been thinking about the config tool I'm planning to add in 1.1, and it strikes me that almost no existing Sphere game actually uses the key mappings set using it (i.e. the GetPlayerKey() function).  Thinking about why that would be, it strikes me that the likely reason is this: Sphere's config tool is, quite frankly, an atrocity.  You have the engine for normal gameplay, but if you want to change keys, plugins, etc., you have to close the engine, run config, and then run the game again.

This whole state of affairs is a shame, as one of the many great things about Sphere is how much tedium it offers to handle for you without getting in your way if you want to do things differently.  So me, not one to let a useful engine convenience go to waste, I came up with the following idea: An in-engine configuration screen.  I could even make it a little pulldown strip at the top of the screen so you can change settings without interrupting gameplay.  I could even allow per-game config this way!

Yes please! And it'd be even nicer if you exposed some of the config settings through the API too, like the key bindings.

Also, input is kind of a complex beast. I was writing a long post asking for more full keymapping support that is analogous to modern gamepads, but thinking about it, this would NEED to come with a way to save the configuration in the game folder itself (and include it as a config in game.sgm or a config.ini in the same folder or something). Because some games have mappings where WASD moves you and the arrow keys do other stuff (or you need to use the mouse) while others would use the arrow keys.

It's probably a good idea to have the global config file which saves things like window scale and filter, and the game-specific section saves stuff relevant for only this game (like the input). I also think you can drop/not implement some stuff like disabling sound, because honestly, OSes just support disabling sound on individual apps now.

Oh! And sometimes you could expect different behavior from the keyboard and mouse compared to gamepads. You will want to stick with the raw keyboard input then. Sir Boingers is set up so that it both accepts the joystick API and keyboard input, but the keyboard input is all done with Sphere's keyboard-related functions because the game simply behaves differently when played with a keyboard. For example, on a keyboard, "up" makes you float, while with a controller it uses other buttons because that's easier.
However, I consider this a "don't worry about it" case as I've set up the game to check both the keyboard and gamepad anyway, and so should anyone else with controls that aren't the same on different controllers. They're more specialized cases.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #371

Yes please! And it'd be even nicer if you exposed some of the config settings through the API too, like the key bindings.

They kind of are though?  That's what GetPlayerKey() is, but nobody uses it because the current config.exe is clunky (and huge--take a look at a Sphere 1.5 distro some time--config.exe is literally the biggest thing there, even bigger than the editor! :o).  Unless you mean an API to set the mappings, in which case... eh.  I think at the point your game wants to do that, it means you're already exposing your own configuration UI anyway, so might as well go all the way and manage the settings yourself.  Let's not invite scope creep here. :)

Quote

Also, input is kind of a complex beast. I was writing a long post asking for more full keymapping support that is analogous to modern gamepads, but thinking about it, this would NEED to come with a way to save the configuration in the game folder itself (and include it as a config in game.sgm or a config.ini in the same folder or something). Because some games have mappings where WASD moves you and the arrow keys do other stuff (or you need to use the mouse) while others would use the arrow keys.


The current config GetPlayerKey() mappings are already based on a gamepad (an SNES pad, to be specific: a single D-pad with four face buttons and a Start button--Select is MIA for some reason), so it would be easy enough to expand the mappings.  The thing is though, again, Sphere's design is set up primarily for making retro games, so the conveniences provided by the engine reflect that.  Anything more advanced, in my opinion, should be done in script.  This kind of thing is why the File API exists (referring to the .ini-style File object, not RawFiles), after all.

Quote

It's probably a good idea to have the global config file which saves things like window scale and filter, and the game-specific section saves stuff relevant for only this game (like the input). I also think you can drop/not implement some stuff like disabling sound, because honestly, OSes just support disabling sound on individual apps now.

Oh! And sometimes you could expect different behavior from the keyboard and mouse compared to gamepads. You will want to stick with the raw keyboard input then. Sir Boingers is set up so that it both accepts the joystick API and keyboard input, but the keyboard input is all done with Sphere's keyboard-related functions because the game simply behaves differently when played with a keyboard. For example, on a keyboard, "up" makes you float, while with a controller it uses other buttons because that's easier.
However, I consider this a "don't worry about it" case as I've set up the game to check both the keyboard and gamepad anyway, and so should anyone else with controls that aren't the same on different controllers. They're more specialized cases.


I actually don't like the window scaling being global.  It's one of my biggest peeves with Sphere 1.5--I generally keep 2x scale on because the majority of Sphere games are 320x240, but if I happen to come across one that uses 640x480 (or higher--T&E is 800x600!), the window is bigger than the screen and then I have to reconfigure it, which shrinks all my 320x240 games in the process.

Oh, and speaking of Sir Boingers, I'm actually not a big fan on the new control setup in v2.  The 2010 version's setup was better, I think (Ctrl to bounce).  A big issue with the new controls I've had is that, when bouncing and trying to move left and float at the time, the Up input gets ignored because of simultaneous-key limitations on cheaper keyboards (the keyboard on my Core i3 2-in-1 laptop, for example).  This makes a few areas almost impossible and cost me a good number of avoidable deaths.  I think this is why old console emulators used to use Ctrl and Alt for the face buttons, actually, since modifier keys don't contribute to the 3-key limit.
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #372
From what I'd expect, all to almost all of the configuration options should be in a built in menu bar of some kind, like when using Visual Boy Advance, so you can change all those options on the fly. It makes a lot more sense to me, but I'm not sure how feasible it would be to change which graphics and audio plugins you're using on the fly.

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #373

From what I'd expect, all to almost all of the configuration options should be in a built in menu bar of some kind, like when using Visual Boy Advance, so you can change all those options on the fly. It makes a lot more sense to me, but I'm not sure how feasible it would be to change which graphics and audio plugins you're using on the fly.


Yeah, that's what I was planning here, ability to change the configuration without stopping the game you're playing.  Plugins aren't an issue as minisphere's backend isn't customizable--it's always Allegro. :)
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub

  • Fat Cerberus
  • [*][*][*][*][*]
  • Global Moderator
  • Sphere Developer
Re: minisphere 1.1b1 (stable: 1.0.10)
Reply #374
Well, I decided on a whim that 1.1 doesn't represent a big enough evolution and am now going to implement the Sapphire API from TurboSphere.  After looking at the method signatures and such, it seemed like low-hanging fruit to me. :)

If minisphere 1.1 doesn't end up being the most awesome Sphere implementation ever after this... well, I don't know what to tell you. :D
neoSphere 5.9.2 - neoSphere engine - Cell compiler - SSj debugger
forum thread | on GitHub