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
16
Assuming this is for your Fire-Emblem-style game, where you see the list of possible movement locations and ensure that only one of those is selected, then breadth-first is most suitable. I've done this before, and it's actually easier to understand than how it would be used in regular pathfinding.
17
I think so. I'm now a professional software developer, totally self-taught, and I basically started with Sphere.
18
That's because as a part of the license for OS X, you may only run it on an Apple-produced computer. This includes under a VM. And since VMWare and VirtualBox require OS support, not having emulation to fallback on like Qemu does, they have to play nice with Apple to have OS X support at all.
19
A Mac Mini is also a cheaper option. But MacBooks really are pretty nice. They feel very solid, they have very good screens, keyboards, and touchpads, and have very decent built in speakers for a laptop.
20
gdb is the GNU debugger. On Mac, you probably have lldb, the llvm debugger. Both can debug executables from either toolchain. Their syntax is not quite compatible (lldb tends to be more verbose, I far prefer gdb).
21
The JS map engine implementation I did in TurboSphere ran at very good speeds. Two things helped this: For most games, you're limited by the time taken to draw the map to begin with, so more than half your time will spent in graphics no matter what happens or doesn't happen in script. In TurboSphere I 'fixed' this by making the graphics system asynchronous, but this then meant that most of the time you sat in a sleep function, although if your game did lots of computation this was a big win. Second, using a native map engine requires at least two calls out of native per frame (update, render, more if triggers, zones, keybindings, etc. are used) which will easily eclipse the overhead of script compared with native. True, you could have a game with no update or render scripts, but at that point even a script map engine in 1.5 would be more than fast enough.
I found again and again, with even close to modern JS engines the big performance hit isn't in using JS, it's in the boundaries between JS and native code.
I found again and again, with even close to modern JS engines the big performance hit isn't in using JS, it's in the boundaries between JS and native code.
22
I agree, I don't think binary formats are as evil as most folks seem to. Especially when they are as simple as the Sphere formats. But if you have to pick an interchange format for a tool outside your software stack, using JSON for a JS-based game engine seems like a decent choice.
23
Tiled does include a JSON exporter by default, as well.
24
Alternatively, I think that writing a loader for the JSON output of tiled in Sphere to load it into the map engine manually wouldn't be too tough. I've played with the format in native code, and except for its tileset specification (just uses an image, at least it's simple) it seems pretty reasonable to me. Tiled has properties that could be converted to Sphere zone, trigger, and collision properties at load time.
25
Oh, I know about that, that's why I always run them in a terminal. But it still wasn't outputting anything by using the minisphere command.
No, that's what I meant - even if you have a terminal window, if the executable was compiled as a GUI application, Windows won't allow it to print anything.
It will if you manually fflush after every newline.
26
There are also LGPL-licenses MP3 decoders, which would not interfere with the permissive license.
27
More than just being less stable, V8's API isn't very friendly. It's developed solely to be a part of Chrome, while SpiderMonkey is intended to be a good JS VM. As a part of that, it is also far better documented.
28
Also, is anyone here familiar with creating a port/pkg on FreeBSD? Once I get minisphere compiled properly on it I'd like to see how far we can take that, though admittedly we'd probably have to nudge Allegro into updating their BSD port to 5.2.x to cover our bases.
I'm pretty sure the normal way to do it is to create an entry in the ports tree and use the infrastructure there to create the package.
29
I had always expected it would be ^^. But I guess this means I can still dream of a day where ^^ will mean logical-xor.
30
That doesn't sound too ridiculous. I would, however, be surprised if the ports tree devel version was that old.