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 - Fat Cerberus

1
Game Development / Re: The Screenshot Thread
@DaVince I think it didn't help that for a long time all my computers had just enough RAM to run the operating system on them.  4MB for Win95, 16MB for Win98, 64MB for XP, 512MB for Vista... so even light multitasking would cause a ton of HDD thrashing and hit the system even harder than usual.
2
Game Development / Re: The Screenshot Thread
That's awesome.  Yeah, Homestar Runner was the best thing about the 00s internet.  Shame the creators moved onto bigger and better things around 2009 and just kind of left the site to rot.  Pretty soon Flash will be totally obsolete and the cartoons won't even be watchable anymore. :(

I'm kind of surprised they never ran ads on that site.  Guess they made enough money from merchandise to keep it running without them.
3
Game Development / Re: The Screenshot Thread
I still find this excerpt from the Wap 1.5 page kind of funny. "MIDI music in particular tends to hog a lot of processor capacity."
As usual, technology marches on.

Yeah, back in the day playing MIDIs, especially on Windows, was surprisingly processor-intensive.  I could never figure it out myself, apparently the Roland soundfont included with Windows was hard to decode or something.  It was bad enough that MIDI playback would actually stutter--badly--when the processor was taxed.  Then again, that was in the days of Pentiums and PIIs for which even mp3 decoding was a chore.

I still remember trying to coax Winamp into playing mp3's on a 486/66... it was an uphill battle, but I did ultimately get it to work--by forcing the mp3 plugin to decode at 8-bit quarter-resolution (i.e. 11kHz).  It murdered the sound quality, but at least I got to listen to my music! :stuck_out_tongue:
4
Libraries / Re: MapEngine for Sphere v2
Well, it's not just a matter of renaming the file, for the record - the file extension is just a hint to programs.  You actually need to convert the .rmp map to the .mem format, which is what the included Cellscript does.  Same deal with the spritesets.
5
Projects / Re: Project ZeC (My Zelda-esque Clone)
@DaVince I think the last time FBnil was active he was using miniSphere 1.x-ish so that was definitely before I committed to supporting Linux officially.  I now do tarball releases for Linux so building there should be no issue at all these days.
6
Engine Development / Re: miniSphere 5.2.11
I released miniSphere 5.2.11 which fixes a bug with dynamic import() and updates ChakraCore to the latest stable release (1.10.0).  This is the final version of miniSphere 5.2 so that I can focus on coming up with ideas for 5.3.  As always though, if there are any issues let me know so they can get fixed. :smiley:
7
Engine Development / Re: miniSphere 5.2.9
Forgot to mention this above, the module fix besides fixing the aforementioned crash, also corrects module load order which was previously reversed, such that imports will now correctly execute in the expected order, e.g. this will now work properly:
Code: [Select]
import 'side-effect-module-1';
import 'side-effect-module-2';

In miniSphere versions prior to 5.2.9, such imports would execute in reverse order, which could cause issues especially in cases where modules are pulled in only for their side effects, à la legacy RequireScript. Special thanks to @Rhuan for fixing this in ChakraCore.
8
Engine Development / Re: miniSphere 5.2.9
miniSphere 5.2.9 is up.  It fixes a few minor SSj bugs as well as a bigger issue where certain combinations of circular module dependencies and import() (or require()) can crash the engine.  Barring major unforeseen issues (read: a showstopping bug), this will be the final release in the 5.2 series so that work can commence on miniSphere 5.3.
9
Projects / Re: Project ZeC (My Zelda-esque Clone)
You had an excuse before as Duktape wasn't *that* much faster, but now you're missing out on blazing fast JS by sticking with 1.5 ;)
10
Engine Development / Re: miniSphere 5.2.7
Yeah, the default project has been broken since miniSphere 5.0.0, that release changed the API significantly compared to 4.8 but it seems that I neglected to test creating a new project before I did the release.  I'll fix this in 5.2.8.  There was also a separate, more serious issue I discovered where several APIs are missing due to a bug in apiLevel handling.

Note that API Level 1 is frozen since 5.0.0 (the system modules are not, but I do try not to break them unnecessarily), so breakage like this should be minimized going forward.
11
Projects / Re: Project ZeC (My Zelda-esque Clone)
The minimum requirement to run ChakraCore (the JavaScript engine miniSphere uses since 5.0) is Windows 7 SP1 so there's probably no hope of getting miniSphere to run on that machine, unfortunately. :(
12
Game Development / Re: The Screenshot Thread
It'll be neat to see something using vector graphics, I think.  You didn't see much of that with Sphere v1 because the API just wasn't designed for it.  The v2 Shape class is a perfect fit for that, though. :D
13
Game Development / Re: The Screenshot Thread
Quote
SSj Blue

It makes me happy to see this banner :)

Kind of off-topic, I notice it says "60 fps" instead of "60/60 fps", which means you have Sphere.frameRate set to infinity or else are using the Sphere v1 API without calling SetFrameRate (presumably you're FPS-locked by your graphics driver hence why it stays at 60).  I don't recommend doing this as it will max out a CPU core and kill battery life on laptops.  If you set a specific framerate the engine will be more friendly to the CPU and background programs :P
14
Engine Development / Re: miniSphere 5.2.5
5.2.5 is up as a hotfix for a regression that prevented miniSphere 5.2.4 from being able to run standalone .js and .mjs scripts (it would show an unsupported API level error and quit).  Sorry about that!
15
Engine Development / Re: miniSphere 5.2.4
miniSphere 5.2.4, 5.1.4 and 5.0.2 are up.  I did a simultaneous release across three minor versions to bring the API back into parity, since backward compatibility had drifted due to important bug fixes (for example 5.0 didn't support index.mjs) and the recent addition of system-directory packaging.  Now if you target API level 1 and the game works properly with --retro it is also guaranteed to work in miniSphere 5.0 (which notably is the last 32-bit version), as it should be.

No functional changes in 5.2.4 other than to drop the reported API level back down to 1.  Since I updated 5.1 to realign the level 1 API, the premature freeze mentioned above is no longer necessary.

5.0.2 and 5.1.4 are available on either the miniSphere GitHub Releases page or the Downloads Drive, if anyone needs them.