Skip to main content


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 - Beaker

Engine Development / Re: miniSphere 4.5.9
It's a problem with drawZoomedText.  Using drawText will render correctly with the semi-transparent pixels, but drawZoomedText with zoom set to 2 or 1 will not draw them.

Code: [Select]

// main.js automatically generated by Sphere Studio
// Vanilla compiler plugin
font1 = LoadFont("main.rfn");
font2 = LoadFont("main.rfn");
var c = CreateColor(255,0,128,255)


function game()
var txt = "SeT GQwWoO!";
while (true)
font1.drawZoomedText(0,0,2,txt);//renders without alpha
font2.drawZoomedText(0,20,2,txt);// ..

font1.drawZoomedText(0,40,1,txt);//also renders without alpha
font2.drawZoomedText(0,60,1, txt);// ...

font1.drawText(0,80,txt);//Render correctly
font2.drawText(0,100, txt);// ..


Engine Development / Re: miniSphere 4.5.9

There indeed shouldn't be much effort needed to migrate - almost all of the Sphere 1.5 API is implemented.  I tried to make it as painless as possible to phase in the new features too - in large part you can mix Sphere v1 and v2 functions freely (objects are not interchangeable, however).

There's really only a handful of stuff that's not implemented, mostly some esoteric APIs like Complex() and a few surface blend modes (because they're impossible to implement with the OpenGL fixed-function pipeline), but otherwise everything should work correctly.  There shouldn't be any issues with fonts though; what kind of bugs did you encounter there?

In the case of the font, it seems to either switch to a default font instead of the font loaded, or just not draw the transparencies of the font.  As far as I can remember, the only special things done to the font was possibly a color mask and doing the zoomblits.  In the case of the images, it seemed to be transparencies with zoomblits (basically, everything is a zoomblit).  Doing a quick re-look, I can't find the transparency with images problem, but I found a new bug wherein the restart(); function doesn't seem to reread the .sgm file like Sphere 1 does.  Sort of.  The first restart to change resolution works well enough (it doesn't work the same with the 320x240 option, but I assume that was deliberate), but the later restarts which were added to get around out-of-memory issues of (hopefully) yesteryear cause the engine to restart at the options menu instead of going to where it left off.

I also noticed some other differences as well with I think off-by-one pixels when drawing lines of text character by character vs drawing all the characters at once (a bit hard to explain, I'll have to send you a demo to explain that one).  When I finish the rest of the game, I can move over into doing the port fully, and give you a comprehensive list of the things I find.

In terms of the fonts, here's some screenshots:


Engine Development / Re: miniSphere 4.5.9
I'm in the process of porting The Rainis Manuscript over to miniSphere.  It seems very little is actually needed to get it to run, but I have noticed a few graphical bugs involving transparencies and fonts.  It's been a few months since I ran it last since I'm still working on the game proper, but I could try it again if these are not known issues.
Game Development / Re: The Screenshot Thread
A lot of the new battle engine is done, so I started working on some tutorials and redoing some of the intro graphics.  Decided to practice imitating an early 90's vga style.

Game Development / Re: The Screenshot Thread

All scenes done, but the battle engine has to be updated to make it more compelling, as well as a lot of polishing here and there.  Still, good progress.
Sphere General / Re: The Sphere 1.x API is enormous
Yeah, back in 2004 I noticed how long the api was when I was making the python demo for sphere.   But still, 5k lines is not unexpected, the ika source code for the script extension also takes up 5k lines as well, but in their case, it's split up over multiple files. 

As time goes on more and more apis need to be created, that's just to be expected.  The source for script.cpp in sphere v0.75 was only 46k.
Programming / Re: Colliding a Sphere with a Plane

I should note that while translating this code to JS, I did make an error (now fixed) in the plane_d function.

No, this code is still wrong.  As I said, plane_d is returning a VECTOR and it's assigned to this.d.  It doesn't make sense to add point.x+point.y+point.z+this.d. 

Which also explains the plane's equation in a different way. The D is actually the distance of the plane as it intersects a normal vector from the origin. Which makes sense, since if you plug the origin back into the equation, you just get D...the distance between the point you plugged in and the plane.

Edit: I've removed this comment, it was mainly about being careful of the normal vector being a unit vector as well, which is not generally assumed for normal vectors.

Regardless, this fact for a plane equation is easily derivable from projections which are a lot less complicated than you think they are:

a, b vectors
<a,b> = a.x*b.x+a.y*b.y+a.z*b.z
|a| = root(a.x*a.x+a.y*a.y+a.z*a.z)

<a,b> = |a|*|b| cos(angle between vectors a and b)

So, the projection of a onto b, if b is a unit vector is <a,b> in the direction of b, hence <a,b> is the value of a_1 in this diagram

So, once you know that, it's a lot easier to derive the correct answer involving the dot product <a,b> (what you've written as point.x+point.y+point.z) and d. 
Programming / Re: Colliding a Sphere with a Plane
During your whole derivation, you didn't mention projections once, which is the obvious tool to use to get the answer here.  In the case that the plane goes through the origin, project the sphere center onto a unit normal of the  plane, then compare the length of this vector to the spheres radius.  In the case the plane doesn't go through the origin, subtract off any vector in the plane from the sphere center and do the same process.  This should give your final result without any guesswork.

Some corrections to your code: the multiply function makes no sense.  At no point is coordinate-wise vector multiplication a good function to define in linear algebra.  What you should be defining is the dot product instead, which is what you use anyway when you do point.x+point.y+point.z. 

Speaking of which, how does that final answer make any sense if this.d is defined as plane_d(this.normal,a), which returns a vector, while in the final answer is the sum of three numbers and that vector?

As homework, go to, read it all, and then solve the problem again using dot products and projects.  Also to increase your understanding, write a 2d version for circles and lines since the cross product is not defined in two dimensions, so you'll have to find the normal in a more general way.
Game Development / GaMc

GaMcis a metroidvania puzzle platformer made during TOJam 11.  Grab blocks, jump around and solve the puzzles to unlock all the switches to the end.  For the adventurous, find all the golden treasure goats to get to the secret end room, but be warned, you better be ready to glitch the game out to make it there...

It's a pretty short game.  Getting to the end should be reasonably ok if you explore the full map.  Getting all the treasures should be pretty hard since you have to abuse a few different glitches in the process, so good luck!

Also, as a side note, while I was testing this game after the jam, I noticed that on some screens the game would update normally, but the screen just wouldn't flip correctly.  It would appear to lag and chop excessively, but the game would still be playing normally, I just couldn't see it.  It seems like that problem was fixed after changing the draw/update loop:

Code: [Select]

while (true)
    while (GetTime()-last_time < frame_time);
while (true)
    while (GetTime()-last_time < frame_time)
        FlipScreen();//without this line it would still chop.

Got into this problem on both 1.4 and 1.5 of the engine and open_gl.  Didn't try it out on earlier versions.
Both The Particle of Infinite Free Will as well as RTD:E had code to contain the mouse's position inside the window.  In the case of RTD:E it was optional but if enabled allowed for mouse sensitivity to be configurable.  Since RTD:E used a modified executable, it also had access to check if the sphere window was in focus, so unlike TPIFW, if you managed to click outside the window, then the game would detect that and pause the game while letting go of the mouse, which made the mouse capturing more reasonable.
Game Development / Re: Rouge Rogue Rabbit Puncher

I ended up just walking past the mid-boss, but the ending is great.

Super cool to see a new beaker game in 2015.

Walking pass bosses is an underrated option in games. :)

I was actually hoping to release another game in 2015, but it'll probably be next year instead.  Much like it was for RRRP, soundtracks can take a long time.

Speaking of new games though, have you been able to work on new stuff?
Editor Development / Re: Tileset editing bug
First and foremost, I've tried Sphere Studio and I don't like it.  One thing I've always liked about Aegis was that he was very keen on UI/UX, and he did a good job on the editor.  Sphere Studio's layout is much more restrictive than the windowed approach in the Vanilla editor.

In terms of the bug, I've found that these bugs don't happen in v1.4, so if all else fails I can use that version.  Looking at the memory usage, in v1.4 when I draw a line it seems to allocate a new image's worth of memory (eg: for a 2x2 tile box, it would create 4*16*16*4 = 4k, no extra memory when only one tile is selected), and then with the next line, it'll allocate another 4k of memory and so on, until I select a new tileset rectangle, at which point that allocated memory will be deallocated.  However, in v1.5, while the extra memory is still allocated for each pixel edit (line, pencil, etc.), after changing the tile rectangle, the extra memory is freed.  As well, if I stay on a single tileset rectangle in v1.4 and keep modifying it, I can easily get to 100mbs of memory, and then free it down to 4mbs, but in v1.5, the crash starts happening at around 20mbs of allocated memory.

For the tile insert, it literally happens every single time I try to insert a tile or image/frame in a spriteset.  There's no randomness to it all.
Editor Development / Tileset editing bug
Hello all.

I've been doing a bit more work in sphere lately, and a bug that's been around for a while now is starting to... bug me.

Specifically, I've often used the sphere map editor for pixel work, since I can use the tileset palette to select a rectangle of tiles and then edit those tiles in the tileset tab.  I've always preferred the sphere image editor, and using the map editor this way has been the best method I've found for larger images.  However, in v1.5 or 1.4 of the editor, doing this over and over again (selecting a rectangle in the tileset, working on it, selecting a new rectangle, and so on), first causes the Sphere IDE menus to draw black, and then eventually cause the IDE to stop responding.  As well, in these version the insert tile in the tileset and insert frame/direction/sprite in the spriteset editor cause a crash immediately.

Has anyone looked into these issues before?
Game Development / Rouge Rogue Rabbit Puncher
Rouge Rogue Rabbit Puncher

RRRP is a rogue-like where you explore 10 levels of killer rabbits.  It's fairly simple, you punch rabbits.  Hope you enjoy it.

It was made during TOJam10 in April this year, but I wanted to add music and sound to the game, but never got around to it until now.

You can download it from the site:

Game Development / Entropy and Schroden
TOJam 9 has just finished, so I'm posting my game from that jam here.  First though, I haven't posted anything on Spherical from the previous one.


Game page

Entropy is a puzzle game where the player has to get past a computer overlord that is able to detect the entropy of the player's actions relative to the non-playable characters in the game.  This computer overlord has trapped the world inside an Atari 2600 simulation, and you must get to the blue colored column of pixels that are supposed to represent a river in order to complete a desperate plan to save the world.

Every time the player completes a level, the computer overlord will try to find a highly entropic property of the player's movement (for example: x-position, speed, etc.), and from then on, it will start measuring this property of the dots in the system.  If the player's values becomes too different from that of the other dots in the system, then the computer will discover this and the player will lose.  If on the other hand, the computer is unable to find something entropic in the players actions, then it will increase its accuracy in measuring the said properties, making it harder for the player to reach the end goal.

Made at TOJam 8.


Game page

Schroden is a minimalistic puzzle platformer, where the main character, Schroden, is both alive and dead.  You control both the alive Schroden, as well as his ghost, and when the alive Schroden dies, he becomes a ghost and his ghost comes back to life. 

It's a short game, with 6 screens, but the last one is quite a difficult one to figure out.  Made at TOJam 9.

A final note about Schroden, it was designed at 320x180, and uses 4x scaling to bring it up to 1280x720, but since it uses the map engine, it needed to use 2x layer sizes for the drawn layers, but when it's drawn out, there's overlap in the coordinates of the tiles (likely inconsistent rounding errors).  This is why the shadows (in particular), form 1 pixel wide double opaque boxes inside them.