Skip to main content ↑ ↓

Show Posts

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

Messages - Flying Jester

1
Engine Development / Re: miniSphere 4.8.4
That's not a great method even on Linux, the proc filesystem is not very consistent or portable even between kernel versions.
2
Engine Development / Re: miniSphere 4.8.3
Quote from: Rhuan – on
A couple of notes on my points above:
V8 documentation: a lot of content on their wiki has been written this year, so it may have been a lot worse before.

It was non-existent before. A big part of when I switched to SM for TurboSphere was that V8 was largely undocumented, and what was there was unusable. The API changed wildly every couple months (compared with SM's, which is quite stable in comparison), and there was no documentation at all, except three pages of outdated descriptions of APIs that no longer existed, and two examples that were not updated since before I began the project.

Regarding API stability, unless things have drastically changed in the last couple months since I updated some Turbo code to SM 52, SM is still way, way more stable than V8.

I also caution against using V8 for anything relating to graphics or files, since its GC is very unreliable. SM's was much more stable, always releasing memory in a timely manner. This made V8 basically unusable for Galileo or any FS work.
3
Engine Development / Re: miniSphere 4.6.0
There's a reason that I had proposed for Pegasus (and implemented in TurboSphere) clients and servers explicitly being different (a Socket and a Listener).
4
Engine Development / Re: miniSphere 4.5.11
Well, a lot of the lines in that function are because one: Sphere 1.x does all GC rooting there manually (and does a lot of unnecessary GC rooting), and two: Spritesets don't have actual constructors/classes, so it is literally doing this in the most complicated way possible.
5
Engine Development / Re: miniSphere 4.5.11
If you do use it directly, you usually want to put it into your game's engine code. In my prototype games (mostly RTS and puzzles, but the concepts apply to RPGs) I usually attached Shapes to a character [proto]type (ie a sprite), and then had a Group/Model for each character that included the shape of the type. This is more efficient than the v1 API which amounts to immediate mode, and actually works pretty well with a prototypical object model, and for an RPG type of game (each prototype of a character or enemy 'class' in the RPG sense, or unit type in an RTS has a Shape, and each instance has a Group/Model, which means the actual sprite is the Shape, and is not duplicated between individual characters in memory or on the GPU).
6
Engine Development / Re: miniSphere 4.5.11
I managed to avoid any of those issues by only ever using nearest-neighbor filtering for zooms. That should never cause bleedover from adjacent atlas entries.
7
Engine Development / Re: miniSphere 4.5.11
I also wouldn't look too much at how the old Sphere drivers worked, they tended to be assuming a very fill-limited architecture, rather than vertex-limited. A much smarter solution would just have been to do per-scanline fills using GL_LINES. There was a reason that I decided to write my own, although doing so strengthened my resolve that an API with persistent primitives was needed for performance that was significantly higher than a software solution.

That was a part of what lead my first prototypes of Galileo, and I determined that you got a HUGE boost in performance by forcing triangle-based geometry definitions (slow geometry is hard to specify, fast geometry is simpler), and by encouraging persistent geometry (all modern graphics frameworks use this in some manner). The design also lends itself to "accumulator" based asynchronicity, as it was implemented in Sapphire, which vastly improves performance.
8
Engine Development / Re: miniSphere 4.5.11
Quote from: Fat Cerberus – on

So apparently Sphere 1.x implements Complex in OpenGL by drawing it pixel-by-pixel using GL_POINTS.  *shudder*  Even with a modern GPU I can’t imagine that being very efficient.  And in any case it won’t work properly with miniSphere’s fullscreen scaling method.  I’ll have to see if I can come up with a different approach.


I can't imagine that the complex primitive is very important, though. I never even bothered implementing it, even in the faster GL driver I wrote for Sphere 1.6, and I never had any issues.
9
Site Comments / Re: Idea: eventually migrating the forum?
Assuming that the performance is reasonable, I think that being better maintained is a big enough plus given how important anti-spam and security (which also is a plus for newer PHP) is for forum software.
10
Sphere General / Re: Collection of all the Sphere games I have
Unfortunately, a number of my better tech demos (including Attack! and Organ Grinder) I never actually released, and they are completely lost now :(

But it's amazing that you saved my SimCity attempt, that's a real trip back in time.
11
Engine Development / Re: miniSphere 4.5.11
Quote from: Fat Cerberus – on
The problem here actually has to do with when slurp_size is zero--because the file was totally empty--then al_open_memfile() doesn't cooperate and crashes.


This is largely the same as how memory mapping files directly with OS APIs works. A zero-length file is not obvious from a file that doesn't yet exist if you try to memory map a file without checking if it exists first.
12
Resources / Re: Function to parse a CSV file
Quote from: Fat Cerberus – on

Huh, CSV is a weird format.

CSV is a "format" in only the loosest sense. Parsers have to be extremely lax, and encoders should be extremely simple, since it's so loose.

Quote from: Fat Cerberus – on

I've never seen any language where putting a newline between quotes wasn't a syntax error (usually they are escaped as, e.g. \n).

Python lets you do it if you use three double quotes. Mercury works this way by default. It's actually extremely convenient, and makes me wish more languages had some way to do this.
13
Programming / Re: Pathfinding - can someone give me some pointers?
Quote from: Rhuan – on

Thanks for all of the replies, sorry for the slow turn around, life got in the way.

I've now scripted Dijkstra's Algorithm and it's working nicely, the key thing that Breadth First can't do as far as I understand that Dijkstra could do is have different movement costs for different nodes and ultimately find the cheapest route to each point - a feature I wanted.


You can do this with breadth-first, but it requires explicitly storing each graph node's current movement value (instead of using the branch's length), and performing merges where you find shorter paths to existing found locations, which is much more complex than if you don't want to have differing node costs.
14
Engine Development / Re: miniSphere 4.5.11
If TypeScript actually got sum types/discriminated unions (as they claim they will), it might be very useful. But I think that's still not even agreed upon for inclusion.
15
Sphere General / Re: Sphere as a starting point for programming
Thinking about the tutorials, one thing that was always really good about the Spherical culture (in particular compared with RPG Maker culture) is that when someone asks for help, the response is always to help teach them. People very rarely just copy scripts from other people, rather they use them to learn how things are actually done, and everyone is very helpful in teaching.

Even compared with the culture of more advanced tools and languages, where copying source without understanding it is still frowned upon, there is a much stronger culture of learning and teaching here. Probably it's because Sphere is incompatible with 99% of all JS in the wild without some modification of the script, and the small community size. But perhaps that's not a bad thing, given how helpful people try to be.