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
16
Good to know. When I'm further along the development process for TRM, I'll send you a release to help debug some more issues.
17
I went "woah..." the second the image loaded. Impressive work.
When I started making the images for the first battle tutorial, I noticed that they had a bit of a msdos style to them. I started on some bigger images and it seems the key takeaways to the style is realistic proportions and colors, grit, and extra use of grays and browns... at least for the style I'm interested in.
The style seems easier to do, but also takes way longer than more modern styles it seems.
18
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.
https://rpgmaker.net/users/Beaker/locker/main.rfn
https://rpgmaker.net/users/Beaker/locker/main.rfn
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)
font2.setColorMask(c);
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);// ..
FlipScreen();
}
}
19
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:
Sphere:
miniSphere:
20
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.
21
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.
22
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.
23
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.
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.
24
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 https://upload.wikimedia.org/wikipedia/commons/thumb/9/98/Projection_and_rejection.png/200px-Projection_and_rejection.png
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.
25
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 https://en.wikipedia.org/wiki/Vector_projection, 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.
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 https://en.wikipedia.org/wiki/Vector_projection, 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.
26
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:
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.
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]
//From
while (true)
{
drawMap();
FlipScreen();
UpdateEntities();
while (GetTime()-last_time < frame_time);
}
//To
while (true)
{
drawMap();
FlipScreen();
UpdateEntities();
while (GetTime()-last_time < frame_time)
{
drawMap();
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.
27
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.
28
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?
29
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.
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.
30
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?
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?