Skip to main content ↑ ↓
Topic: neoSphere 5.10.1 (Read 8506178 times) previous topic - next topic
0 Members and 13 Guests are viewing this topic.

Re: minisphere 1.0b4

Reply #180 –
The three that I know are used at least sometimes are circles.js, time.js, and colors.js. I would leave at least those. Colors just needs a working CreateColor (I modified the one included with TurboSphere to use the color constructor), time.js just needs GetTime(), and circles.js needs Surfaces that have the circle primitive methods.

On the other hand, I really recommend exposing a Delay function that replaces time.js from the engine itself, as TurboSphere does, to allow games to not use 100% of the CPU even when idling.

Re: minisphere 1.0b4

Reply #181 –
Quote from: Flying Jester – on

On the other hand, I really recommend exposing a Delay function that replaces time.js from the engine itself, as TurboSphere does, to allow games to not use 100% of the CPU even when idling.


Way ahead of you on that one.  I already implemented Delay() a few days ago, it will be in 1.0b5.  Keeping CPU usage down is one of my main concerns with minisphere.  I hate that Sphere 1.5 maxes out a core the whole time it's running, which is why I implemented the timed sleep after FlipScreen a few betas ago.

Re: minisphere 1.0b4

Reply #182 –
So, minisphere finally has in-engine error messages.  Having to grab the mouse when an error popped up during testing was starting to get annoying. :P  See screenshot below:

Edit: minisphere 1.0b5 is out!  This will probably be the last beta, next release will either be 1.0 or a release candidate, depending on how confident I'm feeling about the code.

Re: minisphere 1.0b5

Reply #183 –
Oh, by the way, there's an Easter egg related to the Abort and Alert functions, let's see if anyone can find it.  :) (No cheating by looking at the code!)

Re: minisphere 1.0

Reply #184 –
Well, after 2 months of nonstop coding, minisphere 1.0 has been released! ;D  There's still a handful of Sphere APIs missing or unimplemented, but no real showstoppers, so I figured now was as good a time as any for the 1.0 release.

See the OP to download and go crazy!  Don't forget to report bugs as I'm sure there's a ton of them... :P

Re: minisphere 1.0.1

Reply #185 –
Just posted minisphere 1.0.1, fixing a couple bugs discovered by Radnen.

Re: minisphere 1.0.1

Reply #187 –
So, I just tried compiling Minisphere on OS X.

How high is the warning level on MSVC turned up for you? You have on bazillion implicit-int and default-return warnings now...it wasn't like that before.

I opened another pull request. I had to remove min/max again, and itoa is nonstandard and does not exist outside MSVC and GCC, but it's just a few lines different, plus the SCons files. The bare minimum to confirm that everything is compiling correctly.

Re: minisphere 1.0.1

Reply #188 –
Quote from: Flying Jester – on

So, I just tried compiling Minisphere on OS X.

How high is the warning level on MSVC turned up for you? You have on bazillion implicit-int and default-return warnings now...it wasn't like that before.

I opened another pull request. I had to remove min/max again, and itoa is nonstandard and does not exist outside MSVC and GCC, but it's just a few lines different, plus the SCons files. The bare minimum to confirm that everything is compiling correctly.


The warning level is whatever MSVC's default is.  It doesn't usually warn for implicit conversions, so I don't bother with casts.  I'm trying to keep those to a minimum anyway to make the code easy to read; if given the choice between cluttering up the code with casts or putting up with warnings, I'll generally choose the latter.  If I wanted to have to cast everything I'd be using c++ not C...

Long story short, I find implicit conversion warnings patronizing. :P

A min/max snuck back in?  I've been using fmin/fmax... Must have been a brainfart on my part.

The default returns are actually spurious and can be ignored.  There is no platform-independent way to declare a no-return function so I just put up with them.  duk_error_ni() calls duk_error_va_raw, which calls longjmp and thus doesn't return.  The compiler isn't smart enough to figure that out though, so you get warnings.  Before I was calling the built in duk_error directly, which IS declared no-return, which is why you didn't get them before.

Re: minisphere 1.0.1

Reply #189 –
Quote from: DaVince – on

Awesome! Good work. Any way to compile this under Linux?


Well as you can see, Jester got it to compile under OS X, so in theory nothing should be stopping it from compiling in Linux either.  I tried to write the code to be as portable as possible, and libraries were also carefully chosen to this end (Allegro, Duktape and Dyad are all supposed to work on at least the Big 3).  Unfortunately Win8.1 doesn't appreciate dual boot configurations and I don't have a spare computer, or I would have tried this myself in Ubuntu.

Re: minisphere 1.0.1

Reply #190 –
Note that it aborts on something about joystick in Allegro when starting up on OS X. But it should still compile with GCC, at least on 64-bit systems.

https://github.com/FlyingJester/TSPR/blob/master/noreturn.h

It's not too difficult to do noreturn in a way that MSVC, Clang, and GCC accept :)

Re: minisphere 1.0.1

Reply #191 –
Do you know what the joystick error is by any chance?  If I knew the exact message I could google it.

Re: minisphere 1.0.1

Reply #192 –
@Flying Jester:
Well, I experimented with raising the warning level in MSVC from level 3 to level 4, and got a ton of spurious warnings, so I'm thinking I will probably lower it again.  What irks me most is all the C4706 warnings (assignment within conditional expression) from perfectly idiomatic lines like this:
Code: [Select]
if (!(image = create_subimage(parent, x, y, width, height))) goto on_error;


That code is perfectly clear in its intent, the warning is not needed.  And sure, I could go around disabling warnings individually, but that starts to defeat the purpose of the higher warning level, so I might as well just leave it at level 3 where it compiles cleanly.  I think the low number of major bugs putting together an engine this fast speaks to the fact of me knowing what I'm doing here without the compiler complaining at me. :P

Also: Don't ever try to compile a Win32 app in MSVC with -Wall - You will get a crapton of warnings (as in, tens of thousands! :o) just from the Windows headers alone.

Re: minisphere 1.0.1

Reply #193 –
Some of it a little concerning, even so. This is on the default the settings for GCC/Clang. Clang not pretending to be GCC is even less forgiving.

You should probably at least add safe-guard return statements or use some macros to fix the non-return statements. Technically it's undefined behaviour to even call a function like that.

Some some stuff, like this:

Code: [Select]

static js_BindJoystickButton(duk_context* ctx)


It's not well formed ANSI C to not have a return type. GCC is gracious about it, but Clang doesn't accept it.

In this case:
Code: [Select]

minisphere/main.c:267:13: warning: assigning to 'char *' from 'const char *' discards qualifiers [-Wincompatible-pointer-types-discards-qualifiers]
                file_name = file_name != NULL ? file_name + 1 : file_path;


This is bad. Not respecting constness is undefined behaviour, as well. If you cannot avoid it then you should add a cast.

...anyway...

In some cases it is telling you that you are not following the standard, but the compiler is willing to let it slide, such as in the default-int, const-incorrectness, and non-returns. The compiler could quite validly deny this code even to compile. These are the ones I'm properly worried about, because a standards-compliant compiler may or may not actually compile it.

Re: minisphere 1.0.1

Reply #194 –
The functions with no return type I discovered myself during my foray into /W4, those were accidental and I'm not even sure how that happened.  I must have been falling over tired when I wrote something like static js_BindJoystickButton.  I fixed it in my latest commit.

As for const-correctness, from what I understand - if we're being technical about it it's not undefined behavior to cast away constness (C++ has const_cast for a reason), it's only UB if you write to an actual constant.  I'm not saying this isn't a potential source of bugs of course, just want to dispel any misconceptions.  That said, const-correctness is something I do take seriously (if you look at the code, I declare a good number of const pointers myself), but if MSVC doesn't warn me about it, I may not always catch violations.  But even with /W4, I don't get any such warnings, and /Wall is just unfeasible as mentioned above.  Clang must just be REALLY pedantic.

I did fix the no-return functions in the latest commit, I added a noreturn macro so I can now use noreturn in place of a return type.  I wasn't aware GCC would accept the __attributes__ before the function declaration, I thought it had to go after, which would have complicated the macro.  Thanks for the tip. :)

Oh, and regarding that const violation on line 267, I'm thinking that came about due to confusion with strrchr, which is defined, at least in MSVC, as:
Code: [Select]
char* strrchr(const char*, int);


Not sure who had that bright idea, but that's a const correctness violation waiting to happen--and in fact, one did.  Anyway, I fixed it.