Skip to main content

News

Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - Flying Jester

31
Engine Development / Re: Sphere/MiniSphere on FreeBSD?
I would check the ports tree version of Allegro, the ports tree usually has newer versions.

Of note, 'devel' on FreeBSD usually means 'bleeding edge', not 'development libraries and headers'

EDIT: If you do build Allegro from scratch, I would try to be sure to configure for actual OSS support rather than using ALSA emulation.
32
Off-Topic Discussions / Re: Gaming on FreeBSD?
Natively, I play OpenTTD and Minecraft on FreeBSD a lot. In theory, Quake I, II, and III should work on FreeBSD natively, too. There's also a fully functioning DosBox port.

Wine on FreeBSD also works just as well as Linux, and I play a lot of Steam and GOG games on FreeBSD.

I have not had any luck getting Linux games to work through the Linux emulation layer, though. Only a few games' dedicated, headless servers.
33
Projects / Re: Sphere 6502 emulator
I will go ahead and say that for anything resembling accurate SNES emulation, JS (or really almost any non-native language) is just way too slow. The NES may be another matter, though.
34
Sphere General / Re: Sphere v2 API discussion

What do you mean about a caveat for Socket.bytesPending?


It isn't an API issue, but if you are writing documentation you should probably mention that this value can be stale by the time you actually perform a read. It's good to have people new to networking keep things like that in mind, and it's not bad to remind more experienced folks, too.


kb.getString() is there, except I named it kb.keyString() instead.  Not sure which name is better, probably getString.


Ah, I just didn't see it then.
35
Sphere General / Re: Sphere v2 API discussion
Just skimming, a few ideas:


  • Resolution should probably use actual numbers in JSON, like "resolution":{"w":320, "h":480}

  • Shouldn't time be a function? It's a little strange to have a monotonically increasing variable.

  • No kb.getString(key, shift)?

  • The argument order of Shape.draw() is a little strange. Maybe it would be better to have a shape.surfaceDraw() or shape.transformDraw() as well, since otherwise there are two default variables, either of which you may want to exclude? I would think it would be better to have two obvious functions than one weird one.

  • No support for vertex attributes in glsl?

  • You should probably add a caveat about socket.bytesPending()



36
Hellos and Byes / Re: A temporary absence for me
Of note, Chrome also has the same tech as Firefox Hello, it's just under a different name (WebRTC).


On a side note, I also wonder why, if Mozilla cares so much about privacy, they switched from Google as the default browser to Yahoo, instead of something like, say, DuckDuckGo.


Because the search engine deals help pay the bills, and DuckDuckGo isn't in a position to really have that kind of relationship with Mozilla. Yahoo is, and it is a more anonymizing front-end to Bing. It's a compromise.
37
Hellos and Byes / Re: A temporary absence for me
Firefox is nice, too. And less evil.
38
Sphere General / Re: The Sphere 1.x API is enormous
The big thing that jumped out at me was that we had lots of graphics functions that could be coalesced, ByteArrays can/should be replaced with ArrayBuffers (ByteArrays were considered a hack by Chad Austin and several others to begin with), and the map engine.

Moving the map engine to script is the logical thing to do nowadays, so that solves that. Using a newer graphics API, or simply condensing the existing graphics functions helps there.

I do think that moving towards a polygon-based graphics API (Galileo-like or otherwise) is the way to go. Although in that case, something like TurboSphere's planned shapelib is a good idea, to easily generate basic shapes like rectangles, circles, etc., since it will help projects get up and running quickly. Likely most projects will move to the raw graphics API at least in part at some point, but it's important to have that first step be easy.

The rest of the API is pretty concise. There are warts here and there, but the rest isn't so bad.
39
I think it's better to not change the clipping rect on flip. That causes more implicit rules. Without it, you know there is only one function that changes the clipping rect: SetClippingRect. With the change, you need to remember there are two, SetClippingRect and FlipScreen.

And I can also imagine getting a few support topics, "Why is the clipping rect wrong?" with that kind of change :)
40
Engine Development / Re: minisphere 3.2.0
https://developer.mozilla.org/en-US/docs/Mozilla/Projects/SpiderMonkey/releases/45

The documentation on the MDN isn't quite up to date for 45 yet. But the changes aren't too bad from 38 (mostly removing deprecated versions of functions), and in general I've really only had a couple changes to make every release. Almost always they about half the changes are related to initialization.
41
Engine Development / Re: minisphere 3.2.0
You need to either configure it to use the system nspr (default) or configure it to build its own. Fortunately, there is an effort underway to remove the NSPR dependency soon.

Also, SM is up to 45 now.
42
Engine Development / Re: minisphere 3.2.0
That was the supposed procedure right when I gave up on V8, but the depot tools were basically completely broken. 'gclient sync' would just puke a bunch of errors out when I ran it, and the V8/Chromium folks said I needed to set about twenty environment variables and set an identity in a config file, and that was when I had had enough of Google's development process :P

Before that, the gyp build scripts were broken or generated broken MSVC projects most of the time. Before that, the SCons setup they had actually worked quite well. That was actually what made me want to use SCons, since everything else V8 used seemed to be a huge disaster. That and autotools is not easy to use on Windows, while SCons just works on Unix and Windows (and a few other places Python works, too).

Building SM isn't so bad, assuming you get the actual SM source release instead of building it inside gecko. Then you download the MozBuild tools, run their terminal, go to the SM directory, and it's a matter of ./configure && make.
43
Engine Development / Re: minisphere 3.2.0
V8  is simple to build? Well, that's new, it was a huge hassle before.

SpiderMonkey isn't too bad, their instructions just worked for me on Windows the last time I tried a fw weeks ago.
44
Spherical News / Re: Server upgrade
What the hell kind of text editor turns word wrap on by default anyway?!


The same thing happened a few years ago to pico's GNU-itized variant, nano. They somehow decided that if you wanted to edit code, go use vi(m) or emacs. Any other editor must be a word processor for actual writing.

And people wonder why I still try to get real pico instead of nano.
45
I think the easiest way to make an mng would be to make a gif or apng, and then use ffmpeg to convert to mng.

And to be fair, back when Sphere was young, mng was a serious contender to gif. It's still superior in many ways, but now apng has surpassed it...for some reason.